블로그 이미지
No pain, no gain!
lepoussin

Tag

Notice

Recent Post

Recent Comment

Recent Trackback

Archive

calendar

1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
  • total
  • today
  • yesterday
03-29 19:02
2009. 7. 23. 00:51 Embedded System
AESOP S3C6410 보드의 경우 커널의 부트 아규먼트를 uBoot에서 커널로 넘겨줄 수 있습니다.
이외에 보드 환경 설정을 위한 다양한 환경 설정을 uBoot에서 지원 합니다.

따라서, 커널의 재 컴파일 작업이 없이도, 간단하게 커널의 부트 환경 설정을 변경할 수 있습니다.

1. NFS를 이용한 루트 파일 시스템 마운트 방법

최초로 이솝 보드를 받았을 때 NAND Flash에 루트 파일 시스템을 기록하기 위해서 또는 어플리케이션 등을 개발할 때는
NFS로 루트 파일 시스템을 마운트 하여 개발을 진행 합니다.

이 경우, uBoot의 명령 프롬포트에서 다음의 명령을 수행하면, NFS로 루트 파일 시스템을 마운트 합니다.
(해당 환경 설정을 수행하기 이전에, 호스트PC의 /nfsroot 디렉터리에 이솝 보드용 NFS 루트 파일 시스템이 있어야 합니다.)

setenv bootargs console=ttySAC0,115200 root=/dev/nfs rw nfsroot=[호스트PC의 IP주소]:/nfsroot/RootFS-aESOP6410 ip=[타깃 보드의 IP주소]:[호스트 PC의 IP주소]:[게이트 웨이 주소]:[서브넷 마스크]::eth0:off mem=128M ethaddr=[이더넷 컨트롤러의 MAC 주소]

saveenv => 환경 설정을 NAND Flash 저장

boot       => 적용한 환경 설정을 가지고 부팅

예)

setenv bootargs console=ttySAC0,115200 root=/dev/nfs rw nfsroot=192.168.1.15:/nfsroot/RootFS-aESOP6410 ip=192.168.1.85:192.168.1.15:192.168.1.1:255.255.255.0::eth0:off mem=128M ethaddr=00:40:5c:26:0a:5b

saveenv

boot

2. uBoot의 IP주소 설정 방법

uBoot에서 호스트 PC의 TFTP를 이용한 다운로드를 하기위한 IP 주소 설정은 다음과 같이 합니다.

setenv gatewayip [게이트 웨이 주소];setenv ipaddr [타깃 보드 IP주소];setenv serverip [호스트 PC IP주소]

saveenv => 환경 설정을 NAND Flash 저장

예)
setenv gatewayip 192.168.1.1;setenv ipaddr 192.168.1.100;setenv serverip 192.168.1.15

saveenv

3. TFTP를 이용하여 리눅스 커널 이미지를 다운로드 한 후 부팅

리눅스 커널 개발 시, 커널을 수정하면서 테스트가 필요할 경우 다음과 같이 옵션을 넣어주면,
이솝 보드는 TFTP를 통하여 리눅스 커널 이미지를 다운로드 받은 후 다운로드 받은 커널 이미지를 가지고 부팅을 수행 합니다.

setenv bootcmd tftp c0008000 zImage-aESOP6410\;bootm c0008000

saveenv => 환경 설정을 NAND Flash 저장

4. TFTP를 이용하여 커널을 다운로드 받고 NAND Flash에 기록

다음은 TFTP를 이용하여 리눅스 커널 이미지를 다운로드 받고, 자동으로 다운로드 받은 커널을 NAND Flash에
기록하는 명령 입니다.

tftp 0xc0008000 zImage-aESOP6410;nand erase 60000 200000;nand write 0xc0008000 60000 200000

5. NAND Flash에 저장된 커널로 자동 부팅

다음의 명령을 입력하면, 이솝 보드는 부팅 시 자동으로 NAND Flash에 기록된 커널을 읽어서 부팅을 수행 합니다.

setenv bootcmd nand read C0008000 60000 200000\;bootm C0008000

saveenv => 환경 설정을 NAND Flash 저장

6. TFTP를 이용하여 부트로더를 다운로드 받고 NAND Flash에 기록

부트로더가 수정되었거나, 교체가 필요할 경우 다음의 명령을 입력하면, 부트로더를 다운로드 받고 이것을
자동으로 NAND Flash에 기록 합니다.

tftp 0xc0008000 uBoot-aESOP6410.bin;nand write 0xc0008000 0 30000

7. NAND Flash에 저장된 루트 파일 시스템을 마운트 하여 부팅

루트 파일 시스템이 NAND Flah에 저장되어 있을 경우 부트로더에서 다음의 옵션을 입력하면, NAND Flash에
저장된 루트 파일 시스템을 마운트하여 부팅 합니다.

setenv bootargs root=/dev/mtdblock3 rootfstype=yaffs2 console=ttySAC0,115200

8. NAND Flash에 루트 파일 시스템을 기록하는 방법

제공 되는 이솝 보드용 NFS 루트 파일 시스템으로 부팅을 수행 한 후, 다음의 명령을 이용하여 NAND Flash에
루트 파일 시스템을 기록할 수 있습니다. (NAND Flash 기록된 루트 파일 시스템으로 부팅하려면 7번을 참조하세요.)

# NFS로 부팅한 리눅스 프롬포트에서 수행

flash_eraseall /dev/mtd3
tar -C /mnt/nand -xf ~/RootFS-aESOP6410.tar
sync
umount /mnt/nand

posted by lepoussin
2009. 7. 23. 00:25 Embedded System
커널에서 NFS로 파일시스템을 마운트 할 경우, 다음과 같은 메시지가 발생하여 부팅을 실패하는 경우가 많다.

nfs: server 192.168.1.15 not responding, still trying

위의 메시지 발생시, 커널의 부트 아규먼트에서 다음의 옵션을 추가해 주면 된다.

setenv bootargs root=/dev/nfs rw nfsroot=192.168.0.77:/opt/RootFS-aESOP6410,nolock,tcp,rwize=4096,wsize=4096 ip=192.168.0.102:192.168.0.77:192.168.0.1:255.255.255.0::eth0:off console=ttySAC0,115200n81 ethaddr=00:40:5c:26:0a:5c

posted by lepoussin
2009. 5. 3. 14:22 Embedded System/Embedded Linux

posted by lepoussin
2009. 5. 3. 14:08 Embedded System/Embedded Linux
임베디드 리눅스 시스템에서 플래시는 일반적으로 다음과 같은 용도로 사용된다.
  • 부트로더의 저장
  • OS(커널) 이미지의 저장
  • 응용 프로그램과 이들에서 이용하는 라이브러리
  • (설정 데이터를 포함한) 읽고 쓰기가 가능한 파일들
만약 시스템에 부트로더가 사용된다면 최소한 두 개의 파티션이 필요하다. 하나는 부트로더 정보를 저장하는 파티션으로 나머지 하나는 루트 파일 시스템을 저장할 것이다. 이러한 (플래시의) 구분은 플래시 맵으로 표현할 수 있다.

※ 출처 : ITC "임베디드 리눅스 시스템의 설계와 개발"
posted by lepoussin
2009. 5. 3. 11:40 Embedded System/Embedded Linux
하드웨어와 전원 관리
일반적으로 LCD 디스플레이 유닛이 시스템 내에서 가장 많은 전력을 소비하고, 그 다음으로는 프로세서, 그 다음으로는 사운드 카드, 메모리, 네트워크 카드 순으로 전력을 많이 소비한다. 이러한 장치들은 디바이스 드라이버는 전원 관리 기능을 고려하여 작성되어야 한다.

그 중에서 가장 중요한 CPU 전원 관리는 다음과 같은 사실들을 기초로 한다.
  • 프로세서의 전력 소비는 클록 주파수에 직접적으로 비례한다.
  • 프로세서의 전련 소비는 전압의 제곱에 직접적으로 비례한다.
최신의 임베디드용 프로세서들은 이 점을 고려하여 동적 주파수 조정(dynamic frequency scaling)동적 전압 조정(dynamic voltage scaling)이라는 두 가지 기능을 제공한다.

CPU가 제공하는 이러한 기능들은 일반적으로 OS가 시스템 부하에 따라 모드를 변경하도록 사용된다.
  • 아이들(idle) 모드
    • 여러 프로세서 클록들이 중지된 상태(주변 장치에 대한 클록은 살아 있음).
    • 임베디드 시스템은 보통 이벤트 기반의 시스템으로 구현되므로 프로세서는 대부분의 시간을 사용자나 외부 세계로부터 이벤트가 발생하기를 기다리는 데 소모한다. 프로세서가 사용자로부터 이벤트가 발생하기를 기다리며 아이들(idle) 모드에 있는 동안은 타이머 인터럽트 처리와 같은 시스템에 필요한 최소한의 태스크만이 동작하게 될 것이다.
  • 슬립(sleep) 모드
    • CPU와 대부분의 주변 장치에 대한 전원이 꺼진 상태
    • 최저의 전력을 소비하는 모드
운영체제는 전원 관리 프레임워크에서 매우 중요한 역할을 담당하며, 다음과 같은 기능을 수행한다.
  • 프로세서가 아이들 모드나 슬립 모드와 같은 여러 모드로 동작하도록 결정한다.
  • 시스템 부하에 따라 동적으로 주파수와 전압을 변경할 수 있는 기능을 제공해야 한다.
  • 여러 디바이스 드라이버에서 주변 장치의 절전 모드를 사용할 수 있도록 하는 드라이버 프레임워커를 제공해야 한다.
  • 특정 응용 프로그램에게 전원 관리 프레임워크를 제공해야 한다. 이 과정은 매우 중요한데, 각 임베디드 장치의 전원 요구사항은 각기 다르기 때문에 다양한 임베디드 장치에 적합한 전원 관리 정책을 OS 내에 구현하는 것은 매우 힘들다. 대신 OS는 단지 이러한 프레임워크를 구성해 주고, 응용 프로그램에서 전원 관리 정책을 구현하여, 각 장치에 맞도록 이 프레임워크를 설정할 수 있도록 하였다.
전원 관리 표준
리눅스가 지원하는 전원 관리 표준은 APM과 ACPI의 두 가지이다. 이 두 표준 모드 x86 아키텍처를 기반으로 하고 있다.
  • APM
    • 전원 관리에 관한 작업을 주로 BIOS에 의존하여 처리
    • BIOS에서 전원 관리 기능을 제어하는 방법에는 많은 단점이 존재
      • BIOS는 시스템의 부하를 키보드와 같은 IO 장치의 부하를 통해 판단하기 때문에, 시스템이 거대한 프로그램을 컴파일하는 경우와 같이 계산 위주의 작업들을 수행하는 중에도 키보드나 마우스 같은 장치를 사용하지 않고 있으면 시스템을 저전력 모드로 들어가게 하는 경우가 발생한다.
      • BIOS는 시스템의 부하를 오직 마더보드상에 존재하는 장치들을 통해서만 판단한다. 따라서 USB 버스에 연결된 장치의 경우 마더보드에 직접 연결되지 않았으므로 전원 관리 시스템과 연계되지 못한다.
      • APM은 BIOS에 의존적이며 각각의 BIOS는 고유한 제한사항 및 인터페이스(그리고 버그)들을 갖고 있으며 이 모든 것에 맞추기는 매우 힘들다.
  • ACPI
    • 대부분 전원 관리 작업을 OS에서 처리
    • BIOS에 의존하는 부분이 있지만 APM에 비해 그 정도가 매우 작다.
    • AML(ACPI Machine Language)이라는 인터프리터 언어를 통해 OS는 장치에 대한 세부적인 지식이 없어도 장치의 전원 관리를 적절히 수행
프로세서의 절전 모드 지원
전원 관리와 관련하여 리눅스 커널 내에서 가장 먼저 수행되는 일 중의 하나는 아이들 루프 내에서 프로세서를 아이들 모드로 전환하도록 하는 일이다.

전원 관리 표준의 사용은 x86 외의 플랫폼에서도 이용할 수 있는 인터페이스의 집합을 제공하며, 따라서 전원 관리용 응용 프로그램을 직접 이용할 수 있다. x86 외의 플랫폼에서 선택된 방법은 리눅스 커널을 수정하여 x86 BIOS에서 수행하는 작업들을 커널과 부트로더에서 제공하고, 이를 통해 APM/ACPI 형식의 인터페이스를 사용자 공간에 제공하는 것이다.

2.6 커널은 주파수 조정을 위한 통합 프레임워크를 제공한다. 이 프레임워크는 주파수 조정 기능을 지원하는 아키텍처상에서 동적으로 주파수를 변경하는 방법을 제공한다. 하지만 커널에서는 전원 관리에 대한 정책을 제공하지 않고, 이를 응용 프로그램에 넘겨 응용 프로그램이 프레임워크를 이용하여 주파수를 관리하도록 한다. 이것은 주파수 조정 정책이 시스템의 용도에 따라 달라지기 때문이다. 이를 위한 일반적인 솔루션은 구현하기가 불가능하며, 따라서 전원 관리 정책의 구현은 사용자 공간의 응용 프로그램이나 데몬(daemon)이 담당한다.

전원 관리를 위한 통합 드라이버 프레임워크
디바이스 드라이버는 전원 관리 소프트웨어의 중심을 이룬다. 디바이스 드라이버와 커널 내의 실제 전원 관리 소프트웨어를 분리해 놓았으며, 디바이스 드라이버는 전원 관리 기능을 사용하기 위해 자신을 커널을 등록해야 한다. 만약 디바이스 드라이버가 전원 관리 기능을 이용한다면, 장치가 동작하지 않을 때는 아무런 작업도 이루어지지 않도록 보장해야 한다.

전원 관리를 디바이스 드라이버 단에서 처리하도록 구현하는 데 있어 중요한 사항은 순서에 대한 문제이다. 어떤 장치가 다른 장치에 종속적으로 동작하는 경우에는 두 장치는 반드시 적절한 순서대로 전원 관리가 이루어져야 한다.

전원 관리 응용 프로그램
  • apmd 데몬
  • acpid 데몬
    • ACPI
    • /proc/acpi/event 파일을 감시하여 전원 관리에 관련된 이벤트가 발생할 경우 이를 처리하기 위한 프로그램을 실행
    • http://acpid.sf.net

※ 출처 : ITC "임베디드 리눅스 시스템 설계와 개발"
posted by lepoussin