[Linux:Kernel] Linux CPUFreq Core

이 문서의 저작권은 GPL License를 따릅니다(This document is released under the GPL license).

  리눅스(TM) 커널안의 CPU 동작속도와 전압 조절 코드 
        L i n u x    C P U F r e q
 C P U F r e q    C o r e
   Dominik Brodowski  <linux@brodo.de>
    David Kimdon <dwhedon@debian.org>
번역 : 양정석 <dasomoli@gmailREMOVETHIS.com>

   클럭 조정은 동작하고 있는 CPU의 클럭 속도를 바꿀 수 있게 합니다. 이 것은

    배터리 파워를 절약할 수 있는 좋은 방법입니다. 왜냐하면 클럭 속도가
   낮을수록 CPU가 소비하는 전력도 낮아지기 때문입니다.

    

차례:

—–

1.  CPUFreq 코어와 인터페이스

2.  CPUFreq 노티파이어(notifires)

1. 일반적인 정보

================

CPUFreq 코어 코드는 drivers/cpufreq/cpufreq.c 안에 있습니다. 이 cpufreq

코드는 CPUFreq 구조 드라이버(실제 주파수 전이를 수행하는 코드 조각)를

위한 표준화된 인터페이스, “노티파이어(notifires)”를 제공합니다. 이들은 정책 변경

(예를 들면, ACPI 같은 온도 모듈), 모든 동작 속도 변화(예를 들면,

타이밍 코드)의 알림을 필요로 하거나, 혹은 일정 속도 제한을 강제할 필요가

있는(예를 들면, ARM 아키텍처의 LCD 드라이버 같은) 디바이스 드라이버거나

혹은 커널의 다른 부분 입니다. 추가적으로, 커널 “상수” loops_per_jiffy는

여기 주파수 변경 상에서 업데이트 됩니다.

레퍼런스 카운트는 cpufreq 프로세서 드라이버가 코어와 함께 정확히

등록되었고, cpufreq_put_cpu가 호출되기 전까지 로딩되지 않을 것임을

확실하게 해주는 cpufreq_get_cpu와 cpufreq_put_cpu에 의해서 수행됩니다.

2. CPUFreq 노티파이어(notifires)

================================

CPUFreq 노티파이어는 표준 커널 노티파이어 인터페이스를 따릅니다.

노티파이어에 대한 자세한 사항은 linux/include/linux/notifire.h 를

보세요.

두가지 CPUFreq 노티파이어-정책 노티파이어와 전이 노티파이어-가 있습니다.

2.1 CPUFreq 정책 노티파이어

—————————

새 정책이 셋팅되려고 할 때 이것들이 알려집니다. 각 CPUFreq 정책 노티파이어는

정책의 전이 동안 세 번 호출 됩니다:

1.) CPUFREQ_ADJUST 동안 모든 CPUFreq 노티파이어는 이를 봐야 할 필요가 있다면

   그 제한 사항-온도에 대한 고려나 하드웨어 제한 사항-을 변경할 것입니다. 

2.) CPUFREQ_INCOMPATIBLE 동안 하드웨어 실패를 피하기 위한 변경들만 수행될

   것입니다.

3.) 그리고 CPUFREQ_NOFITY 동안 모든 노티파이어들은 새 정책-만약 두 하드웨어

   드라이버가 이 단계 전에 새 정책에 대해 동의하는데 실패했다면, 그 호환될 수

   없는 하드웨어는 꺼지고 사용자에게 이를 알릴 것입니다-을 알립니다.

이들 단계는 노티파이어의 두번째 인자로 지정됩니다.

세번째 인자, void * 포인터는 다섯 개의 값으로 구성된  cpufreq_policy 구조체를

가리킵니다: cpu, min, max, policy와 max_cpu_freq. min과 max는 새 정책의 

주파수의 상한과 하한 값(kHz) 을, policy는 새 정책, cpu는 영향을 미칠 CPU의

번호, 그리고 max_cpu_freq 는 최고로 지원하는 CPU 주파수입니다. 이 값은

정보 제공 목적으로만 주어집니다.

2.2 CPUFreq 전이 노티파이어

—————————

이 것들은 CPUFreq 드라이버가 CPU 코어 주파수를 바꿀 때와 이 변경이 어떤 외부

영향을 가질 때, 두 번 알려집니다.

두번째 인자는 이들 단계-CPUFREQ_PRECHANGE나 CPUFREQ_POSTCHANGE-를 지정합니다.

세번째 인자는 다음 값들을 가지는 cpufreq_freq 구조체입니다:

cpu
– 영향을 미치는 CPU 번호

old
– 이전 주파수

new
– 새 주파수

시스템이 suspend된 동안 cpufreq 코어가 주파수의 변경을 알아차리면,

이들 노티파이어는 두번째 인자로 CPUFREQ_RESUMECHANGE와 함께 호출됩니다.


 

국정원 대선 개입 의혹..

지난 대선 당시에도 국정원 여직원 사건의 경우, 말도 안되는 주장, 일들이 많았다고 생각한다.

지금도 하늘을 손바닥으로 가리려 하는가..

민주주의 국가의 근간을 흔드는 이 사건을, 그 세력을 도대체 어찌해야 하는가..

* 2013.06.28. 추가. 이걸 보고 뭐라고 해야 하는가.. 유형과 판단 이유에 주목해서 한번 보시라.
http://www.ohmynews.com/NWS_WEB/Event/nisre.aspx

update-alternatives

프로그램이 버전업 되거나 같은 이름으로 여러 다른 프로그램을 사용하고 싶을 때 다음과 같이 이용한다.

update-alternatives –install /usr/bin/<프로그램이름> <프로그램이름> <프로그램경로> 1
update-alternatives –config <프로그램이름>

예를 들면, 나는 p4v 가 계속 버전업될 때마다 다음과 같은 식으로 사용할 p4v 를 고른다.
사실 ln -s 와 같은 식으로 소프트 링크를 바꿔주는 것과 동일하다.

update-alternatives –install /usr/bin/p4v p4v /opt/p4v-어쩌고저쩌고/bin/p4v 1
update-alternatives –config p4v

[Linux] vmlinux -> Image

명령어만 덜렁 써놓기 뭐해서 설명을 덧붙인다.
가끔 undefined instrunction 예외가 날 때, 코드 메모리의 이상 여부를 확인해야 할 때가 있다.
커널은 알다시피 zImage를 Decompressed 하여 메모리상에 올린 후 실행하는데, 그 Decompressed Image가 Image 이다. Image는 커널의 빌드 과정에서 아래와 같이 objcopy를 이용해서 만든다. Makefile 을 참고해보면 알 수 있을 것이다. ARM의 경우는 arch/arm/boot/ 와 그 아래의 Makefile을 살펴보면 된다.
Android JB MR1의 경우 아래 경로의 prebuilt 된 툴체인을 사용한다.

prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-objcopy -O binary -R .comment -S vmlinux arch/arm/boot/Image

나온 Image를 Trace32로 실제 커널 메모리를 dump 해서 Binary Diff 해보면 메모리의 H/W적인 이상여부나 코드 메모리를 어디서 건드려서 깨지진 않았는지 확인해 볼 수 있다.
커널 프로그램이 물리메모리 0x40008000과 같은 주소에 로딩되므로, 특정 모듈이나 특정 루틴의 경우 objcopy로 걸러낸 후, 해당 주소의 프로그램을 실제 메모리에서 offset을 뺀 값으로 Image파일에서 찾아야 한다.

Windows에서는 HxD와 같은 툴로 Binary Diff 할 수 있다. Beyond compare를 써도 되고(근데 유료라는 점)…