2005. 9. 26. 11:01
uClinux 상에서 플래시 메모리 사용하기
저자: Greg Ungerer gerg_at_snapgear.com
번역: 김남형 namhyung_at_gmail.com
1 소개
2 플래시 메모리
3 시스템
4 부트 로더의 사용 여부
5 uClinux 커널의 블럭 디바이스 드라이버
6 루트 파일 시스템
7 플래시 메모리를 위한 도구들
8 예제
9 참고 문헌
1 소개 #
이 문서는 플래시 메모리를 사용하여 부팅하고 동작하는 uClinux 시스템을 구축하는 이론과 방법에 대해서 설명한다. 이 문서의 대부분은 프로세서에 독립적이다.
먼저 플래시 메모리에 대해서 간략히 소개하고 uClinux 시스템의 여러 요소들을 플래시 메모리 상에 올릴 수 있는 여러 방법들을 설명할 것이다. 그리고는 커널 드라이버 설정과 루트 파일 시스템의 선택에 대한 부분을 설명하도록 하겠다.
비록 플래시 메모리를 사용하는 것에 초점을 두었지만, 대부분의 아이디어는 ROM 에도 동일하게 적용될 수 있다. You just won't have the ability to update it in circuit, or to run read/write filesystem with standard ROM devices.
여기서는 상세한 부분까지 살펴볼 수 있도록 실제로 사용될 수 있는 예제를 가지고 설명할 것이다. 이 문서를 읽은 후에는 플래시 메모리의 장점을 활용한 uClinux 시스템을 빌드하는 방법을 이해하고 그에 따른 여러가지 선택의 문제와 각각의 장단점을 이해할 수 있길 기대한다.
2 플래시 메모리 #
지난 20년간, ROM (그리고 EPROM) 이 임베디드 시스템에서 사용되는 비휘발성 메모리의 중심이었다. 하지만 최근의 임베디드 시스템에서는 플래시 메모리가 주로 사용된다.
플래시 메모리는 기본적으로 NOR 와 NAND (그 외에도 AND 와 같은 변종이 존재하지만 여기서는 다루지 않겠다)의 두가지 종류가 있다.
NOR 플래시를 읽는 것은 기본적으로 SRAM 을 읽는 것과 동일하므로 모든 주소 공간에 접근할 수 있고, 임의의 영역의 값을 읽어올 수 있다. 또한 NOR 플래시의 코드를 직접 실행시킬 수도 있다 (Execute-In-Place 혹은 XIP 라고 한다). 내 생각으로는 이러한 기능 때문에 작은 임베디드 시스템에서 NOR 플래시가 주로 사용되는 것 같다. 모든 코드는 잠재적으로 플래시 메모리 상에서 직접 실행될 수 있기 때문에 RAM 사용량을 줄일 수 있다. NOR 플래시를 생산하는 업체는 삼성, Intel, AMD, Fujitsu, Toshiba 등이 있다. NOR 플래시 메모리의 용량은 일반적으로 수십 KB 에서 64MB 까지이다.
일반적으로 NAND 플래시는 블럭 단위로 읽으므로 일반적인 RAM 과는 다르다. 그보다 512 단위의 블럭 크기를 가지는 하드 드라이브와 비슷하다. NAND 플래시는 비트 단위로 조작하기가 쉽지만? (cheaper), 비트 단위로 조작하는 것은 에러가 발생할 확률이 높기 때문에 소프트웨어적으로 배드 블럭을 처리해야 한다. NAND 플래시에서는 직접 코드를 실행할 수 없다. NAND 플래시를 이용한 장치 중의 흥미로운 것은 M-System 의 ?DiskOnChip 장치이다. 이 장치는 내부적으로 NAND 플래시를 이용하고 에러 인식 및 수정을 위한 로직을 포함하며 외부 CPU 접근을 용이하게 하였다. 이름 때문에 혼란스러워 하지 않길 바란다. 이 장치의 인터페이스는 일반 하드 디스크 드라이브와 다르지 않다. NAND 플래시를 생산하는 업체는 삼성, Toshiba 으로 이들은 M-System 의 ?DiskOnChip 장치의 NAND 플래시도 공급한다. NAND 플래시 메모리의 용량은 일반적으로 8MB 에서 1GB 까지이다.
플래시 메모리에 데이터를 쓰는 것은 일반적은 RAM 에 쓰는 것과는 다르다. NOR 와 NAND 플래시 모두 데이터를 쓰기전에 적절한 처리를 하는 과정이 필요하다. 쓰기 작업은 대부분 먼저 플래시 메모리의 특정 부분을 삭제하는 과정을 포함한다.
모든 플래시 메모리는 블럭 혹은 세그먼트 (좀더 정확히 말하면 삭제 세그먼트 (erase segment)) 라는 형식으로 구성된다. 이것은 플래시 메모리의 내용을 지울 수 있는 최소 단위이다. 단순히 한 바이트 혹은 몇 바이트의 데이터만을 지울 수는 없다. 블럭의 크기는 장치에 따라 다르다. 일반적인 크기는 16KB 나 128KB 이다. 삭제 연산은 플래시 메모리 블럭 내의 모든 비트의 값을 "1" 로 만든다.
데이터를 쓰는 작업은 실제로 각 비트의 값을 "0" 으로 바꾸던지 아니면 그대로 "1" 로 두는 일을 한다. 그래서 기본적으로는 원하는 모든 곳에 쓰기 연산을 수행할 수는 있다고 해도 삭제 연산을 수행하지 않고 "0" 값을 가지는 비트를 "1" 로 쓸 수는 없다.
따라서 일반적으로 플래시 메모리의 내용을 바꾸고 싶은 경우에는 먼저 삭제 연산을 수행한 후에 쓰기 연산을 수행한다. 여기에는 한가지 고려해야 할 사항이 있다. 이것은 플래시 메모리 파일 시스템의 읽기/쓰기 연산을 수행하는 경우에 볼 수 있다.
플래시 메모리의 수명은 일반적으로 삭제 연산이 수행된 횟수로 계산한다. 정확한 수는 장치에 따라 다르지만 일반적으로 10,000 번에서 1,000,000 사이의 값을 가진다. 실제로 플래시 메모리 블럭에 얼마나 자주 삭제/쓰기 연산이 수행되는지 주의깊은 관심을 기울일 필요가 있다. 이것은 플래시 메모리 상에 읽기/쓰기 연산을 지원하는 파일 시스템을 올린 경우에는 특히 중요하다.
여기서는 주로 NOR 플래시에 대해 다루도록 하겠다. NOR 플래시는 작은 시스템에서 많이 사용되며 uClinux 시스템에서 주로 이용되는 플래시 메모리이기 때문이다.
3 시스템 #
임베디드 시스템내에 포함되는 플래시와 RAM 의 용량에는 언제나 trade-off 가 있다. 주로 가격을 먼저 고려하게 되는데, 일반적으로 플래시 메모리가 RAM 보다 비싸다. 마지막으로는 시스템의 세부적인 요구사항에 따른 메모리의 크기가 결정된다.
플래시 메모리는 시스템의 코드와 데이터를 저장하고 전원이 켜졌을 때 시스템이 수행되는 장치이고 uClinux 의 장치들이 파일을 저장하는 주 저장 장치이다.
아주 간단한 방식으로, 프로세서가 시작되는 위치에 uClinux 의 시작 코드를 저장해 두고 플래시 메모리를 하나의 커다란 저장 공간으로서 사용할 수 있다.
다른 방식으로는, 플래시 메모리를 분리된 영역의 파티션으로 나누는 것이 편리할 수 있다. 이것은 디스크 드라이브 파티션의 개념과 동일하지만 더 단순하고 작은 크기를 가진다. 일반적인 플래시 메모리의 파티션은 다음과 같다:
블럭 용도
0 부트 로더
1 공장 설정값 (factory configuration)
2
.
. 커널
.
X
.
. 루트 파일시스템
.
Y
위에서는 0 번 블럭에 부트 로더 코드를 넣고, 1번 블럭에는 공장 설정값 (이더넷 MAC 주소값 혹은 커널 명령행 옵션 등) 이 있으며, 2번 블럭부터 X번 블럭 까지는 커널 코드를, 마지막으로 X번 블럭 다음부터 Y번 블럭까지 루트 파일 시스템을 올렸다.
이것은 매우 단순한 예제이다. 시스템에서 필요한 경우에는 당연히 보다 복잡한 파티션으로 나누어 질 수 있다. 뒤에서 살펴보겠지만 플래시 메모리를 지원하는 uClinux 의 블럭 디바이스는 이러한 파티셔닝의 개념을 지원한다. Note that the partitions are always a whole number of Flash segments. You really want to do it this way since you can only erase an entire segment at a time.
또한 위의 예제에서는 커널과 루트 파일 시스템을 다른 파티션으로 분리하였다. 이것은 일반적인 리눅스의 설정 방식이 아니다. 일반적으로는 리눅스 커널은 루트 파일 시스템 내에 일반 실행 파일의 형태로 존재한다. 이 방법의 문제점은 (LILO 나 GRUB 과 같은) 똑똑한 부트 로더 프로그램이 필요하다는 것이다. 이러한 부트 로더 프로그램은 (커널 이미지를 포함하는) 하드 디스크 블럭을 RAM 상에 로드하는 일을 수행한다. 커널 이미지를 플래시 메모리 상의 연속적인 공간에 저장하는 것은 두가지 장점을 가진다. 하나는 플래시 메모리 상에서 바로 실행시킬 수 있다는 것이고 (XIP), 다른 하나는 부트 로더가 단순해 진다는 것이다 (심지어 부트 로더가 필요 없을 수도 있다).
커널과 루트 파일 시스템을 배치하는 몇가지 방법이 있다. 최선의 방법을 선택하는 데에는 여러가지 trade-off 가 존재한다. 여기에서는 가장 일반적인 몇가지 방법을 살펴보면서 각각의 장단점에 대해 알아보도록 하자.
커널과 루트 파일 시스템 모두 고정된 시작 주소를 가지는 방법
b. 커널의 마지막 부분에 이어서 루트 파일 시스템이 시작되는 방법
c. 커널과 루트 파일 시스템을 압축하는 방법
(a) 방법은 시스템의 요소들이 고정된 주소에 위치한다는 장점을 가진다. 부트 로더는 커널을 찾기 쉽고, 커널은 루트 파일 시스템을 찾기 쉽다. 또한 커널과 루트 파일 시스템이 서로 독립적으로 업그레이드 되기 쉽다는 장점이 있다. 이 방법의 단점은 커널 이미지와 루트 파일 시스템 사이에 공간이 낭비된다는 것이다.
(b) 방법은 루트 파일 시스템을 독립적인 파티션으로 분리하지 않았기 때문에 공간적인 측면에서 장점을 가진다. 또한 uClinux 시스템에서는 커널 이미지와 루트 파일 시스템을 하나의 파일로 묶는 것이 일반적이다. 이것은 곧 커널과 루트 파일 시스템을 동시에 업그레이드 해야 한다는 것을 의미한다 (종종 이것이 더 좋을 수도 있다).
(c) 방법은 커널과 루트 파일 시스템을 압축해서 저장하므로 플래시 메모리의 공간을 많이 절약할 수 있다. 이 방법을 사용하기 위해서는 압축된 이미지를 RAM 상에 풀 수 있는 부트 로더가 필요하다. 때문에 이 방법은 더 많은 RAM 영역을 차지하지만 다른 방법들에 비해서 많은 플래시 메모리 공간을 절약할 수 있다. 물론 상황에 따라 커널이나 루트 파일 시스템 중의 하나 만을 압축하는 방법도 사용할 수 있다.
여러 개의 파일 시스템 파티션도 물론 가질 수 있다. 이것은 파일 시스템의 일부분을 자주 변경하게 되는 경우나 파티션을 구분하여 읽기/쓰기 권한을 주려고 하는 경우에 유용하다.
4 부트 로더의 사용 여부 #
부팅 시에 가장 먼저 고려해야 할 것은 CPU 마다 다르다. 전원이 켜지면 프로세서는 어디서부터 실행을 시작할까? (ARM 이나 x86 과 같은) 많은 CPU 들은 고정된 시작 주소를 가진다. (m68k 나 Coldfire 에서 사용되는) 또 다른 방식으로는 고정된 주소의 값을 읽어서 그 값을 시작 주소로 사용하기도 한다. 이것은 시스템 시작 코드를 플래시 메모리 상에 집어넣어야 하는 경우에 직접적인 영향을 미친다.
이 시점에서 부트 로더 프로그램을 사용할 지 아니면 직접 uClinux 커널을 시작할 지 고려해 볼 필요가 있다.
CPU 가 (부트 로더를 거치지 않고) 직접 커널 코드에서부터 실행을 시작해도 아무런 문제가 없다. uClinux 시작 코드는 (보통 CPU 칩에 대한 설정과 RAM 설정 등을 포함하는) 모든 하드웨어 설정 작업과 커널의 데이터 영역을 RAM 에 로드하는 일과 BSS 영역을 초기화 하는 일을 수행해야 한다. 하지만 이러한 작업들은 매우 직관적이다. 이 방법의 유일한 문제점은 리셋이 되었을 때 CPU 가 다시 적절히 수행될 수 있도록 커널 코드를 적절한 위치에 배치해야 한다는 점이다. 최근의 대부분의 CPU 들은 주소 0 에서 실행을 시작하거나 0번 근처에 시작 주소를 가지고 있으므로, 이 작업이 간편해 진다.
부트 로더는 (CPU 와 RAM 설정 등의) 기본적인 하드웨어 설정 작업과 uClinux 커널을 적절한 위치에 로드하거나 직접 실행시키는 일을 수행하는 작은 독립적인 (stand-alone) 프로그램이다. 부트 로더에서 몇가지 유용한 작업을 수행하게 할 수도 있다. 사용자에게 플래시 메모리 상에 있는 여러 개의 커널 중에서 어느 것을 사용할 것인지 물어볼 수도 있고, (시리얼 포트나 이더넷 포트와 같은) 다른 I/O 장치를 통해 커널과 루트 파일 시스템을 로드할 수도 있다.
부트 로더에서 잘못된 커널 이미지의 실행을 막는 기본적인 보호 수단을 제공할 수도 있다. 이 기능은 플래시 메모리 상에서 동작할 때 특히 유용한데, 플래시 메모리에서는 (전원 문제 등으로 인해) 커널이나 중요 부분을 업데이트 하는 과정에서 오류가 일어날 수 있고 더 나쁜 경우는 이러한 버그가 있는 코드를 로드해 버릴 수도 있다. 부트 로더는 플래시 메모리 상에 영구적으로 고정되어 있을 수 있으므로 이러한 상황에 대처하는 기능을 제공할 수 있다.
현재 uClinux 에서 사용되는 부트 로더는 여러 가지가 있다. 무료로 사용할 수 있는 부트 로더에는 ?CoLilo, My Right Boot (MRB), ?PPCboot, Motorola dBUG 등이 있다. ?SnapGear 와 Arcturus Networks 같은 회사는 특정한 작업을 수행하는 고유한 부트 로더를 가지고 있다.
5 uClinux 커널의 블럭 디바이스 드라이버 #
현재 uClinux 의 루트 파일 시스템을 포함하는 블럭 디바이스는 아래와 같은 3 종류가 있다:
Blkmem 드라이버
MTD 드라이버
RAM disk 드라이버
blkmem 드라이버는 오래되었지만 여전히 uClinux 에서 가장 많이 사용되고 있다. 이 드라이버는 uClinux 를 위해 고안된 것이지만, 작은 크기의 NOR 플래시와 RAM 상의 루트 파일 시스템 만을 지원한다. 또한 설정하기가 어렵고 파티셔닝을 위해서 테이블 설정에 대한 코드를 변경해야 한다. 하지만 플래시 메모리 상의 특정 영역에 대한 기본적인 쓰기/삭제 연산을 제공한다.
MTD 드라이버는 리눅스의 표준 플래시 메모리 드라이버이다. 이 드라이버는 다양한 플래시 장치를 지원하고 파티셔닝에 대한 강력한 기능을 제공한다. 좀더 복잡한 설정을 위해서 플래시 메모리의 레이아웃을 정의하는 맵 드라이버를 생성한다. 이를 이용해 여러개의 플래시 메모리를 (인터리빙 방식으로) 연결할 수 있으며 심지어 시스템 내의 다른 종류의 플래시 메모리를 연결하는 것도 가능하다. 리눅스 커널에는 MTD 설정을 위한 여러 가지 옵션이 존재한다. 온라인 도움말을 통해 어떤 옵션들이 필요한 지 알아볼 수 있다. 처음에는 MTD 드라이버를 사용하는 장치들을 살펴보는 것이 도움이 될 것이다.
세번째로 리눅스의 RAM disk 드라이버를 사용할 수 있다. 이 드라이버는 주로 디스크 없이 리눅스 시스템을 부팅하고자 할 때 사용된다. RAM disk 드라이버는 플래시 메모리에 대한 어떠한 기능도 제공하지 않으므로 단지 루트 파일 시스템을 유지(holding)할 목적으로만 사용된다. 이 방법은 루트 파일 시스템을 플래시 메모리 상에 압축해서 저장하는 경우에 유용하다.
MTD 드라이버는 플래시 메모리를 위한 강력한 기능을 제공한다. 이것을 이용하면 플래시 메모리를 위해 특별히 고안된 JFFS, ?JFFS2 와 같은 실제 (read/write 가 가능한) 파일 시스템을 사용할 수 있다. blkmem 드라이버로는 불가능하다.
6 루트 파일 시스템 #
uClinux 에서 사용되는 루트 파일 시스템은 여러 가지가 있다.
일반적으로 ?ROMfs 타입이 가장 많이 쓰인다. 이것은 작고 단순한 읽기 전용 파일 시스템이다. ?ROMfs 는 파일의 모든 데이터를 순차적으로 저장하기 때문에 (m68k, ?ColdFire, ARM 과 같이) XIP 를 지원하는 CPU 에서 ?ROMfs 파일 시스템 내의 실행 파일을 직접 실행시킬 수 있다. 이 기능은 시스템 실행 중에 메모리의 사용량을 대폭 감소시킬 수 있다.
Cramfs 는 리눅스 커널 2.4 에서 새롭게 선보인 파일 시스템이다. Cramfs 는 작은 크기의 읽기 전용 파일 시스템으로 설계되었다. Cramfs 의 최대 장점은 모든 파일들이 압축된 형태로 저장되며 실행 중에 그 파일들이 압축 해제된다는 것이다. 파일들이 압축되어 있기 때문에 응용 프로그램이 XIP 로 동작하지 못한다. 이 방법은 플래시 메모리의 사용량을 감소시키지만 프로그램이 실행되기 위해선 RAM 에 복사되어야 하므로 더 많은 RAM 이 필요하게 된다.
시스템에 따라 읽기 전용이 아닌 읽기/쓰기가 가능한 파일 시스템이 필요할 수 있다. 리눅스 MTD 드라이버를 사용하면 플래시 메모리 상에서 JFFS 나 ?JFFS2 와 같은 저널링 파일 시스템을 이용할 수 있다. 저널링 파일 시스템은 (시스템이 적절히 셧다운 되지 않았을 때의 같이) 갑작스럽게 전원이 끊긴 상황에서도 안전하며, 다음번 부팅때 파일 시스템을 체크하지 않아도 된다. JFFS 와 ?JFFS2 는 특별히 플래시 메모리에서 사용하기 위해 설계되었기 때문에 wear leveling 이라고 하는 기능을 제공한다. 이것은 파일 시스템 내의 모든 데이터를 기록하거나 업데이트 할 때 플래시 메모리의 모든 영역이 골고루 사용되도록 (모든 블럭에 비슷한 수의 삭제 연산이 수행되도록) 한다. 이 기능은 플래시 메모리의 수명을 비약적으로 향상시켜 준다. ?JFFS2 는 파일을 압축시켜서 저장하기 때문에 더 적은 공간을 차지한다는 장점도 가지고 있다. 그래서 이전 버전인 JFFS 보다 더 많이 사용된다. 이러한 저널링 파일 시스템을 사용할 때 고려해야 할 또 한가지 사항은 저널링과 가비지 컬렉션 시스템에 의해 약간의 영역이 소비된다는 점이다. 일반적으로 이 크기는 2 블럭 정도?이다 (This wasted space is typically of the order of 2 Flash segments in size).
만약 RAM 디스크를 사용한다면 Ext2 파일 시스템을 쓰는 것이 일반적이다. 이것은 uClinux 에서도 마찬가지이다. Ext2 파일 시스템은 공간적인 측면에서 특별히 효율적이지는 않다. 또한 RAM 디스크에서 수정한 사항은 저장되지 않으므로 다음번 부팅 때 찾아볼 수 없다 (어떤 사람들은 이러한 특징으로 인해 시작시에 항상 파일 시스템의 상태를 알 수 있으므로 임베디드 시스템에서 더 좋을 수도 있다고 한다).
이 밖에도 사용할 수 있는 몇가지 파일 시스템이 더 존재한다. 리눅스에는 많은 수의 파일 시스템이 사용 가능하다. 하지만 위에서 말한 파일 시스템들이 uClinux 에서 주로 사용되는 것들이다. 원한다면 MS-DOS 의 FAT 파일 시스템도 사용할 수 있다.
한가지 더 말하자면, 루트 파일 시스템은 uClinux 상에서 사용될 수 있도록 구성되어야 한다. 보통 임베디드 장치에서 사용될 루트 파일 시스템은 개발 호스트에서 구성된 후에 타겟에 로드된다. 일반적으로 호스트 상에서 타겟에 올라갈 최종 루트 파일 시스템의 디렉토리 트리를 구성한 후에 호스트 기반의 툴을 사용하여 이진 파일 시스템 이미지를 만든다. genromfs 라는 프로그램이 대표적인 예이다. 이 프로그램은 호스트 상의 주어진 디렉토리를 ?ROMfs 이미지 파일로 구성한다. 다른 파일 시스템에 대해서도 비슷한 프로그램이 존재한다 (JFFS 는 mkfs.jffs, CD 이미지(?ISO9660)는 mkisofs 라는 프로그램이 담당한다).
7 플래시 메모리를 위한 도구들 #
uClinux 상에서 플래시 메모리를 다루기 위해 응용 프로그램 수준에서 다룰 수 있는 몇가지 프로그램이 존재한다. 이 중 몇몇은 사용하고 있는 블럭 디바이스 드라이버에 종속적이다.
MTD 드라이버와 함께 사용할 수 있는 것들은 다음과 같다:
erase -- 특정 블럭에 삭제 연산 수행
eraseall -- 모든 블럭에 삭제 연산 수행
lock -- 특정 블럭을 쓰기 연산을 위해 잠금
unlock -- 특정 블럭에 대해 쓰기 연산 잠금 해제
mkfs.jffs -- 주어진 디렉토리에 대한 JFFS 파일 시스템 구성
mkfs.jffs2 -- 주어진 디렉토리에 대한 JFFS2 파일 시스템 구성
erase, eraseall, lock, unlock 프로그램은 모두 MTD 파티션 내의 타겟 장치에서 사용된다. mkfs.jffs 와 mkfs.jffs2 는 일반적으로 호스트 시스템 상에서 타겟 장치의 플래시 메모리에 로드될 파일 시스템 이미지를 구성하는데 사용된다. MTD 드라이버는 타겟 장치에 대한 기본적인 문자 장치와 블럭 장치를 제공하므로 dd 와 같은 시스템 툴을 사용하여 특정한 내용을 플래시 메모리에 기록할 수 있다.
netflash 는 uClinux 를 위해 개발된 툴로서, MTD 드라이버나 blkmem 드라이버에서 모두 다 사용된다. netflash 는 주어진 파일을 플래시 메모리에 기록한다 (물론 삭제 연산을 먼저 수행한다). netflash 는 시스템 상의 로컬 파일 뿐 아니라 (tftp, httpd, NFS 등을 이용해) 네트워크를 통해 파일을 받아서 플래시 메모리에 기록할 수도 있다.
8 예제 #
이제 지금까지 논의한 여러가지 세부적인 사항들을 점검해 보기위해 실제로 사용되고 있는 예제를 하나 살펴보기로 하자. 예제 시스템은 ?ColdFire 5272 프로세서에 AMD 의 2Mb 플래시 메모리와 4Mb SDRAM 이 장착되어 있다 (참고로, 이것은 ?SnapGear 사의 LITE VPN router product 이다).
시스템에는 uClinux 2.4.x 커널이 사용되었고, 플래시 메모리를 위해 MTD 드라이버를 사용한다. 여기서는 읽기/쓰기가 가능한 파일 시스템이 필요치 않으므로 대신에 ?ROMfs 를 사용하기로 한다.
시스템에 사용된 AMD 플래시 메모리는 "bottom boot" 타입이다. 아래쪽의 주소 공간에는 각각 16KB, 8KB, 8KB, 32KB 의 크기를 가지는 작은 삭제 블럭들이 있다. 나머지 블럭은 모두 64KB 로 동일하다.
플래시 메모리의 파티션 맵은 아래와 같은 형태가 된다:
그리고 MTD 드라이버는 Toshiba 플래시 메모리를 인식하고 우리가 원하는 매핑에 따라 파티션을 분할해 준다. MTD 드라이버는 디버그 정보의 레벨을 조정할 수 있는 옵션을 가지며 이것은 커널 설정에서 정해줄 수 있다. 이 값을 높이면 장치 검색 과정에 대한 많은 정보를 제공하며 검색된 플래시 메모리에 대한 더 자세한 정보를 얻을 수 있다.
초기의 검색 메시지로부터 플래시 메모리가 CPU 주소 공간의 0xf0000000 매핑된다는 것을 알 수 있다. 이 주소값은 매핑 드라이버에 설정된다 (nettel-uc.c).
실제로 커널과 파일 시스템 이미지는 netflash 프로그램을 통해 업데이트 된다. 명령행 옵션은 간단히 표현하자면 다음과 같다:
netflash <서버 IP> imagez.bin
서버 IP에 이미지를 제공할 tftp 서버의 주소를 써 넣으면 netflash 프로그램이 나머지 일을 다 처리해 주고 완료된 경우 시스템을 리부팅한다 (루트 파일시스템이 플래시 메모리에서 커널 바로 뒤에 배치되어 있을 때 필요한 과정이다).
9 참고 문헌 #
다음 URL 을 참고하기 바란다:
http://www.uclinux.org : uClinux 홈페이지
http://www.linux-mtd.infradead.org : 리눅스 MTD 드라이버 홈페이지
http://www.ucdot.org : uClinux 관련 뉴스, 현재의 진행 사항 등 소개
관련된 SnapGear 의 기술 문서 #16 New Linux MTD driver support for the M-Systems Millennium Plus family of DiskOnChip flash devices(http://www.cyberguard.info/snapgear/tb20030402.html) 도 살펴보도록 하자.
저자: Greg Ungerer gerg_at_snapgear.com
번역: 김남형 namhyung_at_gmail.com
1 소개
2 플래시 메모리
3 시스템
4 부트 로더의 사용 여부
5 uClinux 커널의 블럭 디바이스 드라이버
6 루트 파일 시스템
7 플래시 메모리를 위한 도구들
8 예제
9 참고 문헌
1 소개 #
이 문서는 플래시 메모리를 사용하여 부팅하고 동작하는 uClinux 시스템을 구축하는 이론과 방법에 대해서 설명한다. 이 문서의 대부분은 프로세서에 독립적이다.
먼저 플래시 메모리에 대해서 간략히 소개하고 uClinux 시스템의 여러 요소들을 플래시 메모리 상에 올릴 수 있는 여러 방법들을 설명할 것이다. 그리고는 커널 드라이버 설정과 루트 파일 시스템의 선택에 대한 부분을 설명하도록 하겠다.
비록 플래시 메모리를 사용하는 것에 초점을 두었지만, 대부분의 아이디어는 ROM 에도 동일하게 적용될 수 있다. You just won't have the ability to update it in circuit, or to run read/write filesystem with standard ROM devices.
여기서는 상세한 부분까지 살펴볼 수 있도록 실제로 사용될 수 있는 예제를 가지고 설명할 것이다. 이 문서를 읽은 후에는 플래시 메모리의 장점을 활용한 uClinux 시스템을 빌드하는 방법을 이해하고 그에 따른 여러가지 선택의 문제와 각각의 장단점을 이해할 수 있길 기대한다.
2 플래시 메모리 #
지난 20년간, ROM (그리고 EPROM) 이 임베디드 시스템에서 사용되는 비휘발성 메모리의 중심이었다. 하지만 최근의 임베디드 시스템에서는 플래시 메모리가 주로 사용된다.
플래시 메모리는 기본적으로 NOR 와 NAND (그 외에도 AND 와 같은 변종이 존재하지만 여기서는 다루지 않겠다)의 두가지 종류가 있다.
NOR 플래시를 읽는 것은 기본적으로 SRAM 을 읽는 것과 동일하므로 모든 주소 공간에 접근할 수 있고, 임의의 영역의 값을 읽어올 수 있다. 또한 NOR 플래시의 코드를 직접 실행시킬 수도 있다 (Execute-In-Place 혹은 XIP 라고 한다). 내 생각으로는 이러한 기능 때문에 작은 임베디드 시스템에서 NOR 플래시가 주로 사용되는 것 같다. 모든 코드는 잠재적으로 플래시 메모리 상에서 직접 실행될 수 있기 때문에 RAM 사용량을 줄일 수 있다. NOR 플래시를 생산하는 업체는 삼성, Intel, AMD, Fujitsu, Toshiba 등이 있다. NOR 플래시 메모리의 용량은 일반적으로 수십 KB 에서 64MB 까지이다.
일반적으로 NAND 플래시는 블럭 단위로 읽으므로 일반적인 RAM 과는 다르다. 그보다 512 단위의 블럭 크기를 가지는 하드 드라이브와 비슷하다. NAND 플래시는 비트 단위로 조작하기가 쉽지만? (cheaper), 비트 단위로 조작하는 것은 에러가 발생할 확률이 높기 때문에 소프트웨어적으로 배드 블럭을 처리해야 한다. NAND 플래시에서는 직접 코드를 실행할 수 없다. NAND 플래시를 이용한 장치 중의 흥미로운 것은 M-System 의 ?DiskOnChip 장치이다. 이 장치는 내부적으로 NAND 플래시를 이용하고 에러 인식 및 수정을 위한 로직을 포함하며 외부 CPU 접근을 용이하게 하였다. 이름 때문에 혼란스러워 하지 않길 바란다. 이 장치의 인터페이스는 일반 하드 디스크 드라이브와 다르지 않다. NAND 플래시를 생산하는 업체는 삼성, Toshiba 으로 이들은 M-System 의 ?DiskOnChip 장치의 NAND 플래시도 공급한다. NAND 플래시 메모리의 용량은 일반적으로 8MB 에서 1GB 까지이다.
플래시 메모리에 데이터를 쓰는 것은 일반적은 RAM 에 쓰는 것과는 다르다. NOR 와 NAND 플래시 모두 데이터를 쓰기전에 적절한 처리를 하는 과정이 필요하다. 쓰기 작업은 대부분 먼저 플래시 메모리의 특정 부분을 삭제하는 과정을 포함한다.
모든 플래시 메모리는 블럭 혹은 세그먼트 (좀더 정확히 말하면 삭제 세그먼트 (erase segment)) 라는 형식으로 구성된다. 이것은 플래시 메모리의 내용을 지울 수 있는 최소 단위이다. 단순히 한 바이트 혹은 몇 바이트의 데이터만을 지울 수는 없다. 블럭의 크기는 장치에 따라 다르다. 일반적인 크기는 16KB 나 128KB 이다. 삭제 연산은 플래시 메모리 블럭 내의 모든 비트의 값을 "1" 로 만든다.
데이터를 쓰는 작업은 실제로 각 비트의 값을 "0" 으로 바꾸던지 아니면 그대로 "1" 로 두는 일을 한다. 그래서 기본적으로는 원하는 모든 곳에 쓰기 연산을 수행할 수는 있다고 해도 삭제 연산을 수행하지 않고 "0" 값을 가지는 비트를 "1" 로 쓸 수는 없다.
따라서 일반적으로 플래시 메모리의 내용을 바꾸고 싶은 경우에는 먼저 삭제 연산을 수행한 후에 쓰기 연산을 수행한다. 여기에는 한가지 고려해야 할 사항이 있다. 이것은 플래시 메모리 파일 시스템의 읽기/쓰기 연산을 수행하는 경우에 볼 수 있다.
플래시 메모리의 수명은 일반적으로 삭제 연산이 수행된 횟수로 계산한다. 정확한 수는 장치에 따라 다르지만 일반적으로 10,000 번에서 1,000,000 사이의 값을 가진다. 실제로 플래시 메모리 블럭에 얼마나 자주 삭제/쓰기 연산이 수행되는지 주의깊은 관심을 기울일 필요가 있다. 이것은 플래시 메모리 상에 읽기/쓰기 연산을 지원하는 파일 시스템을 올린 경우에는 특히 중요하다.
여기서는 주로 NOR 플래시에 대해 다루도록 하겠다. NOR 플래시는 작은 시스템에서 많이 사용되며 uClinux 시스템에서 주로 이용되는 플래시 메모리이기 때문이다.
3 시스템 #
임베디드 시스템내에 포함되는 플래시와 RAM 의 용량에는 언제나 trade-off 가 있다. 주로 가격을 먼저 고려하게 되는데, 일반적으로 플래시 메모리가 RAM 보다 비싸다. 마지막으로는 시스템의 세부적인 요구사항에 따른 메모리의 크기가 결정된다.
플래시 메모리는 시스템의 코드와 데이터를 저장하고 전원이 켜졌을 때 시스템이 수행되는 장치이고 uClinux 의 장치들이 파일을 저장하는 주 저장 장치이다.
아주 간단한 방식으로, 프로세서가 시작되는 위치에 uClinux 의 시작 코드를 저장해 두고 플래시 메모리를 하나의 커다란 저장 공간으로서 사용할 수 있다.
다른 방식으로는, 플래시 메모리를 분리된 영역의 파티션으로 나누는 것이 편리할 수 있다. 이것은 디스크 드라이브 파티션의 개념과 동일하지만 더 단순하고 작은 크기를 가진다. 일반적인 플래시 메모리의 파티션은 다음과 같다:
블럭 용도
0 부트 로더
1 공장 설정값 (factory configuration)
2
.
. 커널
.
X
.
. 루트 파일시스템
.
Y
위에서는 0 번 블럭에 부트 로더 코드를 넣고, 1번 블럭에는 공장 설정값 (이더넷 MAC 주소값 혹은 커널 명령행 옵션 등) 이 있으며, 2번 블럭부터 X번 블럭 까지는 커널 코드를, 마지막으로 X번 블럭 다음부터 Y번 블럭까지 루트 파일 시스템을 올렸다.
이것은 매우 단순한 예제이다. 시스템에서 필요한 경우에는 당연히 보다 복잡한 파티션으로 나누어 질 수 있다. 뒤에서 살펴보겠지만 플래시 메모리를 지원하는 uClinux 의 블럭 디바이스는 이러한 파티셔닝의 개념을 지원한다. Note that the partitions are always a whole number of Flash segments. You really want to do it this way since you can only erase an entire segment at a time.
또한 위의 예제에서는 커널과 루트 파일 시스템을 다른 파티션으로 분리하였다. 이것은 일반적인 리눅스의 설정 방식이 아니다. 일반적으로는 리눅스 커널은 루트 파일 시스템 내에 일반 실행 파일의 형태로 존재한다. 이 방법의 문제점은 (LILO 나 GRUB 과 같은) 똑똑한 부트 로더 프로그램이 필요하다는 것이다. 이러한 부트 로더 프로그램은 (커널 이미지를 포함하는) 하드 디스크 블럭을 RAM 상에 로드하는 일을 수행한다. 커널 이미지를 플래시 메모리 상의 연속적인 공간에 저장하는 것은 두가지 장점을 가진다. 하나는 플래시 메모리 상에서 바로 실행시킬 수 있다는 것이고 (XIP), 다른 하나는 부트 로더가 단순해 진다는 것이다 (심지어 부트 로더가 필요 없을 수도 있다).
커널과 루트 파일 시스템을 배치하는 몇가지 방법이 있다. 최선의 방법을 선택하는 데에는 여러가지 trade-off 가 존재한다. 여기에서는 가장 일반적인 몇가지 방법을 살펴보면서 각각의 장단점에 대해 알아보도록 하자.
커널과 루트 파일 시스템 모두 고정된 시작 주소를 가지는 방법
b. 커널의 마지막 부분에 이어서 루트 파일 시스템이 시작되는 방법
c. 커널과 루트 파일 시스템을 압축하는 방법
(a) 방법은 시스템의 요소들이 고정된 주소에 위치한다는 장점을 가진다. 부트 로더는 커널을 찾기 쉽고, 커널은 루트 파일 시스템을 찾기 쉽다. 또한 커널과 루트 파일 시스템이 서로 독립적으로 업그레이드 되기 쉽다는 장점이 있다. 이 방법의 단점은 커널 이미지와 루트 파일 시스템 사이에 공간이 낭비된다는 것이다.
(b) 방법은 루트 파일 시스템을 독립적인 파티션으로 분리하지 않았기 때문에 공간적인 측면에서 장점을 가진다. 또한 uClinux 시스템에서는 커널 이미지와 루트 파일 시스템을 하나의 파일로 묶는 것이 일반적이다. 이것은 곧 커널과 루트 파일 시스템을 동시에 업그레이드 해야 한다는 것을 의미한다 (종종 이것이 더 좋을 수도 있다).
(c) 방법은 커널과 루트 파일 시스템을 압축해서 저장하므로 플래시 메모리의 공간을 많이 절약할 수 있다. 이 방법을 사용하기 위해서는 압축된 이미지를 RAM 상에 풀 수 있는 부트 로더가 필요하다. 때문에 이 방법은 더 많은 RAM 영역을 차지하지만 다른 방법들에 비해서 많은 플래시 메모리 공간을 절약할 수 있다. 물론 상황에 따라 커널이나 루트 파일 시스템 중의 하나 만을 압축하는 방법도 사용할 수 있다.
여러 개의 파일 시스템 파티션도 물론 가질 수 있다. 이것은 파일 시스템의 일부분을 자주 변경하게 되는 경우나 파티션을 구분하여 읽기/쓰기 권한을 주려고 하는 경우에 유용하다.
4 부트 로더의 사용 여부 #
부팅 시에 가장 먼저 고려해야 할 것은 CPU 마다 다르다. 전원이 켜지면 프로세서는 어디서부터 실행을 시작할까? (ARM 이나 x86 과 같은) 많은 CPU 들은 고정된 시작 주소를 가진다. (m68k 나 Coldfire 에서 사용되는) 또 다른 방식으로는 고정된 주소의 값을 읽어서 그 값을 시작 주소로 사용하기도 한다. 이것은 시스템 시작 코드를 플래시 메모리 상에 집어넣어야 하는 경우에 직접적인 영향을 미친다.
이 시점에서 부트 로더 프로그램을 사용할 지 아니면 직접 uClinux 커널을 시작할 지 고려해 볼 필요가 있다.
CPU 가 (부트 로더를 거치지 않고) 직접 커널 코드에서부터 실행을 시작해도 아무런 문제가 없다. uClinux 시작 코드는 (보통 CPU 칩에 대한 설정과 RAM 설정 등을 포함하는) 모든 하드웨어 설정 작업과 커널의 데이터 영역을 RAM 에 로드하는 일과 BSS 영역을 초기화 하는 일을 수행해야 한다. 하지만 이러한 작업들은 매우 직관적이다. 이 방법의 유일한 문제점은 리셋이 되었을 때 CPU 가 다시 적절히 수행될 수 있도록 커널 코드를 적절한 위치에 배치해야 한다는 점이다. 최근의 대부분의 CPU 들은 주소 0 에서 실행을 시작하거나 0번 근처에 시작 주소를 가지고 있으므로, 이 작업이 간편해 진다.
부트 로더는 (CPU 와 RAM 설정 등의) 기본적인 하드웨어 설정 작업과 uClinux 커널을 적절한 위치에 로드하거나 직접 실행시키는 일을 수행하는 작은 독립적인 (stand-alone) 프로그램이다. 부트 로더에서 몇가지 유용한 작업을 수행하게 할 수도 있다. 사용자에게 플래시 메모리 상에 있는 여러 개의 커널 중에서 어느 것을 사용할 것인지 물어볼 수도 있고, (시리얼 포트나 이더넷 포트와 같은) 다른 I/O 장치를 통해 커널과 루트 파일 시스템을 로드할 수도 있다.
부트 로더에서 잘못된 커널 이미지의 실행을 막는 기본적인 보호 수단을 제공할 수도 있다. 이 기능은 플래시 메모리 상에서 동작할 때 특히 유용한데, 플래시 메모리에서는 (전원 문제 등으로 인해) 커널이나 중요 부분을 업데이트 하는 과정에서 오류가 일어날 수 있고 더 나쁜 경우는 이러한 버그가 있는 코드를 로드해 버릴 수도 있다. 부트 로더는 플래시 메모리 상에 영구적으로 고정되어 있을 수 있으므로 이러한 상황에 대처하는 기능을 제공할 수 있다.
현재 uClinux 에서 사용되는 부트 로더는 여러 가지가 있다. 무료로 사용할 수 있는 부트 로더에는 ?CoLilo, My Right Boot (MRB), ?PPCboot, Motorola dBUG 등이 있다. ?SnapGear 와 Arcturus Networks 같은 회사는 특정한 작업을 수행하는 고유한 부트 로더를 가지고 있다.
5 uClinux 커널의 블럭 디바이스 드라이버 #
현재 uClinux 의 루트 파일 시스템을 포함하는 블럭 디바이스는 아래와 같은 3 종류가 있다:
Blkmem 드라이버
MTD 드라이버
RAM disk 드라이버
blkmem 드라이버는 오래되었지만 여전히 uClinux 에서 가장 많이 사용되고 있다. 이 드라이버는 uClinux 를 위해 고안된 것이지만, 작은 크기의 NOR 플래시와 RAM 상의 루트 파일 시스템 만을 지원한다. 또한 설정하기가 어렵고 파티셔닝을 위해서 테이블 설정에 대한 코드를 변경해야 한다. 하지만 플래시 메모리 상의 특정 영역에 대한 기본적인 쓰기/삭제 연산을 제공한다.
MTD 드라이버는 리눅스의 표준 플래시 메모리 드라이버이다. 이 드라이버는 다양한 플래시 장치를 지원하고 파티셔닝에 대한 강력한 기능을 제공한다. 좀더 복잡한 설정을 위해서 플래시 메모리의 레이아웃을 정의하는 맵 드라이버를 생성한다. 이를 이용해 여러개의 플래시 메모리를 (인터리빙 방식으로) 연결할 수 있으며 심지어 시스템 내의 다른 종류의 플래시 메모리를 연결하는 것도 가능하다. 리눅스 커널에는 MTD 설정을 위한 여러 가지 옵션이 존재한다. 온라인 도움말을 통해 어떤 옵션들이 필요한 지 알아볼 수 있다. 처음에는 MTD 드라이버를 사용하는 장치들을 살펴보는 것이 도움이 될 것이다.
세번째로 리눅스의 RAM disk 드라이버를 사용할 수 있다. 이 드라이버는 주로 디스크 없이 리눅스 시스템을 부팅하고자 할 때 사용된다. RAM disk 드라이버는 플래시 메모리에 대한 어떠한 기능도 제공하지 않으므로 단지 루트 파일 시스템을 유지(holding)할 목적으로만 사용된다. 이 방법은 루트 파일 시스템을 플래시 메모리 상에 압축해서 저장하는 경우에 유용하다.
MTD 드라이버는 플래시 메모리를 위한 강력한 기능을 제공한다. 이것을 이용하면 플래시 메모리를 위해 특별히 고안된 JFFS, ?JFFS2 와 같은 실제 (read/write 가 가능한) 파일 시스템을 사용할 수 있다. blkmem 드라이버로는 불가능하다.
6 루트 파일 시스템 #
uClinux 에서 사용되는 루트 파일 시스템은 여러 가지가 있다.
일반적으로 ?ROMfs 타입이 가장 많이 쓰인다. 이것은 작고 단순한 읽기 전용 파일 시스템이다. ?ROMfs 는 파일의 모든 데이터를 순차적으로 저장하기 때문에 (m68k, ?ColdFire, ARM 과 같이) XIP 를 지원하는 CPU 에서 ?ROMfs 파일 시스템 내의 실행 파일을 직접 실행시킬 수 있다. 이 기능은 시스템 실행 중에 메모리의 사용량을 대폭 감소시킬 수 있다.
Cramfs 는 리눅스 커널 2.4 에서 새롭게 선보인 파일 시스템이다. Cramfs 는 작은 크기의 읽기 전용 파일 시스템으로 설계되었다. Cramfs 의 최대 장점은 모든 파일들이 압축된 형태로 저장되며 실행 중에 그 파일들이 압축 해제된다는 것이다. 파일들이 압축되어 있기 때문에 응용 프로그램이 XIP 로 동작하지 못한다. 이 방법은 플래시 메모리의 사용량을 감소시키지만 프로그램이 실행되기 위해선 RAM 에 복사되어야 하므로 더 많은 RAM 이 필요하게 된다.
시스템에 따라 읽기 전용이 아닌 읽기/쓰기가 가능한 파일 시스템이 필요할 수 있다. 리눅스 MTD 드라이버를 사용하면 플래시 메모리 상에서 JFFS 나 ?JFFS2 와 같은 저널링 파일 시스템을 이용할 수 있다. 저널링 파일 시스템은 (시스템이 적절히 셧다운 되지 않았을 때의 같이) 갑작스럽게 전원이 끊긴 상황에서도 안전하며, 다음번 부팅때 파일 시스템을 체크하지 않아도 된다. JFFS 와 ?JFFS2 는 특별히 플래시 메모리에서 사용하기 위해 설계되었기 때문에 wear leveling 이라고 하는 기능을 제공한다. 이것은 파일 시스템 내의 모든 데이터를 기록하거나 업데이트 할 때 플래시 메모리의 모든 영역이 골고루 사용되도록 (모든 블럭에 비슷한 수의 삭제 연산이 수행되도록) 한다. 이 기능은 플래시 메모리의 수명을 비약적으로 향상시켜 준다. ?JFFS2 는 파일을 압축시켜서 저장하기 때문에 더 적은 공간을 차지한다는 장점도 가지고 있다. 그래서 이전 버전인 JFFS 보다 더 많이 사용된다. 이러한 저널링 파일 시스템을 사용할 때 고려해야 할 또 한가지 사항은 저널링과 가비지 컬렉션 시스템에 의해 약간의 영역이 소비된다는 점이다. 일반적으로 이 크기는 2 블럭 정도?이다 (This wasted space is typically of the order of 2 Flash segments in size).
만약 RAM 디스크를 사용한다면 Ext2 파일 시스템을 쓰는 것이 일반적이다. 이것은 uClinux 에서도 마찬가지이다. Ext2 파일 시스템은 공간적인 측면에서 특별히 효율적이지는 않다. 또한 RAM 디스크에서 수정한 사항은 저장되지 않으므로 다음번 부팅 때 찾아볼 수 없다 (어떤 사람들은 이러한 특징으로 인해 시작시에 항상 파일 시스템의 상태를 알 수 있으므로 임베디드 시스템에서 더 좋을 수도 있다고 한다).
이 밖에도 사용할 수 있는 몇가지 파일 시스템이 더 존재한다. 리눅스에는 많은 수의 파일 시스템이 사용 가능하다. 하지만 위에서 말한 파일 시스템들이 uClinux 에서 주로 사용되는 것들이다. 원한다면 MS-DOS 의 FAT 파일 시스템도 사용할 수 있다.
한가지 더 말하자면, 루트 파일 시스템은 uClinux 상에서 사용될 수 있도록 구성되어야 한다. 보통 임베디드 장치에서 사용될 루트 파일 시스템은 개발 호스트에서 구성된 후에 타겟에 로드된다. 일반적으로 호스트 상에서 타겟에 올라갈 최종 루트 파일 시스템의 디렉토리 트리를 구성한 후에 호스트 기반의 툴을 사용하여 이진 파일 시스템 이미지를 만든다. genromfs 라는 프로그램이 대표적인 예이다. 이 프로그램은 호스트 상의 주어진 디렉토리를 ?ROMfs 이미지 파일로 구성한다. 다른 파일 시스템에 대해서도 비슷한 프로그램이 존재한다 (JFFS 는 mkfs.jffs, CD 이미지(?ISO9660)는 mkisofs 라는 프로그램이 담당한다).
7 플래시 메모리를 위한 도구들 #
uClinux 상에서 플래시 메모리를 다루기 위해 응용 프로그램 수준에서 다룰 수 있는 몇가지 프로그램이 존재한다. 이 중 몇몇은 사용하고 있는 블럭 디바이스 드라이버에 종속적이다.
MTD 드라이버와 함께 사용할 수 있는 것들은 다음과 같다:
erase -- 특정 블럭에 삭제 연산 수행
eraseall -- 모든 블럭에 삭제 연산 수행
lock -- 특정 블럭을 쓰기 연산을 위해 잠금
unlock -- 특정 블럭에 대해 쓰기 연산 잠금 해제
mkfs.jffs -- 주어진 디렉토리에 대한 JFFS 파일 시스템 구성
mkfs.jffs2 -- 주어진 디렉토리에 대한 JFFS2 파일 시스템 구성
erase, eraseall, lock, unlock 프로그램은 모두 MTD 파티션 내의 타겟 장치에서 사용된다. mkfs.jffs 와 mkfs.jffs2 는 일반적으로 호스트 시스템 상에서 타겟 장치의 플래시 메모리에 로드될 파일 시스템 이미지를 구성하는데 사용된다. MTD 드라이버는 타겟 장치에 대한 기본적인 문자 장치와 블럭 장치를 제공하므로 dd 와 같은 시스템 툴을 사용하여 특정한 내용을 플래시 메모리에 기록할 수 있다.
netflash 는 uClinux 를 위해 개발된 툴로서, MTD 드라이버나 blkmem 드라이버에서 모두 다 사용된다. netflash 는 주어진 파일을 플래시 메모리에 기록한다 (물론 삭제 연산을 먼저 수행한다). netflash 는 시스템 상의 로컬 파일 뿐 아니라 (tftp, httpd, NFS 등을 이용해) 네트워크를 통해 파일을 받아서 플래시 메모리에 기록할 수도 있다.
8 예제 #
이제 지금까지 논의한 여러가지 세부적인 사항들을 점검해 보기위해 실제로 사용되고 있는 예제를 하나 살펴보기로 하자. 예제 시스템은 ?ColdFire 5272 프로세서에 AMD 의 2Mb 플래시 메모리와 4Mb SDRAM 이 장착되어 있다 (참고로, 이것은 ?SnapGear 사의 LITE VPN router product 이다).
시스템에는 uClinux 2.4.x 커널이 사용되었고, 플래시 메모리를 위해 MTD 드라이버를 사용한다. 여기서는 읽기/쓰기가 가능한 파일 시스템이 필요치 않으므로 대신에 ?ROMfs 를 사용하기로 한다.
시스템에 사용된 AMD 플래시 메모리는 "bottom boot" 타입이다. 아래쪽의 주소 공간에는 각각 16KB, 8KB, 8KB, 32KB 의 크기를 가지는 작은 삭제 블럭들이 있다. 나머지 블럭은 모두 64KB 로 동일하다.
플래시 메모리의 파티션 맵은 아래와 같은 형태가 된다:
그리고 MTD 드라이버는 Toshiba 플래시 메모리를 인식하고 우리가 원하는 매핑에 따라 파티션을 분할해 준다. MTD 드라이버는 디버그 정보의 레벨을 조정할 수 있는 옵션을 가지며 이것은 커널 설정에서 정해줄 수 있다. 이 값을 높이면 장치 검색 과정에 대한 많은 정보를 제공하며 검색된 플래시 메모리에 대한 더 자세한 정보를 얻을 수 있다.
초기의 검색 메시지로부터 플래시 메모리가 CPU 주소 공간의 0xf0000000 매핑된다는 것을 알 수 있다. 이 주소값은 매핑 드라이버에 설정된다 (nettel-uc.c).
실제로 커널과 파일 시스템 이미지는 netflash 프로그램을 통해 업데이트 된다. 명령행 옵션은 간단히 표현하자면 다음과 같다:
netflash <서버 IP> imagez.bin
서버 IP에 이미지를 제공할 tftp 서버의 주소를 써 넣으면 netflash 프로그램이 나머지 일을 다 처리해 주고 완료된 경우 시스템을 리부팅한다 (루트 파일시스템이 플래시 메모리에서 커널 바로 뒤에 배치되어 있을 때 필요한 과정이다).
9 참고 문헌 #
다음 URL 을 참고하기 바란다:
http://www.uclinux.org : uClinux 홈페이지
http://www.linux-mtd.infradead.org : 리눅스 MTD 드라이버 홈페이지
http://www.ucdot.org : uClinux 관련 뉴스, 현재의 진행 사항 등 소개
관련된 SnapGear 의 기술 문서 #16 New Linux MTD driver support for the M-Systems Millennium Plus family of DiskOnChip flash devices(http://www.cyberguard.info/snapgear/tb20030402.html) 도 살펴보도록 하자.