'Device Driver/Memory'에 해당하는 글 5건

보통 h/w개발자와 s/w개발자가 의논해서 "메모리 맵"을 결정하는 것으로 알고 있습니다.
일단, 메모리 맵이 결정이 되면, 이것에 의해서 h/w개발도 하고,
s/w 작업(kernel,driver porting등)도 하는 것으로 알고 있습니다.

그리고, 메모리 맵(또는 h/w설계)에 이 결정되면,
이것에 의해서, physical address가 정해지구요.
이렇게 정해진 각각의 physical address와
이에 해당되는(매칭되는) virtual address 배정(매핑)을 하게 됩니다.
이러한 "physical address <-> virtual address " 메모리의 매핑 작업은
[아래]의 예와 같이 linux/arch/arm/mach-pxa/xxx.c 파일에서 해 주는 것으로 알고 있습니다.

예를 들어서…커널 2.4 버전에서… xxx.c 파일의 경우는 [아래]와 같이 해줍니다.

===============[아래]====================================================================
static struct map_desc cerf_io_desc[] __initdata = {
/* virtual physical length domain r w c b */
{ 0xe8000000, 0x00000000, 0x02000000, DOMAIN_IO, 1, 1, 0, 0 }, /* Flash bank 0 */
{ 0xf0000000, 0x08000000, 0x00100000, DOMAIN_IO, 1, 1, 0, 0 }, /* Crystal Ethernet Chip */
#ifdef CONFIG_SA1100_CERF_CPLD
{ 0xf1000000, 0x40000000, 0x00100000, DOMAIN_IO, 1, 1, 0, 0 }, /* CPLD Chip */
{ 0xf2000000, 0x10000000, 0x00100000, DOMAIN_IO, 1, 1, 0, 0 }, /* CerfPDA Bluetooth */
{ 0xf3000000, 0x18000000, 0x00100000, DOMAIN_IO, 1, 1, 0, 0 }, /* CerfPDA Serial */
72 #endif73 LAST_DESC74 };
==========================================================================================

즉...
physical address는 메모리맵을 기준으로 자동적 특정 번지로 결정이 됩니다.
그렇다면, virtual address는 어떤 기준(방법)으로 physical address와 매칭을 시키나요 ?
즉…physical address에 대응되는 virtual address는 어떻게 결정을 하는지요?
좋은 하루 되시구요…답변 주시면…감사드리겠습니다.





물리메모리 가상메모리 매핑방법 | 답장: 2개(RSS) | 본문에 답장
정렬 :  

답장 익명 (2007년 06월 21일 오후 02:47)
설계하시는 분이 하기 나릅입니다만...
기본적으로는 linux\Documentation\arm\memory.txt 파일을 보시면
암에서 메모리 설계에 대한 기본 구조가 있습니다.
그안에서 하드웨어에 맞게 구성하시면 됩니다.
[ 이글에 답장 | 본문에 답장 ]

답장 익명 (2007년 06월 28일 오후 03:30)
물리주소와 가상주소의 매핑은 어떻게 결정을 하는게 아니고.
위에 보니까 PXA27x CPU같은데 CPU 데이터시트 뒤쪽 memort map and registers부분 챕터를 찾아보시면 이미 CPU에서 대응해서 정해져 있다는걸 아실 수 있습니다.


'Device Driver > Memory' 카테고리의 다른 글

ioremap() VS. phys_to_virt()  (0) 2009.06.17
램디스크를 쓸것인가? MTD를 쓸것인가?  (0) 2009.06.08
MTD(Memory Technology Device)  (0) 2009.06.08
Common Flash Interface(CFI)  (0) 2009.06.08

WRITTEN BY
RootFriend
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.

,
ioremap()함수와 phys_to_virt()함수는, 둘다 물리주소를 가상주소로 바꿀때 쓰인다.

하지만 차이점은 존재한다.

ioremap()함수는 요구된 물리 주소로 시작하는 영역을 커널 모드에서 사용할 수 있도록 가상 주소 공간으로 등록 하지만,

phys_to_virt() 함수는 PAGE_OFFSET과 같은 값을 이용하여 변환 처리만 계산하기 때문이다.

void* ioremap(unsigned long offset , unsigned long size);
반환 값: 가상 주소의 선두 주소
offset : 물리 주소의 시작 주소
size : 크기

void* phys_to_virt(unsigned long address);
반환 값 : 변환된 가상주소
address : 물리 주소


* PAGE_OFFSET 매크로 상수값 : 물리 주소와 가상 주소간에 변환을 위해 쓰이며, #include <asm/page.h>에 정의된다.

WRITTEN BY
RootFriend
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.

,
APK003 램디스크를 쓸것인가? MTD를 쓸것인가?
==============================================

1. 개요

이 문서는 ESP-NS에서 동작하는 응용 프로그램을 실장하는 파일 시스템으로 램디스크를 사용할것인지
아니면 MTD를 사용할 것인지를 결정할때 도움을 주기 위한 문서입니다.

작성자 : 유영창
frog@falinux.com
작성일 : 2004년 9월 6일
수정일 :

관련된 ADK( Application Developer Kit ) 디렉토리

없음

2. 파일 시스템

응용 프로그램이 동작하기 위해서는 파일 시스템이 반드시 필요합니다.

윈도우즈 프로그램만 하시던 분들은 이 파일 시스템에 대한 관심이 필요한 시점은 딱 한번! 윈도우 운영체제 설치시에만 필요합니다. NTFS 라는 이름을 가지는 것이 바로 그것입니다.
(물론 설치가 빈번해지면 이 한번이 여러번 되죠 ㅜㅜ)

그래서 파일 시스템이 왜 필요한지도 모르고 살아갑니다.(부럽습니다.)

그러나 임베디드 시스템에 리눅스를 사용하고 응용 프로그램을 적재하는 과정에서는 이 파일 시스템에 대한 이해가 필요합니다.더불어 램디스크나 MTD와 같은 블럭 디바이스 드라이버에 대한 이해도 필요합니다.

솔찍히 저도 윈도우 프로그램만 작성하다가 리눅스로 넘어 오면서뭐 이딴것을 알아야 하는가에 대한 고민도 했읍니다. 하지만 어쩔 수 없이 알아야 하는 내용입니다.

우리는 두가지 개념에 대하여 이해가 필요합니다.

첫번째는 저장 매체를 다루는 블럭 디바이스 드라이버와 관련된내용입니다.

두번째는 저장 매체에 파일을 저장하고 관리할 수 있는 파일시스템에 대한 내용입니다.


2. 블럭 디바이스 드라이버

임베디드 시스템은 전원이 소실되어도 데이터를 지속적으로 보관하거나 보드에서 동작하는 응용프로그램( 펌웨어라고도 합니다. )을 담고 있는 물리적인 매체가 필요합니다.

이런 저장 매체에는 ROM을 사용하기도 하고 RAM을 사용하기도 하고 플래쉬 메모리를 사용하기도 하고 하드 디스크를 사용하기도 합니다.

그러나 이 글은 ESP 보드에서 동작하는 응용 프로그램울 작성하는 방법에 대한 내용이므로 RAM 과 플래쉬 메모리와 관련된 이야기만 하겠읍니다.

여기서 의문을 제기하시는 분이 있을 겁니다.

"RAM 이라니? 그건 전원이 나가면 내용이 소실되는데?"

맞습니다. RAM은 전원이 나가면 내용이 소실됩니다. 그러나 이야기 전개상 필요하므로 넘어 갔으면 좋겠읍니다.
( 싫으면 이 글을 더 이상 읽지 마세요.. 쩝 )

리눅스에서 저장 장치를 다루는 디바이스 드라이버가 블록 디바이스 드라이버 입니다. 물론 이 저장 장치라는 것은 소프트웨어 관점으로 보았을때 하드 디스크와 같은 특성을 가지는 것들을 말합니다.

임베디드 리눅스에서 블록 디바이스 드라이버로 주로 사용되는 것에는 램디스크,MTD 가 있읍니다.

램디스크는 램을 이용해서 하드 디스크를 흉내내는 것입니다.
MTD는 플래쉬 메모리를 이용해서 하드 디스크를 흉내 내는 것입니다.

램디스크는 보드에 장착된 램을 이용합니다.

MTD는 NOR 나 NAND 플래쉬 메모리를 이용하여 구현합니다

여기서 잠깐 저장 장치로서 NOR 와 NAND 플래쉬중 어떤 것이 우수한가를 살펴 봅시다.

제 경험상 NOR 계열의 플래쉬보다는 NAND 계열의 플래쉬가 저장장치로 사용하기에는 더 좋습니다. 데이터를 써 넣는 속도가 더 빠르고 데이터를 읽어 오는 속도나 용량 대비 단가가 더 싸고 안정적입니다.

하드웨어 설계자 입장에서 보면 NAND 계열의 플래쉬보다는 NOR 계열의 플래쉬가 더 유리합니다. 왜냐하면 부팅 롬으로 바로 이용이 가능하고 부가 회로가 별로 필요 없기 때문입니다.

대량 양산 보드에서는 가격적인 문제라면 NAND가 유리합니다. 반면 양산 생산 관리에서는 NOR가 유리합니다

ESP 보드는 NAND 플래쉬를 사용한 저장방식입니다 (저희 회사 보드들이 다 그렇죠... 다 경험의 산물입니다. )

아무래도 이 글은 ESP 와 관련된 보드를 중심으로 설명하는 것이므로 NAND 플래쉬 관점에서 이야기 해야 겠죠...

어찌 되었든 ESP 보드는 두가지 블럭 디바이스 드라이버를 사용할 수 있읍니다.

1) 램을 이용한 램디스크 시스템
2) NAND 플래쉬를 이용한 MTD 시스템

ESP 보드는 처음 판매될 때 램디스크를 이용하고

/app 디렉토리에 NAND 플래쉬에 접근할수 있는 MTD 시스템이 마운트되어 있읍니다.

이 두가지 장치는 모두 동시에 사용 가능합니다.

3 파일 시스템

램디스크나 NAND 플래쉬를 이용한 MTD가 있다고 해서 파일을 읽거나 쓸수는 없습니다.

왜냐하면 해당 저장 장치에 어떤식으로 파일을 기록해야 하는 방법이 없기 때문입니다

즉 블록 디바이스 드라이버라는 것은 단순히 섹터단위로데이터를 어떻게 기록하고 읽는 방법만 제공하기 때문입니다.

그러나 파일을 읽고 쓰기 위해서는 디렉토리도 관리해야 하고 파일 명이나 기타 정보도 관리해야 합니다.

이렇게 섹터단위로 읽고 쓸수 잇는 장치에 파일을 저장하고 읽도록 하는 것이 파일 시스템입니다

리눅스는 이런 파일 시스템으로 사용할수 있는 것은 여러가지가 있읍니다. 가장 대표적인것인 EXT2 라는 파일 시스템입니다.

ESP 보드에서는 EXT2 파일 시스템은 램디스크에 사용하고 있습니다. PC 의 하드 디스크에는 최근에는 EXT3 가 가장 많이 사용되고 있습니다. (배포판이 이 파일 시스템을 사용하기 때문이 가장 큰 이유죠 )

이외에도 ESP 보드에서는 YAFFS 파일 시스템을 사용합니다. 이 YAFFS 파일 시스템은 리눅스에 정식으로 포함되어 있지 않습니다. 하지만 NAND 파일 시스템에 사용하기에는 제 경험상 이놈이 딱! 입니다.

NAND 플래쉬나 NOR 플래쉬에 사용되는 것으로는 JFFS2 가 있읍니다.
NOR 플래쉬라면 아무래도 JFFS2 가 더 좋습니다.

ESP 보드에는 YAFFS 를 사용하기 때문에 JFFS2 에 대한 이야기는 하지 않겠지만 여러분에게 주의 사항은 이야기 하고 싶습니다.

JFFS2는 치명적인 결함이 있습니다. ( 지금은 고쳐졌는지 잘 모르겠읍니다. ) JFFS2에 사용하는 파티션이 2에 지수 단위로 나누어 지지 않으면 지속적인 파일을 기록하는 경우에는 리눅스 시스템이 죽어 버립니다.
원인은 저도 잘 모르겠읍니다. ㅜㅜ
또 플래쉬의 크기가 커지면 시스템 메모리를 많이 사용해 버립니다.  32M 정도의 NOR 플래쉬라면 큰 문제는 없지만 그 이상의 메모리를 사용하게 되면 문제가 될 소지가 있읍니다.

이 점은 JFFS2 파일 시스템을 사용하시는 분들은 조심하시기 바랍니다.

어쨌든 여기서 파일 시스템을 정리하면 다음과 같습니다.

RAM : 램디스크 : EXT2
NAND 플래쉬 : MTD : YAFFS
NOR 플래쉬 : MTD : JFFS2

이것이 ESP 보드에 사용되는 파일 시스템의 구성 정리 입니다.


4. 램디스크와 램디스크 이미지

램디스크는 램에 하드 디스크처럼 저장을 할수 있도록 합니다.

그..런..데

램은 전원이 나가면 소실됩니다.

원래 램디스크는 다음과 같은 과정을 거쳐야 사용 가능합니다.

[root@ESP /] mkfs.ext2 /mtd/ram0
[root@ESP /] mount /mtd/ram0 /test

이렇게 하면 /test 디렉토리에 파일을 만들면 램디스크에 데이터를 저장할 수 있읍니다.

그러나 보드에 전원이 나가면 데이터는 소실됩니다.  또 보드가 부팅될 때 램디스크를 루트로 사용하려고 해도
파일 시스템도 안 만들어져 있고 내용도 없기 때문에 루트 파일 시스템으로 사용이 불가능합니다.

그래서 이런 점을 해결하기 위해서 램디스크 이미지라는 것을 사용합니다.

램디스크 이미지는 램디스크에 EXT2 포맷으로 만들고 필요한 파일을 모두 넣은 후에 램 디스크의 내용을 모두 파일 형태로 복사한 파일입니다.리눅스 커널은 이 파일의 내용이 있는 위치를 지정하면 해당 내용을 부팅시에 램디스크에 모두 옮겨 넣습니다. 이때 커널은 램디스크 이미지가 압축되어 있다고 가정합니다.

ESP 에서는 이지부트가 이 압축된 램디스크 이미지를 특정 램에 복사해 놓고 커널 부팅전에 커널에 이 이미지 데이터가 어디 잇는지를 알려 줍니다.

그래서 커널은 부팅 후 루트로 램디스크 이미지를 사용 할수 있는 겁니다.

5. 램디스크를 사용할 것인가 아니면 MTD에 YAFFS를 사용할 것인가

이제 결론적으로 이 두가지에 대한 결론을 내려 봅시다.

램디스크 이미지를 이용하여 응용 프로그램을 탑재하고 사용할것인가 아니면 YAFFS 파일 시스템을 이용하여 NAND 플래쉬를 이용하여  응용 프로그램을 탑재하고 사용할 것인가..

이 두가지 중 하나를 선택하기 위해서는 각각의 장단점을 알아야 합니다.

5.1 램디스크 이미지를 이용하는 방법의 장점 과 단점

램디스크 이미지를 이용하는 장점은 딱! 두가지 입니다.  그 외에는 장점이 별로 없읍니다.

첫번째 장점은 시스템이 안정적이라는 것입니다.

램디스크는 응용 프로그램이나 기타 등등의 이상이 있을 때 파일 시스템을 박살내더라도 전원만 껐다가 키거나 리부팅이 되면 원위치가 됩니다.

두번째 장점은 많은 수량의 보드를 제작할때 쉽게 전체 시스템을 설치할 수 있습니다.
즉 부트로더 + 커널 + 램디스크 이미지 를 한꺼번에 실장하면 됩니다.

그...러...나

가장 큰 단점은 개발시에 무척 불편하다는 것입니다.  항상 램디스크 이미지를 매번 만들어야 합니다.
(물론 nfs 파일 시스템을 이용해서 개발하고 나중에 한번에 써 넣어도 되죠 )

또 다른 단점은 응용 프로그램의 업그레이드를 하려면 골치아프다는 것입니다. 원격지에서 자동으로 응용 프로그램을 업데이트 하려면 결국  램디스 이미지를 통째로 바꾸어야 하는데 이게 만만한 작업이 아닙니다.


5.2 YAFFS 파일 시스템을 사용할때의 장점 과 단점

YAFFS 파일 시스템을 이용해서 개발할 때 가장 큰 장점은  개발할때 편리하다는 것입니다.

하드 디스크에 저장하는 것과 같은 기분으로 응용 프로그램이나 기타 데이터를 그대로 복사하여 사용하면 됩니다.

/etc/ 나 기타 등등에 필요한 파일을 복사만 하면 전원을 껐다가 켜도 보관이 됩니다.

이에 반해 많은 제품을 양산하기에는 일일히 복사해야 하는 단점이 있고 파일 시스템이 깨지는 경우 ( 거의 없읍니다만 ) 시스템이 사용 불가능해 지는 단점이 있습니다.

5.3 결론

저는 램디스크 이미지 형식을 사용하는 것보다 MTD에 YAFFS 을 이용하기를 권합니다.

개발시에 편하고 생각보다도 안정적이기 때문입니다.  실제로 제가 YAFFS에서 데이터가 깨지는 경우는 본적이 없읍니다.  (하드웨어가 고장나서 깨지는 경우는 보았읍니다. ㅜㅜ )

가장 큰 이유는 저 같은 게으른 사람에게는 개발시에 무척 편리하다는  것입니다.

'Device Driver > Memory' 카테고리의 다른 글

물리메모리 가상메모리 매핑방법  (0) 2009.06.22
ioremap() VS. phys_to_virt()  (0) 2009.06.17
MTD(Memory Technology Device)  (0) 2009.06.08
Common Flash Interface(CFI)  (0) 2009.06.08

WRITTEN BY
RootFriend
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.

,

MTD 서브시스템은 플래시 메모리 IC아 같은 다양한 메모리 형태의 장치를 지원하기 위해 만들어진 기술이다.

MTD 계층 구조는 메모리 장치가 사용하는 상위 레벨의 데이터 구조와 저장 형식을 하위 레벨의 장치와 관련된

복잡한 구조와 분리시킬 수 있다.

 

                                                   < MTD system Organization >

 

1. MTD 서비스 활성화하기

 

MTD 서비스를 이용하기 위해서는 커널이 MTD를 사용할 수 있도록 구성되어 있어야 한다.

 

.config 파일의 MTD 기본 구성 옵션

 

 1) CONFIG_MTD=y

 2) CONFIG_MTD_CHAR=y

 3) CONFIG_MTD_BLOCK=y

 4) CONFIG_MTD_MTDRAM=m

 5) CONFIG_MTDRAM_TOTAL_SIZE=8192

 6) CONFIG_MTDRAM_ERASE_SIZE=128

 

1) MTD 활성화

2) char device 모드에서 접근 활성화 (순차적으로 한 바이트씩 read/write)

3) block device 모드에서 접근 활성화 (블럭단위로 data를 read/write)

4) MTD device가 없더라도 MTD 서브시스템을 테스트해 볼 수 있는 special test driver

5) 4) driver의 전체 크기 = 8192 KB

6) 4) driver의 삭제 크기 = 128 KB

 

2. MTD 기초

 

1 장에서 언급한 test driver를 통해 MTD 장치를 용해서 JFFS2 이미지를 mount 할 수 있다.

리눅스 커널은 ext2 나 다른 파일 시스템 이미지는 loopback device에서 직접 mount 할 수 있지만 JFFS2

파일 시스템을 직접 mount 하는 기능은 지원하지 않는다. 이때 test driver를 이용한다.

 

 1) #modprobe jffs2

 2) #modprobe mtdblock

 3) #modprobe mtdram

 4) #dd if=jffs2.bin of=/dev/mtdblock0

 5) #mkdir /mnt/flash

 6) #mount -t jffs2 /dev/mtdblock0 /mnt/flash

 7) #ls -l /mnt/flash

 

1) jffs2 모듈을 커널에 로드

2,3) mtdblock과 mtdram 모듈을 적재

4) 리눅스 dd 명령으로 jffs2 파일 시스템 이미지를 mtdblock 장치를 이용해서 MTD RAM 테스트 드라이버에 복사

6) jffs2 파일 시스템 이미지를 MTD block device 에 복사한 후에 mount 한다.

   

MTD pseudo-device가 mount 되면 jffs2 파일 시스템 이미지를 원하는대로 이용할 수 있다.

만약 변경된 내용을 저장하고 싶으면 그 파일 시스템 내용을 다시 다른 파일로 백업해야 한다.

 

 #dd if=/dev/mtdblock0 of=./your-modified-fs-image.bin

 

이 명령어는 커널 구성시에 지정한 mtdblock0 장치와 같은 크기의 파일 your-modified-fs-image.bin을 만든다.

 

이처럼 진짜 플래시 메모리가 없는 개발 시스템에서 MTD 서브시스템에 대한 기본 개념을 확인해 볼 수 있다.

 

2.1 MTD 구성하기

  • 플래시 장치의 파티션 지정하기
  • 플래시 메모리의 종류와 주소 영역 지정하기
  • 플래시 IC에 대한 올바른 플래시 드라이버 구성하기
  • 알맞는 드라이버를 커널에 포함하도록 구성하기

3. MTD 파티션

플래시 메모리는 파티션이라고 부르는 몇 개의 부분들로 나누어져 MTD 서브시스템은 이런 플래시 파티션을

지원해 주는데 이를 위해 MTD partitioning support 이라는 항목이 활성화되어 있어야 한다.





WRITTEN BY
RootFriend
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.

,

- Wikipedia의 내용을 번역 -

 

Common Flash Interface(CFI)는 Intel, AMD, Sharp 그리고 Fujistu에 의해 공동 개발된 오픈 스탠다드이다. 스펙에 대한 개요는 AMD에 서 얻을 수 있다. CFI는 JEDEC의 비휘발성 메모리 분과 위원회의 승인을 얻은 오픈 스탠다드이다. 이 말은 모든 플래시 메모리 제조업체가 제약없이 구현할 수 있음을 뜻한다. CFI의 뒷받침되는 사상은 여러 업체들이 만드는 플래시 메모리에 대해서 현재 그리고 앞으로 교환성(또는 호환성)이다. 개발자는 하나의 드라이버로 다른 종류의 플래시 메모리를 사용할 수 있다.

플래시 메모리 내부의 정보는 메모리 사이즈, 바이트, 워드 설정, 블록 설정, 전압과 타이밍 이다.

 

이 개념의 장점은

1. 기본적으로 시스템 소프트웨어 플래쉬에 대한 정보를 거의 가지지 않는다

2. 코드를 재작성없이 다시 사용할 수 있으므로 플래시 메모리의 비용을 절감할 수 있다.

3. 현재의 소프트웨어 시스템을 이전의 것과 같이 쉽고 빠르게 적용할 수 있다.




WRITTEN BY
RootFriend
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.

,