NOR Flash Memory 토막 지식

Flash 메모리의 경우 sector 단위로 erase가 가능하며 Erase 된 섹터는 모든 bit가 1이라는 값을 가지게 된다. Flash 메모리에 write 하는 작업은 각 bit별 값을 1 to 0으로 바꾸는 작업으로 반대로 0 to1로 바꾸는 write는 불가능하다. 즉 한번 0이된 bit를 1로 바꾸기 위한 유일한 방법은 해당 bit가 포함된 sector 전체를 erase하는 방법밖에 없다.

flash 메모리에서 각각의 bit는 (일반적으로)한개의 cell에 저장이 되는데 이 cell에 전하를 모두 잃으면 1(charge loss), 전하가 쌓이면(charge gain) 0으로 해석된다. 즉 flash erase는 해당 sector에 전하를 모두 비우는 과정이 된다.

때때로 flash에 저장된 값이 0 to 1 혹은  1 to 0으로 값이 변하는 오류가 발생하기도 하는데 이와 같은 bit flipping이 발생하는 이유가 flash memory 자체의 문제인지 SW의 오류로 발생하는 문제인지를 판단하기 어려운 경우가 많다.

먼저, 특정 bit의 값이  0 to1로 값이 변경되었다면 이는  아래와 같은 이유로 flash device의 문제일 가능성이 매우 높은다.   
  1. SW적으로 특정 bit만 0 to1로 변경할 수 없다. 앞서 설명한데로 이를 위해서는 해당 sector를 모두 지운 후 해당 bit만 1이되도록 다시 해당 sector 전체를 다시 write를 해야 하는데, 일부러 이렇게 SW를 작성할 이유가 없고, 이러한 버그가 생기기도 거의 불가능하기 때문이다.
  2. 해당 bit 정보를 저장하는 flash cell에 전류 leakage가 발생하여 전하가 방전(charge loss)되면, 값이 0 to1로 바뀔 수 있다. 먼저 flash에 0을 write할 때(Charge Gain) 전하가 충분히 주입되지 못하여 전하량이 0과 1의 경계부분에 있다가 시간이 지나면서 발생하는 미세한 방전으로 0 to 1로 값이 바뀔 수 있으며, 이와 같은 방전은 일반적으로 시간이 지남에 따라 자연스레 발생하며 cell 특성에 따라 특정 cell이 다른 cell보다 더 빠르게 방전 되기도 한다. 또한 X-ray등으로 냉납등을 조사하는 공정이 있다면, X-ray조사로 인하여 방전이 더 빠르게 발생하기도 한다.

만일 bit값이 1 --> 0 (charge gain)으로 변경되었다면 이 경우는 좀 더 골치 아픈 경우다. SW적으로 erase없이 1 --> 0으로 해당 bit값 만 바꿀 수 있으므로  0 --> 1로 바뀌는 경우보다는 SW 버그일 가능성이 조금 더 크다고 할 수 있겠다. HW적으로도 전하 loss가 아닌 전하 충전이 발생하여야 가능한 현상인데, 전하는 자연적으로는 방전되지 충전되지는 않는다. (물론 손상된 장치에서 특정 cell이 충전되지 않는다고 보증할 수는 없겠지만 )

참고 사이트
http://j102.net/lecture/3595


앞서서 한 cell에 한 bit가 저장된다고 했는데, 데이터 용량을 늘리기 위해 한 cell에 여러 bit를 저장하는 MirrorBit기술이나 MBC(Multi-Bit Cell) 기술등이 적용되고 있다. 이는 NAND flash에서의 MLC 기술과 유사한 것으로 이해된다.

NAND flash에서는 device특성상 불가피하게 발생하는  bit값 변경을 막기 위해서 ECC를 사용한 값 보정 기능이 오래전부터 사용되고 있으나 NOR에서는 최근에서야 ECC기능이 포함되고 있다. 특히 MLC 기술을 사용하는 NOR에 ECC 적용이 활발하게 이루어지고 있다

NAND flash memory 이해하기.

Block
- NAND flash는 여러개의 Block으로 구성되며, Block단위로만 erase가 가능함.
- 64KByte ~ 512KByte의 크기를 가짐.
Page
- 하나의 Block은 보통 512Byte~8KByte 크기를 가지는 다수의 page들로 구성됨.
- Page는 NAND flash의 읽기 및 쓰기의 기본 단위로, byte 혹은 word 단위로 읽고 쓸수 있는 NOR flash에는 없는 개념이다. 즉 읽기 쓰기가 byte단위로는 불가능하기 때문에 driver에서 이를 고려하여 주어야 한다.

OOB(Out of Band)- Page마다 따라오는 수~수백 바이트 정도 크기의 extra 데이터 영역으로 16의 배수 바이트인 경우가 많다. spare영역이라고도 불린다.
- 이 영역은 사용자에게는 숨겨진 영역으로 아래와 같은 용도로 사용됨

1. Bad Block Marking : 특정 블록이 bad block일 경우 한 Block안의 첫 page 혹은 마지막 page의 OOB에 이를 표시함. 예를들어 최근에 출시되는 삼성 NAND는 공장 출하시부터 존재하는 bad block을 표시하기 위해서 bad block의 마지막 page의 첫 Byte를 Non-FF value로 표시함. 이는 NAND flash별, 제조사별로 다르며 해당 디바이스의 data sheet에서 확인해야 한다.
2. ECC(error correction codes)
3. File System Info.: 특정 file system은 이부분을 사용하여 구현됨.

이 영역은 대부분 r/w가 모두 가능함. 하지만 이 영역에 공장 출하시부터 존재하는 Bad Block Marking 정보가 지워질 경우 이 정보를 다시 살릴 수 있는 방법이 없으므로 절대로 OOB영역의 bad block 정보를 지우지 않도록 주의하여야 함. 필요시 이 정보를 사용하여 BBT를 작성하게 됨.


SLC/MLC- NAND flash의 type에는 SLC/MLC가 있는데 이는 각각 Single Level Cell/Multi Level Cell을 뜻함.
- SLC는 MLC보다 수명이 10배가량 길지만 가격이 비쌈. 따라서 write가 자주 발생하는 데이터용으로 적합.
- MLC에는 고용량이면서 write가 자주 발생하지 않는 데이터에 적합. (ex, MP3, video등 multimedia files)

BBT (Bad Block Table)- BBT는 boot loader나 flash관련 tool을 사용하여 flash를 erase 할 때 OOB를 참조하여 만들 수 있으며, Linux의 경우 kernel과 boot loader간에 BBT생성 규칙과 구조에 대해서 상호 협의가 되어 있음.

- BBT는 flash file system에 따라서 사용하기도, 사용하지 않기도 하므로 필수적으로 필요한 것은 아님.
- BBT를 만들어 놓으면 특정 block의 bad 여부를 빨리 확인할 수 있지만, BAD block 데이터가 OOB의 데이터와 항상 sync.가 되도록 주의하여야 하며, BBT를 기록하려는 block이 BAD block일 경우 어떻게 처리해야 할 지 등도 고려하여야 함.
- BBT는 두 개의 Block을 사용하며 NAND flash내의 마지막 Block에서부터 거꾸로 non-bad block을 찾아, 첫번째 발견된 non-bad block이 primary BBT, 두번째로 발견되 non-bad block이 secondary BBT가 됨.
- BBT에는 한 Block당 2bit를 사용하여 NAND flash 전체의 Block의 상태를 기록하는데, 각각의 Block은 "good", "bad" , "reserved" 세개의 상태로 표현됨.
- File System에서는 "good"으로 표시된 영역만 사용함. BBT가 저장된 Block은 "reserved" 로 표시하여 File System에서 덮어쓰지 못하도록 알려줌.


그 외 특성- NAND flash로 부팅하기 위해서 첫번째 sector에 boot loader가 위치해야 하는데, 첫 sector가 bad block이면 boot loader가 위치할 수 없으므로, 대부분의 제조사는 1st block이 bad block이 아님을 보증함.
- NAND는 NOR와 달리 읽기 횟수에도 제한이 있다. NAND에서는 매번 특정 블럭을 읽을때마다 해당 정보를 저장하는 전하가 약해진다. (물론 정보를 잃은 block은 erase후 다시 사용가능하다) 따라서 읽기 전용 파일이라 하더라도 해당 정보를 너무 여러번 읽어 데이터가 지워지기 전에 다른 곳으로 옮겨서 저장하는것을 고려하여야 한다. 또한 전체 파일 시스템 내에 읽기 전용 블록이 고정되어 있을 경우, 쓰기 가능한 영역에 erase가 집중되어 해당 영역의 수명이 짧아지는 문제도 발생할 수 있다(NOR도 마찬가지). 따라서 NAND용 flash file system은 설계 시 읽기 전용 블록의 읽은 횟수를 count하여 데이터가 유실되기 전에 다른 블록으로 옮겨 줌으로써, 데이터의 유실을 막고 flash erase가 읽기 쓰기 영역에만 집중되는 것을 피하도록 설계되어야 한다.
- NAND flash를 부팅 장치로 사용하는 경우 부트로더와 OS 영역은 일반적으로 file system의 관리를 받지 못하는 영역으로, flash의 읽기 수명이 해당 제품의 예상 수명보다 짧을 경우에는 해당 영역을 주기적으로 지운 후 다시 기록하여 주거나, 부팅 실패시 backup 영역에서 부팅을 재시도하도록 하는 등의 대책을 세워야 한다. 이는 해당 시스템의 NAND controller와 부트로더의 구현에 따라 적절히 설계되어야 한다.
- NAND flash는 NAND controller의 도움을 받아야만 부팅장치로 사용될 수 있다. 만약 NAND controller가 HW적인 ECC를 지원한다면 부팅 속도가 NOR보다 빠를 수도 있다. 최근의 SoC들은 대부분 HW적인 ECC및 부팅기능을 지원하는 NAND flash controller를 가지고 있다.

참조 링크http://wiki.openmoko.org/wiki/NAND_bad_blocks
NAND bad block management by uboot and kernel
NAND 플래시 메모리의 이해
http://www.ibm.com/developerworks/kr/library/l-flash-filesystems/

Priority Inversion Protection

우선순위가 낮은 테스크가 소유한 자원을 우선순위가 높은 자원이 요청할 경우 대부분의 최신 OS는 우선순위 상속을 사용하여 문제를 해결한다. 우선순위 상속이 발생 시 낮은 우선순위 테스크의 우선순위가 높아지므로, 또다른 우선순위 역전이 발생할 수 있음을 주의해야 한다.

예를들어 flash driver에서 우선순위 상속이 발생하여 flash recalim등과 같이 CPU를 오래 소모하는 작업의 우선순위가 상승할 경우, 예기치 못한 우선순위 역전이 발생할 수 있다. flash reclaim자체는 write 작업에서만 발생하지만, 우선순위가 높은 task에서 요청한 flash read가 낮은 우선순위 task의 flash reclaim으로 지체 될 경우, OS는 priority inheritance로 이를 해결하려 하고, 이 때문에 flash reclaim이 높은 우선순위에서 실행되어, 예기치 못하게 오랜 시간동안 다른 테스크들의 실행을 막을 수 있는 것이다.

이와 같은 경우를 고려하여 우선순위 역전이 발생하지 않도록 appliacation들의 우선순위를 조절하고, flash driver의 서비스 처리 테스크 수를 늘려, 동시 접근에 대한 처리를 가능하도록 하여 문제를 해결할 수 있다.

MTD 이해하기...

MTD는 memory technology device의 약자로, char. device, block device와 같은 별도의 디바이스그룹이라고 간주하는것이 맞을 것 같다. 전통적으로 OS에서 장치를 char. device 와 block device 로 나누어왔기 때문에 flash memory용 디바이스 드라이버를 둘 중 어떤 것으로 분류 시켜야 하는지 고민이 생기게 된다, MTD는 분명 hdd를 대체하는 장치로 사용되고 있지만, 그 동작 특성이 block device와는 현저히 다르기 때문에 굳이 이를 block device 로 부르는 것은 옳지 않으므로 그냥 MTD 라고 부르는 것이 맞을 것 같다. MTD가 선보이기 시작하였을 때 개발자들은 hdd를 대신하여 MTD를 사용하기 위해서 MTD에 기존의 파일 시스템을 올리는 방법을 궁리하였고 가장 손쉬운 방법으로 고안한 것이 FTL 이다. FTL은 Flash devcie 를 block device처럼 보이도록 변환해주는 Layer로 이를 통해서 기존의 block device용으로 개발된 파일 시스템을 변경없이 flash memroy위에서 사용할 수 있게 되었다. 하지만, FTL 을 얼마나 잘 구현했는지에 따라서 성능이나 flash device의 수명이 큰 영향을 받게 된다. 실제로 가장 손쉬운 FTL구현을 생각해 보자, 특정 data를 overwrite하기 위해서 flash는 해당 sector를 모두 지우고 새 데이터를 포함한 sector전체를 다시 write해야 한다. 단지 한바이트의 데이터를 바꾸기 위해서 매번 해당 바이트가 포함된 sector전체를 지우고 다시쓰도록 FTL을 구현한다면, 손쉬운 구현이 되겠지만 flash device의 수명(10만~100만번 erase)이 아주 짧아질 수 밖에 없을 것이다. 따라서 다양한 방법을 사용해서 모든 flash sector가 균등하게 사용되도록 FTL을 구현해야 하며, 이를 Wear Leveling이라고 부른다.

USB drive같은 몇몇 flash devices는 FTL을 아예 H/W로 구현하여 제품에 내장하여 출시하고, 이런 장치는 MTD가 아닌 block device로 보는 것이 타당하다. 그렇지 않은 Flash device에서는 FTL을 소프트웨어로 구현하게 된다.

MTD는 때로는(오히려 더 자주, 일반적으로) device차체가 아닌, device driver를 지칭하는 말로 사용된다. 이 경우에는 MTD는 FTL이 해당 Device를 control 할 수 있도록 도와주는 Low Level Driver라고 생각하면 된다. 제조사 별로, device별로 device를 제어하는 방법이 조금씩 다르기 때문에 MTD Layer에서 이를 일반화하여 주는 것이다. 따라서 FTL은 하위 device의 제조사나 특정 제품에 상관 없이 구현 될 수 있는 것이다. 아래는 FTL 을 사용하는 시스템의 구조를 표현한 것이다.

File System for block device
-----------------------------
FTL
-----------------------------
MTD Layer

최근에는 flash device를 위해서도 몇몇 파일 시스템이 개발되었으며, 이 경우 FTL이 없이 file system이 MTD Layer위에 올리기도 한다.

File System for flash device
-----------------------------
MTD Layer

하지만 필요에 따라서 flash file system이 FTL을 포함하고 있는 경우도 있으며, 이 경우의 FTL은 위에서 설명한 FTL과는 약간 다른 일을 수행하게 된다. 즉 최초의 FTL은 flash device를 block device로 변환시켜주기 위해 사용한 library 나 h/w를 의미하였으나, 최근에는 좀더 광범위한 의미로 사용되고 있다.

읽어볼만한 자료들
http://www.linux-mtd.infradead.org/faq/general.html
http://blog.naver.com/idkiss?Redirect=Log&logNo=50018755390
http://lsea.tistory.com/160
http://www.hongikcom.com/entry/4FTLFlash-Translation-Layer