uClinux系统平台下的Flash存储技术
扫描二维码
随时随地手机看文章
在过去的二十年里,ROM和EPROM一直是嵌入式系统的存储设备的首选。但是,今天越来越多的嵌入式系统设计者采用Flash这种可读写的存储设备进行设计开发。
Flash存储技术
在过去的二十年里,ROM和EPROM一直是嵌入式系统的存储设备的首选。但是,今天越来越多的嵌入式系统设计者采用Flash这种可读写的存储设备进行设计开发。
Flash主要分为NOR和NAND两类。NOR和NAND是现在市场上两种主要的非易失闪存技术。Intel于1988年首先开发出NOR Flash技术,彻底改变了原先由EPROM和EEPROM一统天下的局面。紧接着,1989年,东芝公司发表了NAND Flash结构,强调降低每比特的成本,更高的性能,并且象磁盘一样可以通过接口轻松升级。
NOR的特点是芯片内执行(XIP, eXecute In Place),这样应用程序可以直接在Flash闪存中运行,而不必再把代码读到系统RAM中。NOR的传输效率很高,在1~4MB的小容量时具有很高的成本效益,但是很低的写入和擦除速度大大影响了它的性能。
NAND结构能提供极高的单元密度,可以达到高存储密度,并且写入和擦除的速度也很快。但应用NAND的困难在于Flash的管理需要特殊的系统接口。
但是历经十多年之后,仍然有相当多的硬件工程师分不清NOR和NAND闪存。因为大多数情况下闪存只是用来存储少量的代码,这时NOR闪存更适合一些。“Flash存储器”便经常与“NOR存储器”互换使用。但NAND则是高数据存储密度的理想解决方案。
下面对二者作较为详细的比较:
性能比较
Flash闪存是非易失存储器,可以对称为块的存储器单元块进行擦写和再编程。任何Flash器件的写入操作只能在空或已擦除的单元内进行,所以大多数情况下,在进行写入操作之前必须先执行擦除。NAND器件执行擦除操作是十分简单的,而NOR则要求在进行擦除前先要将目标块内所有的位都写为0。
由于擦除NOR器件时是以64~128KB的块进行的,执行一个写入/擦除操作的时间为5s,与此相反,擦除NAND器件是以8~32KB的块进行的,执行相同的操作最多只需要4ms。
执行擦除时块尺寸的不同进一步拉大了NOR和NADN之间的性能差距,统计表明,对于给定的一套写入操作(尤其是更新小文件时),更多的擦除操作必须在基于NOR的单元中进行。这样,当选择存储解决方案时,设计师必须权衡以下的各项因素。
● NOR的读速度比NAND稍快一些。
● NAND的写入速度比NOR快很多。
● NAND的4ms擦除速度远比NOR的5s快。
● 大多数写入操作需要先进行擦除操作。
● NAND的擦除单元更小,相应的擦除电路更少。
接口差别
NOR Flash带有SRAM接口,有足够的地址引脚来寻址,可以很容易地存取其内部的
每一个字节。
NAND器件使用复杂的I/O口来串行地存取数据,各个产品或厂商的方法可能各不相同。8个引脚用来传送控制、地址和数据信息。
NAND读和写操作采用512字节的块,这一点有点像硬盘管理此类操作,很自然地,基于NAND的存储器就可以取代硬盘或其他块设备。
容量和成本
NAND Flash的单元尺寸几乎是NOR器件的一半,由于生产过程更为简单,NAND结构可以在给定的模具尺寸内提供更高的容量,也就相应地降低了价格。
NOR Flash占据了容量为1~16MB闪存市场的大部分,而NAND Flash只是用在8~128MB的产品当中,这也说明NOR主要应用在代码存储介质中,NAND适合于数据存储,NAND在CompactFlash、Secure Digital、PC Cards和MMC存储卡市场上所占份额最大。
可靠性和耐用性
采用Flash介质时一个需要重点考虑的问题是可靠性。对于需要扩展MTBF的系统来说,Flash是非常合适的存储方案。可以从寿命(耐用性)、位交换和坏块处理三个方面来比较NOR和NAND的可靠性。
寿命(耐用性)
在NAND闪存中每个块的最大擦写次数是一百万次,而NOR的擦写次数是十万次。NAND存储器除了具有10比1的块擦除周期优势,典型的NAND块尺寸要比NOR器件小8倍,每个NAND存储器块在给定的时间内的删除次数要少一些。
位交换
所有Flash器件都受位交换现象的困扰。在某些情况下(很少见,NAND发生的次数要比NOR多),一个比特位会发生反转或被报告反转了。
一位的变化可能不很明显,但是如果发生在一个关键文件上,这个小小的故障可能导致系统停机。如果只是报告有问题,多读几次就可能解决了。
当然,如果这个位真的改变了,就必须采用错误探测/错误更正(EDC/ECC)算法。位反转的问题更多见于NAND闪存,NAND的供应商建议使用NAND闪存的时候,同时使用EDC/ECC算法。这个问题对于用NAND存储多媒体信息时倒不是致命的。当然,如果用本地存储设备来存储操作系统、配置文件或其他敏感信息时,必须使用EDC/ECC系统以确保可靠性。
坏块处理
NAND器件中的坏块是随机分布的。以前也曾有过消除坏块的努力,但发现成品率太低,代价太高,根本不划算。NAND器件需要对介质进行初始化扫描以发现坏块,并将坏块标记为不可用。在已制成的器件中,如果通过可靠的方法不能进行这项处理,将导致高故障率。
易用性
可以非常直接地使用基于NOR的闪存,可以像其他存储器那样连接,并可以在上面直接运行代码。
由于需要I/O接口,NAND要复杂得多。各种NAND器件的存取方法因厂家而异。在使用NAND器件时,必须先写入驱动程序,才能继续执行其他操作。向NAND器件写入信息需要相当的技巧,因为设计师绝不能向坏块写入,这就意味着在NAND器件上自始至终都必须进行虚拟映射。
软件支持
当讨论软件支持的时候,应该区别基本的读/写/擦操作和高一级的用于磁盘仿真和闪存管理算法的软件,包括性能优化。
在NOR器件上运行代码不需要任何的软件支持,在NAND器件上进行同样操作时,通常需要驱动程序,也就是内存技术驱动程序(MTD),NAND和NOR器件在进行写入和擦除操作时都需要MTD。
使用NOR器件时所需要的MTD要相对少一些,许多厂商都提供用于NOR器件的更高级的软件,这其中包括M-System的TrueFFS驱动,该驱动被Wind River System、Microsoft、QNX Software System、Symbian和Intel等厂商所采用。驱动还用于对DiskOnChip产品进行仿真和NAND闪存的管理,包括纠错、坏块处理和损耗平衡。[!--empirenews.page--]
目前,全世界的NOR Flash生产商主要有:Intel、AMD、Fujitsu和Toshiba,NOR Flash存储芯片的容量从几K到64M不等,未来数年里作为标准存储设备NOR Flash很有可能取代ROM。NAND Flash 的生产厂商包括Samsung和Toshiba,同时二者也是M-System公司的“DiskOnChip”上Flash的供应商。NAND Flash存储芯片的容量从8M到128M,而DiskonChip可以达到1024M的容量。
对于小型嵌入式系统设计,尤其是uClinux系统设计时,NOR Flash更多的被采用。所以下面的介绍将更多集中在NOR Flash上。
系统设计
一般来说,在嵌入式系统设计中RAM和Flash的选择是由设计者来权衡的,而价格往往是主要的决定因素。Flash在每M字节的存储开销上较RAM要昂贵,对于uClinux系统来说选择Flash作为存储器具有一定的优势,uClinux系统在上电后需要运行的程序代码和数据都可以存储在Flash中,甚至于放在CPU起始地址中的uClinux的启动内核都可以写入Flash中。所以从一定意义上讲,嵌入式系统只用Flash就可以完成所需的存储功能。
Flash存储器的分区较硬盘的分区更为简单,分区后的Flash使用起来更加方便。典型的Flash分区如下
SEGMENT PURPOSE
0 Bootloader
1 foctory configuration
2
. kernel
X
. root filesystem
Y
分区0放置Bootloader,分区1放置factory configuration,分区2到分区X放置系统内核,分区X到分区Y放置根文件系统。Flash的分区可以根据需要划分,uClinx中支持Flash存储器的块设备驱动负责定义上述的分区。
和PC机下的Linux不同,Flash的分区把系统的内核文件和根文件系统单独划分到两个分区中,而PC机的硬盘是把内核文件和根文件放在一个分区内。PC机下的Linux的Bootloader是LILO或GRUB,它们在系统启动时能智能地在分区中找到内核文件块并把它加载到RAM中运行。对于Flash而言,把内核的镜像文件写进一个单独的分区对嵌入式系统有两大优点:1)系统可以直接在Flash上运行2)对于LILO或GRUB更易找到内核代码加载,甚至可以不用LILO或者GRUB引导而知直接运行。
内核文件和根文件系统在Flash中的放置可以根据系统设计需要适当选择,选择见下表。
模 式 选 择 |
优 点 |
缺 点 |
内核和根文件放在固定偏移地址单元(单独分区) |
适用于主要系统成员地址单元固定,易于引导程序(Bootloader)加载和分别升级内核和根文件系统。 |
在内核和根文件系统之间不可避免要浪费Flash空间。 |
根文件系统紧跟内核放置(不单独分区) |
节省Flash存储空间 |
内核文件和根文件合二为一,单独升级不够方便。 |
内核和根文件系统压缩放置 |
节省大量的Flash存储空间,可选择压缩放置内核或者根文件系统 |
系统需要引导程序(Bootloader)和RAM支持。 |
表1
引导程序选择(Bootloader Selection)
系统启动之前的引导过程是CPU初始化的过程。包括ARM和X86在内的许多CPU是从固定的地址单元开始运行引导程序的。其它的部分CPU而是从某个地址单元读入引导程序的入口地址,然后再运行引导程序,譬如M68K和COLDFIRE系列。所以这些都影响到Flash中的系统启动代码的存放地址。
首先系统要考虑的是系统在什么地址存放Bootloader,或者说系统从哪个地址单元开始加载运行系统内核代码。
CPU启动后直接运行系统内核是可以实现的。对于uClinux来说启动代码必须包括芯片的初始化和RAM的初始化等硬件的配置,同时加载内核的代码段到RAM中并清除初始化的数据段内容。尽管这些实现起来很直观,但是具体要把启动代码存放在Flash中正确的地址偏移单元内使CPU在一启动就能执行就比较困难了。不过现在技术比较先进的CPU都将默认的偏移地址设置为0或者在偏移地址为0的附近存放起始地址。[!--empirenews.page--]
Bootloader使一段单独的代码,它用以负责基本硬件的初始化过程,并且加载和运行uClinux的内核代码。作为系统启动工具,Bootloader经过配置以后可以加载Flash中多内核,甚至可以通过串口和网口来加载内核和系统的镜像到RAM中运行。Bootloader同时也提供对内核镜像文件的多级别保护,这一点对于以Flash作为存储设备的系统来说尤为重要。譬如,当系统进行内核升级和重要数据备份时候,系统突然掉电,正如PC机进行BIOS刷写过程中的掉电一样,都是灾难性的。但是利用Bootloader就可以实现保护性的恢复。
目前运行在uClinux上的免费Bootloader有COLILO、MRB、PPCBOOT和DBUG。也有为特殊需求设计的SNAP GEAR和ARCTURUS NETWORKS。
uClinux的块驱动器(Block Driver)
对于嵌入式系统的块设备可选择存储文件系统的块驱动器主要有三种选择。
1)Blkmem driver。Blkmem driver仍是uClinux上使用最普遍的Flash驱动器,它是为uClinux而设计的,但是相对的它的结构比较简单并且仅支持NOR Flash的操作,需要在RAM中建立根文件系统。同时它也很难配置,需要代码修改表来建立Flash分区。尽管如此,它还是提供了最基本的分区擦/写操作。
2)MTD driver。MTD driver是Linux下标准的Flash驱动器。它支持大多数Flash存储设备,兼有功能强大的分区定义和映象工具。借用交叉存取技术(interleaving),MTD driver甚至可支持同一系统中不同类型的Flash,Linux内核中关于MTD driver配置有较为详细的选项。
3)RAM disk driver。在无盘启动的标准Linux中用的最多的就实RAM disk driver,但它不支持底层的Flash存储器,仅对根文件系统的建立有意义,即压缩的根文件系统压缩以后存放在Flash的什么地方。
通过上面的比较可以看到,MTD driver提供对Flash最有力的支持,同时它也支持从Flash上直接运行文件系统,譬如JFFS和JFFS2,而Blkmem driver则不能够支持。
根文件系统(Root Filesystem)
uClinux中的文件系统可以有很多种选择。通常情况下ROMfs是使用最多的文件系统,它是一种简单、紧凑和只读的文件系统。ROMfs顺序存储文件数据,并可以在uClinux支持地存储设备上直接运行文件系统,这样可以在系统运行时节省许多RAM空间。
Cramfs是针对Llinux内核2.4之后的版本所设计的一种新型文件系统,它也是压缩和只读格式的。它主要的优点是将文件数据以压缩形式存储,在需要运行的时候进行解压缩。由于它存储的文件形式是压缩的格式,所以文件系统不能直接在Flash上运行。虽然这样可以节约很多Flash存储空间,但是文件系统运行需要将大量的数据拷贝进RAM中,消耗了RAM空间。
考虑到有多数系统需要读/写的文件系统,可以使用MTD driver的诸如JFFS和JFFS2日志式文件格式在Flash头部建立根文件系统。日志式文件系统可以免受系统突然掉电的危险,并且在下一次系统引导时不需要文件系统的检查。由于JFFS和JFFS2文件格式是特别为Flash存储器设计的,二者都具有一种称为“损耗平衡”的特点,也就是说Flash的所有被擦写的单元都保持相同的擦写次数。利用这种特有的保护措施,Flash的使用周期得到相当大的提升。JFFS2使用了压缩的文件格式,为Flash节省了大量的存储空间,它更优于JFFS格式在系统中使用。值得注意的是,使用JFFS2格式可能带来少量的Flash空间的浪费,这主要是由于日志文件的过度开销和用于回收系统的无用存储单元,浪费的空间大小大致是两个数据段。
如果使用RAM disk,一般应选择EXT2文件格式。但EXT2并不是一种特别高效的文件存储空间。由于存在在RAM disk上,所以任何改变在下一次启动后都会丢失。当然,也有许多人认为对于嵌入式存储空间来讲,这是一种优势,因为每次系统启动都是从已知的文件系统状态开始的。
虽然在Linux下有许多的文件格式可供选择,但是对于uClinux一般只选择上述的几种文件格式。另外一点就是如何在目标系统上建立根文件系统。大致步骤如下:
首先在开发宿主机上建立一个目标机的根文件系统的目录树,然后利用嵌入式根文件系统生成工具在宿主机上生成目录树的二进制文件镜像,最后下载到目标机上就可以了。对于不同的文件格式有不同的二进制镜像生成工具,譬如JFFS的mkfs.jffs2、ISO9660的mkisofs。
Flash工具及实例
uClinux下的Flash的操作工具有很多种,它们都是为底层的块设备而设计使用的。
当使用MTD driver时,主要的工具有:erase(数据段擦除工具)、eraseall(擦除Flash)、lock(写保护)、unlock(打开写保护)、mkfs.jffs(从目录结构生成JFFS格式文件工具)和mkfs.jffs2(JFFS2格式生成工具)。由于MTD driver提供字符和块设备支持,所以在目标机上可以使用诸如dd命令来写Flash。
实际设计实例:
系统硬件配置:S3C4510B,2M Flash,4M SDRAM。内核:uClinux2.4.x,使用MTD driver支持Flash存储。文件系统格式选择ROMfs。在Flash存储器的地址底部存在一系列的大小不等的可擦除的地址空间,它们的大小分别是16K、8K、8K和32K,总计大小为64K ,我们选择Flash的“bottom boot”。
Flash 分区如下
● SEGMENT SIZE MTD-DEVICE DESCRIPTION
0 16K mtd0 boot loader
1 8K mtd1 内核引导参数
2 8K mtd2 出厂设置信息
3 32K mtd3 空闲
4 64K mtd4 固化设置
5
. 1984K mtd5 内核+根文件系统 .
35
0-35 2048K mtd6 all of Flash memory
在Flash分区的过程中,尽量使用Flash的顶部和底部。不同的MTD分区可以部分重叠,但是在操作时要特别注意。
系统内核是压缩存储的,Bootloader在初始化SDRAM后就解压内核到SDRAM中运行。根文件系统存储在压缩的内核镜像文件之后的,它可以直接在Flash上运行,移除内核压缩镜像后,典型的根文件系统的大小约有1.5M左右。
内核文件和根文件系统合并在一个镜像文件中有一个最大的好处就是当二者需要升级的时候,只需要重新编译MTD4上的配置文件即可。
在所有配置中关键是MTD驱动器映射的建立, uClinux-2.4.x/drivers/mtd/maps下的nettle-uc.c是文件系统建立的源程序,其主要是解释了分区映射的内容和在MTD4上如何配置根文件系统。[!--empirenews.page--]
通过引导日志可以分析引导过程,譬如引导过程的日志如下:
SnapGear Flash probe(0xf0000000,2097152,2): 200000 at f0000000
CFI: Found no Flash device at location zero
Found: Toshiba TC58FVB160
number of JEDEC chips: 1
Creating 7 MTD partitions on "Flash":
0x00000000-0x00004000 : "Bootloader"
0x00004000-0x00006000 : "Bootargs"
0x00006000-0x00008000 : "MAC"
0x00010000-0x00020000 : "Config"
0x00008000-0x00010000 : "Spare"
0x00020000-0x00200000 : "Image"
0x00000000-0x00200000 : "Flash"
从上面的日志可以看到,MTD drivers发现了Toshiba Flash,并按先前的要求把它分为指定的几个分区,Flash被映射到CPU地址单元的0xf0000000开始。当然,MTD driver提供更为复杂的配置设置,通过对位于内核配置内的MTD drivers的配置,可以得到更为详细的关于Flash device的日志报告。
使用netFlash工具来刷新系统的内核和文件系统。命令行仅是: netFlash imagez.bin ,将镜像文件放在Tftp 服务器上,netFlash从指定地址的Tftp服务器上下载并完成烧录工作,重新启动目标板就可以让uClinux跑起来了。