制作嵌入式Linux根文件系统

篇2：关于根文件系统的

看到百度百科里关于“根文件系统”的描述，觉得很不错，遂整理部分经典内容如下：

根文件系统首先是一种文件系统，该文件系统不仅具有普通文件系统的存储数据文件的功能，

它是内核启动时所挂载（mount）的第一个文件系统，

内核代码的映像文件保存在根文件系统中，

系统引导启动程序会在根文件系统挂载之后从中把一些初始化脚本（如rcS,inittab）和服务加载到内存中去运行，

我们要明白文件系统和内核是完全独立的两个部分，

在嵌入式中移植的内核下载到开发板上，是没有办法真正的启动Linux操作系统的，会出现无法加载文件系统的错误。

根文件系统之所以在前面加一个”根“，说明它是加载其它文件系统的”根“，

它包含系统引导和使其他文件系统得以挂载（mount）所必要的文件。

Linux启动时，第一个必须挂载的是根文件系统；

若系统不能从指定设备上挂载根文件系统，则系统会出错而退出启动。

成功之后可以自动或手动挂载其他的文件系统。

因此，一个系统中可以同时存在不同的文件系统。

篇3：星载嵌入式文件系统技术研究及实现

星载嵌入式文件系统技术研究及实现

介绍了一种面向空间应用的嵌入式文件系统的.设计要点,着重说明了采用B+树组织文件、锁链方式组织元数据以及低资源占用的空间分配回收机制三个方面问题.自主开发的文件系统较好地解决了NAND型 Flash存储芯片作为星载存储设备所遇到的磨损均衡、存储空间使用效率的问题,能够更好地支持星载数据的文件化存储管理和可靠传输.

篇4：适宜于嵌入式多媒体应用的Flash文件系统

适宜于嵌入式多媒体应用的Flash文件系统

关键词：嵌入式系统 多媒体Flash存储器 文件系统

随着电子技术的不断发展，嵌入式系统越来越多地在控制类、消费类、通讯类等电子产品广泛应用，并且随着数字信号处理与人机交互界面等相关技术的不断成熟，嵌入式多媒体应用数量也逐渐上升。多媒体业务的数据量大，数据内容复杂，在多媒体应用中数据的存储与管理是不容回避的问题。Flash存储器制造成本低廉、存储容量大、数据非易失、无机械故障，在目前的嵌入式系统中被广泛用作外存储器件。然而Flash存储器却是一种数据正确性非理想的器件，应用中可能会出现坏损数据单元，这又给应用Flash存储器嵌入式系统进行数据存储管理增添了新的难度[1]。

在嵌入式系统中应用Flash存储器最好的办法是在其上构造一个文件系统，对Flash存储器中的数据内容进行基于文件代号的存储管理，同时对于Flash存储器本身的坏损单元自动进行应用透明的坏损管理。目前在通用计算机上已经有很多成熟的文件系统，如DOS下的FAT文件系统、Windows NT下的NTFS文件系统及UNIX文件系统等[2]。但是这些文件系统并不适合直接用到嵌入式系统中进行多媒体数据内容的存储：第一，嵌入式系统的应用条件远比计算机恶劣，电源电压的不稳定以及突发性断电将对Flash的存储造成灾难性的影响，通用文件系统对于可靠性的设计考虑不足；第二，通用文件系统是针对系统资源非常丰富的计算机平台并基于速度较慢的磁盘驱动器，它们常常大量使用缓存技术，如注重文件系统的速度特性，要耗费比较多的系统资源。这与嵌入式系统中系统资源十分有限，Flash存储器又相对于磁盘驱动器较快的应用情况不用；第三，嵌入式系统中存储于Flash上的内容很多是多媒体数据资料，这些数据内容往往鸡一定程度的误码损伤，未必需要如通用文件系统那样严格保证存储的正确性。通过灵活的校验机制与坏损管理，达到更优化的存储速度与更高效的存储空间利用，这对成本敏感的嵌入式系统来说尤其具有帮助。

基于上述考虑，设计了一个适合嵌入式多媒体应用的Flash文件系统。它不仅支持文件代号管理、文件指针存取以及应用透明的自动坏损管理这些通用文件系统所具有的功能，并且在文件系统的可靠性以及文件系统的额外资源消耗方面进行了改善；此外还引入了基于存储内容自适应的坏损管理策略，从而使该Flash文件系统更加适合嵌入式多媒体应用。

1 Flash存储器的操作特点

Flash存储器在读取方面与普通的SRAM存储器类似，一般可以实现完全随机的读取。Flash存储器最大的不同在于写操作方面。Flash存储器的写操作需要经过“擦除―写入”两个操作过程。当希望对Flash存储器的某一个单元进行写入时，首先必须对这个存储单元所在的区块（Block）执行擦除操作，擦除操作成功完成后，整个区块的数据内容都被清空（一般被设置成0xFF）；然后对目的单元所在的页面（Page）执行写入操作，需要一次写入整个页面的全部数据内容（也有一次Flash存储器支持部分页的写入，这样可以分多次写完一个页面，但是一旦写过的存储单元数据就不能再被更改），操作成功后要进行数据正确性的校验。

一个区域（Block）包含一个或多个页面（Page），一个页面包含多个数据存储单元（字节或字）。

为了增强所设计Flash文件系统在不同Flash存储器上的移植能力，选取了3个最基本的操作作为本Flash文件系统与Flash存储器设备的应用接口：区块擦除（Block_Erase）、页面写入（Page_Write）、页面读出（Page_Read）。这样虽然可能会忽略某些Flash存储器产品的独有特性，但却增加了所设计的Flash文件系统对同Flash存储器产生的适应能力。另外，Flash存储器写入的时间瓶不在于数据传递，而是Flash存储器内部的擦除和写操作等；Flash存储器读出的速度和微处理器处理数据的速度都很快，因此虽然将读和写的基本单位扩大到了页面，但额外增加的操作时间是很短的。

2 Flash文件系统的基本结构

本Flash文件系统在基本结构上与MS-DOS的FAT文件系统类似[3]。MS-DOS是一个应用于几十年的商业化软件产品，其FAT文件系统技术成熟、结构简单、系统资源开销小，易于在嵌入式系统的硬件平台上实现。本Flash文件系统的基本结构如图1所示，整个文件系统包括如下几个部分：

(本网网收集整理)

（1）系统记录（SR，System Record）存放媒质信息和最重要的文件系统信息。媒质信息诸如Flash存储器的类型、容量，划分成多少个区块，每区块包含多少个页面等。文件系统信息包括版本信息、保留区块的数目和位置、文件分配表和文件登记表所在的位置和大小、数据区域的位置和大小等。

（2）文件分配表（FAT，File Allocation Table）存放着Flash存储器上所有区块的占用与空闲情况以及每个文件的存储连接结构。MS-DOS FAT文件系统中有12位、16位、32位三种不同的.FAT格式。考虑到在微处理器上实现的方便性并权衡Flash文件系统应用的规模，选择将文件分配表固定为16位的格式。

（3）文件登记表（FRT，File Register Table）存放着Flash文件系统中每一个文件的文件代号、文件长度、文件属性以及该文件的存储链在文件分配表中的入口。考虑到嵌入式系统的应用范围，本Flash文件系统不支持子目标结构。

（4）数据区域（Data Area）用于存放文件的数据内容。本Flash文件系统中，数据分配的最小单位是Flash存储器的一个基本擦除单元，即一个物理区块（Block）。

本Flash文件系统提供：文件系统的格式化（Format）、文件的创建（Create）、删除（Delete）、打开（Open）、关闭（Close）、读（Read）、写（Write）、文件指针的移动（Seek）、位置读取（Tell）等基本的功能。程序主体代码ANSI C语言写成，使用一个非常小的Flash存储器设备驱动接口，扩展及移植的能力都比较好。

3 提高Flash文件系统的可靠性

在MS-DOS的FAT文件系统中，仅仅对数据区域提供坏损管理，而对于它的主引导记录、文件分配表和根目录这三个极重要的文件系统数据结构却未做任何保护（虽然MS-DOS的FAT文件系统中存在着两张FAT表，但是DOS只是简单地复写第二张FAT表而从不使用它）。一旦这三个区域的内容出现一点失效，将必然导致文件数据的大量损失。另外，如果这些数据结构的存储区域发生物理性损坏，更会导致整张磁盘的报废。这在由Flash存储器占据很大成本比重的嵌入式应用中，是非常不希望的。

归结起来，嵌入式系统中的Flash存储器主要面临两大类不稳定因素：一是Flash存储器本身可能出现物理性的损坏；二是嵌入式系统面对较多的突发掉电与重启动，造成Flash存储器写操作的异常终止。

针对Flash存储器的物理损霈问题，除对文件数据区域提供坏损管理外，还将系统记录、文件分配表和文件登记表这三个文件系统重要数据结构采用浮动位置的方法存储。即不仅对文件数据存储进行动态的分配管理，对于Flash文件系统中这三个重要数据结构也不固定其存储位置。这样可以避免因它们的存储区域发生物理损坏造成整个文件系统失效。具体做法是：对于系统记录定义一个系统记录保留区，将系统记录存在这个区域内，确切的位置在文件系统初始的时候通过标识幻数（Magic Number）的方法扫描找到；而文件分配表和文件登记表则存放在文件数据区域内，通过系统记录中的索引项找到。

针对Flash存储器的写操作异常终止问题，将6系统记录、文件分配表和文件登记表这三个对Flash文件系统最重要的数据结构均进行双份的存储改善其安全性。在文件系统的操作中，程序对每一个表结构的两个备份进行顺次修改，以此确保Flash存储器上总是存有一整套完好的系统记录表、文件分配表和文件登记表。在系统被启动运行时，文件系统会首先进行自检，通过这三个表结构中的标识幻数，以及最开关和最末尾的更新序列号可以确定每一张表备份的合法性和时效性，判断出前次系统关闭中存在着的操作异常终止并及时更正。通过这样的设计，即使文件系统大使用中出现了写操作异常终止的情况，错误将只涉及当时被操作的文件数据，不会扩散给Flash文件系统中的其它文件，更不会因此损坏三个文件系统表结构，造成整个文件系统的彻底瘫痪。

通过以上两个方面的改进，本Flash文件系统的可靠性比于MS-DOS FAT文件系统有了很大的提高。从实验1和实验2的仿真结构可以看到，即使在Flash极不可靠和写操作异常防止频发的最恶劣工作条件下，本Flash文件系统也能够保持可靠工作，从而使之能够适合于嵌入式系统的应用。

实验1 高坏损率状况下本Flash文件系统的可靠工作

实验条件

实验结果

实验2 频繁写操作异常终止状况下本Flash文件系统的可靠工作

4 降低Flash文件系统的资源消耗

嵌入式系统相对于通用计算机系统来讲，往往有荷刻得多的成本要求，需要嵌入式系统尽可能低的系统资源配置。尤其对于Flash文件系统这种用于增强系统功能的服务性质模块，就更需要降低对系统资源的消耗，才能够扩大其使用的范围。

就Flash文件系统的资源消耗来讲，主要包括程序代码开销、处理器占用时间、运行时内存开销以及额外的Flash存储器消耗。其中，运行时内存开销最限制Flash文件系统的应用，同时设计结构的改善与运行时内存开销直接相关。所以针对资源消耗的结构优化主要着重于降低运行时的内存开销。

Flash存储器的擦除单位是区块（Block），这是本Flash文件系统中数据存储分配的最小单元。如果不采用任何措施的话，运行时内存开销中将至少包括备份一个完整区块数据的缓冲区。但一个Flash存储器的区块可能很大（Sumsung[TM]KM29U128是16KB），这在很多嵌入系统中都是过大的资源开销（最通用的8位微处理器MCS-51系列，总线寻址的能力只有64KB），必须进行改进。

为此，采用交换缓冲区（Swap Buffer）技术来解决这个困难。当需要准备某一个区块的数据时，并不直接向该区块写入，而是首先擦除用于做交换缓冲区的区块，然后逐步向交换缓冲区填入目的数据内容。因为此时，任何有用数据内容都未被破坏，所以运行内存中的缓冲就可以做得比较小。当交换缓冲区填写完成后，再擦除目的区块，拷贝交换缓冲区内容到目的区块。

采用交换缓冲区后，对内存中的缓冲区大小没有特别要求，考虑到Flash存储器的操作特性，选取Flash存储器的页面（Page）容量作为内存缓冲区大小。在结构上作了上述改进后，虽然大大降低了Flash文件系统的运行时内存消耗，但代价是将一个数据区块的写入时间延长了一倍。不过一般的Flash存储器中都有一特点制作的区块，该区域保证不会损坏，正好适用做交换缓冲区。这样就可以省去中间交换缓冲过程的数据完整性检验，加快写操作的速度。

表1给出了在与MCS-51兼容的微处理器上本Flash文件系统实例，对Sumsung KM29U128 Flash存储器（16KB/Block×1024Block）[4]进行管理应用中的系统资源开销。地于一般的成本要求来讲，是可以接受的。

表1 一个应用实例中本Flash文件系统的系统资源开销

5 基于存储内容的自适应环境管理策略

嵌入式系统中应用Flash存储器，与多媒体相关的应用占据相当的比例，如数码相机、语音监录、MP3播放器等。存储在Flash上的内容多数是多媒体数据流，这种应用相对于普通文件系统的单纯数据业务具有其自己的数据特点。据此在本Flash文件系统上提了出了基于存储内容的自适应坏损管理策略。

Flash存储器上存储的内容包括数据文件和多媒体数据流。数据文件对于数据完整性要求很严格，不允许存储中出现任何错误。但多媒体数据流则不同，很多种多媒体数据流允许一定情况下传输差错，一些甚至允许传输差错很严重，如CVSD编码的语音。而Flash存储器的区块发生物理损坏时，经常是只有几个bit出现错误，其它部分却是完好的。综合考虑这两个方面的因素，就可以对不同内容的数据流赋予不同的数据完整性要求。这样一方面充分发挥了Flash存储器的存储能力，另一方面也可以降低弱数据完整性要求的数据检验强度，提高数据写入速度。

在本Flash文件系统中，把不同数据内容对于数据完整性的要求分成一个组别：0、1和2级。其中，0级的数据完整性最高，不允许在存储中出现任何差错， 用于数据型的好。2级的数据完整性要求最低，允许出现较多的差错，用于抗差错性强的多媒体码流。相应地，对于Flash存储器的每个可用区块，也按照其物理损坏的程度分成对应的三个级别：0级的区块所有的存储单元都完好；2级的区域则存在着比较多的损坏位；损坏程度超过2级允许的区块成为彻底损坏块，不能再使用。存储的原则为：对于特定的存储内容用损坏级别不超过其数据完整性要求级别的Flash区块存储。

同时，在存储不同数据完整性要求的内容时，采用不同强度的差错校验。存储0级内容时，每一次写入都进行差错校验，存储1级和2级内容时，以1/N的概率进行差错校验。差错校验的结果更新该物理存储区块的损坏级别，但是损坏级别只升不降。最初的损坏级别在格式化并建立文件系统时设定。

通过实验3的结果可以看到，采用存储内容自适应的坏损管理策略后，对于可容错的多媒体码流，存储效率和存储速度都可以得到明显提高。并且，设定合适的校验概率所发生的漏检率是很低的。

实验3 内容自适应的坏损管理策略对多媒体数据流的应用效果

实验条件

0级块，不允许出现损坏，每次写入都进行校验，对应理想存储媒质；

1级块，允许1～2 bits损坏，以1/4概率校验，对应3.8E-6差错率；

2级块，允许3～8 bits损坏，以1/32概率校验，对应6.1E-5差错率。

设定Flash页面的写入以1%概率损坏1个bit，对单一文件重复进行

{打开文件，写入1KB数据，关闭文件}的操作10000次。

实验结果

1级Blocks 780级 Blocks 616

1级 Blocks 8

2级 Blocks 1无法于使用的Flash空间348 Blocks6Blocks0 Blocks对数据内容进行的写入校验次数10000次2564次320次数据写入了未达要求的存储块，而检验漏过检出的次数0次1次0次

针对嵌入式多媒体应用中大量数据在Flash上存储的管理问题，文件系统是一种比较全面优秀的解决方案。本文对嵌入式多媒体应用中Flash文件系统的应用特点与关键设计进行了分析，设计实现了一个适宜于嵌入式多媒体应用的Flash文件系。其主要特点包括：

（1）完全支持文件代号管理、文件指针存取以及对应用透明的自动坏损管理这些通用文件系统所具有的功能。

（2）针对嵌入式系统的应用环境，设计改进了本Flash文件系统的可靠性，使其可以工作在很恶劣的条件下。

（3）针对嵌入式系统的成本与系统资源限制，改进降低了本Flash文件系统的系统资源开销，扩大了其应用范围。

（4）针对多媒体应用的数据特点，提出了基于存储内容自适应的坏损管理策略，提高了在多媒体应用中的存储效率与存储速度。

最终设计的Flash文件系统其结构如图2。

通过仿真分析，本Flash文件系统相对类似MS-DOS FAT的基础系统，在可靠性、系统资源开销等方面的性能提高是可观的，对于多媒体数据流在Flash存储器资源有效利用和改善存储性能等方面，也有明显的改善。因此，本Flash文件系统很适合于嵌入式多媒体应用。

篇5：嵌入式系统中的线性Flash文件系统设计

嵌入式系统中的线性Flash文件系统设计

作者： WuYJ@263.net.cn

摘要：设计一种能够在典型嵌入式环境下应用的线性文件系统，为嵌入式系统Flash空间的管理提供一种非常有效的手段。它包装和通用文件系统类似的API接口，设计的实现独立于实时操作系统（RTOS）和具体的Flash典型，可方便移植到不同的嵌入式应用中。

在嵌入式系统中，为了便于对闪存（Flash）空间进行管理，会采用文件的形式来访问Flash。目前，可以购买到的Flash文件系统一般都是兼容DOS的文件系统（Flash File System，FFS），这对需要一个具有复杂的目录层次，并且DDS文件兼容的系统来说是必要的；但是对大多数的嵌入式应用来说，这种文件系统太过奢侈。笔者在参与嵌入式系统项目的时候，设计了一种线性文件系统，它适用于大多数的嵌入式应用对Flash文件系统的需求。

线性文件系统设计基于三个目标：一是提供给应用程序通过文件名而不是物理地址访问系统Flash的能力；二是文件系统的设计独立于实时操作系统（RTOS），这样可以很容易移植到不同的嵌入式应用中；三是设计统一的底层接口，适应不同的Flash类型。本文设计的线性文件系统为典型的嵌入式系统提供了所需的类文件系统能力。需要注意的是，本文件系统不支持复杂的Flash扇区擦写次数均衡算法，没有目录层次，并且和其它的文件系统不兼容。

1 线性文件系统

线性文件系统的设计思路是这样的：文件分为文件头和文件数据区两个部分，每个文件按照顺序存放在Flash中，以单向链表来链接文件。文件的起始部分是文件头，包含文件的属性、指向下一个文件头的指针、文件头和文件数据区的32位循环冗余校验和（CRC32）等。文件头用一个32位的字来表示文件属性，每位表示一种属性，如数据文件或者是可执行文件，是否已删除的文件等，具体可以根据应用的需要来定义文件的属性；文件头和文件数据区维护独立的CRC32校验，使文件系统能更精确检测文件的完整性。文件的起始地址没有特殊需求，分配给文件系统的Flash大小限制了文件的大小。另外，线性文件系统作为嵌入式系统的一个功能模块，它为应用程序提供与标准文件系统类似的API接口，如：read、write()、open、close()、stat()和seek（）等。对于同时在多片Flash的系统而言，每片Flash相当于一个目标，文件都可存储在任何一片中（当然受物理空间限制），但不能跨片存储。

图1 Flash文件系统空间

在第一个文件创建之前，必须进行初始化，将所有分配给文件系统的`Flash空间擦除。当创建第一个文件时，起始位置从文件系统的起始地址开始，文件头指针指向下一个空文件的起始位置（链表尾部）；第二个文件的位置从当前的链表尾部开始，同时文件头中的链表指针指向新的尾部。删除文件时，仅仅是简单地把文件头的标识位中的活动文件标识位置0，表示删除。这样，在经过多次删除之后，就有必要运行碎片整理模块来进行文件系统Flash空间的碎片整理。碎片整理模块还需要在文件系统Flash空间尾部留一个扇区来数据备份，以便当碎片整理被打断时（如下电或者复位）可以恢复文件系统。这个保留的扇区称空闲扇区。它必须放在文件系统空间之后，这样可以保证文件系统的所有文件在所占用的Flash空间是连续的。整个文件空间的分配如图1所示。

阴影部分是文件头，数据结构如下：

struct hdr{

unsigned short hdrsize; /*文件头字节数*/

long filsize; /*文件头版本*/

long filsize; /*文件大小*/

long flags; /*描述文件的标识*/

unsigned long filcrc； /*文件数据的CRC32的值*/

unsigned long hdrcec; /*文件的最后修改时间*/

struct hdr *next; /*指向下一个文件头的指针*/

char name[NAMESIZE]; /*文件名*/

char info[INFOSIZE]; /*文件描述信息*/

};

碎片整个记录区包含两种数据类型：碎片整理文件头信息表defraghdr和文件区扇区整理前后的CRC值备份表sectorcre。具体的地址分配从空闲扇区的起始地址减1开始，往前分配文件系统扇区数乘以4字节作为sectorcrc的空间；从sectorcrc起始地址减1开始，往前分配活动文件个数乘以64字节作为碎片整理文件头信息表。这两个结构定义如下：

struct defraghdr{

struct hdr *ohdr; /*文件头的原始位置指针*/

struct hdr *nextfile; /*指向下一个文件的指针*/

long filsize; /*文件大小*/

unsigned long crc; /*这个头的CRC32值*/

unsigned long ohdrcrc; /*原始文件头CRC32值的拷贝*/

long idx; /*碎片整理表头的索引*/

long nesn; /*新的文件尾的扇区号*/

long neso; /*新的文件尾的扇区偏移量*/

char *nda; /*新的文件起始地址*/

char fname[NAMESIZE]; /*文件名*/

};

struct sectorcrc{

unsigned long precrc; /*碎片整理前扇区数据CRC32的值*/

unsigned long postcrc; /*碎片整理后扇区数据CRC32的值*/

}；

从上面介绍可知，除了文件数据之外，文件系统还需要如下4种额外的开销。

①文件头：这是每个文件必须的开销，如果文件名和信息域各24字节，那么整个文件头共76字节。

②碎片整理文件头信息表：每个活动（非删除）的文件在进行碎片整理时在这个表里创建一个表项，每个表项64字节。

③碎片整理前后的扇区CRC32值表：保存文件整理前后的CRC32值，总的字节数约为文件所占扇区数的4倍。

④空闲块：用来在碎片整理过程中备份当前整理扇区数据。它必须不小于文件系统其它所有扇区。

可以用下面方程计算系统开销的总和：

overhead=(FTOT*(HDRSIZE+64))+SPARESIZE+(SECTORCOUNT*8)

其中：

FTOT是总的文件数；

HDRSIZE是文件头字节数（目前为76字节）；

SPARESIZE是空闲块的大小；

SECTORCOUNT是分配给文件系统的Flash扇区数，不包括空闲块。

图2 文件碎片整理

2 碎片整理

创建新文件需要占用文件系统空间；但是，由于Flash的底层技术不允许Flash中的任意地址空间被删除，而是按照扇区为单位删除，为此在删除一个文件的时候，暂时没有把整个文件所占的空间删除，仅仅是在文件头的标识里作一个删除标识，并保留在Flash中。这样，被删除文件积累到一定的数量时，就会占用相当大的空间。因此，需要整理文件系统Flash空间，使被删除文件占用的空间重新使用。图2显示了碎片整理过程。文件F1、F2和F5已经被删除，并且在碎片整理之后从Flash中被清除。

进行碎片整理的方法可以有多种。对于嵌入式系统来说，选择哪种方法，衡量的依据是复杂性和功能之间的平衡。下面讨论两种不同的方法：第一种方法相当简单，但是有缺陷；第二种方法功能强大得多，笔者在线性文件实现中即采用这种方法。当然，存在更加复杂的解决办法，但通常的情况是，所添加的复杂性会使整个文件系统的实现更加复杂。目标是保持文件存储的简单和线性，保证所有的文件都是以连续的空间存储在Flash中。

最简单的方法是将活动的文件备份在RAM中，删除分配给文件系统的Flash空间，然后将RAM中备份的所有文件拷贝回Flash。这种方法很简单，并且不需要分配一个扇区作为空闲区；但问题是，需要有一整块和分配给文件系统的空间一样大的RAM来完成这项工作。更糟的是，如果此时系统被复位，或者在删除扇区内容却还没有将文件拷贝回Flash的时候被断电，文件系统将会崩溃。因为RAM中的内容会随之选择，文件内容会被破坏掉。

我们在文件系统实现设计了一种碎片整理方法，可以防止在碎片整理过程中系统复位导致文件崩溃的情况。采用这种方法，不需要大块的RAM，但是需要预选先分配给碎片整理过程一个Flash扇区作为备份区。这个扇区的字节数不小于任何分配给文件系统的扇区。在整个文件系统中，这个扇区位于分配给文件系统最后一个扇区的下一个扇区。因为扇区可能比需要分配给非删除文件的备份的空间要小，所以它必须逐个扇区进行处理，而不是一下就把所有的碎片整理完。采用备份扇区的好处是，在碎片整理过程中，无论断电或者复位都不会破坏文件系统。当下次系统重新恢复时，会根据在碎片整理前记录的每个扇区碎片整理前后CRC值，来判断当前的文件碎片整理状态。如果上次文件整理没有完成，就会继续上次的整理。这种技术的一个缺陷是空闲扇区的擦写次数会较多。这样空闲扇区就可能因为达到擦写寿命而失败。达到这一点的关键依赖于使用的Flash、所分配给文件系

统的扇区数、文件删除和重建的频率。一个可行的解决办法采用电池备份的RAM来替换空闲扇区，可以增加Flash的整体寿命，但是对那些预算紧张的应用来说太过奢移。

具体的碎片整理过程是，首先建立碎片整理区。①为每个扇区建立2个CRC32表项；第一个CRC32是这个扇区在碎片整理前的CRC值；第二个CRC32值是计算出来的碎片整理后的CRC32值。这些CRC是当碎片整理过程被打断时，用来重新恢复整理用的。②创建碎片整理文件头信息表，每个活动的文件占用一个表项。③计算①和②的CRC值，并保存。①～③的数据保存在图1中的碎片整理记录区。第二步是文件重定位；遍历文件系统的每个扇区，处理重新定位后存储空间和该扇区相覆盖的文件。在每个扇区被重写之前，扇区原来的信息被保存在空闲扇区里。第三步，擦除Flash；遍历未使用的扇区，确认所有的扇区被删除。第四步，完整性检测：对新的文件进行检测，保证所有重定位的文件都是完整的。

3 应用分析

Flash的扇区有最大擦写次数。当前的Flash芯片一般支持10万～100万次的擦除。文件系统的应用各不相同，所以这里不能下结论说采用线性文件系统Flash的寿命会有多长。下面解释文件系统访问Flash的方法。这样用户可以根据应用来判断Flash的预期寿命。

我们所设计的线性文件系统并不进行扇区删除次数均衡，以延长Flash的使用寿命。如果所需要的文件系统频繁修改并需要扇区删除次数均衡，可以购买现成的Flash文件系统。扇区删除均衡算法大大增加了底层实现的复杂性，并且超出本文的讨论范围。一般来说，通过文件系统来管理Flash的需求远大于对Flash扇区擦写次数均衡的需求，特别是现在越来越多的Flash扇区都支持100万次的擦写。

如上面所提到的，文件系统本身提供给编程者的接口API与标准OS提供的接口类似。这可能误导开发者认为文件系统可以看作是一个硬盘，以任意的频率进行读写操作。事实并不是这样，线性文件系统碎片整理同制并没有进行擦写次数均衡，这意味着空闲扇区可能会是最早损坏的Flash扇区。因为在碎片整理过程中，空闲扇区被用作其它所有扇区的暂时存放扇区。例如在设计里，有13个扇区Flash用来作线性文件系统区，有1个扇区作为空闲扇区。假设对于最坏情况的碎片整理（13个扇区都影响到），如果每天进行1次碎片整理，对于100 000次擦写次数的Flash而言，可用期能够超过（100 000/13/365=21）。20年是基于每天进行1次碎片整理，并且所有扇区都影响到的情况。碎片整理的频率和整理所影响到的扇区数受应用程序使用文件的限制。用户可以根据文件系统的应用来估算Flash扇区的磨损情况，并作相应的处理。

下面讨论文件系统是如何使用扇区的。Flash扇区仅仅在碎片整理时候才被擦除。当删除文件的时候，只是简单地作一个标识（文件头的一个位）。如果一个存在的文件以写的方式打开，实际的修改步骤是，删除原有的文件，并在当前文件系统的最后一个文件之后重写该文件。最后，这个过程会使文件系统的Flash空间被耗尽，这要就需要运行碎片整理程序。碎片整理程序会使已被删除文件所占用的空间被清除，所有活动的文件在Flash中的位置以连续的方式存放。每个扇区的整理过程是，扇区被拷贝到空闲扇区作备份，然后原来的扇区被删除，计算出该扇区在文件整理后的内容，写入扇区，之后删除空闲扇区的备份。文件系统从头到尾每个扇区重复这样作。在碎片整理时，如果一个扇区不需要进行碎片整理，碎片整理程序就不会动这个扇区因此，受碎片整理程序影响的扇区数目依赖于当前被文件系统占用的Flash扇区数和被删除文件在Flash中的位置。

在一个典型的嵌入式应用里，文件系统中的可执行文件本身就是应用程序。可执行文件一般是最大的文件，也是最不可能经常改变的文件。这意味着执行文件所占用的空间是相对固定的，将会减少空闲扇区因为碎片整理而进行的擦写次数。另外一方面，如果有任何文件需要定期改动，碎片整理将会更加频繁运行。

结语

本文所设计的线性文件系统已经成功应用在笔者参加的嵌入式系统的产品，并且在实践中证明是一种比较有效的管理Flash的方式。当然，线性文件系统不是解决所有嵌入式应用管理Flash空间问题的答案，但是它对于那些不能判断是否要购买现成的Flash文件系统的项目提供了一个非常有用的选择方案。有关线性文件系统实现的C源代码，可以通过E-Mail:WuYJ@263.net.cn直接与笔者联系。

篇6：嵌入式操作系统VxWorks中TFFS文件系统的构建

嵌入式操作系统VxWorks中TFFS文件系统的构建

关键词：VxWorksFlashMTDTFFS文件系统

嵌入式系统正随着Internet的发展而在各个领域得到广泛的应用，作为一个优秀的操作系统，VxWorks实现了比其他实时操作系统更好的有效性、商用性、可裁减性以及互操作性，广泛应用在通信、军事、航空、航天等高精尖技术及实时性要求极高的领域中，如卫星通讯、军事演习、弹道制导、飞机导航等。

如今越来越多的嵌入式操作系统中，通常都使用FLASH作为主存介质。许多开发者和用户为了方便以后升级用户程序，通常在FLASH上建立TFFS文件系统，建立文件系统后，我们就可以象在windows操作系统下对硬盘操作一样，进行数据的拷贝、删除以及文件的建立等操作。

NOR和NAND是现在市场上两种主要的非易失闪存技术。Intel于1988年首先开发出NORflash技术，彻底改变了原先有EPROM和EEPROM一统天下的局面。NOR的特点是芯片内执行XIPexecuteInPlace，这样应用程序可以直接在flash闪存内运行，不必再把代码读到系统RAM中。NOR的传输效率很高，在1～4MB的小容量时具有很高的成本效益，因此在嵌入式系统得到广泛的应用。

一、TFFS文件系统结构简介

Tornado的TrueFFS是和VxWorks兼容的一种M-SystemsFlite实现方式，版本为2.0。它为种类繁多的flash存储设备提供了统一的块设备接口，并且具有可重入、线程安全的特点，支持大多数流行的CPU构架。有了Tornado的TrueFFS，应用程序对flash存储设备的读写就好象它们对拥有MS-DOS文件系统的磁碟设备的操作一样。

如图1所示，TrueFFS由核心层（corelayer）和三个功能层，翻译层（translationlayer），MTD层（MTDlayer），socket层（socketlayer）组成。

核心层（Corelayer）：核心层主要起相互连接其他几层的功能。同时它也可以进行碎片回收、定时器和其他系统资源的维护。通常WindRiver公司将这部分内容以二进制文件提供。

翻译层主要实现TrueFFS和dosFs之间的高级交互功能。它也包含了控制flash映射到块、wear-leveling、碎片回收和数据完整性所需的智能化处理功能。目前有三种不同的翻译层模块可供选择。选择哪一种层要看你所用的flash介质是采用NOR-based,还是NAND-based,或者SSFDC-based技术而定。

Socket层则是提供TrueFFS和板卡硬件（如flash卡）的接口服务。其名字来源于用户可以插入flash卡的物理插槽。用来向系统注册socket设备，检测设备拔插，硬件写保护等。后面将详细讲解它的.功能。

MTD层（MemoryTechnologyDrivers）功能主要是实现对具体的flash进行读、写、擦、ID识别等驱动，并设置与flash密切相关的一些参数。TrueFFS已经包含了支持Intel,AMD以及samsung部分flash芯片的MTD层驱动。新的芯片需要新的MTD支持，你可以使用一个标准的接口来加入这些驱动。

以上四部分，我们通常要的工作就是后两层。

当在VxWorks下配置TrueFFS时，你必须为每一层至少包含一个软件模块。后面我们将详细讨论。

二、MX29LV160BT芯片上建立TrueFFS文件系统

1、配置相关文件

在此，我以NorFlashMX29LV160BT为例，开发工具为Tornado2.2forPPC。要在VxWorks映像中包含TrueFFS文件系统，首先必须在config.h文件中定义INCLUDE_TFFS。这使得VxWorks的初始化代码调用tffsDrv()来创建管理TrueFFS所需的结构和全局变量，并为所有挂接了的flash设备注册socket组件驱动。在链接的时候，通过解析与tffsDrv()相关联的符号（symbols）可以将TrueFFS所必需的软件模块链接到VxWorks映象中。

为了支持TrueFFS，每一个BSP目录下都必须包含一个sysTffs.c文件。它将TrueFFS所有的层（翻译层，socket层和MTD层）链接到一起并和VxWorks绑定。因此，我必须编辑这个文件并决定哪一种MTD和翻译层模块应该包含到TrueFFS中。即：

#defineINCLUDE_MTD_MX29LV/*MX29LV160BTMTDdriver*/

#defineINCLUDE_TL_FTL/*FTLtranslationlayer*/

#defineFLASH_BASE_ADRS0x2a10000/*Flashmemorybaseaddr

ess*/

#undefFLASH_SIZE

#defineFLASH_SIZE0x001f0000/*Flashmemorysize,2M(parameterblock)*/

其他无关的MTDdriver包含头都#undef掉，同时定义Flash在系统中的基地址和大小。另外，还必须编辑sysLib.c中的sysPhysMemDesc[]数组，将Flash基地址和大小加入到MMU中，以供将来访问Flash，否则访问Flash会失败。如果BSP目录下没有sysTffs.c文件，那么我们可以从其他BSP目录下拷贝一个即可，然后做上述修改，其他的内容基本可以不用修改。

接下来需要修改tffsConfig.c文件，为了方便管理，通常我们将src/drv/tffs/目录下该文件拷贝到我们BSP目录下，然后再做出修改。在MTDidentifyRoutinemtdTable[]表中加入如下语句：

#ifdefINCLUDE_MTD_MX29LV

mx29lvMTDIdentify,

#endif/*INCLUDE_MTD_MX29LV*/

并在该文件开头声明。

#ifdefINCLUDE_MTD_MX29LV

FLStatusmx29lvMTDIdentify(FLFlashvol);

#endif/*INCLUDE_MTD_MX29LV*/

最后就是将我们的flash相关MTD驱动加入到makefile中。即：

MACH_EXTRA=mx29lvMtd.o

为了方便我们调试MTD驱动，应该在重新编译VxWorks映象前将诸如格式化flash、创建TrueFFS块设备、绑定此块设备到dosFs所必要的功能包含到VxWorks映像中。比如如下定义：

#defineINCLUDE_TFFS

#ifdefINCLUDE_TFFS

#defineINCLUDE_TFFS_DOSFS

#defineINCLUDE_TFFS_SHOW

#defineINCLUDE_DOSFS/*dosFsfilesystem*/

#defineINCLUDE_SHOW_ROUTINES/*showroutinesforsystemfacilities*/

#defineINCLUDE_TL_FTL

#defineINCLUDE_IO_SYSTEM

#defineINCLUDE_DISK_UTIL

#endif/*INCLUDE_DOSFS*/

2、MTD驱动简介

做了上述配置后，进入VxWorks操作系统后，我们在shell上利用tffsShow工具来显示flash的信息。TffsShow函数最终会调用MTD驱动中的mx29lvMtdIdentiy()函数，在mx29lvMtdIdentiy()函数主要是通过读取MX29LV160BT芯片的设备和厂商ID来识别它，然后对FLFlash结构成员进行初始化，最主要的几个参数是：

type

Flash内存的JEDECID号。

erasableBlockSize

Flash内存的擦除块大小（字节）。设置这个值时应考虑到interleaving。因此，通常通过如下方法来设置它的大小。

Vol.erasableBlockSize=MX29LV_MTD_SECTOR_SIZE*vol.interleaving;

对于MX29LV160BT，MX29LV_MTD_SECTOR_SIZE为64K字节。

chipSize

使用来构建TrueFFS文件系统的flash实际大小（字节）。

noOfChips

使用来构建TrueFFS文件系统的flash实际片数。

interleaving

Flash内存交叉因子（interleavingfactor）。即扩展数据总线的设备数。比如，一个32位数据总线上，我们可以使用4片8位或2片16位的设备。

map

指向flash内存映射（map）函数。该函数将flash映射到内存区。

read

指向flash内存的读函数。在MTD驱动识别函数中，这个成员函数已经被初始化为缺省的读函数。通常情况下，我们不需要再初始化它，否则还需要修改很多相关的函数。

write

指向flash内存的写函数。这个成员必须初始化，这是我们要做的一个重要工作。

erase

指向flash内存的擦除函数。这个成员必须初始化，这也是我们要做的一个重要工作。

针对FLFlash结构成员，我们所关心的两个函数就是写和擦除函数。在mx29lvMtdIdentiy()函数中必须有如下定义：

vol.write=mx29lvWrite;

vol.erase=mx29lvErase;

在mx29lvWrite()函数中主要是实现将数据写到flash中。首先需要对扇区进行解锁，然后写入写命令，之后才能进行数据的写入。最后需要判断数据是否写完。为了确保操作成功，我们应该在写完每个数据后进行数据的比较，比较正确后方能进行下一个数据的操作。

在mx29lvErase()函数中主要是实现f

lash扇区的擦除。如今的flash一般都是按照扇区进行擦除操作的。在擦除操作之前也应该首先对扇区进行解锁，然后写擦除建立和扇区擦除命令。擦除成功后，flash中的内容应该是0xffff。所以为了确保成功，我们还是应该在擦除后进行比较，比较正确后方能进入下一个扇区的擦除操作，否则返回擦除错误标志。

所以，对于MTD驱动的调试，基本上就是调试写和擦除两个函数。在调试过程中，我们可以在这两个函数相应位置加入打印语句来调试。为了能调试这两个函数，我们通过在shell上输入命令tffsDevFormat来格式化flash，tffsDevFormat最终会调用mx29lvErase和mx29lvWrite函数，如果成功就会返回0，否则返回-1。当然也可以调用tffsDevCreate函数来验证我们的写和擦除函数的正确性。图2说明了tffsDevCreate调用过程。

在shell上利用tffsShow来验证mx29lvMtdIdentiy。

ètffsShow

0:socket=RFA:type=0x2249,unitSize=0x10000,mediaSize=0x1f0000

value=49=0x31=“1”

说明已正确识别到MX29LV160BT设备，设备号为0x2249。

三、建立TFFS设备

1、挂接设备名

MTD驱动调试成功后，我们就可以给flash设备挂接上dos设备名，如下操作：

格式化：

ètffsDevFormat

value=1

èusrTffsConfig0,0,”/tffs0”

value=0

然后通过devs来查看挂接的设备名。

èdevs

drvname

0/null

1/tyCo/0

1/tyCo/1

5host:

6/pty/rlogin.S

7/pty/rlogin.M

3/tffs0/

8/vio

value=25=0x19

看到/tffs0/说明挂接设备已经成功，接下来就可以利用dosFs文件系统相关命令来操作flash了。如，ls、copy等。

2、从Flash中启动并下载VxWorks映像

要从flash中下载VxWorks映像，首先需要把VxWorks映像拷贝到flash中，在shell中的操作命令为copy“VxWorks”,”/tffs0/VxWorks”，然后修改config.h文件中引导行，如下：

#defineDEFAULT_BOOT_LINE

“tffs=0,0(0,0)host:/tffs0/VxWorksh=192.168.0.153e=192.168.0.154u=targetpw=targeto=cpm”

修改完后，重新编译生成bootrom_uncmp.bin，并把它烧写到flash中（注意：该flash与上面建立TFFS文件系统的flash不一样，它并没有建立文件系统）。然后重新启动，即可看到如下启动画面：

bootdevice:tffs=0,0

unitnumber:0

processornumber:0

hostname&

nbsp;:host

filename:/tffs0/VxWorks

inetonethernet(e):192.168.0.154

hostinet(h):192.168.0.153

user(u):target

ftppassword(pw):target

flags(f):0x0

other(o):cpm

AttachingtoTFFS...done.

Loading/tffs0/VxWorks...894304

Startingat0x10000...

DevelopmentSystem

VxWorksversion5.5.1

KERNEL:WINDversion2.6

CopyrightWindRiverSystems,Inc.,1984-

CPU:MotorolaADS-PowerPC860.Processor#0.

MemorySize:0x1000000.BSPversion1.2/5.

WDBCommType:WDB_COMM_END

WDB:Ready.

到此，说明引导成功。flash整个TFFS文件系统就已经建立成功。

四、结论

VxWorks操作系统中支持TFFS文件系统，我们将VxWorks映像作为文件放到flash上，这就有利于开发者和用户更新应用程序而不需要影响bootrom，直接更新VxWorks映像或者将应用程序直接copy到flash中，然后装载到RAM中运行。

参考文献

1VxWorks5.5Programmer’sGuide.

篇7：嵌入式系统中的线性Flash文件系统设计

嵌入式系统中的线性Flash文件系统设计

作者： WuYJ@263.net.cn

摘要：设计一种能够在典型嵌入式环境下应用的线性文件系统，为嵌入式系统Flash空间的管理提供一种非常有效的手段。它包装和通用文件系统类似的API接口，设计的实现独立于实时操作系统（RTOS）和具体的Flash典型，可方便移植到不同的嵌入式应用中。

在嵌入式系统中，为了便于对闪存（Flash）空间进行管理，会采用文件的形式来访问Flash。目前，可以购买到的Flash文件系统一般都是兼容DOS的文件系统（Flash File System，FFS），这对需要一个具有复杂的目录层次，并且DDS文件兼容的系统来说是必要的；但是对大多数的嵌入式应用来说，这种文件系统太过奢侈。笔者在参与嵌入式系统项目的时候，设计了一种线性文件系统，它适用于大多数的嵌入式应用对Flash文件系统的需求。

线性文件系统设计基于三个目标：一是提供给应用程序通过文件名而不是物理地址访问系统Flash的能力；二是文件系统的设计独立于实时操作系统（RTOS），这样可以很容易移植到不同的嵌入式应用中；三是设计统一的底层接口，适应不同的Flash类型。本文设计的`线性文件系统为典型的嵌入式系统提供了所需的类文件系统能力。需要注意的是，本文件系统不支持复杂的Flash扇区擦写次数均衡算法，没有目录层次，并且和其它的文件系统不兼容。

1 线性文件系统

线性文件系统的设计思路是这样的：文件分为文件头和文件数据区两个部分，每个文件按照顺序存放在Flash中，以单向链表来链接文件。文件的起始部分是文件头，包含文件的属性、指向下一个文件头的指针、文件头和文件数据区的32位循环冗余校验和（CRC32）等。文件头用一个32位的字来表示文件属性，每位表示一种属性，如数据文件或者是可执行文件，是否已删除的文件等，具体可以根据应用的需要来定义文件的属性；文件头和文件数据区维护独立的CRC32校验，使文件系统能更精确检测文件的完整性。文件的起始地址没有特殊需求，分配给文件系统的Flash大小限制了文件的大小。另外，线性文件系统作为嵌入式系统的一个功能模块，它为应用程序提供与标准文件系统类似的API接口，如：read()、write()、open（）、close()、stat()和seek（）等。对于同时在多片Flash的系统而言，每片Flash相当于一个目标，文件都可存储在任何一片中（当然受物理空间限制），但不能跨片存储。

图1 Flash文件系统空间

在第一个文件创建之前，必须进行初始化，将所有分配给文件系统的Flash空间擦除。当创建第一个文件时，起

[1] [2] [3]

★分布式文件系统 FastDFS

★嵌入式实验心得体会

★嵌入式软件开发论文

★个人嵌入式学习总结

★嵌入式实训心得体会

★嵌入式的培训心得体会

★嵌入式的实验心得

★根高一作文

★根童话作文

★生命“根”作文

《制作嵌入式Linux根文件系统（共7篇）.doc》

将本文的Word文档下载到电脑，方便收藏和打印

推荐度：

点击下载文档

文档为doc格式