uClinux 平台下的Flash 存储技术

liuzhixian

uClinux 平台下的Flash 存储技术
http://www.dzkf.cn/html/qianrushixitong/2007/0626/2289.html
1 Flash类型与技术特点
    Flash 主要分为NOR 和NAND 两类。下面对二者作较为详细的比较。
1.1 性能比较
   
Flash 闪存是非易失存储器，可以对存储器单元块进行擦写和再编程。任何Flash 器件进行写入操作前必须先执行擦除。NAND
器件执行擦除操作十分简单；而NOR则要求在进行擦除前，先要将目标块内所有的位都写为0。擦除NOR 器件时是以64～128KB 的块进行的，执行一
个
写入/ 擦除操作的时间为1~ 5s ；擦除NAND 器件是以8～32KB 的块进行的，执行相同的操作最多只需要4ms。执行擦除时，
块尺寸的不同近一步拉大了NOR 和NAND之间的性能差距。统计表明，对于给定的一套写入操作( 尤其是更新小文件时) ，更多的擦除操作必须在基于
NOR 的单元中进行。因此， 当选择存储解决方案时， 设计师必须权衡以下的各项因素。

• NOR 的读取速度比NAND 稍快一些。
• NAND 的写入速度比NOR 快很多。
• NAND 的擦除速度远比NOR 快。
• 大多数写入操作需要先进行擦除操作。
• NAND 的擦除单元更小，相应的擦除电路更少。

1.2 接口差别
    NOR Flash 带有SRAM 接口，有足够的地址引脚来寻址， 可以很容易地存取其内部的每一个字节。
   
NAND 器件使用复杂的I/O 口来串行地存取数据，各个产品或厂商的方法可能各不相同。8 个引脚用来传送控制、地址和数据信息。NAND
的读和写操作采用512 字节的块， 这一点有点像硬盘管理此类操作。很自然地，基于NAND 的存储器就可以取代硬盘或其它块设备。
1.3 容量和成本
    NAND Flash 的单元尺寸几乎是NOR 器件的一半。由于生产过程更为简单，NAND 结构可以在给定的模具尺寸内提供更高的容量， 也就相应地降低了价格。
    NOR Flash 占据了大部分容量为1 ～16MB 的闪存市场，而NAND Flash 只是用在8～128MB 的产品当中。
1.4 可靠性和耐用性
    采用Flash 介质时，一个需要重点考虑的问题是可靠性。对于需要扩展MTBF 的系统来说，Flash 是非常合适的存储方案。可以从寿命( 耐用性) 、位交换和坏块处理三个方面来比较NOR 和NAND 的可靠性。

寿命(耐用性)
    在NAND 闪存中， 每个块的最大擦写次数是100 万次，而NOR 的擦写次数是10
万次。NAND 存储器除了具有10∶1 的块擦除周期优势外，典型的NAND 块尺寸要比NOR 器件小8 倍， 每个NAND
存储器块在给定时间内的删除次数要少一些。

位交换
    所有Flash
器件都受位交换现象的困扰。在某些情况下( 很少见，NAND 发生的次数要比NOR 多)
，一个比特位会发生反转或被报告反转了。一位的变化可能不很明显，但是如果发生在一个关键文件上，
这个小小的故障就可能导致系统停机。如果只是报告有问题， 多读几次就可能解决。
    位反转的问题更多见于NAND 闪存，NAND 的供应商建议使用NAND 闪存的时候，同时使用EDC/ECC 算法。当然， 如果用本地存储设备来存储操作系统、配置文件或其它敏感信息时，必须使用EDC/ECC 系统以确保可靠性。

坏块处理
   
NAND 器件中的坏块是随机分布的。以前做过消除坏块的努力， 但发现成品率太低， 代价太高， 根本不划算。NAND
器件需要对介质进行初始化扫描以发现坏块， 并将坏块标记为不可用。在已制成的器件中， 如果通过可靠的方法不能进行这项处理， 将导致高故障率。
1.5 易用性
    可以非常直接地使用基于NOR 的闪存，
像其它存储器那样连接，并可以在上面直接运行代码。由于需要I/O接口，NAND 要复杂得多。各种NAND
器件的存取方法因厂家而异。在使用NAND 器件时， 必须先写入驱动程序， 才能继续执行其它操作。向NAND 器件写入信息需
要相当的技巧， 因为设计师绝不能向坏块写入， 这就意味着在NAND 器件上自始至终都必须进行虚拟映射。
1.6 软件支持
   
在NOR 器件上运行代码不需要任何的软件支持。在NAND 器件上进行同样操作时， 通常需要驱动程序，也就是内存技术驱动程序( MTD )
。NAND 和NOR 器件在进行写入和擦除操作时都需要MTD 。使用NOR 器件时，所需要的MTD
要相对少一些。许多厂商都提供用于NOR器件的更高级的软件， 其中包括M-System 的TrueFFS 驱动，该驱动被Wind River
System、Microsoft、QNX Software
System、Symbian和Intel等厂商所采用。驱动还用于对DiskOnChip 产品进行仿真和NAND 闪存的管理，
包括纠错、坏块处理和损耗平衡。
    目前，NOR Flash 的容量从几KB~64MB 不等，NANDFlash 存储芯片的容量从8MB~128MB，而DiskonChip 可以达到1024MB。
2 Flash系统设计
    Flash 在每MB 的存储开销上较RAM 要昂贵，
但对于uClinux 系统来说，选择Flash 作为存储器具有一定的优势。uClinux
系统在上电后，需要运行的程序代码和数据都可以存储在Flash 中， 甚至放在CPU 起始地址中的uClinux 启动内核都可以写入Flash
中。从一定意义上讲，嵌入式系统只用Flash 就可以完成所需的存储功能。
    Flash 存储器的分区较硬盘的分区更为简单，分区后的Flash 使用起来更加方便。典型的Flash 分区如下。
SEGMENT PURPOSE
0       Bootloader
1       factoryconfiguration
2
:       kernel
X
:       root filesystem
Y
   
分区0 放置Bootloader ，分区1 放置factory configuration，分区2 到分区X 放置系统内核，分区X 到分区Y
放置根文件系统。Flash 的分区可以根据需要划分，uClinux 中支持Flash 存储器的块设备驱动负责定义上述的分区
.
和PC
机下的Linux 不同，Flash 的分区把系统内核文件和根文件系统单独划分到两个分区中，而PC
机的硬盘是把内核文件和根文件系统放在一个分区内。PC 机下Linux 的Bootloader 是LILO
或GRUB。它们在系统启动时能智能地在分区中找到内核文件块， 并把它加载到RAM 中运行。对于Flash
而言，把内核的镜像文件写进一个单独的分区对嵌入式系统有两大优点：
① 系统可以直接在Flash 上运行；
② LILO 或GRUB 更易找到内核代码并加载，甚至可以不用LILO 或GRUB 引导而直接运行。
    内核文件和根文件系统在Flash 中的放置，可以根据系统设计需要适当选择， 选择如表1 所列。
   
        
            模式选择
            优点
            缺点
        
        
            内核和根文件系统放在固定偏移地址单元（单独分区）
            适用于主要系统成员地址单元固定，易于引导程序（ Bootloader）加载和分别升级内核和根文件系统
            在内核和根文件系统之间不可避免要浪费Flash 空间
        
        
            根文件系统紧跟内核放置（不单独分区）
            节省Flash 存储空间
            内核文件和根文件系统合二为
一，单独升级不够方便
        
        
            内核和根文件系统压缩放置
            节省大量的Flash 存储空间，可选择压缩放置内核或根文件系统
            系统需要引导程序（Bootloader）和RAM 支持
        
   
3 引导程序选择
    系统启动之前的引导过程是CPU 初始化的过程。包括ARM 和X86
在内的许多CPU 是从固定地址单元开始运行引导程序（Bootloader）的。其它的部分CPU 是从某个地址单元读入引导程序的入口地址，
然后再运行引导程序，譬如M68K 和Coldfire 系列。所以这些都影响到Flash 中系统启动代码的存放地址。
   
系统首先要考虑的是在什么地址存放Bootloader，或者说系统从哪个地址单元开始加载运行系统内核代码。CPU
启动后直接运行系统内核是可以实现的。对于uClinux 来说，启动代码必须包括芯片的初始化和RAM的初始化等硬件配置；
同时加载内核的代码段到RAM中， 并清除初始化的数据段内容。尽管这些实现起来很直观，但是要具体把启动代码存放在Flash
中正确的地址偏移单元内，使CPU 一启动便能执行就比较困难了。不过， 现在技术比较先进的CPU 都将默认的偏移地址设置为0 ，
或者在偏移地址为0 的附近存放起始地址。
    Bootloader
是一段单独的代码，用以负责基本硬件的初始化过程，并且加载和运行uClinux 的内核代码。作为系统启动工具，Bootloader
经过配置可以加载Flash 中的多个内核， 甚至可以通过串口和网口来加载内核和系统的镜像到RAM 中运行。Bootloader
同时也提供对内核镜像文件的多级别保护，这一点对于以Flash 作为存储设备的系统来说非常重要。譬如，
当系统进行内核升级和重要数据备份时，系统突然掉电，正如PC 机进行BIOS刷写过程中的掉电一样， 都是灾难性的。但是利用Bootloader
就可以实现保护性的恢复。
    目前运行在uClinux 上的免费Bootloader 有COLILO、MRB 、PPCBOOT 和DBUG。也有为特殊需求设计的SNAPGEAR 和ARCTURUS NETWORKS。
4 uClinux的块驱动器
    对于嵌入式系统的块设备，可选择存储文件系统的块驱动器（Block Driver）主要有三种选择。
①
Blkmem driver。Blkmem driver仍是uClinux上使用最普遍的Flash 驱动器。它是为uClinux
而设计的，但是它的结构相对比较简单，并且仅支持NOR Flash 的操作，需要在RAM 中建立根文件系统。同时它也很难配置，
需要代码修改表来建立Flash 分区。尽管如此，它还是提供了最基本的分区擦/ 写操作。
② MTD driver。MTD driver
是Linux 下标准的Flash驱动器。它支持大多数Flash
存储设备，兼有功能强大的分区定义和映像工具。借用交叉存取技术（interleaving），MTD driver
甚至可支持同一系统中不同类型的Flash，Linux 内核中关于MTD driver 配置有较为详细的选项。
③ RAM disk driver。在无盘启动的标准Linux中，用得最多的就是RAM disk driver；但它不支持底层的Flash存储器，仅对根文件系统的建立有意义， 即根文件系统压缩以后存放在Flash 的什么地方。
    通过上面的比较可以看到，MTD driver 提供对Flash最有力的支持，同时它也支持在Flash 上直接运行文件系统，譬如JFFS 和JFFS2，而Blkmem driver 则不支持。
5 根文件系统
    uClinux 中的文件系统可以有多种选择。通常情况下，ROMfs
是使用最多的文件系统，它是一种简单、紧凑和只读的文件系统。ROMfs 顺序存储文件数据，并可以在uClinux
支持的存储设备上直接运行文件系统，这样可以在系统运行时节省许多RAM 空间。
    Cramfs 是针对Linux 内核2.4
之后的版本所设计的一种新型文件系统，也是压缩和只读格式的。它主要的优点是将文件数据以压缩形式存储，在需要运行的时候进行解压缩。由于它存储的文件形
式是压缩的格式， 所以文件系统不能直接在Flash 上运行。虽然这样可以节约很多Flash
存储空间，但是文件系统运行需要将大量的数据拷贝进RAM 中， 消耗了RAM 空间。
    考虑到多数系统需要能够读/
写的文件系统，可以使用MTD driver 的JFFS 和JFFS2 日志式文件格式在Flash头部建立根文件系统（Root
Filesystem）。日志式文件系统可以免受系统突然掉电的危险，并且在下一次系统引导时不需要文件系统的检查。由于JFFS 和JFFS2 文件格
式
是特别为Flash 存储器设计的，二者都具有一种称为“损耗平衡”的特点，也就是说Flash
的所有被擦写的单元都保持相同的擦写次数。利用这种特有的保护措施，Flash 的使用周期得到相当大的提升。JFFS2
使用压缩的文件格式，为Flash 节省了大量的存储空间，它更优于
JFFS 格式在系统中使用。值得注意的是，使用JFFS2 格式可能带来少量的Flash 空间的浪费，这主要是由于日志文件的过度开销和用于回收系统的无用存储单元，浪费的空间大小约是两个数据段。
   
如果使用RAM disk，一般应选择EXT2 文件格式，但EXT2 并不是一块特别高效的文件存储空间。由于存在RAM disk
上，所以任何改变在下一次启动后都会丢失。当然， 也有许多人认为对于嵌入式存储空间来讲，
这是一种优势，因为每次系统启动都是从已知的文件系统状态开始的。
    虽然在linux 下有许多的文件格式可供选择，但是对于uClinux 一般只选择上述的几种文件格式。另外一点就是如何在目标系统上建立根文件系统， 步骤如下：
首
先在开发宿主机上建立一个目标机的根文件系统的目录树，然后利用嵌入式根文件系统生成工具在宿主机上生成目录树的二进制文件镜像，
最后下载到目标机上就可以了。对于不同的文件格式有不同的二进制镜像生成工具，譬如JFFS 的mkfs.jffs2、ISO9660
的mkisofs。
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/28827/showart_475979.html