UART 가 System에서 동작하기 위해서는 Register, TX,RX FIFO, ISR 등 여러 요소들이 필요하다. 이번 글에서는 각각의 요소들을 살펴보겠다.

1. UART에서 사용하는 주요 Register 및 용도

 Register Name Description 
Transmitter Holding Register (THR)  전송할 Char저장
Receiver Buffer Register (RBR)  전송 받은 char 저장
Interrupt Enable Register (IER)  UART가 trigger 할 Interrupt 종류 설정
FIFO Control Register (FCR)   FIFO RCV TX Set/Clear, Interrupt Trigger level 설정
Interrupt Identification Register (IIR)  Trigger된 Interrupt의 종류 저장(RX, TX, Timeout, RLS)
Line Status Register (LSR) frame, parity, overrun error 정보 저장. DR, THR 상태 저장

FIFO Enable인 경우, FIFO에 Data full 상황에서 데이터를 읽기 위해서는 FIFO Size 만큼 RBR을 읽으면 되고, FIFO Data Empty 상황에서 데이터를 보낼 경우에는 THR에 FIFO Size 만큼 쓰면 된다. 즉 RX FIFO의 첫 Element가 RBR이 되고, TX FIFO 의 마지막 Element가 THR이라고 생각하면 된다.

2. UART Interrupt 가 발생하는 상황
 * THRE(Transmitter Holding Register Empty) Interrupt : THR이 비었으니 전송할 데이터를 보내라고 요청
 * RD(Received Data Available) Interrupt: RBR에 값이 있으니 데이터를 읽으라고 요청.
   (FIFO Enable인 경우 설정한 Trigger level에 따라 Interrupt 발생.)
 * Timeout interrupt: RBR 이 비어있지 않은 상황에서 일정시간동안 데이터를 받지 못하거나 CPU가 데이터를 읽어가지 않았을 때 발생.

3. Serial Interrupt Service Routine (linux/drivers/serial/8250.c)
  UART에서 발생한 모든 Interrupt는 serial8250_interrupt() 에서 처리된다.

 static irqreturn_t serial8250_interrupt(int irq, void *dev_id)
{
    struct irq_info *i = dev_id;
    struct list_head *l, *end = NULL;
    int pass_counter = 0, handled = 0;

    DEBUG_INTR("serial8250_interrupt(%d)...", irq);

    spin_lock(&i->lock);

    l = i->head;
    do {
        struct uart_8250_port *up;
        unsigned int iir;

        up = list_entry(l, struct uart_8250_port, list);

        iir = serial_in(up, UART_IIR);
        if (!(iir & UART_IIR_NO_INT)) { //Pending된 Interrupt 가 있는 경우 (rx, tx, timeout 모두)
            serial8250_handle_port(up); //RX 또는 TX에 따라 Transmit or Receive 수행

            handled = 1;                                                                                  
                                                                                                          
            end = NULL;                                                                                   
        } else if (up->port.iotype == UPIO_DWAPB &&                                                       
              (iir & UART_IIR_BUSY) == UART_IIR_BUSY) {                                                   
            /* The DesignWare APB UART has an Busy Detect (0x07)                                          
             * interrupt meaning an LCR write attempt occured while the                                   
             * UART was busy. The interrupt must be cleared by reading                                    
             * the UART status register (USR) and the LCR re-written. */                                  
            unsigned int status;                                                                          
            status = *(volatile u32 *)up->port.private_data;                                              
            serial_out(up, UART_LCR, up->lcr);                                                            
                                                                                                          
            handled = 1;                                                                                  
                                                                                                          
            end = NULL;                                                                                   
        } else if (end == NULL)                                                                           
            end = l;                                                                                      
                                                                                                          
        l = l->next;                                                                                      
                                                                                                          
        if (l == i->head && pass_counter++ > PASS_LIMIT) 
        { //isr 의 수행 시간 제한
             /* If we hit this, we're dead. */                                                             
            printk(KERN_ERR "serial8250: too much work for "                                              
                "irq%d\n", irq);                                                                          
            break;                                                                                        
        }                                                                                                 
    } while (l != end);                                                                                   
                                                                                                          
    spin_unlock(&i->lock);                                                                                
                                                                                                          
    DEBUG_INTR("end.\n");                                                                                 
                                                                                                          
    return IRQ_RETVAL(handled);                                                                           


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

,
보통 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
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.

,

USB On-The-Go

Device Driver 2009. 5. 19. 03:13

USB OTG기술은 PC 나 다양한 usb 저장매체와 연결해서 데이터를 이동할수 있는 기술이다.

PC없이도 호스트와 디바이스 연결시에 사용하는 케이블인데 이 기능을 이용하려면

장치가 OTG를 지원해야 하며 USB2.0 에서만 작동한다. 

 

 

Due to its widespread acceptance, USB is becoming the de facto industry standard for connecting peripherals to PCs and laptops. Many of the new peripherals now using USB are also portable devices.

As these portable devices increase in popularity, there is a growing need for them to communicate directly with each other when a PC is not available. The On-The-Go Supplement addresses this need for mobile interconnectivity by allowing a USB peripheral to have the following enhancements:

  • Limited host capability to communicate with selected other USB peripherals
  • A small USB connector to fit the mobile form factor
  • Low power features to preserve battery life

Revision 1.2 of the USB On-The-Go Supplement, and other information regarding USB On-The-Go, is available below. Compliance testing for low-speed, full-speed and high-speed USB On-The-Go products is available now.

In addition to passing USB-IF compliance testing and inclusion of its USB On-The-Go products on the Integrators List, companies wishing to use the certified USB On-The-Go logos must have a current USB-IF Trademark License Agreement on file.

 

On-The-Go            usb OTG 포트

 

 

글: Jon Titus, 시니어 테크니컬 에디터

‘USB On-The-Go’를 안다면 노트북에 USB 주변기기를 연결해 작업할 필요가 없다. USB OTG(On-The-Go)는 소형 휴대용 디바이스 간의 USB 통신을 간소화하는 기술이다. 현재 USB 2.0 사양에는 새로운 호스트-주변기기 관계를 정의하고, 하우스키핑 프로토콜을 지정하며, 저전력 모드를 설정하고, 휴대 기기에 작은 USB 커넥터를 제공하는 ‘On-The-Go’ 기능이 포함돼 있다.

대부분의 설계 엔지니어들은 USB의 표준 호스트-주변기기 통신에 대해 알고 있다. 물론, 호스트로 사용되는 PC, 주변기기로 작동하는 프린터, PDA 같은 디바이스를 포함해서 말이다. 그렇지만 OTS 사양은 PC 외의 디바이스에 대한 방법을 정의해 주어 주변기기와의 직접적인 통신을 할 때 제한된 호스트 역할을 가정한다. 중간에 PC 없이 컬러 프린터와 디지털 카메라를 직접 연결하는 것을 생각해 보면 쉽게 이해할 수 있을 것이다. 이러한 연결은 특정 디바이스가 항상 호스트의 역할을 하는 관계로 P2P 연결은 아니다.

USB OTG 영역에서 어떤 디바이스는 두 가지 역할을 한다. 즉, 호스트와 주변기기의 역할을 하는 것이다. 앞서 언급한 컬러 프린터는 PC에 연결돼 있을 때 주변기기로 작동하고, 디지털 카메라에 연결되면 호스트의 역할을 한다. 마우스와 키보드 같은 디바이스는 주변기기의 역할만 한다. OTG 작동은 USB 2.0 사양을 보완하기 때문에, 기존의 USB 디바이스는 OTG 가용(enabled) 디바이스와 함께 작동할 수 있다. 또한 각 케이블의 끝에 OTG 디바이스를 연결할 필요가 없다.

OTG 가용 디바이스는 Mini-A 또는 Mini-B 플러그를 꽂을 수 있는 새로운 Mini-AB 콘센트를 사용한다. 그래서 OTG 호환 케이블의 경우 한 쪽 끝에는 Mini-A 플러그를 제공하고 다른 쪽에는 Mini-B 플러그를 제공한다(호스트 전용 디바이스는 Mini-A 콘센트를 제공하고, 주변기기 전용 디바이스는 Mini-B 콘센트를 제공한다). USB 표준이 네 가지 신호를 지정했음에도 불구하고, ‘Mini’ 커넥터에는 연결된 디바이스를 호스트나 주변기기로 식별하는 다섯 번째 신호가 포함되어 있다. Mini-A 플러그는 이 ID 핀을 단락시켜 호스트로 작용하는 로컬 전자기기에 신호를 보내기 위해 접지한다(그림1). 한편, Mini-B 플러그는 ID 핀이 연결이 끊긴 상태로 유지하고, 연결된 디바이스에서 주변기기로 작동하도록 경고한다. 이런 연유로, 두 OTG 디바이스를 연결하는 케이블의 방향은 호스트-주변기기 관계를 결정한다.

 

플러그 방향은 연결된 OTG 디바이스가 HNP(Host-Negotiation Protocol) 세션을 반대로 만드는 초기 구성을 결정한다. 사용자가 OTG를 지원하는 PLC(프로그래머블 로직 컨트롤러)와 PDA를 연결했다고 가정해 보자. 케이블 방향이 PDA를 호스트로 설정하고 PLC를 주변기기로 설정한다. 하지만 PLC에 더 많은 처리 능력이 있고 더 많은 데이터를 저장하므로 HNP 세션은 PDA를 주변기기로 작동하도록 구성하고 PLC를 호스트로 작동하도록 구성한다. 하지만 OTG 프린터에 연결하면 PDA가 호스트로 작동한다.

 

또한 USB OTG 사양에는 주변기기가 OTG 호스트에서 서비스를 요청하도록 허용하는 SRP(Session-Request Protocol)가 포함된다. OTG 연결을 통해 통신이 되지 않으면 호스트 디바이스가 USB 전원 출력(VBUS)을 꺼서 전원을 절약한다. 서비스를 요청하기 위해 OTG 주변기기는 VBUS 전력선에 펄스를 발생시켜 호스트를 “깨운다”. OTG 호스트가 응답을 하고 버스 동작이 두 디바이스 간에 시작된다(또한 OTG 주변기기는 VBUS 전력선을 모니터링함으로써 표준 USB 호스트에서 제공하는 전원이 인가된 VBUS 전력선에 펄스가 발생하지 않도록 한다).

 

USB 2.0 호스트는 외부 디바이스에 대해 5V에서 500mA(또는 Bus-powered 허브에 대해 100mA)를 공급해야 한다. 하지만 OTG 사양은 VBUS 전력선의 5V에서 최소 8mA를 요구한다.

 

부분참조 : www.ecnkoreamag.com

               www.usb.org

[출처] USB OTG|작성자 자명


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

,