chocokeki

modprobe -D snd_hda_codec_realtek

insmod /lib/modules/4.5.0/kernel/sound/soundcore.ko 

insmod /lib/modules/4.5.0/kernel/sound/core/snd.ko 

insmod /lib/modules/4.5.0/kernel/sound/core/snd-timer.ko 

insmod /lib/modules/4.5.0/kernel/sound/core/snd-pcm.ko 

insmod /lib/modules/4.5.0/kernel/sound/core/snd-hwdep.ko 

insmod /lib/modules/4.5.0/kernel/sound/hda/snd-hda-core.ko 

insmod /lib/modules/4.5.0/kernel/sound/pci/hda/snd-hda-codec.ko 

insmod /lib/modules/4.5.0/kernel/sound/pci/hda/snd-hda-codec-generic.ko 

insmod /lib/modules/4.5.0/kernel/sound/pci/hda/snd-hda-codec-realtek.ko 

이런 상황이었다

나는 마지막 파일명만 알고 싶었다

awk를 쓰려 했으나 /로 파싱한 뒤 필드 수가 일정하지 않아서 문제였다

modprobe -D snd_hda_codec_realtek | rev | cut -d '/' -f1 | rev

soundcore.ko 

snd.ko 

snd-timer.ko 

snd-pcm.ko 

snd-hwdep.ko 

snd-hda-core.ko 

snd-hda-codec.ko 

snd-hda-codec-generic.ko 

snd-hda-codec-realtek.ko 

결국 하긴 했는데 뭔가 개운치 않다 rev도 두번이나 들어가고

음......;;

안드로이드에서 와이파이 연결 되어 있긴 한데 비밀번호를 잊어버린 상황일 때 비번 찾는법

루팅이 되어 있다는 가정 하에

adb shell

su root

휴대폰 화면에서 root 권한 허용창이 저절로 뜨면 ok

cd /data/misc/wifi

cat wpa_supplicant.conf

하면 psk="비번"

이런식으로 뜹니다

롤리팝 - 3.4 kernel 에서 확인

혹은 root explorer 같은거 다운 받아서 /data/misc/wifi 에 직접 가셔서 wpa_supplicant.conf 파일을 텍스트뷰어로 열어서 확인해도 됩니다

루팅 없이 하는법?

이건 일종의 취약점일 수도 있기에 허용하지 않는듯 싶네요

컴터로 휴대폰을 백업해서 그걸 또 풀고 복잡하게 하면 되기도 하는거 같은데 여기서는 다루지 않겠습니다

창이 그냥 홱 닫혀 버리고 가만히 있어도 실행이 안될 때

-> jdk 1.8 이상 설치하면 됩니다

1.7은 android.bat 파일에 직접 java 위치 설정해줘도 안되더군요

고객님 손가락 관절 보호를 위해 url까지 겁니다

http://www.oracle.com/technetwork/java/javase/downloads/index.html

마쉬멜로 소스를 받으려는데 mr1이 있고 mr1-eas가 있어서 뭐로 받아야할지 궁금해서 찾아보다가 신기한걸 찾아서 정리해보았다

참고 링크

(http://www.linaro.org/blog/core-dump/energy-aware-scheduling-eas-project/)

깊은 지식 없이 바로 찾아서 정리했기 때문에 틀린 내용이 많을 수 있다

scheduler - OS에서 돌아가는 여러 프로세스들의 실행 우선 순위를 결정 배분

cpu를 어느 순간의 시간동안 어떤 프로그램이 돌게 할지 정하며 시스템 목적에 따라 여러가지 정책이 있다

예시#1 - cpu연산이 별로 필요 없는 카톡(순위 낮음), cpu연산이 무지막지 필요한 게임(순위 높음)

예시#2 - cpu연산은 조금하고 외부 장치 i/o를 많이 하는 프로그램(순위 낮음), 

            cpu연산이 주되고 외부 장치 i/o는 드문 프로그램(순위 높음)

          -> i/o 시간은 cpu가 연산하는 비해 상대적으로 엄청나게 느리기 때문에 i/o를 기다리는 동안

 스케쥴러는 다른 프로세스에게 cpu 사용을 넘기도록 한다(task scheduling)

governor - 유휴 상태(cpuidle)나 활성화 상태(cpufreq)에 진입하도록 결정하는 정책이다

cpu frequency, voltage를 scaling하며 이를 통해 퍼포먼스와 베터리 소모량을 조절할 수 있다

예를 들어서 cpufreq의 여러 governor중에 Interactive governor를 설명하면

latency를 중요시 하는 디자인으로 설계 되었으며 cpu에 걸리는 부하에 따라 적당히 cpu 클럭 속도를 조절하도록 되어있다

cpu에 걸리는 부하는 짧은 시간동안 얼마나 사용하는지 샘플링을 하는데 이 비율(샘플링 레이트) 역시 중요하다

스케쥴러는 작업량이나 i/o 대기, 우선 순위 등에 따라 적당히 cpufreq와 cpuidle subsystem으로 프로세스들이 공평하게 cpu를 쓸 수 있도록 한다(위의 그림 참고)

즉 스케쥴러는 cpu에 균등하게 부하가 걸리도록 노력을 하지만 전력 소모에 대한 고려는 하지 않아 문제가 된다

위 그림을 참고로 스케쥴러 하부의 cpufreq, cpuidle subsystem은 각각 cpu 속도를 늦추거나 idle하게 만드는 식으로 각자 전력을 아끼기 위해 노력한다

CPUIdle

the menu governor

CPUFreq

Interactive governor

CPUFreq?

CPU Driver로 cpu frequency, voltage scaling을 통해 실시간으로 clock 속도를 조절할 수 있음

별건 아니고 그냥 참고

문제는 이러한 스케쥴러의 코드는 모든 cpu코어가 동일한 구조와 전력소모, 성능을 가지고 있다는 가정 하에 즉 데스크탑 cpu 구조 기반으로 작성되어 있다는 점이다

요즘 휴대폰에서 많이 사용되는 cpu 구조인 ARM의 big.LITTLE 를 예로 들자

이 구조는 적은 연산이 필요할 경우 느리지만 적은 전력을 소모하는 코어(LITTLE)를 계산량이 많이 필요할 때는 고성능 big 코어를 사용한다

이들의 코어에 동일한 부하를 50%씩 준다고 가정하면 스케쥴러 입장에서는 균등히 부하를 나눠주므로 매우 일을 잘하고 있다고 생각하지만 실제로는 LITTLE코어와 big 코어의 전력 사용량이 다르므로 최적의 전력소모 상태는 아니라고 할 수 있다

PM(Power Management) subsystem은 가버너에 휴리스틱 알고리즘이 있어 성능에 영향없이 cpu가 전력을 절약할 수 있는 최적의 시간을 예측한다

이 휴리스틱 루틴은 현재의 cpu 활용정도를 측정하기 위해서 그들이 소유한 수단을 사용한다 그리고 시스템의 변화에 반응하기 위해 반드시 여러번 수행되어야 한다

게다가 스케쥴러는 SoC의 power topology에 대한 어떠한 배경 지식 없이 설계 되었기 때문에 task 스케쥴링을 통해 지속적으로 휴리스틱의 예측을 깨뜨린다

(뭔가 내용이 이상한데? 게다가??? 그러나가 아니라??)

번역하기 싫다

대충 핵심은 task들의 cpu 부하나 i/o wait같은 것들을 파악하기 위한 최고의 위치는 스케쥴러라는 것

A key observation here is that the scheduler is the best place to know about past, current and immediate-future utilisation of the CPU since it controls where to place various tasks. 

So we could, in theory, scale the frequency of the source and destination CPUs (decrease and increase them respectively) during a task migration from one CPU to another. 

Similarly, the scheduler could arrange for tasks to be scheduled on fewer CPUs, thereby allowing the remaining CPUs to be shut-off to save power. Developers could become more proactive in their ability to take advantage of smarter task scheduling to save energy.

키 이슈들

1. 스케쥴러는 SoC의 power topology의 어떠한 관념도 가지고 있지 않다

task를 어떤 core에서 돌릴껀지 현재의 스케쥴링에 사용되는 휴리스틱 기법보다 더 나은 기법을 사용하도록 만들어야 한다

(대충 이런 의미 일 것이라고 추정중 ㅈㅅ합니다 영어 못하는데 설쳐서)

2. 스케쥴러와 PM 프레임워크의 통합을 하는 동안 기존 리눅스 커널에 작성된 cpu는 동일하다는 가정이 담긴 코드들을 고치는 중이다 

그래서 big.LITTLE 시스템에서 더욱 포괄적으로 잘 동작하도록 만들었다(heterogeneous multi-processing) 

컴퓨터에 들어가는 x86 cpu는 멀티코어라도 모든 코어가 동일한 스펙이므로 상관 없지만

요즘 휴대폰에 들어가는 arm 계열 cpu는 big.LITTLE 구조로 빠른 동작 코어와 느린 코어가 하나의 cpu에 같이 들어있는 

즉 코어의 종류에 따라 전력 소모가 틀린 구조에 대한 고려가 없다 아마도 이런 이야기인거 같다

3. CPUIdle-scheduler 통합에 2가지 진행중인 작업이 있다

a. CPUIdle과 스케쥴러 안에서 idle task의 더욱 긴밀한 통합

(Tighter integration of the idle task in the scheduler with CPUIdle)

b. CPUIdle core의 간소화와 idle path의 추척 용이성 향상

menu governor 교체: performance multiplier 같은 다음 wakeup 이벤트를 예측하기 위해 메뉴 가버너를 사용하는 몇몇의 휴리스틱들은 

다른 시스템에서 그닥 잘 동작하지 않는 단지 x86 시스템들에서 계산된 매직넘버일 뿐이다

static inline int performance_multiplier(void)

{

int mult = 1; //default;

mult += 2 * get_loadavg();

mult += 10 * nr_iowait_cpu();

return mult;

}

이런식의 2 * 평균로드값, 10 * io wait cpu수 를 매직넘버라고 의미하는듯

왜 2인지 10인지 모르니까 ㅎㅎ

새로운 IO latency tracking framework 을 통해 다음 IO 이벤트에 대한 예측을 더 효율적으로 하여 기존 메뉴가버너 보다 낫게 하였고 task-specific에서 device-specific으로 latency가 추적 되도록 노력했다

(아무래도 모바일 플랫폼이 기존 x86 시스템 보다는 i/o 가 더 중요해서 그런 것 같다

 워낙 개별 모듈로 분리된 입력 장치들이 많고 각각 파트별 전력 소모, latency가 다르니 말이다)

4. CPUFreq 그리고 스케쥴러를 더 잘 통합하기 위해 cpu type에 따라 서로 다른 작업 부하를 주도록 고쳐야 했다

(big.LITTLE 같은)

예를 들어 500Mhz core의 20% 부하 = 100Mhz 는 1Ghz core의 10% 부하와 같다

이하 Scheduler-driven DVFS라든가 등등 내용 생략

*** DVFS(dynamic voltage and frequency switching ) 

전력인가량에 따라 클럭 속도를 바꿀 수 있는 그런거

cpu에 국한된게 아니라 ram, pci-e, vga 등의 제어도 가능하다고 한다

5. 그런거 없다

그래서 바꿨답디다

결과 

1. 전력 소모 감소 그리고 퍼포먼스 강화에 스케쥴러를 최적화 함

2. big.LITTLE 시스템에서도 정확하게 스케쥴링 된다

3. SMP 시스템에서 PM의 성능 향상이 있음

4. 온도 관리를 위한 메카니즘을 제공함

기타 참고 url

http://lwn.net/Articles/602479/

https://www.linaro.org/blog/core-dump/summary-energy-aware-scheduling-workshop-linux-kernel-summit-2014/

기타 참고 내용

drivers/cpufreq/arm_big_little_dt.c 

big.LITTLE CPUFreq Interface driver

bL platform driver로 아래의 bL_cpufreq_register를 호출한다

drivers/cpufreq/arm_big_little.c

cpufreq_register_driver()를 호출해서 cpufreq_driver structure를 CPUFreq core에 등록하도록 한다

1줄 요약

스케쥴러를 모바일 환경에 맞게 개선함

레퍼런스 문서

http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf

각 block 내용 및 W[64]의 내용들이 자세하게 나와있음

http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA256.pdf

위와 비슷한 정보 

http://www.iwar.org.uk/comsec/resources/cipher/sha256-384-512.pdf

sha256은 hash 함수의 일종이다

hash 함수라는게 뭐냐면 다 알고 있겠지만 간단히 설명해보겠다

y = x + 2 이런 함수는 y를 알면 x도 알 수 있다

하지만 y = hash(x) 이런 해쉬 함수는 y를 알아도 x를 알 수 없는게 특징이다

그리고 모든 x값에 대해 각기 다른 y값을 내뱉는 특징 때문에 x가 원본임을 증명하는 일종의 시그니쳐로도 사용할 수 있다

(정확하게 말하자면 hash 함수는 단사함수가 아니다. hash collision이 있어서 다른 x임에도 같은 y값이 나오는 경우도 있다.

 hash collision을 피하기 위해선 계산을 더 복잡하게 하면 된다. 적당한 기회 비용을 두고 밀당을 해야한다는 소리)

hash 결과값은 32bit 8개를 병렬로 늘어놓은 값 

32bit x 8 = 256bit 그래서 이름이 sha256이다

원본 메세지의 각 문자(ascii 8bit)를 적당히 잘라 붙이고 쉬프트하고 and, or 등등 해서 512bit 단위의 블럭으로 만들고 이를 볶고 지져 hash를 계산한다

512bit 블럭으로 만들기 위해 크면 자르고(parsing) 모자라면 붙인다(padding)

아래의 공식에 맞춰 hash 계산에 필요한 블럭을 만든다

L + 1 + k = 448mod512

L(data length)는 hash를 만들고 싶은 원본 message의 bit길이 이므로 무조건 8의 배수이다

구현할 때 447bit 이런거 머리 빠지게 고민할 필요 없다

그리고 중요한 정보 - little endian을 기준으로 동작하도록 설계되어있다

x86, arm을 보통 사용하는 우리는 짜증나는 endian 전환을 해야 한다

실제 구현 관련 정리 - 블럭 제작 방법 및 hash 계산 방법

hash 계산 및 업데이트

간단하므로 생략, fips 문서에 나온데로 4개의 절차를 수행하면 된다(복잡해 보이는 시그마 같은거 다 문서에 잘 정의 되어있다)

메세지 길이 = len

case 1. len < 56(448bit)

마지막에 1bit를 추가하고 448bit까지 0으로 채움

그리고 마지막 64bit는 총 메세지 길이(lenx8)를 기록한다

hash 계산, 업데이트

case 2. 56 <= len < 64

마지막에 1bit를 추가하고 512bit까지 0으로 채워 block을 만든다

그리고 hash를 계산, 업데이트 한다

그리고 448bit까지 모두 0으로 채우고 마지막 64bit를 총 메세지 길이(lenx8)를 기록한다

그리고 hash 계산, 업데이트

case 3. len >= 64(512bit 이상)

512bit 씩 block으로 잘라 hash 계산, 업데이트 한다

마지막 남는 메세지는 길이에 따라 case1 혹은 case2와 동일하게 진행

last

계산한 32bit 8개의 값을 나열하면 sha256 완성

기타 유용한 참고 소스 코드

kernel 에 포함된 sha....코드.......이해하기 너무 어려움

openssl 의 crypto/sha에 있는 코드들 추천, 다만 최적화 되어있는 부분은 이해하기 힘듬

https://github.com/b-con/crypto-algorithms 매우 추천 깔끔하게 정리 되어있음

gunzip initrd.img

gzip: initrd.img: unknown suffix -- ignored

-> mv initrd.img initrd.img.gz

gunzip initrd.img.gz

어이 없게도 확장자를 바꿔야한다

확장자를 mv 명령어를 통해 .gz로 바꿔주면 쉽게 해결된다

-f나 --suffix 옵션 안 먹힌다 -.-;;

1. 키 스케쥴링

비슷한데 좀 다르다

암호화 할 때랑 동일하게 계산하는데 사용하는 순서는 반대다

암호화 할 때 마지막에 사용한 key == 복호화 할 때 처음 사용하는 key

복호화 할 때 마지막에 사용한 key == 암호화 할 때 처음 사용하는 key

혹시나 해서 적는데 동일한 SBOX를 사용한다

2. init round

동일하게 add round key를 하는데 key scheduling해서 얻은 마지막 키부터 거꾸로 사용한다

3. inverted shift rows

반대로 쉬프트 한다

inverted sub bytes

inverted sbox 에서 가져와 치환한다(inverted sbox라는 배열이 별도로 있다)

add round key

이건 변한거 없다

inverted mix columns

역행렬을 구하는, 즉 행렬곱 연산을 하는건데 연산꺼리가 훨씬 늘어났다

이거도 그냥 미리 계산된 배열에서 찾아서 쓰면 된다

4. final round

마지막에 사용하는 round key 값은 순수한 암호키다

이하 생략

최적화

cpu가 aes가속을 지원하면 어셈블리로 짜서 써도 좋고 그게 아니라면

L, E table에서 곱연산 찾아오는 것도 있고 아니면 0xb, 0xd, 0x9, 0xe, 0x2, 0x3 행렬곱 연산을 미리 계산한거 가져다가 쓸 수도 있다

그 외 register 크기인 32bit 씩 가져다가 한 번에 처리하는 방법도 있고

값 swap 할 때 xor로 swap하는 거나 rotate 최적화 등등

자세한건 openssl 소스 중에 crypto/aes/aes_core.c (맞나?)을 참조해서 분석해보면 좋을 것이다

난 머리가 나빠서 이해를 못하겠따 ㅋㅋ

linux device driver 4판이 연기에 연기를 반복하다 드디어 출간하는 듯 하다

Pre-order 가격 56.99 달러

http://www.amazon.com/gp/product/1449371612/ref=pe_11480_166765280_emwa_email_title_1

무려 10년이 넘은 후에 4판이 나오는구나

그런데 문제가 Nov 25, 2016..................

어라? 작년에도 연말에 나온다카지 않았냐? 혹시 또 뻥치는거 아님?

듀크뉴켐포에버 스멜이 풀풀난다

포에버는 출시 했으니 아닌가

이하는 아마존 원문

Having already helped two generations of programmers explore Linux and write devices, the fourth edition of this classic book delves into tty, USB, and HCI devices such as keyboards, in addition to basic character devices. Linux Device Drivers includes numerous full-featured examples that you can compile and run without special hardware.

Written by well-known leaders in Linux development and programming, this book covers significant changes to Version 3.2 of the Linux kernel, the basis of the Precise Pangolin release of Ubuntu. All you need to get started is an understanding of the C programming language and some background in Unix system calls.

• Learn how to support computer peripherals under the Linux operating system
• Develop and write software for new hardware that Linux supports
• Understand the basics of Linux operation, even if you don't expect to write a driver
• Dive into new chapters on video, audio, wireless, and Bluetooth devices

As the operating system for Android and many embedded systems, Linux constantly needs new device drivers. This book helps you get it done.

Device Drivers -> USB support -> USB Gadget Support -> USB Gadget Drivers -> Ethernet Gadget

비글본 블랙 환경구성하느라 별의 별 미친짓을 다 해봤는데 가장 깔끔한 구성은 

debian + linux-3.14.41-ti-r63 kernel 이 조합이었다

https://github.com/beagleboard/linux/tree/3.14

지금은 리비전이 꽤 올라갔을꺼다

debian은 8.1 jessie 괜찮았다 apt도 계속 업데이트 되고 안정성도 아주 만족스러웠다

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

위의 url 가면 지속적으로 업뎃해서 릴리즈 한다 ㅎㄷㄷ

지금은 8.2가 나와있다 그런데 다운 받을 때 eMMC 용인지 아니면 마이크로SD용인지 잘 확인해서 받을것

https://rcn-ee.com/rootfs/bb.org/testing

혹은 아래 항목

BeagleBoard-X15 weekly

Bug tracker: http://bugs.elinux.org/projects/beagleboard-x15

Flasher: (lxqt-4gb) (BeagleBoard-X15)

wget https://rcn-ee.com/rootfs/bb.org/testing/2016-01-10/lxqt-4gb/bbx15-eMMC-flasher-debian-8.2-lxqt-4gb-armhf-2016-01-10-4gb.img.xz
sha256sum: 6a8a4ae57c5c7c7b2248c4bc4fb4c4cd4d2a3d4be27ab8b961cf60b1f23c4b9d

microSD/Standalone: (lxqt-4gb) (BeagleBoard-X15)

wget https://rcn-ee.com/rootfs/bb.org/testing/2016-01-10/lxqt-4gb/bbx15-debian-8.2-lxqt-4gb-armhf-2016-01-10-4gb.img.xz
sha256sum: decfdebc9a8ea9d6e5bc39c491fb7cac2ff5076190ebbd43e8247ac94eedb864