麒麟色在线影院怎么看:嵌入式Linux下NAND存储系统的设计与实现

作者：胡勇其，侯紫峰    时间：2006-10-17  来源:
摘要：讨论嵌入式Linux下与NAND闪存存储设备相关的Linux MTD子系统、NAND驱动，并就与NAND闪存相关的文件系统、内核以及NAND闪存存储设计所关注的问题如坏块处理、从NAND启动、当前2.4 和2.6 内核中NAND通用驱动所存在的缺陷进行讨论并给出解决方案。以Omap161x H2开发板为例，给出了NAND闪存存储实现实例并指出设计中需要关注的问题。
关键词：NAND闪存；驱动；MTD；Omap161x
引言
NAND和NOR是现在市场上两种主要的非易失闪存技术。相对于NOR 而言，NAND结构能提供极高的单元密度，可以达到高存储密度，并且写入和擦除速度很快，同时，NAND闪存的成本要低于NOR 闪存。因此尽管NAND的接口特殊，管理复杂，读取速度不及NOR，但是从性价比出发，NAND闪存逐渐成为嵌入式系统的首选存储设备。
NAND闪存具有以下特点：NAND器件是基于I/O接口的（NOR闪存是基于Bus的RAM接口），以页为单位读写，以块为单位擦除。NAND芯片通过多个引脚传送命令、地址和数据，使用较复杂的I/O接口来控制，同时，根据NAND规范，NAND闪存中允许存在坏块。NAND闪存的每一页都有8B（页长度256B）或者16B（页长度为512B）的OOB（Out Of Band）数据区，用来存放ECC（Error Checking &Correction）、ECC有效标志、坏块标志等。所有这些决定了基于NAND的存储系统设计需要处理不同于其它类型闪存的特有问题。
MTD 结构和NAND驱动接口
Linux上设计了MTD子系统为闪存类型的设备向上层提供统一接口。MTD的主要目的是实现子系统公用部分，使新的存储设备的驱动设计更加简单。一个MTD设备按照用户访问的顺序可以得到图1 所示的层次结构。图1中NAND特定硬件驱动层为具体NAND设备的驱动，实现特定硬件的具体操作；NAND通用驱动层是所有NAND设备的公用部分，实现了NAND设备发现、通用NAND读写等操作；MTD 原始设备层是MTD原始设备的通用代码，此外还包括各个特定的闪存设备所注册的数据，例如NAND分区等。MTD向上提供块设备和字符设备两种接口。文件系统通过MTD 块设备接口访问NAND闪存驱动。

图1 Linux MTD 的层次结构
具体的NAND闪存驱动是和NAND通用驱动相关联的，要实现一个NAND闪存硬件驱动，需要实现以下部分：初始化函数，硬件相关的设备就绪函数和控制函数，为了灵活起见，还可以实现硬件相关的命令函数、硬件相关的等待函数和硬件ECC函数。
NAND设备驱动初始化时分配必要的内存，设置IO地址，然后利用NAND通用驱动提供的设施，调用nand_scan来完成通用部分的设置，最后定义闪存分区并在MTD中注册来完成初始化。可以通过Linux 内核中的实例了解NAND驱动的结构。
和NAND特性相关的问题
NAND闪存具有其它类型的闪存所不具有的特性，因此基于NAND的存储设计需要考虑这些问题。NAND闪存的正确、高效使用取决于以下问题的正确解决。
坏块问题
NAND闪存定位为一种低成本存储介质，从成本和技术上综合考虑，NAND闪存允许存在一定比例的坏块。坏块的产生有多种原因，如解码失败，地址线错误，存储单元错误等，出品前厂商经过测试，将确认的坏块标记出来。同时，因为NAND闪存的擦写寿命有限（一般在105-106次），当使用到一定时限后也会产生坏块， 这些坏块通过擦除和写入后的状态来判断，产生擦除或写入失败的块应该认为已经损坏，并由文件系统或者其它管理程序标记出来。
坏块在NAND闪存的OOB 区域中标记，NAND闪存的每页都有16B的OOB（以页为512B 为例），每个块的第一页的OOB的第6个B用来记录该块是否是坏块，当该B为非0xff时则表明该块是坏块。
为了正确使用NAND闪存，需要进行坏块管理，坏块管理的基本思想是：避免操作坏块，同时在读写操作时跳过坏块而使得上层操作看来闪存存储区仍然是连续的。
与文件系统相关的坏块管理
在NAND闪存上使用较多的文件系统是JFFS2和Cramfs，其中JFFS2有针对NAND闪存的实现，因此可以很好地处理NAND特性相关的问题，包括坏块，但是Cramfs无法意识到NAND闪存的存在（Cramfs 不是为NAND闪存设计的），为了能够在NAND闪存上使用Cramfs，需要增加坏块管理，考虑到文件系统的复杂性，直接在Cramfs中增加比较困难，因此本文考虑在NAND闪存和Cramfs文件系统之间增加一个管理层次来处理这个问题。
Samsung S3C2440X有一个类似的实现方式，但是这个设计存在以下不足：该实现通过存储在NAND闪存分区尾部的分区表来定义又一级的分区，本文认为这是多的，一般来说用户不会再在闪存分区上定义另外的分区，也没有必要因此而考虑使用专用的操作工具，基于NAND闪存驱动中定义的分区来直接管理坏块并作为用户分区已经足够，而且这样不需要专有工具支持，设计和使用都比较简单；该实现需要把MTD分区中的坏块信息存储到闪存上，这需要占用空间，本文的实现通过打开NAND分区时扫描分区上的全部块来记录坏块，由于是每块仅读一次OOB的1位，总耗时不会太长；同时也没有必要把所有的NAND分区都加入到坏块控制中，只有要使用Cramfs的分区才是需要的，因此应该给予用户选择权。
作者所设计的NAND块管理模块BM 实现为一个只读的块设备驱动程序，它将读操作的地址经过转换处理之后用新的地址执行MTD 的读操作。除了执行与MTD 和NAND相关的特定处理之外它是标准的块设备驱动。
# define NOT2BLON 256
/* 控制标志，所有NAND设备都有此标志，需要加入到BM 者
在其分区上设置此标志（实际上是清除该标志）*/
/* 初始化， 注册MTD User，为MTD 提供设备加入时的回调函
数*/
struct mtd_notifier BM_Notifier = {
add： BM_notify_add，
remove： BM_notify_remove
}；
register_mtd_user(&BM_Notifier)；
/* 当有新设备加入，或者注册时已经存在MTD 设备时，MTD通过调用BM_notifier_add 通知BM 驱动*/
/*BM_notifier_add 判断设备是否需要加入BM，如果是NAND闪存并且无NOT2BLON 标志则加入BM*/
if (!mtd->type！=MTD_NANDFLASH) return；
if(mtd->flags & MTD_NOT2BLON) return；
/* 扫描设备，获得所有坏块的地址，并保存到bad_blocks 中*/
bad_blocks=kmalloc ((1+mtd->size/mtd->erasesize)*
sizeof(unsigned short)， GFP_KERNEL)；
offset=0； length=mtd_size –mtd_block_size
for(；offset<= length； offset+=mtd_block_size) {
if (MTD_READOOB(mtd， offset， 8， &retlen， oobbuf) < 0)
continue
if (oobbuf[5] != 0xff)
bad_blocks[badnum++]=offset/mtd->erasesize；
}
/* 读操作时，计算所有小于地址old_block_address 的坏块，得到此地址之前的坏块个数，然后将该地址增加相应的长度作为新地址
new_block_adderss 访问设备*/
if (bad_blocks) {
unsigned short *bad = bad_blocks；
while(*bad++ <= old_block_addrerss)
block++；
}
new_block_adderss=old_block_adderss+block；
BM_notifier_remove 在删除MTD 设备时调用，执行与
BM_notify_add 相反的资源操作，释放占有的资源。
损耗均衡
NAND闪存的寿命是有限的，一个NAND块的擦写次数大概在105-106 次，为了保持NAND的使用寿命足够长，必须避免擦写区域的不均衡，否则闪存会因为局部达到擦写极限而报废，这实际上是浪费。必须实现机制达到磨损均衡(Wear Balance)，延长闪存的有效使用寿命。
损耗均衡需要由文件系统或者附加的层次来处理。JFFS2采取日志和顺序写入，很好的解决了这个问题，Cramfs是只读的，除了初始化之外不进行擦除和写入操作，不需要关心这个问题；需要使用其它非NAND闪存特定的文件系统者（比如Ext2 等）需要考虑这个问题。
NAND存储系统设计
NAND驱动设计相关的问题
除了上述NAND设备的共性问题之外，在设计和实现中还有以下问题需要考虑：
(1)地址自动增加问题
存在两种类型的NAND地址处理方式：地址自动增加和地址不自动增加。对于地址自动增加的NAND，当读数据至一页的末尾时，NAND内部地址自动增加到下一页的数据区，读取OOB数据时，也会自动增加到下一页的OOB区（部分NAND支持通过GND管脚信号把整个数据区和OOB作为一个连续的区域增加地址），这个过程会持续到一块结束，然后需要重新向NAND闪存写命令和地址；地址不自动增加的NAND闪存的开始每一页操作都需要重新写命令和地址，否则内部地址不会自动增加到下一页，无法继续正确操作。这是NAND闪存驱动设计需要注意的，后面就会看到，现在的Linux内核中的MTD版本恰恰存在这方面的问题。
(2)设备就绪和时间限制
确定设备是否就绪用于判断是否可以开始执行下一个操作，实现的方式有：延时，读取NAND的状态，读取R/B（Ready/Busy）管脚的输入信号。R/B管脚输入是最快捷的方式，一般的设计中会将R/B管脚连接到GPIO，NAND驱动通过读取GPIO 输入获得R/B状态，无R/B输入就需要通过延时和读取NAND的状态寄存器来判断。不同的NAND芯片和不同的操作其耗时是不同的（如Samsung K9F56xxQ0B 的写操作时间为200μum-500μm，擦除操作时间为2ms-3ms），需要根据设备Data sheet来设定，不正确的设置会导致错误。
(3)连接方式问题
NAND到系统的连接有软件连接方式和硬件连接方式：软件方式是在满足时序要求的条件下直接将NAND闪存的IO管脚、控制管脚和系统的数据、地址和读写信号线相连，因此这种连接方式对NAND的命令、地址的输入和数据的输入输出类似对不同地址的几个寄存器的访问；另一种方式是通过NAND控制器和系统相连，NAND芯片连接到NAND控制器上，由NAND控制器来满足NAND的时序，控制NAND，并实现硬件ECC等功能，命令、地址输出、数据输入输出和控制是对NAND控制器的相应寄存器的操作。软件方式硬件接口简单，但需要较多的软件操作来实现功能，硬件方式需要NAND控制器，但是可以通过NAND控制器完成更多的功能，应该根据成本和功能要求进行设计，根据实际连接方式进行NAND操作。
从NAND闪存启动
作为嵌入式系统的存储设备，从NAND闪存启动的要求是很自然的。由于NAND闪存采用IO接口，无SRAM接口（NOR闪存是RAM接口），不能通过Bus访问NAND，在NAND驱动加载之前无法访问NAND，因此无法直接从NAND上启动系统，需要其它的辅助机制。有如下的启动机制可供需要从NAND启动的系统使用：
(1)Boot loader方式：通过系统上的ROM或者NOR闪存，存储一段boot代码，这段代码可以是boot loader的一部分，也可以是全部boot loader，由于ROM和NOR闪存是可以直接启动的，系统启动后加载这部分代码，执行这段代码从NAND读入boot loader的剩余部分和内核映像或者直接读入内核映像，实现从NAND启动。
(2)启动机方式（Boot Engine Method）：在系统加电后和产生CPUReset信号之前，通过附加的硬件电路产生符合NAND读操作流程的操作时序（命令、地址和数据读入信号），将NAND闪存的第一块数据自动加载到系统内存，然后再产生CPU的Reset信号，CPU执行这部分加载到内存中的代码，由这段代码从NAND闪存读入boot loader的其余部分和内核映像。按照NAND规范的要求，NAND芯片厂商保证出厂时其NAND产品的第一块是完好的，因此所有NAND闪存都可以作为启动设备。一些NAND闪存支持加电时自动首页读入，当NAND加电时，NAND闪存自动把第一页的内容放到内部缓存，这种情况下实现第二种启动机制所要做的工作可以简化为把NAND的读信号使能，然后读入第一页。许多系统同时拥有NAND闪存和NOR 闪存，因此从NOR启动不需要额外的工作，第一种启动方式是更好的选择，但是从成本等考虑，第二种启动方式更有吸引力。基于TI Omap 161x的平台支持第二种启动方式。许多开发平台也实现了类似的启动机制，开发者应该根据自己的平台和需求选择合适的启动方式。
基于OMAP161x的实现和Linux内核中的问题
以下部分通过本文的实现和遇到的问题来示例NAND驱动和子系统的设计，并指出内核中NAND部分所存在的一些问题。
基于Omap161x H2的实现
采用TI Omap161x H2开发板来实现基于NAND闪存的存储系统，TI 的Omap 平台在通信类产品中有着很广泛的应用，同时其比较复杂的设计使得这个平台下NAND存储的设计更具典型性。Linux 2.4 和2.6 内核中还没有该平台下NAND的驱动支持，需要开发者来实现。
Omap平台系统支持从NAND启动。Omap161x H2所采用的NAND芯片为Samsung K9F5608Q0B（8位）和K9F5616Q0B（16 位），由于2.4 和2.6.*内核的MTD 版本不支持16 位接口，因此本文采用8 位接口。
该NAND闪存具有如下特点：
页大小：512B，块大小：16kB，OOB 大小：16B；该芯片不支持地址自动增加；采用软件连接方式和Omap 连接。
为了实现该NAND闪存的驱动，需要完成以下工作：
配置EMIFS 寄存器：这是Omap161x 和NAND芯片或者NAND控制器的直接控制接口，需要配置EMIFS与NAND对应的片选寄存器CS2 和NAND管脚复用，片选寄存器CS2需要设置使系统I/O 时序满足NAND的时序要求，同时，需要使和NAND相连接的管脚支持NOR 闪存工作模式。对于首次接触Omap平台的开发者来说，开放源码的Boot Loader是很好的参考，如U-Boot，大部分工作可参考U-Boot中的设置。
实现NAND特定的硬件相关的函数：
由于omap161x H2上NAND是以软件方式连接的，地址比较特殊，需要更改已有的nand_command 函数，实现设备特定的nand_command 函数：Omap161x H2上的NAND闪存通过地址0x0A000000，0x0A000002，0x0A000004进行数据数输入输出、命令输入和地址输入，在内核看来这是3个8位的寄存器，需要在命令发送、地址发送和数据输入输出中使用这些地址。
实现设备特定的nand_ready，nand_wait 函数，通过超时和读取NAND的状态查询设备是否就绪。Omap161x上的NAND芯片的R/B管脚通过GPIO连接到Omap，可以通过GPIO获得R/B信号输入，但是设置GPIO比较复杂，尤其是2.4 内核对它的支持很少，更简单的方式是通过超时和读取NAND的状态来实现，这完全可以达到所要求的效果。
本系统采用的文件系统为JFFS2 和Cramfs，JFFS2 能够直接管理NAND的ECC和坏块，为了在NAND闪存上运行Cramfs并使用ECC，实现了块管理层BM，增加了与JFFS2类似的ECC存储和验证方式，Cramfs 通过/dev/bm/* （*为序号） 挂接对应的MTD 分区（通过BM 的proc 接口可以查到对应关系）。
2.4 和2.6 内核中存在的问题
实现过程中额外的工作是更正内核中的错误。2.4 和2.6 内核的MTD 版本都假设NAND是支持地址自动增加的，而且没有可供用户选择的地方，因此对于不支持地址自动增加的NAND设备，NAND通用驱动部分的nand_read_ecc 和nand_read_oob 函数无法正常工作，所产生的错误调试信息往往使开发者陷入误区。作者更改了内核的这部分，通过每一页的读操作都发送读命令和地址，解决了这个问题，这样对两种类型的NAND闪存都是正确的（尽管对地址自动增加的NAND而言有些多余）。NAND通用驱动中的写操作始终以1 页为1 个操作单元，不存在这个问题。2.4 和2.6 内核中的MTD 版本的NAND通用实现中有关NAND状态和操作队列的实现也存在错误，会导致操作中断和错误的重入。在nand_get_chip 函数中有如下的代码：
if (this->state == FL_ERASING) {
if (new_state != FL_ERASING) {
this->state = new_state；
spin_unlock_bh (&this->chip_lock)；
nand_select ()； /* select in any case */
this->cmdfunc(mtd， AND_CMD_RESET， -1， -1)；
return；
} }
这种实现方式会打断NAND操作，导致未完成擦除操作时重入，从而破坏操作队列和后续操作，引入错误。作者更改了nand_get_chip，删除这部分代码以避免错误的重入。
其它细节问题需要通过调试逐渐优化。充分利用MTD和文件系统（如JFFS2）输出的调试信息是发现错误并使设备驱动等正常工作的重要途径。
结语
全文结合我们的实现介绍了嵌入式Linux中NAND存储系统的结构和实现方式，同时就NAND特定的一些问题给出了表述和解决方法，就所要关注的问题如NAND坏块管理、从NAND闪存启动、以及当前2.4 和2.6 内核中的MTD 版本的缺陷进行了阐述，给出了实现，并通过实例说明了NAND存储系统设计中的具体问题，对设计和开发具有参考价值。
嵌入式Linux文件系统及其存储机制分析
开发者在线 Builder.com.cn 更新时间:2008-02-13本文关键词：存储文件系统Linux嵌入式
嵌入式系统与通用PC机不同，一般没有硬盘这样的存储设备而是使用Flash闪存芯片、小型闪存卡等专为嵌入式系统设计的存储装置，本文分析了嵌入式系统中常用的存储设备及其管理机制，介绍了常用的基于FLASH的文件系统类型。
1．嵌入式系统存储设备及其管理机制分析
构建适用于嵌入式系统的Linux文件系统，必然会涉及到两个关键点，一是文件系统类型的选择，它关系到文件系统的读写性能、尺寸大小;另一个就是根文件系统内容的选择，它关系到根文件系统所能提供的功能及尺寸大小。
嵌入式设备中使用的存储器是像Flash闪存芯片、小型闪存卡等专为嵌入式系统设计的存储装置。Flash是目前嵌入式系统中广泛采用的主流存储器，它的主要特点是按整体/扇区擦除和按字节编程，具有低功耗、高密度、小体积等优点。目前，Flash分为NOR, NAND两种类型。
NOR型闪存可以直接读取芯片内储存的数据，因而速度比较快，但是价格较高。NOR型芯片，地址线与数据线分开，所以NOR型芯片可以像SRAM一样连在数据线上，对NOR芯片可以“字”为基本单位操作，因此传输效率很高，应用程序可以直接在Flash内运行，不必再把代码读到系统RAM中运行。它与SRAM的最大不同在于写操作需要经过擦除和写入两个过程。
NAND型闪存芯片共用地址线与数据线，内部数据以块为单位进行存储，直接将NAND芯片做启动芯片比较难。NAND闪存是连续存储介质，适合放大文件。擦除NOR器件时是以64-128KB的块进行的，执行一个写入/擦除操作的时间为5s；擦除NAND器件是以8-32KB的块进行的，执行相同的操作最多只需要4ms。
NAND Rash的单元尺寸几乎是NOR器件的一半，由于生产过程更为简单，NAND结构可以在给定的模具尺寸内提供更高的容量，也就相应地降低了价格。NOR flash占据了容量为1―16MB闪存市场的大部分，而NAND flash只是用在8―128MB的产品当中，这也说明NOR主要应用在代码存储介质中，NAND适合于数据存储。
寿命(耐用性)，在NAND闪存中每个块的最大擦写次数是一百万次，而NOR的擦写次数是十万次。NAND存储器除了具有10比1的块擦除周期优势，典型的NAND块尺寸要比NOR器件小8倍，每个NAND存储器块在给定的时间内的删除次数要少一些。
所有嵌入式系统的启动都至少需要使用某种形式的永久性存储设备，它们需要合适的驱动程序，当前在嵌入式Linux中有三种常用的块驱动程序可以选择。
● Blkmem驱动层
Blkmem驱动是为uclinux专门设计的，也是最早的一种块驱动程序之一，现在仍然有很多嵌入式Linux操作系统选用它作为块驱动程，尤其是在uClinux中。它相对来说是最简单的，而且只支持建立在NOR型Flash和RAM中的根文件系统。使用Blkmem驱动，建立Flash分区配置比较困难，这种驱动程序为Flash提供了一些基本擦除/写操作。
● RAMdisk驱动层
RAMdisk驱动层通常应用在标准Linux中无盘工作站的启动，对Flash存储器并不提供任何的直接支持， RAM disk就是在开机时，把一部分的内存虚拟成块设备，并且把之前所准备好的档案系统映像解压缩到该RAM disk环境中。当在Flash中放置一个压缩的文件系统，可以将文件系统解压到RAM，使用RAM disk驱动层支持一个保持在RAM中的文件系统。
● MTD驱动层
为了尽可能避免针对不同的技术使用不同的工具，以及为不同的的技术提供共同的能力，Linux内核纳入了MTD子系统(memory Technology Device)。它提供了一致且统一的接口，让底层的MTD芯片驱动程序无缝地与较高层接口组合在一起。
JFFS2, Cramfs, YAFFS等文件系统都可以被安装成MTD块设备。MTD驱动也可以为那些支持CFI接口的NOR型Flash提供支持。虽然MTD可以建立在RAM上，但它是专为基于Flash的设备而设计的。MTD包含特定Flash芯片的驱动程序，开发者要选择适合自己系统的Flash芯片驱动。Flash芯片驱动向上层提供读、写、擦除等基本的操作，MTD对这些操作进行封装后向用户层提供MTD char和MTD block类型的设备。
MTD char类型的设备包括/dev/mtd0, /dev/mtdl等，它们提供对Flash原始字符的访问。MTD block类型的设备包括/dev/mtdblock0,/dev/mtdblock1等，MTD block设备是将Flash模拟成块设备，这样可以在这些模拟的块设备上创建像Cramfs, JFFS2等格式的文件系统。
MTD驱动层也支持在一块Flash上建立多个Flash分区，每一个分区作为了一个MTD block设备，可以把系统软件和数据等分配到不同的分区上，同时可以在不同的分区采用不用的文件系统格式。这一点非常重要，正是由于这一点才为嵌入式系统多文件系统的建立提供了灵活性。
2． 基于Flash的文件系统
鉴于Flash存储介质的读写特点，传统的Linux文件系统己经不适合应用在嵌入式系统中，像Ext2fs文件系统是为像IDE那样的块设备设计的，这些设备的逻辑块是512字节、1024字节等大小，没有提供很好的扇区擦写支持，不支持损耗平衡，没有掉电保护，也没有特别完美的扇区管理，这不太适合于扇区大小因设备类型而划分的闪存设备。基于这样的原因，产生了很多专为Flash设备而设计的文件系统，常见的专用于闪存设备的文件系统如下：
● Romfs
传统型的Romfs文件系统是最常使用的一种文件系统，它是一种简单的、紧凑的、只读的文件系统，不支持动态擦写保存;它按顺序存放所有的文件数据，所以这种文件系统格式支持应用程序以XIP方式运行，在系统运行时，可以获得可观的RAM节省空间。uClinux系统通常采用Romfs文件系统。
● Cramfs
Cramfs是Linux的创始人Linus Torvalds开发的一种可压缩只读文件系统在Cramfs文件系统中，每一页被单独压缩，可以随机页访问，其压缩比高达2:1,为嵌入式系统节省大量的Flash存储空间。Cramfs文件系统以压缩方式存储，在运行时解压缩，所以不支持应用程序以XIP方式运行，所有的应用程序要求被拷到RAM里去运行，但这并不代表比Ramfs需求的RAM 空间要大一点，因为Cramfs是采用分页压缩的方式存放档案，在读取档案时，不会一下子就耗用过多的内存空间，只针对目前实际读取的部分分配内存，尚没有读取的部分不分配内存空间，当我们读取的档案不在内存时， Cramfs文件系统自动计算压缩后的资料所存的位置，再即时解压缩到RAM中。
另外，它的速度快，效率高，其只读的特点有利于保护文件系统免受破坏，提高了系统的可靠性;但是它的只读属性同时又是它的一大缺陷，使得用户无法对其内容对进扩充。Cramfs映像通常是放在Flash中，但是也能放在别的文件系统里，使用loopback设备可以把它安装别的文件系统里。使用mkcramfs工具可以创建Cramfs映像。
● Ramfs/Tmpfs
Ramfs也是Linus Torvalds开发的，Ramfs文件系统把所有的文件都放在RAM里运行，通常是Flash系统用来存储一些临时性或经常要修改的数据，相对于ramdisk来说，Ramfs的大小可以随着所含文件内容大小变化，不像ramdisk的大小是固定的。Tmpfs是基于内存的文件系统，因为tmpfs驻留在RAM 中，所以写/读操作发生在RAM 中。tmpfs文件系统大小可随所含文件内容大小变化，使得能够最理想地使用内存;tmpfs驻留在RAM，所以读和写几乎都是瞬时的。tmpfs的一个缺点是当系统重新引导时会丢失所有数据。
● JFFS2
JFFS2是RedHat公司基于JFFS开发的闪存文件系统，最初是针对RedHat公司的嵌入式产品eCos开发的嵌入式文件系统，所以JFFS2也可　● Ramfs/Tmpfs
Ramfs也是Linus Torvalds开发的，Ramfs文件系统把所有的文件都放在RAM里运行，通常是Flash系统用来存储一些临时性或经常要修改的数据，相对于ramdisk来说，Ramfs的大小可以随着所含文件内容大小变化，不像ramdisk的大小是固定的。Tmpfs是基于内存的文件系统，因为tmpfs驻留在RAM 中，所以写/读操作发生在RAM 中。tmpfs文件系统大小可随所含文件内容大小变化，使得能够最理想地使用内存;tmpfs驻留在RAM，所以读和写几乎都是瞬时的。tmpfs的一个缺点是当系统重新引导时会丢失所有数据。
● JFFS2
JFFS2是RedHat公司基于JFFS开发的闪存文件系统，最初是针对RedHat公司的嵌入式产品eCos开发的嵌入式文件系统，所以JFFS2也可以用在Linux,uCLinux中。JFFS文件系统最早是由瑞典Axis Communications公司基于Linux2.0的内核为嵌入式系统开发的文件系统。JFFS2是一个可读写的、压缩的、日志型文件系统，并提供了崩溃/掉电安全保护，克服了JFFS的一些缺点:使用了基于哈希表的日志节点结构，大大加快了对节点的操作速度;支持数据压缩；提供了“写平衡”支持;支持多种节点类型；提高了对闪存的利用率，降低了内存的消耗。这些特点使JFFS2文件系统成为目前Flash设备上最流行的文件系统格式，它的缺点就是当文件系统已满或接近满时，JFFS2运行会变慢，这主要是因为碎片收集的问题。
● YAFFS
YAFFS/YAFFS2是一种和JFFSx类似的闪存文件系统，它是专为嵌入式系统使用NAND型闪存而设计的一种日志型文件系统。和JFFS2相比它减少了一些功能，所以速度更快，而且对内存的占用比较小。此外，YAFFS自带NAND芯片的驱动，并且为嵌入式系统提供了直接访问文件系统的API，用户可以不使用Linux中的MTD与VFS，直接对文件系统操作。YAFFS2支持大页面的NAND设备，并且对大页面的NAND设备做了优化。JFFS2在NAND闪存上表现并不稳定，更适合于NOR闪存，所以相对大容量的NAND闪存，YAFFS是更好的选择。
在具体的嵌入式系统设计中可根据不同目录存放的内容不同以及存放的文件属性，确定使用何种文件系统。以用在Linux,uCLinux中。JFFS文件系统最早是由瑞典Axis Communications公司基于Linux2.0的内核为嵌入式系统开发的文件系统。JFFS2是一个可读写的、压缩的、日志型文件系统，并提供了崩溃/掉电安全保护，克服了JFFS的一些缺点:使用了基于哈希表的日志节点结构，大大加快了对节点的操作速度;支持数据压缩；提供了“写平衡”支持;支持多种节点类型；提高了对闪存的利用率，降低了内存的消耗。这些特点使JFFS2文件系统成为目前Flash设备上最流行的文件系统格式，它的缺点就是当文件系统已满或接近满时，JFFS2运行会变慢，这主要是因为碎片收集的问题。
● YAFFS
YAFFS/YAFFS2是一种和JFFSx类似的闪存文件系统，它是专为嵌入式系统使用NAND型闪存而设计的一种日志型文件系统。和JFFS2相比它减少了一些功能，所以速度更快，而且对内存的占用比较小。此外，YAFFS自带NAND芯片的驱动，并且为嵌入式系统提供了直接访问文件系统的API，用户可以不使用Linux中的MTD与VFS，直接对文件系统操作。YAFFS2支持大页面的NAND设备，并且对大页面的NAND设备做了优化。JFFS2在NAND闪存上表现并不稳定，更适合于NOR闪存，所以相对大容量的NAND闪存，YAFFS是更好的选择。
在具体的嵌入式系统设计中可根据不同目录存放的内容不同以及存放的文件属性，确定使用何种文件系统。
如何为嵌入式开发建立交叉编译环境

文档选项

打印本页

将此页作为电子邮件发送

级别： 初级
恩 梁元 (sunix_yuanenliang@yahoo.com.cn), 软件工程师
2005 年 9 月 01 日
在进行嵌入式开发之前，首先要建立一个交叉编译环境，这是一套编译器、连接器和libc库等组成的开发环境。文章通过一个具体的例子说明了这些嵌入式交叉编译开发工具的制作过程。
随着消费类电子产品的大量开发和应用和Linux操作系统的不断健壮和强大，嵌入式系统越来越多的进入人们的生活之中，应用范围越来越广。
在裁减和定制Linux，运用于你的嵌入式系统之前，由于一般嵌入式开发系统存储大小有限，通常你都要在你的强大的pc机上建立一个用于目标机的交叉编译环境。这是一个由编译器、连接器和解释器组成的综合开发环境。交叉编译工具主要由 binutils、gcc 和 glibc 几个部分组成。有时出于减小 libc 库大小的考虑，你也可以用别的 c 库来代替 glibc，例如 uClibc、dietlibc 和 newlib。建立一个交叉编译工具链是一个相当复杂的过程，如果你不想自己经历复杂的编译过程，网上有一些编译好的可用的交叉编译工具链可以下载。
下面我们将以建立针对arm的交叉编译开发环境为例来解说整个过程，其他的体系结构与这个相类似，只要作一些对应的改动。我的开发环境是，宿主机 i386-redhat-7.2，目标机 arm。
这个过程如下
1. 下载源文件、补丁和建立编译的目录
2. 建立内核头文件
3. 建立二进制工具（binutils）
4. 建立初始编译器（bootstrap gcc）
5. 建立c库(glibc)
6. 建立全套编译器（full gcc）
1. 选定软件版本号
选择软件版本号时，先看看glibc源代码中的INSTALL文件。那里列举了该版本的glibc编译时所需的binutils 和gcc的版本号。例如在 glibc-2.2.3/INSTALL 文件中推荐 gcc 用 2.95以上，binutils 用 2.10.1 以上版本。
我选的各个软件的版本是：
linux-2.4.21+rmk2
binutils-2.10.1
gcc-2.95.3
glibc-2.2.3
glibc-linuxthreads-2.2.3
如果你选的glibc的版本号低于2.2，你还要下载一个叫glibc-crypt的文件，例如glibc-crypt-2.1.tar.gz。 Linux 内核你可以从www.kernel.org 或它的镜像下载。
Binutils、gcc和glibc你可以从FSF的FTP站点ftp://ftp.gun.org/gnu/ 或它的镜像去下载。在编译glibc时，要用到 Linux 内核中的 include 目录的内核头文件。如果你发现有变量没有定义而导致编译失败，你就改变你的内核版本号。例如我开始用linux-2.4.25+vrs2，编译glibc-2.2.3 时报 BUS_ISA 没定义，后来发现在 2.4.23 开始它的名字被改为 CTL_BUS_ISA。如果你没有完全的把握保证你改的内核改完全了，就不要动内核，而是把你的 Linux 内核的版本号降低或升高，来适应 glibc。
Gcc 的版本号，推荐用 gcc-2.95 以上的。太老的版本编译可能会出问题。Gcc-2.95.3 是一个比较稳定的版本，也是内核开发人员推荐用的一个 gcc 版本。
如果你发现无法编译过去，有可能是你选用的软件中有的加入了一些新的特性而其他所选软件不支持的原因，就相应降低该软件的版本号。例如我开始用 gcc-3.3.2，发现编译不过，报 as、ld 等版本太老，我就把 gcc 降为 2.95.3。太新的版本大多没经过大量的测试，建议不要选用。




回页首
首先，我们建立几个用来工作的目录：
在你的用户目录，我用的是用户liang，因此用户目录为 /home/liang，先建立一个项目目录embedded。
$pwd /home/liang $mkdir embedded
再在这个项目目录 embedded 下建立三个目录 build-tools、kernel 和 tools。
build-tools-用来存放你下载的 binutils、gcc 和 glibc 的源代码和用来编译这些源代码的目录。
kernel-用来存放你的内核源代码和内核补丁。
tools-用来存放编译好的交叉编译工具和库文件。
$cd embedded $mkdir build-tools kernel tools
执行完后目录结构如下：
$ls embedded build-tools kernel tools
3. 输出和环境变量
我们输出如下的环境变量方便我们编译。
$export PRJROOT=/home/liang/embedded $export TARGET=arm-linux $export PREFIX=$PRJROOT/tools $export TARGET_PREFIX=$PREFIX/$TARGET $export PATH=$PREFIX/bin:$PATH
如果你不惯用环境变量的，你可以直接用绝对或相对路径。我如果不用环境变量，一般都用绝对路径，相对路径有时会失败。环境变量也可以定义在.bashrc文件中，这样当你logout或换了控制台时，就不用老是export这些变量了。
体系结构和你的TAEGET变量的对应如下表

你可以在通过glibc下的config.sub脚本来知道，你的TARGET变量是否被支持，例如：
$./config.sub arm-linux arm-unknown-linux-gnu
在我的环境中，config.sub 在 glibc-2.2.3/scripts 目录下。
网上还有一些 HOWTO 可以参考，ARM 体系结构的《The GNU Toolchain for ARM Target HOWTO》，PowerPC 体系结构的《Linux for PowerPC Embedded Systems HOWTO》等。对TARGET的选取可能有帮助。
4. 建立编译目录
为了把源码和编译时生成的文件分开，一般的编译工作不在的源码目录中，要另建一个目录来专门用于编译。用以下的命令来建立编译你下载的binutils、gcc和glibc的源代码的目录。
$cd $PRJROOT/build-tools $mkdir build-binutils build-boot-gcc build-gcc build-glibc gcc-patch
build-binutils-编译binutils的目录
build-boot-gcc-编译gcc 启动部分的目录
build-glibc-编译glibc的目录
build-gcc-编译gcc 全部的目录
gcc-patch-放gcc的补丁的目录
gcc-2.95.3 的补丁有 gcc-2.95.3-2.patch、gcc-2.95.3-no-fixinc.patch 和gcc-2.95.3-returntype-fix.patch，可以从http://www.linuxfromscratch.org/ 下载到这些补丁。
再将你下载的 binutils-2.10.1、gcc-2.95.3、glibc-2.2.3 和 glibc-linuxthreads-2.2.3 的源代码放入 build-tools 目录中
看一下你的 build-tools 目录，有以下内容：
$ls binutils-2.10.1.tar.bz2 build-gcc gcc-patch build-binutls build-glibc glibc-2.2.3.tar.gz build-boot-gcc gcc-2.95.3.tar.gz glibc-linuxthreads-2.2.3.tar.gz




回页首
把你从www.kernel.org 下载的内核源代码放入 $PRJROOT /kernel 目录
进入你的 kernel 目录：
$cd $PRJROOT /kernel
解开内核源代码
$tar -xzvf linux-2.4.21.tar.gz
或
$tar -xjvf linux-2.4.21.tar.bz2
小于 2.4.19 的内核版本解开会生成一个 linux 目录，没带版本号，就将其改名。
$mv linux linux-2.4.x
给 Linux 内核打上你的补丁
$cd linux-2.4.21 $patch -p1 < ../patch-2.4.21-rmk2
编译内核生成头文件
$make ARCH=arm CROSS_COMPILE=arm-linux- menuconfig
你也可以用 config 和 xconfig 来代替 menuconfig，但这样用可能会没有设置某些配置文件选项和没有生成下面编译所需的头文件。推荐大家用 make menuconfig，这也是内核开发人员用的最多的配置方法。配置完退出并保存，检查一下的内核目录中的 include/linux/version.h 和 include/linux/autoconf.h 文件是不是生成了，这是编译 glibc 是要用到的，version.h 和 autoconf.h 文件的存在，也说明了你生成了正确的头文件。
还要建立几个正确的链接
$cd include $ln -s asm-arm asm $cd asm $ln -s arch-epxa arch $ln -s proc-armv proc
接下来为你的交叉编译环境建立你的内核头文件的链接
$mkdir -p $TARGET_PREFIX/include $ln -s $PRJROOT/kernel/linux-2.4.21/include/linux $TARGET_PREFIX/include/linux $in -s $PRJROOT/kernel/linux-2.4.21/include/asm-arm $TARGET_PREFIX/include/asm
也可以把 Linux 内核头文件拷贝过来用
$mkdir -p $TARGET_PREFIX/include $cp -r $PRJROOT/kernel/linux-2.4.21/include/linux $TARGET_PREFIX/include $cp -r $PRJROOT/kernel/linux-2.4.21/include/asm-arm $TARGET_PREFIX/include




回页首
binutils是一些二进制工具的集合，其中包含了我们常用到的as和ld。
首先，我们解压我们下载的binutils源文件。
$cd $PRJROOT/build-tools $tar -xvjf binutils-2.10.1.tar.bz2
然后进入build-binutils目录配置和编译binutils。
$cd build-binutils $../binutils-2.10.1/configure --target=$TARGET --prefix=$PREFIX
--target 选项是指出我们生成的是 arm-linux 的工具，--prefix 是指出我们可执行文件安装的位置。
会出现很多 check，最后产生 Makefile 文件。
有了 Makefile 后，我们来编译并安装 binutils，命令很简单。
$make $make install
看一下我们 $PREFIX/bin 下的生成的文件
$ls $PREFIX/bin arm-linux-addr2line arm-linux-gasp arm-linux-objdump arm-linux-strings arm-linux-ar arm-linux-ld arm-linux-ranlib arm-linux-strip arm-linux-as arm-linux-nm arm-linux-readelf arm-linux-c++filt arm-linux-objcopy arm-linux-size
我们来解释一下上面生成的可执行文件都是用来干什么的
add2line - 将你要找的地址转成文件和行号，它要使用 debug 信息。
Ar-产生、修改和解开一个存档文件
As-gnu 的汇编器
C++filt-C++ 和 java 中有一种重载函数，所用的重载函数最后会被编译转化成汇编的标号，c++filt 就是实现这种反向的转化，根据标号得到函数名。
Gasp-gnu 汇编器预编译器。
Ld-gnu 的连接器
Nm-列出目标文件的符号和对应的地址
Objcopy-将某种格式的目标文件转化成另外格式的目标文件
Objdump-显示目标文件的信息
Ranlib-为一个存档文件产生一个索引，并将这个索引存入存档文件中
Readelf-显示 elf 格式的目标文件的信息
Size-显示目标文件各个节的大小和目标文件的大小
Strings-打印出目标文件中可以打印的字符串，有个默认的长度，为4
Strip-剥掉目标文件的所有的符号信息




回页首
首先进入 build-tools 目录，将下载 gcc 源代码解压
$cd $PRJROOT/build-tools $tar -xvzf gcc-2.95.3.tar.gz
然后进入 gcc-2.95.3 目录给 gcc 打上补丁
$cd gcc-2.95.3 $patch -p1< ../gcc-patch/gcc-2.95.3.-2.patch $patch -p1< ../gcc-patch/gcc-2.95.3.-no-fixinc.patch $patch -p1< ../gcc-patch/gcc-2.95.3-returntype-fix.patch echo timestamp > gcc/cstamp-h.in
在我们编译并安装 gcc 前，我们先要改一个文件 $PRJROOT/gcc/config/arm/t-linux，把
TARGET_LIBGCC2-CFLAGS = -fomit-frame-pointer -fPIC
这一行改为
TARGET_LIBGCC2-CFLAGS = -fomit-frame-pointer -fPIC -Dinhibit_libc -D__gthr_posix_h
你如果没定义 -Dinhibit，编译时将会报如下的错误
../../gcc-2.95.3/gcc/libgcc2.c:41: stdlib.h: No such file or directory ../../gcc-2.95.3/gcc/libgcc2.c:42: unistd.h: No such file or directory make[3]: *** [libgcc2.a] Error 1 make[2]: *** [stmp-multilib-sub] Error 2 make[1]: *** [stmp-multilib] Error 1 make: *** [all-gcc] Error 2
如果没有定义 -D__gthr_posix_h，编译时会报如下的错误
In file included from gthr-default.h:1, from ../../gcc-2.95.3/gcc/gthr.h:98, from ../../gcc-2.95.3/gcc/libgcc2.c:3034: ../../gcc-2.95.3/gcc/gthr-posix.h:37: pthread.h: No such file or directory make[3]: *** [libgcc2.a] Error 1 make[2]: *** [stmp-multilib-sub] Error 2 make[1]: *** [stmp-multilib] Error 1 make: *** [all-gcc] Error 2
还有一种与-Dinhibit同等效果的方法，那就是在你配置configure时多加一个参数-with-newlib，这个选项不会迫使我们必须使用newlib。我们编译了bootstrap-gcc后，仍然可以选择任何c库。
接着就是配置boostrap gcc， 后面要用bootstrap gcc 来编译 glibc 库。
$cd ..; cd build-boot-gcc $../gcc-2.95.3/configure --target=$TARGET --prefix=$PREFIX >--without-headers --enable-languages=c --disable-threads
这条命令中的 -target、--prefix 和配置 binutils 的含义是相同的，--without-headers 就是指不需要头文件，因为是交叉编译工具，不需要本机上的头文件。-enable-languages=c是指我们的 boot-gcc 只支持 c 语言。--disable-threads 是去掉 thread 功能，这个功能需要 glibc 的支持。
接着我们编译并安装 boot-gcc
$make all-gcc $make install-gcc
我们来看看 $PREFIX/bin 里面多了哪些东西
$ls $PREFIX/bin
你会发现多了 arm-linux-gcc 、arm-linux-unprotoize、cpp 和 gcov 几个文件。
Gcc-gnu 的 C 语言编译器
Unprotoize-将 ANSI C 的源码转化为 K&R C 的形式，去掉函数原型中的参数类型。
Cpp-gnu的 C 的预编译器
Gcov-gcc 的辅助测试工具，可以用它来分析和优程序。
使用 gcc3.2 以及 gcc3.2 以上版本时，配置 boot-gcc 不能使用 --without-headers 选项，而需要使用 glibc 的头文件。




回页首
首先解压 glibc-2.2.3.tar.gz 和 glibc-linuxthreads-2.2.3.tar.gz 源代码
$cd $PRJROOT/build-tools $tar -xvzf glibc-2.2.3.tar.gz $tar -xzvf glibc-linuxthreads-2.2.3.tar.gz --directory=glibc-2.2.3
然后进入 build-glibc 目录配置 glibc
$cd build-glibc $CC=arm-linux-gcc ../glibc-2.2.3/configure --host=$TARGET --prefix="/usr" --enable-add-ons --with-headers=$TARGET_PREFIX/include
CC=arm-linux-gcc 是把 CC 变量设成你刚编译完的boostrap gcc，用它来编译你的glibc。--enable-add-ons是告诉glibc用 linuxthreads 包，在上面我们已经将它放入了 glibc 源码目录中，这个选项等价于 -enable-add-ons=linuxthreads。--with-headers 告诉 glibc 我们的linux 内核头文件的目录位置。
配置完后就可以编译和安装 glibc
$make $make install_root=$TARGET_PREFIX prefix="" install
然后你还要修改 libc.so 文件
将
GROUP ( /lib/libc.so.6 /lib/libc_nonshared.a)
改为
GROUP ( libc.so.6 libc_nonshared.a)
这样连接程序 ld 就会在 libc.so 所在的目录查找它需要的库，因为你的机子的/lib目录可能已经装了一个相同名字的库，一个为编译可以在你的宿主机上运行的程序的库，而不是用于交叉编译的。




回页首
在建立boot-gcc 的时候，我们只支持了C。到这里，我们就要建立全套编译器，来支持C和C++。
$cd $PRJROOT/build-tools/build-gcc $../gcc-2.95.3/configure --target=$TARGET --prefix=$PREFIX --enable-languages=c,c++
--enable-languages=c,c++ 告诉 full gcc 支持 c 和 c++ 语言。
然后编译和安装你的 full gcc
$make all $make install
我们再来看看 $PREFIX/bin 里面多了哪些东西
$ls $PREFIX/bin
你会发现多了 arm-linux-g++ 、arm-linux-protoize 和 arm-linux-c++ 几个文件。
G++-gnu的 c++ 编译器。
Protoize-与Unprotoize相反，将K&R C的源码转化为ANSI C的形式，函数原型中加入参数类型。
C++-gnu 的 c++ 编译器。
到这里你的交叉编译工具就算做完了，简单验证一下你的交叉编译工具。
用它来编译一个很简单的程序 helloworld.c
#include int main(void) { printf("hello world\n"); return 0; } $arm-linux-gcc helloworld.c -o helloworld $file helloworld helloworld: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), not stripped
上面的输出说明你编译了一个能在 arm 体系结构下运行的 helloworld，证明你的编译工具做成功了。
Wookey ,Chris Rutter, Jeff Sutherland, Paul Webb ,《The GNU Toolchain for ARM Target HOWTO》
Karim Yaghmour，《Building Embedded Linux Systems》，USA：O‘Reilly，2003

 

梁元恩,软件工程师，研究兴趣主要是操作系统，图形学等。您可以通过sunix_yuanenliang@yahoo.com.cn联系他。
http://www.ibm.com/developerworks/cn/linux/theme/embedded.html
嵌入式系统 Boot Loader 技术内幕

文档选项

打印本页

将此页作为电子邮件发送

级别： 初级
詹荣开 (zhanrk@sohu.com), Linux爱好者
2003 年 12 月 01 日
本文详细地介绍了基于嵌入式系统中的 OS 启动加载程序 ―― Boot Loader 的概念、软件设计的主要任务以及结构框架等内容。
在专用的嵌入式板子运行 GNU/Linux 系统已经变得越来越流行。一个嵌入式 Linux 系统从软件的角度看通常可以分为四个层次：
1. 引导加载程序。包括固化在固件(firmware)中的 boot 代码(可选)，和 Boot Loader 两大部分。
2. Linux 内核。特定于嵌入式板子的定制内核以及内核的启动参数。
3. 文件系统。包括根文件系统和建立于 Flash 内存设备之上文件系统。通常用 ram disk 来作为 root fs。
4. 用户应用程序。特定于用户的应用程序。有时在用户应用程序和内核层之间可能还会包括一个嵌入式图形用户界面。常用的嵌入式 GUI 有：MicroWindows 和 MiniGUI 懂。
引导加载程序是系统加电后运行的第一段软件代码。回忆一下 PC 的体系结构我们可以知道，PC 机中的引导加载程序由 BIOS(其本质就是一段固件程序)和位于硬盘 MBR 中的 OS Boot Loader（比如，LILO 和 GRUB 等）一起组成。BIOS 在完成硬件检测和资源分配后，将硬盘 MBR 中的 Boot Loader 读到系统的 RAM 中，然后将控制权交给 OS Boot Loader。Boot Loader 的主要运行任务就是将内核映象从硬盘上读到 RAM 中，然后跳转到内核的入口点去运行，也即开始启动操作系统。
而在嵌入式系统中，通常并没有像 BIOS 那样的固件程序（注，有的嵌入式 CPU 也会内嵌一段短小的启动程序），因此整个系统的加载启动任务就完全由 Boot Loader 来完成。比如在一个基于 ARM7TDMI core 的嵌入式系统中，系统在上电或复位时通常都从地址 0x00000000 处开始执行，而在这个地址处安排的通常就是系统的 Boot Loader 程序。
本文将从 Boot Loader 的概念、Boot Loader 的主要任务、Boot Loader 的框架结构以及 Boot Loader 的安装等四个方面来讨论嵌入式系统的 Boot Loader。




回页首
简单地说，Boot Loader 就是在操作系统内核运行之前运行的一段小程序。通过这段小程序，我们可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境。
通常，Boot Loader 是严重地依赖于硬件而实现的，特别是在嵌入式世界。因此，在嵌入式世界里建立一个通用的 Boot Loader 几乎是不可能的。尽管如此，我们仍然可以对 Boot Loader 归纳出一些通用的概念来，以指导用户特定的 Boot Loader 设计与实现。
每种不同的 CPU 体系结构都有不同的 Boot Loader。有些 Boot Loader 也支持多种体系结构的 CPU，比如 U-Boot 就同时支持 ARM 体系结构和MIPS 体系结构。除了依赖于 CPU 的体系结构外，Boot Loader 实际上也依赖于具体的嵌入式板级设备的配置。这也就是说，对于两块不同的嵌入式板而言，即使它们是基于同一种 CPU 而构建的，要想让运行在一块板子上的 Boot Loader 程序也能运行在另一块板子上，通常也都需要修改 Boot Loader 的源程序。
系统加电或复位后，所有的 CPU 通常都从某个由 CPU 制造商预先安排的地址上取指令。比如，基于 ARM7TDMI core 的 CPU 在复位时通常都从地址 0x00000000 取它的第一条指令。而基于 CPU 构建的嵌入式系统通常都有某种类型的固态存储设备(比如：ROM、EEPROM 或 FLASH 等)被映射到这个预先安排的地址上。因此在系统加电后，CPU 将首先执行 Boot Loader 程序。
下图1就是一个同时装有 Boot Loader、内核的启动参数、内核映像和根文件系统映像的固态存储设备的典型空间分配结构图。

主机和目标机之间一般通过串口建立连接，Boot Loader 软件在执行时通常会通过串口来进行 I/O，比如：输出打印信息到串口，从串口读取用户控制字符等。
通常多阶段的 Boot Loader 能提供更为复杂的功能，以及更好的可移植性。从固态存储设备上启动的 Boot Loader 大多都是 2 阶段的启动过程，也即启动过程可以分为 stage 1 和 stage 2 两部分。而至于在 stage 1 和 stage 2 具体完成哪些任务将在下面讨论。
大多数 Boot Loader 都包含两种不同的操作模式："启动加载"模式和"下载"模式，这种区别仅对于开发人员才有意义。但从最终用户的角度看，Boot Loader 的作用就是用来加载操作系统，而并不存在所谓的启动加载模式与下载工作模式的区别。
启动加载（Boot loading）模式：这种模式也称为"自主"（Autonomous）模式。也即 Boot Loader 从目标机上的某个固态存储设备上将操作系统加载到 RAM 中运行，整个过程并没有用户的介入。这种模式是 Boot Loader 的正常工作模式，因此在嵌入式产品发布的时侯，Boot Loader 显然必须工作在这种模式下。
下载（Downloading）模式：在这种模式下，目标机上的 Boot Loader 将通过串口连接或网络连接等通信手段从主机（Host）下载文件，比如：下载内核映像和根文件系统映像等。从主机下载的文件通常首先被 Boot Loader 保存到目标机的 RAM 中，然后再被 Boot Loader 写到目标机上的FLASH 类固态存储设备中。Boot Loader 的这种模式通常在第一次安装内核与根文件系统时被使用；此外，以后的系统更新也会使用 Boot Loader 的这种工作模式。工作于这种模式下的 Boot Loader 通常都会向它的终端用户提供一个简单的命令行接口。
像 Blob 或 U-Boot 等这样功能强大的 Boot Loader 通常同时支持这两种工作模式，而且允许用户在这两种工作模式之间进行切换。比如，Blob 在启动时处于正常的启动加载模式，但是它会延时 10 秒等待终端用户按下任意键而将 blob 切换到下载模式。如果在 10 秒内没有用户按键，则 blob 继续启动 Linux 内核。
最常见的情况就是，目标机上的 Boot Loader 通过串口与主机之间进行文件传输，传输协议通常是 xmodem／ymodem／zmodem 协议中的一种。但是，串口传输的速度是有限的，因此通过以太网连接并借助 TFTP 协议来下载文件是个更好的选择。
此外，在论及这个话题时，主机方所用的软件也要考虑。比如，在通过以太网连接和 TFTP 协议来下载文件时，主机方必须有一个软件用来的提供 TFTP 服务。
在讨论了 BootLoader 的上述概念后，下面我们来具体看看 BootLoader 的应该完成哪些任务。




回页首
在继续本节的讨论之前，首先我们做一个假定，那就是：假定内核映像与根文件系统映像都被加载到 RAM 中运行。之所以提出这样一个假设前提是因为，在嵌入式系统中内核映像与根文件系统映像也可以直接在 ROM 或 Flash 这样的固态存储设备中直接运行。但这种做法无疑是以运行速度的牺牲为代价的。
从操作系统的角度看，Boot Loader 的总目标就是正确地调用内核来执行。
另外，由于 Boot Loader 的实现依赖于 CPU 的体系结构，因此大多数 Boot Loader 都分为 stage1 和 stage2 两大部分。依赖于 CPU 体系结构的代码，比如设备初始化代码等，通常都放在 stage1 中，而且通常都用汇编语言来实现，以达到短小精悍的目的。而 stage2 则通常用C语言来实现，这样可以实现给复杂的功能，而且代码会具有更好的可读性和可移植性。
Boot Loader 的 stage1 通常包括以下步骤(以执行的先后顺序)：
硬件设备初始化。
为加载 Boot Loader 的 stage2 准备 RAM 空间。
拷贝 Boot Loader 的 stage2 到 RAM 空间中。
设置好堆栈。
跳转到 stage2 的 C 入口点。
Boot Loader 的 stage2 通常包括以下步骤(以执行的先后顺序)：
初始化本阶段要使用到的硬件设备。
检测系统内存映射(memory map)。
将 kernel 映像和根文件系统映像从 flash 上读到 RAM 空间中。
为内核设置启动参数。
调用内核。
3.1.1 基本的硬件初始化
这是 Boot Loader 一开始就执行的操作，其目的是为 stage2 的执行以及随后的 kernel 的执行准备好一些基本的硬件环境。它通常包括以下步骤（以执行的先后顺序）：
1． 屏蔽所有的中断。为中断提供服务通常是 OS 设备驱动程序的责任，因此在 Boot Loader 的执行全过程中可以不必响应任何中断。中断屏蔽可以通过写 CPU 的中断屏蔽寄存器或状态寄存器（比如 ARM 的 CPSR 寄存器）来完成。
2． 设置 CPU 的速度和时钟频率。
3． RAM 初始化。包括正确地设置系统的内存控制器的功能寄存器以及各内存库控制寄存器等。
4． 初始化 LED。典型地，通过 GPIO 来驱动 LED，其目的是表明系统的状态是 OK 还是 Error。如果板子上没有 LED，那么也可以通过初始化 UART 向串口打印 Boot Loader 的 Logo 字符信息来完成这一点。
5． 关闭 CPU 内部指令／数据 cache。
3.1.2 为加载 stage2 准备 RAM 空间
为了获得更快的执行速度，通常把 stage2 加载到 RAM 空间中来执行，因此必须为加载 Boot Loader 的 stage2 准备好一段可用的 RAM 空间范围。
由于 stage2 通常是 C 语言执行代码，因此在考虑空间大小时，除了 stage2 可执行映象的大小外，还必须把堆栈空间也考虑进来。此外，空间大小最好是 memory page 大小(通常是 4KB)的倍数。一般而言，1M 的 RAM 空间已经足够了。具体的地址范围可以任意安排，比如 blob 就将它的 stage2 可执行映像安排到从系统 RAM 起始地址 0xc0200000 开始的 1M 空间内执行。但是，将 stage2 安排到整个 RAM 空间的最顶 1MB(也即(RamEnd-1MB) - RamEnd)是一种值得推荐的方法。
为了后面的叙述方便，这里把所安排的 RAM 空间范围的大小记为：stage2_size(字节)，把起始地址和终止地址分别记为：stage2_start 和 stage2_end(这两个地址均以 4 字节边界对齐)。因此：
stage2_end＝stage2_start＋stage2_size
另外，还必须确保所安排的地址范围的的确确是可读写的 RAM 空间，因此，必须对你所安排的地址范围进行测试。具体的测试方法可以采用类似于 blob 的方法，也即：以 memory page 为被测试单位，测试每个 memory page 开始的两个字是否是可读写的。为了后面叙述的方便，我们记这个检测算法为：test_mempage，其具体步骤如下：
1． 先保存 memory page 一开始两个字的内容。
2． 向这两个字中写入任意的数字。比如：向第一个字写入 0x55，第 2 个字写入 0xaa。
3． 然后，立即将这两个字的内容读回。显然，我们读到的内容应该分别是 0x55 和 0xaa。如果不是，则说明这个 memory page 所占据的地址范围不是一段有效的 RAM 空间。
4． 再向这两个字中写入任意的数字。比如：向第一个字写入 0xaa，第 2 个字中写入 0x55。
5． 然后，立即将这两个字的内容立即读回。显然，我们读到的内容应该分别是 0xaa 和 0x55。如果不是，则说明这个 memory page 所占据的地址范围不是一段有效的 RAM 空间。
6． 恢复这两个字的原始内容。测试完毕。
为了得到一段干净的 RAM 空间范围，我们也可以将所安排的 RAM 空间范围进行清零操作。
3.1.3 拷贝 stage2 到 RAM 中
拷贝时要确定两点：(1) stage2 的可执行映象在固态存储设备的存放起始地址和终止地址；(2) RAM 空间的起始地址。
3.1.4 设置堆栈指针 sp
堆栈指针的设置是为了执行 C 语言代码作好准备。通常我们可以把 sp 的值设置为(stage2_end-4)，也即在 3.1.2 节所安排的那个 1MB 的 RAM 空间的最顶端(堆栈向下生长)。
此外，在设置堆栈指针 sp 之前，也可以关闭 led 灯，以提示用户我们准备跳转到 stage2。
经过上述这些执行步骤后，系统的物理内存布局应该如下图2所示。
3.1.5 跳转到 stage2 的 C 入口点
在上述一切都就绪后，就可以跳转到 Boot Loader 的 stage2 去执行了。比如，在 ARM 系统中，这可以通过修改 PC 寄存器为合适的地址来实现。

正如前面所说，stage2 的代码通常用 C 语言来实现，以便于实现更复杂的功能和取得更好的代码可读性和可移植性。但是与普通 C 语言应用程序不同的是，在编译和链接 boot loader 这样的程序时，我们不能使用 glibc 库中的任何支持函数。其原因是显而易见的。这就给我们带来一个问题，那就是从那里跳转进 main() 函数呢？直接把 main() 函数的起始地址作为整个 stage2 执行映像的入口点或许是最直接的想法。但是这样做有两个缺点：1)无法通过main() 函数传递函数参数；2)无法处理 main() 函数返回的情况。一种更为巧妙的方法是利用 trampoline(弹簧床)的概念。也即，用汇编语言写一段trampoline 小程序，并将这段 trampoline 小程序来作为 stage2 可执行映象的执行入口点。然后我们可以在 trampoline 汇编小程序中用 CPU 跳转指令跳入 main() 函数中去执行；而当 main() 函数返回时，CPU 执行路径显然再次回到我们的 trampoline 程序。简而言之，这种方法的思想就是：用这段 trampoline 小程序来作为 main() 函数的外部包裹(external wrapper)。
下面给出一个简单的 trampoline 程序示例(来自blob)：
.text .globl _trampoline _trampoline: bl main /* if main ever returns we just call it again */ b _trampoline
可以看出，当 main() 函数返回后，我们又用一条跳转指令重新执行 trampoline 程序――当然也就重新执行 main() 函数，这也就是 trampoline(弹簧床)一词的意思所在。
3.2.1初始化本阶段要使用到的硬件设备
这通常包括：（1）初始化至少一个串口，以便和终端用户进行 I/O 输出信息；（2）初始化计时器等。
在初始化这些设备之前，也可以重新把 LED 灯点亮，以表明我们已经进入 main() 函数执行。
设备初始化完成后，可以输出一些打印信息，程序名字字符串、版本号等。
3.2.2 检测系统的内存映射（memory map）
所谓内存映射就是指在整个 4GB 物理地址空间中有哪些地址范围被分配用来寻址系统的 RAM 单元。比如，在 SA-1100 CPU 中，从 0xC000,0000 开始的 512M 地址空间被用作系统的 RAM 地址空间，而在 Samsung S3C44B0X CPU 中，从 0x0c00,0000 到 0x1000,0000 之间的 64M 地址空间被用作系统的 RAM 地址空间。虽然 CPU 通常预留出一大段足够的地址空间给系统 RAM，但是在搭建具体的嵌入式系统时却不一定会实现 CPU 预留的全部 RAM 地址空间。也就是说，具体的嵌入式系统往往只把 CPU 预留的全部 RAM 地址空间中的一部分映射到 RAM 单元上，而让剩下的那部分预留 RAM 地址空间处于未使用状态。 由于上述这个事实，因此 Boot Loader 的 stage2 必须在它想干点什么 (比如，将存储在 flash 上的内核映像读到 RAM 空间中) 之前检测整个系统的内存映射情况，也即它必须知道 CPU 预留的全部 RAM 地址空间中的哪些被真正映射到 RAM 地址单元，哪些是处于 "unused" 状态的。
(1) 内存映射的描述
可以用如下数据结构来描述 RAM 地址空间中的一段连续(continuous)的地址范围：
typedef struct memory_area_struct { u32 start; /* the base address of the memory region */ u32 size; /* the byte number of the memory region */ int used; } memory_area_t;
这段 RAM 地址空间中的连续地址范围可以处于两种状态之一：(1)used=1，则说明这段连续的地址范围已被实现，也即真正地被映射到 RAM 单元上。(2)used=0，则说明这段连续的地址范围并未被系统所实现，而是处于未使用状态。
基于上述 memory_area_t 数据结构，整个 CPU 预留的 RAM 地址空间可以用一个 memory_area_t 类型的数组来表示，如下所示：
memory_area_t memory_map[NUM_MEM_AREAS] = { [0 ... (NUM_MEM_AREAS - 1)] = { .start = 0, .size = 0, .used = 0 }, };
(2) 内存映射的检测
下面我们给出一个可用来检测整个 RAM 地址空间内存映射情况的简单而有效的算法：
/* 数组初始化 */ for(i = 0; i < NUM_MEM_AREAS; i++) memory_map[i].used = 0; /* first write a 0 to all memory locations */ for(addr = MEM_START; addr < MEM_END; addr += PAGE_SIZE) * (u32 *)addr = 0; for(i = 0, addr = MEM_START; addr < MEM_END; addr += PAGE_SIZE) { /* * 检测从基地址 MEM_START+i*PAGE_SIZE 开始,大小为 * PAGE_SIZE 的地址空间是否是有效的RAM地址空间。 */ 调用3.1.2节中的算法test_mempage()； if ( current memory page isnot a valid ram page) { /* no RAM here */ if(memory_map[i].used ) i++; continue; } /* * 当前页已经是一个被映射到 RAM 的有效地址范围 * 但是还要看看当前页是否只是 4GB 地址空间中某个地址页的别名？ */ if(* (u32 *)addr != 0) { /* alias? */ /* 这个内存页是 4GB 地址空间中某个地址页的别名 */ if ( memory_map[i].used ) i++; continue; } /* * 当前页已经是一个被映射到 RAM 的有效地址范围 * 而且它也不是 4GB 地址空间中某个地址页的别名。 */ if (memory_map[i].used == 0) { memory_map[i].start = addr; memory_map[i].size = PAGE_SIZE; memory_map[i].used = 1; } else { memory_map[i].size += PAGE_SIZE; } } /* end of for (…) */
在用上述算法检测完系统的内存映射情况后，Boot Loader 也可以将内存映射的详细信息打印到串口。
3.2.3 加载内核映像和根文件系统映像
(1) 规划内存占用的布局
这里包括两个方面：(1)内核映像所占用的内存范围；（2）根文件系统所占用的内存范围。在规划内存占用的布局时，主要考虑基地址和映像的大小两个方面。
对于内核映像，一般将其拷贝到从(MEM_START＋0x8000) 这个基地址开始的大约1MB大小的内存范围内(嵌入式 Linux 的内核一般都不操过 1MB)。为什么要把从 MEM_START 到 MEM_START＋0x8000 这段 32KB 大小的内存空出来呢？这是因为 Linux 内核要在这段内存中放置一些全局数据结构，如：启动参数和内核页表等信息。
而对于根文件系统映像，则一般将其拷贝到 MEM_START+0x0010,0000 开始的地方。如果用 Ramdisk 作为根文件系统映像，则其解压后的大小一般是1MB。
（2）从 Flash 上拷贝
由于像 ARM 这样的嵌入式 CPU 通常都是在统一的内存地址空间中寻址 Flash 等固态存储设备的，因此从 Flash 上读取数据与从 RAM 单元中读取数据并没有什么不同。用一个简单的循环就可以完成从 Flash 设备上拷贝映像的工作：
while(count) { *dest++ = *src++; /* they are all aligned with word boundary */ count -= 4; /* byte number */ };
3.2.4 设置内核的启动参数
应该说，在将内核映像和根文件系统映像拷贝到 RAM 空间中后，就可以准备启动 Linux 内核了。但是在调用内核之前，应该作一步准备工作，即：设置 Linux 内核的启动参数。
Linux 2.4.x 以后的内核都期望以标记列表(tagged list)的形式来传递启动参数。启动参数标记列表以标记 ATAG_CORE 开始，以标记 ATAG_NONE 结束。每个标记由标识被传递参数的 tag_header 结构以及随后的参数值数据结构来组成。数据结构 tag 和 tag_header 定义在 Linux 内核源码的include/asm/setup.h 头文件中：
/* The list ends with an ATAG_NONE node. */ #define ATAG_NONE 0x00000000 struct tag_header { u32 size; /* 注意，这里size是字数为单位的 */ u32 tag; }; …… struct tag { struct tag_header hdr; union { struct tag_core core; struct tag_mem32 mem; struct tag_videotext videotext; struct tag_ramdisk ramdisk; struct tag_initrd initrd; struct tag_serialnr serialnr; struct tag_revision revision; struct tag_videolfb videolfb; struct tag_cmdline cmdline; /* * Acorn specific */ struct tag_acorn acorn; /* * DC21285 specific */ struct tag_memclk memclk; } u; };
在嵌入式 Linux 系统中，通常需要由 Boot Loader 设置的常见启动参数有：ATAG_CORE、ATAG_MEM、ATAG_CMDLINE、ATAG_RAMDISK、ATAG_INITRD等。
比如，设置 ATAG_CORE 的代码如下：
params = (struct tag *)BOOT_PARAMS; params->hdr.tag = ATAG_CORE; params->hdr.size = tag_size(tag_core); params->u.core.flags = 0; params->u.core.pagesize = 0; params->u.core.rootdev = 0; params = tag_next(params);
其中，BOOT_PARAMS 表示内核启动参数在内存中的起始基地址，指针 params 是一个 struct tag 类型的指针。宏 tag_next() 将以指向当前标记的指针为参数，计算紧临当前标记的下一个标记的起始地址。注意，内核的根文件系统所在的设备ID就是在这里设置的。
下面是设置内存映射情况的示例代码：
for(i = 0; i < NUM_MEM_AREAS; i++) { if(memory_map[i].used) { params->hdr.tag = ATAG_MEM; params->hdr.size = tag_size(tag_mem32); params->u.mem.start = memory_map[i].start; params->u.mem.size = memory_map[i].size; params = tag_next(params); } }
可以看出，在 memory_map［］数组中，每一个有效的内存段都对应一个 ATAG_MEM 参数标记。
Linux 内核在启动时可以以命令行参数的形式来接收信息，利用这一点我们可以向内核提供那些内核不能自己检测的硬件参数信息，或者重载(override)内核自己检测到的信息。比如，我们用这样一个命令行参数字符串"console=ttyS0,115200n8"来通知内核以 ttyS0 作为控制台，且串口采用 "115200bps、无奇偶校验、8位数据位"这样的设置。下面是一段设置调用内核命令行参数字符串的示例代码：
char *p; /* eat leading white space */ for(p = commandline; *p == ‘ ‘; p++) ; /* skip non-existent command lines so the kernel will still * use its default command line. */ if(*p == ‘\0‘) return; params->hdr.tag = ATAG_CMDLINE; params->hdr.size = (sizeof(struct tag_header) + strlen(p) + 1 + 4) >> 2; strcpy(params->u.cmdline.cmdline, p); params = tag_next(params);
请注意在上述代码中，设置 tag_header 的大小时，必须包括字符串的终止符‘\0‘，此外还要将字节数向上圆整4个字节，因为 tag_header 结构中的size 成员表示的是字数。
下面是设置 ATAG_INITRD 的示例代码，它告诉内核在 RAM 中的什么地方可以找到 initrd 映象(压缩格式)以及它的大小：
params->hdr.tag = ATAG_INITRD2; params->hdr.size = tag_size(tag_initrd); params->u.initrd.start = RAMDISK_RAM_BASE; params->u.initrd.size = INITRD_LEN; params = tag_next(params);
下面是设置 ATAG_RAMDISK 的示例代码，它告诉内核解压后的 Ramdisk 有多大（单位是KB）：
params->hdr.tag = ATAG_RAMDISK; params->hdr.size = tag_size(tag_ramdisk); params->u.ramdisk.start = 0; params->u.ramdisk.size = RAMDISK_SIZE; /* 请注意，单位是KB */ params->u.ramdisk.flags = 1; /* automatically load ramdisk */ params = tag_next(params);
最后，设置 ATAG_NONE 标记，结束整个启动参数列表：
static void setup_end_tag(void) { params->hdr.tag = ATAG_NONE; params->hdr.size = 0; }
3.2.5 调用内核
Boot Loader 调用 Linux 内核的方法是直接跳转到内核的第一条指令处，也即直接跳转到 MEM_START＋0x8000 地址处。在跳转时，下列条件要满足：
1． CPU 寄存器的设置：
R0＝0；
R1＝机器类型 ID；关于 Machine Type Number，可以参见 linux/arch/arm/tools/mach-types。
R2＝启动参数标记列表在 RAM 中起始基地址；
2． CPU 模式：
必须禁止中断（IRQs和FIQs）；
CPU 必须 SVC 模式；
3． Cache 和 MMU 的设置：
MMU 必须关闭；
指令 Cache 可以打开也可以关闭；
数据 Cache 必须关闭；
如果用 C 语言，可以像下列示例代码这样来调用内核：
void (*theKernel)(int zero, int arch, u32 params_addr) = (void (*)(int, int, u32))KERNEL_RAM_BASE; …… theKernel(0, ARCH_NUMBER, (u32) kernel_params_start);
注意，theKernel()函数调用应该永远不返回的。如果这个调用返回，则说明出错。




回页首
在 boot loader 程序的设计与实现中，没有什么能够比从串口终端正确地收到打印信息能更令人激动了。此外，向串口终端打印信息也是一个非常重要而又有效的调试手段。但是，我们经常会碰到串口终端显示乱码或根本没有显示的问题。造成这个问题主要有两种原因：(1) boot loader 对串口的初始化设置不正确。(2) 运行在 host 端的终端仿真程序对串口的设置不正确，这包括：波特率、奇偶校验、数据位和停止位等方面的设置。
此外，有时也会碰到这样的问题，那就是：在 boot loader 的运行过程中我们可以正确地向串口终端输出信息，但当 boot loader 启动内核后却无法看到内核的启动输出信息。对这一问题的原因可以从以下几个方面来考虑：
(1) 首先请确认你的内核在编译时配置了对串口终端的支持，并配置了正确的串口驱动程序。
(2) 你的 boot loader 对串口的初始化设置可能会和内核对串口的初始化设置不一致。此外，对于诸如 s3c44b0x 这样的 CPU，CPU 时钟频率的设置也会影响串口，因此如果 boot loader 和内核对其 CPU 时钟频率的设置不一致，也会使串口终端无法正确显示信息。
(3) 最后，还要确认 boot loader 所用的内核基地址必须和内核映像在编译时所用的运行基地址一致，尤其是对于 uClinux 而言。假设你的内核映像在编译时用的基地址是 0xc0008000，但你的 boot loader 却将它加载到 0xc0010000 处去执行，那么内核映像当然不能正确地执行了。




回页首
Boot Loader 的设计与实现是一个非常复杂的过程。如果不能从串口收到那激动人心的"uncompressing linux.................. done, booting the kernel……"内核启动信息，恐怕谁也不能说："嗨，我的 boot loader 已经成功地转起来了！"。

 

詹荣开，研究兴趣包括：嵌入式 Linux、Linux 内核、驱动程序、文件系统等。您可以通过zhanrk@sohu.com连系他。