플래시메모리기반보조기억장치시스템구성

비트 파워 프로젝트/임베디드 리눅스에서 플래시 메모리 블럭 디바이스 구현 1 플래시 메모리 기반 보조 기억장치 시스템 구성

399

소프트웨어 개발자를 위해 간단한 하드웨어에 대한 설명도 곁들일 것이다. 만약 독자가 리눅스 커널에 대해 잘 알고 있다면 이번 장은 넘어가도 좋다.

파일 시스템은 사용자 요구에 대해 단일한 접근을 제공하는 VFS (Virtual File System, 가상 파일 시스템)와 커널에서 상이한 블럭 디바이스에 접근할 수 있도록 하는 두 부분(ext3, fat, ntfs)으로 나 뉜다. 이를 통해 사용자 프로그램은 디스크 종류에 상관없이 단일한 인터페이스를 통해 모든 디스크에 접근할 수 있다. 리눅스 시스템에 서 사용자 프로그램이 블럭 디바이스에 접근할 때는 <그림 1>처럼 가 상 파일 시스템을 통해 블럭 디바이스에 해당하는 파일 시스템을 통 해 접근한다. 블럭 디바이스를 위한 파일 시스템을 관리하기 위해 별 도의 제어 정보를 두는데, 이를 파일 시스템의 메타 데이터(Meta Data)라 하며 리눅스의 표준 파일 시스템인 ext2는 하드 블럭 디바 이스의 두 번째 블럭부터 저장된다. 메타 데이터를 통해 커널은 파일 시스템의 상태를 파악하고 이를 제어한다. 블럭 디바이스는 mount 라는 셸 명령어를 통해 메타 데이터를 메모리로 읽어오며 이를 제어 하기 위한 인터페이스(API, 변수) 등을 설정한다.

임베디드 시스템의 운영체제로 이식된 리눅스는 본래 PC 기반의 데 스크톱 환경에서 발전했으며 파일 시스템이 없는 상황을 고려하지 않았다. 리눅스에서 모든 블럭 디바이스에 접근하기 위해 파일 시스 템 계층을 통해 접근하도록 만들었다. 이것이 리눅스 커널의 정책이 다. 따라서 하드 디스크가 없는 임베디드 리눅스 시스템도 셸과 응용 프로그램을 담아놓을 블럭 디바이스와 파일 시스템을 어딘가에는 반

드시 만들어야 한다. 일반적으로 블럭 디바이스는 램 블럭 디바이스 를 사용하고 이를 위해 ext2 파일 시스템을 사용한다. ‘램디스크’라 는 말이 나타내듯 휘발성 저장 매체인 램을 블럭 디바이스로 사용하 기 때문에 시스템의 전원을 끊으면 파일 시스템을 통해 저장됐던 정 보는 모두 사라진다.

블럭 디바이스는 블럭 단위로만 데이터를 전송하는(예를 들어, 플로 피 디스크나 하드 디스크) 디바이스다. 이때 하드웨어 블럭은 대개 섹터라고 부른다. 반면 블럭이라는 낱말은 소프트웨어 개념을 의미 하는 데 사용한다. 일반적으로 속도를 높이기 위해 캐싱이라는 기법 을 사용하고 파일 시스템에는 캐싱을 위해 사용되는 버퍼 캐시와 파 일의 데이터 입출력을 담당하는 페이지 캐시가 있다.

플래시 메모리는 전원이 끊어져도 데이터가 지워지지 않는 비휘발성 메모리로서 블럭 단위로 내용을 지울 수 있고, 다시 프로그래밍할 수 도 있다. 플래시 메모리는 EEPROM(Electrically Erasable Progr ammable ROM)의 변형 중 하나인데, 바이트 레벨에서 지울 수도 있고 수정할 수도 있는 EEPROM과 달리 블럭 단위로 수정되기 때 문에 속도가 빠르다. 하지만 플래시 메모리는 기존 데이터가 존재하 는 위치에 데이터를 기록하려면 해당 블럭을 지우고, 쓰기 작업을 해 야 한다. 그리고 플래시 메모리의 하드웨어 특성상 플래시 메모리의 블럭을 지우는 횟수의 제한이 있어 특정 블럭을 고정해 쓰게 되면 플 래시 메모리의 수명이 단축된다. 플래시 메모리는 종종 PC의 BIOS 와 같은 코드를 저장하는 데 사용된다. 현재 일반적으로 사용되는 플 래시 메모리는 크게 NOR형, NAND형 두 가지로 구분한다.

<그림 2>에서 보는 것처럼 NOR형 플래시 메모리는 시스템 버스 에 바로 붙일 수 있으며 바이트 단위로 프로그래밍할 수 있기 때문에 일반적인 램처럼 사용할 수 있다. 하지만 NAND형의 플래시 메모리

398

실전! 강의실

베디드 리눅스를 탑재한 기기가 최근 많이 출시되고 있는 데 그 중 하나가 PDA다. 필자 역시 임베디드 리눅스를 탑 재한 PDA를 잠시 사용한 적이 있는데 이를 통해 문서 작업, MP3 청취는 물론 인터넷도 이용할 수 있었다. 다시 말해 하드웨어 플랫폼 만 다를 뿐 PC에서 사용하던 리눅스와 다른 것이 없었다.

예전에 임베디드 리눅스 시스템에서는 루트 디바이스로 램디스 크를 사용했다. 램디스크는 말 그대로 전원 공급이 끊어지면 데이 터가 지워지는 램을 디스크로 사용하기 때문에 사용자 부주의로 인 해 전원이 쉽게 꺼질 수 있는 PDA에서는 휘발성의 램디스크를 사 용할 수 없다. 하지만 비 휘발성 저장장치가 필요하다고 해서 PDA 보다 큰 하드 디스크를 장착한다면 크기나 무게로 인해‘배보다 배 꼽이 더 큰 격’이 되고 만다. 노트북용 하드 디스크를 사용하더라도 시스템 사용 중 이동이 많은 PDA의 경우 이동시 충격으로 인해 오 래 사용할 수 없다. 그러므로 플래시 메모리를 사용해 플래시 메모 리 블럭 디바이스 드라이버를 구현하는 것은 이동성과 안정성이 뛰 어난 임베디드 리눅스 시스템을 위한 최적의 보조 기억장치 솔루션

이라고 할 수 있다.

필자의 연재 순서를 간략히 설명하면 전반부에서는 임베디드 리눅 스 시스템에서 일반적으로 많이 사용하는 NOR형 플래시 메모리를 사용해 플래시 블럭 디바이스를 구현하는 것을 설명할 것이다. 그리 고 나서 2, 3회 연재에서는 고가의 NOR형 플래시 메모리를 사용하 지 않고 저가의 NAND형 플래시 메모리를 사용해 플래시 블럭 디바 이스를 구현하는 방법에 대해 이야기할 것이다.

임베디드 리눅스 시스템을 위한 플래시 메모리를 블럭 디바이스를 구현하기 전에 간단히 이를 위한 개념을 정리하려고 한다. 사족이지 만 많은 임베디드 리눅스 시스템 개발자가 원천 기술을 습득하기보 다는 빠듯한 개발 일정에 밀려 구현하는 데 급급한 경우를 많이 보게 된다. 자신이 개발하는 시스템이 무엇인지 정확히 이해하지 못하고 개발한다면 밤을 새며 하는 수많은 일이 약간은 무의미한‘삽질’이 되지 않을까 싶다. 따라서 앞으로 설명할 MTD(Memory Technology Device)를 이용한 플래시 블럭 디바이스를 설명할 때는 기존 리눅스 커널과 비교해 개념 위주로 설명할 것이다. 그 외에도 PDA 같은 소형 임베디드 시스템에서 사용할 수 있는 보조 기억장치로는 무엇이 있을까? 이것이 이번 연재의 목적이며 시작점이다. 필자는 차세대 저장장치로 각광 받고 있는 플래시 메모리를 사용해 소형 임베디드 리눅스 시스템에 보조 기억장치를 구현하는 것을 보여줄 것이다. 그리고 저가의 플래시 블럭 디바이스를 구성할 수 있는 솔루션인 NAND 플래시 메모리 블럭 디바이스를 구현하는 방법을 간략하게 설명하려 한다.

플래시 메모리 기반

보조 기억장치 시스템 구성

1회 2002. 3 | 플래시 메모리 기반 보조 기억장치 시스템 구성

3회 | 리눅스의 MTD를 이용해 NAND 플래시 메모리 블럭 디바이스를 만들자

서희 [email protected](비트교육센터 158기)

필자는 현재 숭실대학교 컴퓨터 학부에 재학중이며, 비트교육센터 교육 시절 RTAI를 이용한 실시간 프로그래밍을 했다. 하이버스닷컴에서 임베디드 리눅스 시스템용 USB 호스트 컨트롤러를 이식하는 프로젝트를 진행했으며 임베디드 리눅스 소모임인 켈프(www.kelp.or.kr)에서 활동 중이다. 특히 운영체제에 큰 관 심을 가지고 있다.

연 재 순 서

운영체제 | 리눅스

개발도구 | gcc 및 binutils(크로스 컴파일러), make, mtd 모듈 기본지식 | ARM 아키텍처, 리눅스 커널

응용분야 | PDA, 스마트폰 등의 포스트 PC군, 셋톱박스

재 가 이 드

<그림 1> 파일 시스템 구성도

플래시 드라이버

플래시 드라이버 디스크 디바이스

디스크 드라이버

사용자 공간

하드웨어 커널 공간 응용 프로그램 1 응용 프로그램 2

공유 라이브러리

가상 파일 시스템

버퍼 캐시

JFFS ext2 fat hpfs

응용 프로그램 n

<그림 2> NAND형과 NOR형 플래시 메모리 특징

① 빠른 속도의 프로그래밍

② 빠른 속도의 지우는 작업

③ 작은 블럭 크기

① 느린 임의 접근

② 바이트 단위의 프로그래밍 불가능

데이터용 메모리로 적합하다(휴대형 터미 널, 음성 녹음기, DSC, 팩스 모뎀 등)

EPROM을 대신해 사용하기 적합하다.

제어용 메모리로 사용하기 적합하다(코드 용 메모리, BIOS, 셀룰러, HDD 등) NAND 플래시 메모리의 장점

NAND 플래시 메모리의 단점 NOR 플래시 메모리의 단점 NOR 플래시 메모리의 장점

① 빠른 속도로 임의 접근이 가능

② 바이트 프로그래밍이 가능하며 램과 동일하게 접근할 수 있다.

① 느린 속도의 프로그래밍

② 느린 속도의 지우는 작업

플래시 메모리 기반 보조 기억장치 시스템 구성

401

이미지 등을 수시로 변경할 필요성이 있으므로 플래시를 사용했다.

NAND형 플래시 메모리는 <그림 4>에서 보는 것처럼 GPIO를 통해 접근했다. GPIO란 일반적인 입출력 장치 제어를 위해 SA 1110에 서 제공하는 확장 인터페이스 중 하나이며 GPIO에 대해서는 2회의 하드웨어 관련 연재에서 다루는 법을 간단히 설명하겠다.

MTD에서는 두 가지 방법으로 사용자 프로그램에 플래시 메모리를 접근할 수 있는 인터페이스를 제공한다. 문자 디바이스로 접근하는 경우와 블럭 디바이스로 접근하는 경우다. 플래시 메모리를 문자 디 바이스로 접근할 때는 플래시 메모리를 하나의 파일로 인식해 순차 적으로 읽고 쓸 수 있다. 플래시 메모리를 블럭 디바이스로 접근한다 면 블럭 단위의 임의 접근이 가능하다. 블럭 디바이스의 경우 mount 를 통해 메타 정보 데이터를 메모리에서 읽어오며 해당 파일 시스템 의 API의 모듈을 로드한다. <그림 5>는 플래시 메모리를 블럭 디바 이스로 접근하는 경우의 소프트웨어 계층 구조다.

<그림 5>처럼 사용자 응용 프로그램이 시스템 호출을 사용해 사용 자 요구는 가상 파일 시스템을 통해 플래시 메모리를 위해 구축된 파 일 시스템(JFFS)에 접근하게 된다. JFFS는 갑자기 전원 공급이 중 단되는 상황에서도 신뢰성 있는 시스템을 제공하기 위한 것이다. 물 론 ext2 등의 다른 파일 시스템을 통해서도 접근할 수 있지만 JFFS 를 사용해 플래시 메모리에 접근하는 이유는 JFFS가 플래시 메모리 의 특성(2회에서 설명하도록 함)에 알맞게 설계됐기 때문이다. 드라 이버 모듈은 플래시 메모리를 읽고 쓸 수 있도록 하는 장치 구동기 다. JFFS를 비롯한 일반적인 파일 시스템은 블럭 디바이스를 필요 로 하는데, 플래시 메모리는 일반적으로 블럭 디바이스가 아니므로 로우 블럭(Raw block) 모듈을 두어 플래시 메모리가 블럭 디바이스 로 보이도록 했다. 여기서는 각 계층에 대해 간략히 설명하며 3회 연 재에서 각각의 API와 소스를 살펴보며 설명하겠다.

◆ JFFS : 일반적인 파일 시스템 대신 플래시 메모리의 특성을 고려한 파일 시스 템을 사용한다. 일반적인 기존 파일 시스템에서는 파일 시스템의 메타 정보를

특정 블럭에 고정하고 파일 시스템이 수정될 때마다 해당 블럭을 갱신하던 것 을 JFFS는 플래시 메모리의 특성에 맞게 특정 블럭을 고정해 사용하지 않고 플래시 메모리 전 영역을 고르게 사용할 수 있도록 한다. 그리고 비동기적 전원 실패에 대비해 데이터 손실이 없는 신뢰성 있는 임베디드 리눅스 시스템을 위 해 일정 시간마다 전체 파일 시스템의 메타 정보를 로깅(logging)해 시스템이 동작 중에 비동기적으로 전원이 끊어졌을 때도 빠른 시스템 복구 시간을 제공 한다.

◆ 로우 블럭 모듈 : 파일 시스템은 블럭 디바이스 위에서 동작하는데, 플래시 메 모리를 블럭 디바이스로 간주하도록 하는 블럭 디바이스 인터페이스가 로우 블 럭 모듈이다. 블럭 디바이스 인터페이스는 플래시 메모리의 블럭 데이터를 SDRAM에 캐싱한다.

실제 리눅스에서 플래시 메모리 디바이스를 제어하기 위해 플래시 메모리의 저수준 인터페이스 동작을 제공하는 디바이스 드라이버가 필요하며 이를 통해 플래시 디바이스가 서비스할 수 있도록 파일 시 스템 인터페이스와 결합시켜 준다. 디바이스 드라이버는 NOR형 플 래시와 NAND형 플래시의 특성에 맞게 따로 존재한다.

예를 들어 NOR형 플래시 메모리의 경우의 읽기/쓰기 동작은 일 반 메모리와 유사하며 바이트 단위의 프로그래밍이 가능하다. 따라 서 플래시 메모리에 접근할 때 해당 주소에 있는 데이터를 가져오려 면 해당 주소에 있는 데이터를 읽어오기만 하면 된다. 하지만 NAND형 플래시 메모리는 NOR형의 플래시 메모리와는 달리 8비 트 I/O 모드로 동작하는데, 읽거나 쓰기를 할 때는 페이지(512바이 트) 단위로 동작하며 지우는 동작은 블럭 단위(16페이지)로 동작한 다. 플래시 메모리에 대한 쓰기 동작은 NAND형 플래시 메모리 디 바이스 특성상 해당 페이지가 속해 있는 블럭을 모두 지운 다음 쓰기 를 수행해야 하는 플래시의 특성을 감안해 프로그래밍해야 한다. 참 고로 NAND형 플래시를 사용(읽기/쓰기/지우기)하기 위해서는 <그 림 6>과 같은 순서대로 플래시 메모리를 제어해야 한다.

MTD 아키텍처를 통해 플래시 메모리는 블럭 디바이스로 사용할 수

400

실전! 강의실

는 바이트 단위의 프로그래밍이 불가능하고 시스템 버스에 바로 붙 이더라도 NAND형의 플래시 메모리를 위한 별도의 제어 로직이 필 요하다. 물론 PLA를 사용해 NOR형 플래시 메모리를 사용하는 것 처럼 할 수도 있다. 필자가 작업한 보드에는 NAND형의 플래시 메 모리를 GPIO(Genernal Port Input Out) 인터페이스로 제어할 수 있게 했다. NAND형의 플래시 메모리에 대해서는 2회 연재에서 좀 더 자세히 설명하겠다.

MTD 서브시스템은 리눅스 시스템에서 플래시 메모리 디바이스를 이용하기 위해 개발됐다. 각 제조사에 따라 다른 플래시 메모리 디바 이스에 대해 일관되고 공통된 소프트웨어 인터페이스를 제공함으로 써 플래시 메모리를 이용한 리눅스 시스템 개발에 개발자가 손쉽게 대처할 수 있게끔 하고 있다. 하드 블럭 디바이스 같은 일반적인 저장 매체를 사용하기 힘든 임베디드 시스템에서 플래시 메모리는 사실 유 일하게 사용할 수 있는 매체이며, 플래시 메모리를 이용한 리눅스 임 베디드 시스템 개발에 MTD가 좋은 솔루션이 될 수 있다.

MTD는 이전까지는 웹에서 소스 코드를 다운로드하는 방법으로 제공됐으나 리눅스 커널 2.4.0부터는 기본으로 포함하고 있다.

MTD 홈페이지(http://www.linux-mtd.infradead.org)에서도 별도 패키지를 얻을 수 있다.

MTD는 사용자 모듈과 드라이버 모듈 두 가지로 구성된다. JFFS (Journaling Flash File System)를 기준으로 한 MTD 전체 구조는

<그림 5>와 같으며 각각의 계층에 대한 설명은 소프트웨어 구성도에 서 자세히 설명하겠다.

<그림 3, 4>는 필자가 가지고 있는 임베디드 리눅스 시스템 보드의 외관과 내부 하드웨어 구성을 보여준다. CPU는 SA1110을 사용하 며, 메모리로는 SDRAM, NOR 플래시 메모리, NAND형 플래시 메 모리 세 가지를 장착하고 있다. 필자의 보드에서 NOR 플래시는 ROM의 기능을 한다. 일반적으로 개발용 보드는 부트 로더나 커널

<그림 4> Hyper104 보드 외관

<그림 3> 임베디드 리눅스 시스템의 하드웨어 구성

CODEC 인터페이스 LCD 인터페이스

리셋 제너레이터

리셋 아웃

USB 인터페이스 직렬 포트와 IrDA 인터페이스

GPIO

SA1110 StrongARM

프로세서

JTAG 전압

레귤레이터

CPLD XC95144XL

직렬 포트 제어 UART1 DC3.3~6V

입력

컴팩트 플래시 헤더 JTAG

LED CF 제어

주소 버스 데이터 버스

제어 버스

80핀 커넥터 ①

SDRAM

② 인텔 플래시 메모리(NOR)

③ 삼성 플래시 메모리(NAND)

RS 232

<그림 5> 플래시 메모리 블럭 디바이스를 위한 소프트웨어 구성

사용자 응용 프로그램

시스템 호출 인터페이스

가상 파일 시스템

JFFS

사용자 모듈

드라이버 모듈 로우 블럭

MTD 시스템 구성 모듈

MTD 드라이버 모듈

NOR 플래시 NAND 플래시

<그림 6> NAND 플래시 메모리를 위한 제어 흐름도

명령어 레지스터에 해당 명령어를 쓴다.

플래시 메모리에 주소를 넣어준다.

I/O 0~7핀에서 데이터를 읽거나 쓴다.

끝 예 시작

① 32MB SDRAM : 주 기억장치로 사용하는 영역

② 16MB의 인텔 Strata 플래시 메모리(NOR형) : 현 시스템에서는 부트 ROM과 같은 기능을 하며 커널 이미지 등이 들어 있다.

③ 8MB의 삼성 K96408U0A-TCB0 플래시 메모 리(NAND형) : GPIO를 통해 읽기/쓰기가 가능 하며 보조 기억장치로 사용하도록 구성했다.

플래시 메모리 기반 보조 기억장치 시스템 구성

403

이와 같은 커널 옵션을 설정한 후에 상위 화면으로 돌아가서 File systems 항목을 설정한다.

<*> Journalling Flash File System(JFFS) support

MTD에서는 플래시 메모리를 사용하기 위해 플랫폼에 따른 등록 모 듈이 존재한다. 그리고 선형 메모리 디바이스인 플래시 메모리를 파 티션을 나눠 사용할 수 있다. 이를 위해 자신의 시스템 보드에 장착 된 플래시 메모리에 맞게 파티션 테이블을 작성해야 한다. /linux/

drivers/mtd/sa1100-flash.c를 수정해 MTD 시스템에 플래시 메모 리를 등록한다.

파티션 테이블을 보면 현재 시스템의 플래시 메모리 최대 크기 (hyper104_max_flash_size)는 16MB(0x01000000)이며 파티션은 모두 네 개로 나눠져 있고 각각의 심벌은 Loader+param, kernel, root filesystem, User이다. 여기까지 수정했으면 컴파일을 위한 준 비는 모두 끝난 셈이다. 이제 다음 명령을 실행하자.

#sh> Make dep; Make zImage;

크로스 환경과 커널 컴파일 과정이 문제없이 진행됐다면 부팅 화면 이 표시될 것이다(<리스트 2>).

<리스트 2>의 ①은 플래시를 위한 JFFS 파일 시스템이 커널에 등 록되는 작업이다. 이를 통해 플래시 블럭 디바이스를 JFFS를 통해 사용할 수 있도록 해준다.

#hybus104> mount -t jffs /dev/mtdblock3 /mnt JFFS file system type is not support by kernel...

마운트 과정 중 발생한 에러 메시지는 JFFS를 위한 모듈이 로드 되면서 JFFS를 등록할 때 에러가 난 경우다. 커널 설정을 다시 확인 해야 하며 ①번의 메시지가 있는지 확인해야 한다.

이제 다음 명령을 통해 파티션 테이블 정보를 얻을 수 있다.

#hybus104> cat /proc/mtd

이제 정상적으로 플래시 메모리를 하드 블럭 디바이스와 같은 방 법으로 사용할 수 있을 것이다. 이제 플래시 메모리를 사용자 프로그 램에서 접근하기 위한 디바이스 파일이 있는지 확인하고 명령 프롬 프트 상태에서 다음을 실행하자. 만약 앞에서 mtd 유틸리티(/mtd/

util/MAKEDEV)를 사용해 디바이스 파일을 만들었다면 첫 번째 명 령은 수행하지 않아도 된다.

#hybus104> mknod /dev/mtdblock3 b 31 3 ← b는 블럭 디바이스를, 31은

#hybus104> mount -t jffs /dev/mtdblock3 /mnt

콘솔에서 아무런 메시지가 나타나지 않았다면 성공적으로 수행된 것이다. df 명령을 통해 파일 시스템을 통해 접근할 수 있는 블럭 디 바이스의 상태 정보를 확인할 수 있다.

이제 기존 블럭 디바이스가 없는 임베디드 리눅스 시스템에서 루트 디바이스로 램 블럭 디바이스를 사용하던 것을 플래시 블럭 디바이 스로 바꾸는 작업이다. 이 작업이 실제 임베디스 리눅스 시스템으로

402

실전! 강의실

있으며 하드 디스크와 같이 파티션을 나눠 사용할 수도 있다. 플래시 메모리 블럭 디바이스의 파티션 내용은 <표 1>과 같다. 16MB 크기 의 NOR형 플래시 메모리의 파티션을 나눈 모습이다.

이것으로 개념적인 설명은 마치고 MTD를 이용해 임베디드 리눅스 시스템 보드에 있는 NOR형 플래시 메모리 블럭 디바이스를 구현해 보려고 한다. <그림 4>에서 보는 것처럼 보드 내부에 장착된 NOR 플래시를 대상으로 작업했다. NOR형 플래시 메모리를 루트 디바이 스로 사용해 기존의 램디스크를 사용하지 않고 플래시 블럭 디바이 스를 사용해 시스템 사용 중에 수정된 데이터들이 시스템 재부팅 이 후에도 지워지지 않는 시스템을 구성할 수 있다.

현재 NOR형 플래시 메모리를 블럭 디바이스로 사용하기 위해서 는 커널을 설정하고 소스를 약간 수정하면 바로 사용할 수 있다. 만 약 독자 자신의 임베디드 리눅스 시스템 보드가 있다면 따라해 보기 바란다. 백문(百聞)이 불여일행(不如一行) 아니겠는가? MTD와 JFFS를 좀더 알기 원하는 독자들을 위해 관련 커뮤니티의 인터넷 주소를 소개하겠다. MTD와 JFFS 프로젝트는 별도로 진행되고 있 으며 관련 커뮤니티는 다음과 같다.

◆ MTD/DOC/(http://www.linux-mtd.infradead.org)

◆ JFFS(http://developer.axis.com/software/jffs)

만약 독자들 중 MTD를 사용해 임베디드 리눅스 시스템 보드에 플래시 블럭 디바이스를 구현하려고 한다면 우선 자신의 임베디드 시스템에 있는 플래시 메모리가 MTD에서 정상으로 동작하는지 확 인해야 한다. http://www.EmbeddedLinuxWorks.com에서 MTD 를 사용해 플래시 블럭 디바이스가 정상으로 동작하는 플래시 메모 리의 목록을 찾아볼 수 있다.

MTD/JFFS(그 외 몇몇 유틸리티)의 소스 코드는 익명의 계정으로 CVS를 통해 내려받을 수 있다.

cd /usr/src(

cvs -d :pserver:[email protected]:/home/cvs login(

cvs -d :pserver:[email protected]:/home/cvs co mtd

이제 /usr/src 밑에 mtd라는 디렉토리가 생성됐을 것이다. MTD 서비스를 통해 사용자 프로그램은 두 가지 방법으로 플래시 메모리 에 접근할 수 있다.

◆ 문자 디바이스(character device)로 접근할 수 있다. 이를 통해 사용자 프 로그램은 플래시 메모리를 하나의 파일로서 접근하므로 순차적인 접근만 가 능하다.

◆ 블럭 디바이스(block device)로 접근할 수 있다. 문자 디바이스와는 달리 블럭 단위로 접근 가능해 마운트 작업을 통해 사용자 프로그램이 셸에서 접근할 수 있다.

사용자 모듈에 맞는 적절한 디바이스들은 <표 2>와 같다. 만약 /dev 디렉토리 밑에 mtd0, 1, 2 같은 디바이스가 없다면 /mtd/util 밑에 있는 MAKEDEV 유틸리티를 실행해 MTD 시스 템을 위해 /dev 밑에 모든 적절한(주/부 번호) 디바이스를 만들어 준다.

#sh /usr/src/mtd/util/MAKEDEV

다음 명령을 수행하면 mtd 모듈들을 위한 디바이스 파일들이 보 일 것이다.

#ls -al /dev/mtd*

이제 필요한 소스를 받았다면 MTD를 위한 커널 설정을 해야 한다.

기본적으로 선택해야 할 항목은 Memory Technology Devi ces (MTD) 항목이다. 여기서 우리는 모듈화는 하지 않고 빌트인의 경우 만 이야기하겠다. MTD 항목을 선택하면 세부 항목이 화면에 표시 된다.

<*> Memory Technloogy Device (MTD) support

<*> Support for ROM chips in bus mapping

<*> Common Flash Interface(CFI) support

<*> CFI support for Intel/Sharp Extended Commands

<*> CFI Flash device mapped in StongARM SA11x0 ← 각자의 시스템

<*> Direct char device access to MTD devices

<*> Caching block device access to MTD devices ← 블럭 디바이스

<표 1> 플래시 블럭 디바이스 파티션 테이블

파티션 디바이스 파일 크기 삭제 크기 이름

1번 파티션 mtdblock0 0x00080000 00020000 Loader+param 2번 파티션 mtdblock1 0x00100000 00020000 kernel 3번 파티션 mtdblock2 0x00200000 00020000 root filesystem 4번 파티션 mtdblock3 0x00100000 00020000 Configuration 5번 파티션 mtdblock4 0x00B80000 00020000 User 주 - ◆ 디바이스 파일 : 사용자 프로그램은 이 디바이스 파일을 사용해 해당 파티션에 접

근(마운트)할 수 있도록 한다.

◆ 크기 : 해당 파티션의 크기를 나타낸다.

◆ 삭제 크기 : 플래시 메모리를 지울 수 있는 최소 단위를 나타낸다.

◆ 이름 : 해당 파티션의 이름을 나타낸다.

<표 2> 사용자 모듈에 맞는 적절한 디바이스

디바이스 종류 디바이스 파일 주/부 번호

로우 문자 디바이스 /dev/mtd1, 2… 90/0, 2, 4 로우 블럭 디바이스 /dev/mtdblock0, 1… 31/0, 1, 2

#ifdef CONFIG_SA1100_HYPER104

static unsigned long hyper104_max_flash_size = 0x01000000;

static struct mtd_partition hyper104_partitions[] = {

{

name: “Loader+param”, offset: 0,

size: 0x00080000, // 512K },{

name: “kernel”,

offset: MTDPART_OFS_APPEND, size: 0x00100000, // 1M },{

name: “root filesystem”, offset: MTDPART_OFS_APPEND, size: 0x00200000, // 3M },{

name: “Configration”, offset: MTDPART_OFS_APPEND, size: 0x00100000, // 256K },{

name: “User”,

offset: MTDPART_OFS_APPEND, size: MTDPART_SIZ_FULL, }

};

#endif

#ifdef CONFIG_SA1100_HYPER104 if (machine_is_hyper104()) {

parts = hyper104_partitions;

nb_parts = NB_OF(hyper104_partitions);

sa1100_map.size = hyper104_max_flash_size;

}

#endif

add_mtd_partitions(mymtd, parts, nb_parts); ← 플래시 메모리의 파티션 테이블을 MTD 시스템에 등록한다.

<리스트 1> /linux/drivers/mtd/sa1100-flash.c

maso

Microsoftware

플래시 메모리 기반 보조 기억장치 시스템 구성

사용할 것이므로 이 항목을 제거한다.

< >Normal PC floppy disk suport

<*>Loopback device support

< >Network block device support

< >RAM disk support ← 제거.

다음으로 최상위 항목으로 돌아가 General setup의 세부 항목으 로 들어간다. 여러 세부 항목이 표시되는데 우리에게 필요한 옵션 항 목은 Default kernel Command string이다. 이 항목에 다음과 같은 내용을 새로 삽입한다.

Root = /dev/mtdblock2

이와 같은 코드를 삽입하는 이유는 더 이상 램디스크를 사용하지 않을 것이므로 커널에 새로운 루트 파일 시스템의 위치를 알려주기 위해서다. 이제 커널을 다시 컴파일하고 새로 생성한 커널 이미지로 부팅하면 루트 파일 시스템은 램 블럭 디바이스가 아니라 플래시 블 럭 디바이스에 마운트된다. / 밑에 있는 하위 디렉토리 어디에서든지 저장한 내용은 플래시 블럭 디바이스에 저장된다.

정상적으로 에러 없이 커널을 컴파일하고 재부팅하면 <리스트 2>

와 같은 메시지를 확인할 수 있다. 루트 디바이스는 /dev/mtdblock2 이며 루트 파일 시스템은 JFFS이다.

1회에서는 MTD의 개념과 NOR형 플래시 메모리를 블럭 디바이스 로 사용하는 방법에 대해 간단히 이야기했다. MTD의 자세한 내부 메커니즘에 대한 설명은 3회‘NAND 플래시 블럭 디바이스를 구 현하자’에서 자세하게 설명할 것이므로 이번 호에서는 간단히 언급 하고 넘어갔다. 임베디드 리눅스 시스템 보드에 NAND 플래시 메 모리를 사용한 블럭 디바이스를 사용하기 위해서는 NAND 플래시 메모리의 디바이스 드라이버를 수정해야 한다. 이를 위해 다음호에 서는 실제 NAND 플래시 메모리의 하드웨어 특성 및 펌웨어 레벨 에서 NAND 플래시 메모리를 접근하는 방법에 대해 자세히 다룰 것이다.

정리 : 송우일 [email protected]

asmo

405

완전한 독립적 저장장치를 구현하는 가장 마지막 단계다.

플래시 파일 시스템을 루트 파일 시스템으로 마운트하는 것은 두 단 계로 나눠진다. 첫 번째는 루트 파일 시스템으로 사용하기 위해 JFFS로 포맷한 파일 시스템 이미지를 생성하는 것과 두 번째는 루 트 파일 시스템을 플래시 블럭 디바이스에 마운트하는 작업이다.

루트 파일 시스템으로 사용할 JFFS 파일 시스템으로 포맷된 이미지 를 생성하고 이것을 플래시 메모리 블럭 디바이스에 쓰기를 수행하 는 작업이다. 루트 파일 시스템으로 마운트할 디바이스(플래시 블럭 디바이스)에서 사용할 JFFS 파일 시스템 이미지를 생성하는 MKFS.JFFS 유틸리티는 다음과 같은 방법으로 사용한다.

#sh> MKFS.JFFS -d root_directory -o output_file_name

이 명령을 수행하면 해당 루트 디렉토리에 있는 블럭 디바이스 이 미지가 JFFS 파일 시스템 형태로 포맷되며 이를 위한 이미지 (output_file_name)가 생성된다.

루트 디바이스를 플래시 블럭 디바이스로 설정하고 이를 위한 루 트 파일 시스템의 구성을 위한 준비 작업은 모두 끝났다. 이제 준비 된 재료를 사용할 시간이다. JFFS로 포맷된 파일 시스템을 루트 디 바이스인 플래시 블럭 디바이스에 이미지를 기록해야 한다. 이를 위 해 앞에서 설정했던 플래시 블럭 디바이스에 파일 시스템 이미지를 쓴다.

#sh>cp (JFFS 파일 시스템 이미지) /dev/mtdblock3

이때 주의할 것은 JFFS 파일 시스템 이미지를 기록할 수 있는 충 분한 플래시 블럭 디바이스 공간이 있어야 한다는 것이다.

루트 파일 시스템으로 플래시 메모리를 지원하는 두 번째 경우의 커 널을 만드는 방법을 이야기하겠다. 커널 옵션 메뉴의 상단에서 Block Device를 선택한다. 그러면 세부 항목이 나타난다. 현재 임베 디드 리눅스 시스템은 보조 기억장치인 블럭 디바이스 없이 램 블럭 디바이스를 사용하기 때문에 항상 RAM disk support 항목이 체크 되어 있다. 하지만 우리는 루트 디바이스로 플래시 블럭 디바이스를

404

실전! 강의실

Uncompressing Linux... done, booting the kernel.

Linux version 2.4.5-rmk6-np1 (root@bedguy) (gcc version 2.95.2 20000313 (Debian GNU/Linux)) #74 Tue Feb 19 23:29:28 KST 2002

Processor: Intel StrongARM-1110 revision 8 Architecture: Hybus Hyper 104

On node 0 totalpages: 8192 zone(0): 8192 pages.

zone(1): 0 pages.

zone(2): 0 pages.

Kernel command line: root=/dev/mtdblock2 init=/linuxrc ← 루트 디바이스로 플래시 블럭 디바이스(mtdblock2)를 사용

Relocating machine vectors to 0xffff0000 Warning: uninitialized Real Time Clock Console: colour dummy device 80x30 Calibrating delay loop... 147.04 BogoMIPS Memory: 32MB = 32MB total

Memory: 30480KB available (1283K code, 354K data, 60K init) Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) POSIX conformance testing by UNIFIX

Linux NET4.0 for Linux 2.4

Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8

devfs: v0.102 (20000622) Richard Gooch ([email protected]) devfs: boot_options: 0x2

JFFS version 1.0, (C) 1999, 2000 Axis Communications AB ← ①

Console: switching to colour frame buffer device 80x30 pty: 256 Unix98 ptys configured

block: queued sectors max/low 19922kB/6640kB, 64 slots per queue eth0: cs8900 rev J Base 0xF0000300<6>, IRQ 0, MAC 00:D0:CA:F1:26:11 SA1100 flash: probing 16-bit flash bus

SA1100 flash: Found 1 x16 devices at 0x0 in 16-bit mode JEDEC ID: 89 18

0: offset=0x0,size=0x20000,blocks=128 Using static partition definition Creating 5 MTD partitions on “SA1100 flash”: 0x00000000-0x00080000 : “Loader+param”

0x00080000-0x00180000 : “kernel”

0x00180000-0x00380000 : “root filesystem”

0x00380000-0x00480000 : “Configration”

0x00480000-0x01000000 : “User”

NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP

IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 2048) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.

NetWinder Floating Point Emulator V0.95 (c) 1998-1999 Rebel.com VFS: Mounted root (cramfs filesystem) readonly.

Freeing init memory: 60K

Warning: unable to open an initial console.

INIT: version 2.74 booting INIT: Entering runlevel: 3 Starting system logger: syslogd

Linux login:

<리스트 2> 시스템 부팅 메시지

� http://developer.axis.com/software/jffs/

� ftp://ftp.uk.linux.org/pub/people/dwmw2/mtd/cvs/mtd/mtd-jffs-HOWTO.txt/

� http://my.netian.com/~ykjung99/

� http://my.netian.com/~ykjung99/mtd/porting2.html

� Alessandro Rubini, 김인성∙류태 중 역, “Linux Device Drivers“, 한빛미디어, 2000

� The Linux Kernel - LDP(David Ressing)

� UNIX Kernel 완전분석으로 가는 길 - KLDP(박장수)

� Daniel P.Bovet & Marco Cesati, “Understanding the Linux Kernel“, Ore-lly, 2000