引 言
Bootloader(引导装载器)是用于初始化目标板硬件，
给嵌入式操作系统提供板上硬件资源信息，并进一步装
载、引导嵌入式操作系统运行的固件。在嵌入式系统开
发过程中，很多情况都会涉及底层Bootloader的移植问
题， 即使在有些已有Bootloader的参考开发板上也存在
这种可能。概括来说， 如下情况会考虑进行Bootloader
的移植工作。
① 在自主设计的目标板上，用于引导嵌入式操作系
统及其应用。
② 在厂家未提供Bootloader源码的参考板上，遇有
如下情形之一：
a．在实际应用中需要添加或修改一些功能；
b．为了给自行设计主板移植BOotlOade r提供参考，先在参考板上进行移植以积累经验。
另外，从嵌入式系统实际开发角度讲， 嵌入式操作系统的引导、配置甚至应用程序的运行状况都和bootloader有一定的关联，可以说，掌握Bootloader移植是顺利进行嵌入式系统开发的重要利器。
与常见的嵌入式操作系统板级支持包B S P相比，Boot loader与底层硬件更为相关，
即每个不同配置的目标板基本都有不同的Bootloader。因为Bootloader往往更依据量体裁衣、定身制作的原则，
以满足要求的最小化代码存放在启动ROM 或Flash中。
虽然，自行编写Bootloader未尝不可，但从可利用的资源和实际项目开发考虑，采用移植已有的Bootloader源码来解决这一问题更符合大多数项目的开发要求。
1 U-Boot简介
U—Boot，全称Universal Boot Loader，是遵循GPL条款的开放源码项目，从FADSROM、8xxROM
、PPCBOOT逐步发展演化而来，其源码目录、编译形式与Linux内核很相似。事实上，不少U—Boot源码就是相应Linux内核源程序的简化，
尤其是一些设备的驱动程序， 从U-Boot源码的注释中能体现这一点。但是U-Boot不仅仅支持嵌入式Linux系统的引导，
当前，它还支持NetBSD。VxWorks、QNX、RTEMS、ARTOS、LynxOS嵌入式操作系统。其目前要支持的目标操作系统包括0P
enB S D 、NetBSD、FreeBSD、4 4BSD 、Linux、SVR4、Esix、Solaris、Irix、SCO、Dell、NCR、VxWorks、LynxOS、pSOS、QNX、RTEMS和ARTOS。这是u-Boot中Universal的一层含义。另外一层含义则是U-Boot除了支持PowerPC系列的处理器外，还能支持MIPS、x86、ARM
、Nios、XScale等诸多常用系列的处理器。这两个特点正是U-Boot项目的开发目标，即支持尽可能多的嵌入式处理器和嵌入式操作系统。就目前来看，U-Boot对PowerPC系列处理器支持最为丰富，
对Linux的支持最完善。其它系列的处理器和操作系统基本是在2002年1 1月PPCBOOT改名为U-Boot 后逐步扩充的。从PPCBOOT向U—Boot的顺利过渡，很大程度上归功于U-Boot的维护人，德国DENX软件工程中心的Wolfgang
Denk(以下简称w．D)本人精湛的专业水平和持着不懈的努力。当前，u-BOOt项目在他的领军下，众多有志于开放源码Boot
loader移植工作的嵌入式开发人员， 正如火如荼地将各个不同系列嵌入式处理器的移植工作不断展开和深入， 以支持更多嵌入式操作系统的装载与引导。
2 U-Boot主要目录结构
- board一目标板相关文件，主要包含SDRAM、Flash驱动；
- common 一独立于处理器体系结构的通用代码， 如内存大小探测与故障检测；
- cpu一与处理器相关的文件， 如mpc8xx子目录下含串口、网口、LCD 驱动及中断初始化等文件；
- driver一通用设备驱动，如CFI Flash驱动(目前对Intel Flash支持较好)
- doc— U．Boot的说明文档；
- examples一可在U—Boot下运行的示例程序；如hello _ world．C，timer．C；
- include—— U-Boot头文件，configs子目录下与目标板相关的配置头文件是移植过程中经常要修改的文件；
- lib— XXX一处理器体系相关的文件， 如lib—PPC， lib — arm 目录分别包含与PowerPC、ARM体系结构相
关的文件；
- net一与网络功能相关的文件目录，如bootp、nfs、 tftp；
- post一上电自检文件目录， 尚有待于进一步完善；
- rtc— RTC驱动程序；
- tools——用于创建U—Boot S—RECORD和BIN镜像文件的工具。
3 U-Boot支持的主要功能
U—Boot可支持的主要功能如表1所列。
| 系统引导 |
支持NFS挂载、RAMDISK 系统引导 (压缩或非压缩)形式的根文件系统 |
| 支持NFS挂载，从Flash中引导压缩或非压缩系统内核 |
| 基本辅助 |
强大的操作系统接口功能，可灵活设置、传递多个关键参数给操作系统， 适合系统在不同开发阶段的调试要求与产品发布，尤其对Linux支持最为功能强劲 |
| 支持目标板环境参数的多种存储方式，如Flash、NVRAM、EEPROM |
| CRC32校验，可校验Flash中内核、RAMDISK镜像文件是否完好 |
| 设备驱动 |
串口、SDRAM、Flash、以太网、LCD、NVRAM、EEPROM、键盘、USB、PCMCIA、PCI、RTC等驱动支持 |
| 上电自检功能 |
SDRAM、Flash大小自动检测；SDRAM 故障检测；CPU型号 |
| 特殊功能 |
XIP内核引导 |
4 U-Boot移植过程
① 获得发布的最新版本U—Boot源码，与Linux内核源码类似，也是bzip2的压缩格式。可从U．Boot的官方网站http：／／sourceforge．net／projects／U-Boot上获得。
② 阅读相关文档，主要是U．Boot源码根目录下的README文档和U—Boot官方网站的DULG(The DENX
U—
Boot and Linux Guide)文档(http：llwww．denx．de／twiki／bin／view／DULG／Manua1)。尤其是DULG文档，对如何安装建立交叉开发环境和解决U-Boot移植中常见问题，都一一给出了详尽说明。
③ 订阅U—Boot用户邮件列表(http：／／lists．sourceforge．net／lists／listinfo／u—boot—users)。当在移植U-Boot过程中遇有问题，在参考相关文档和搜索u．Boot．U
ser邮件档案库(httP：／／SOurceforge．net／mailarchive／forum．php? forum
— id=l 2898)仍不能解决时，第一时间提交所遇到的问题， 众多U-Boot开发人员会迅速排查问题，而且W．D本人很有可能会直接参与指导。
④ 在建立的开发环境下进行移植工作。绝大多数的开发环境是交叉开发环境。在这方面，DENX和MontaVi sta均提供了完整的开发工具集。
⑤ 在目标板与开发主机间接入硬件调试器。这是进行U-Boot移植应当具备且非常关键的调试工具。因为在整个U—Boot的移植工作中，尤其是初始阶段，硬件调试器是我们了解目标板真实运行状态的唯一途径。在这方面，
W ．D 本人和众多嵌入式开发人员倾向于使用BDI2000。一方面，其价格不如ICE调试器昂贵，同时其可靠性高，功能强大，
完全能胜任移植和调试U—Boot。另外， 网上也有不少关于BDI2000调试方面的参考文档。
⑥ 如果在参考开发板上移植U—Boot，可能需要移除目标板上已有的Boot loader。可以根据板上Boot loader的说明文档，先着手解决在移除当前Boot
loader的情况下，如何进行恢复，以便今后在需要场合能重新装入原先的Boot loader。
5 U-Boot移植方法
当前，对于U．Boot的移植方法，大致分为两种。一种是先用BDI2000创建目标板初始运行环境，将U-Boot镜像
文件u-boot．bin下载到目标板RAM中的指定位置，然后，用BDI2000进行跟踪调试。其好处是， 不用将Uboot镜
像文件烧写到Fla sh中去。但弊端在于， 对移植开发人员的移植调试技能要求较高，BDI2000的配置文件较为复杂。另外一种方法是用BDI2000先将U—Boot镜像文件烧写到Flash中去，然后利用GDB和BDI2000进行调试。这种方法所用的BDI2000配置文件较为简单，调试过程与U-Boot移植后运行过程相吻合。即U—Boot先从Flash中运行，再重载至RAM
中相应位置，并从那里正式投入运行。唯一感到有些麻烦的就是需要不断烧写Flash。但考虑到Flash常规擦写次数基本为l
0万次左右，作为移植U-Boot， 不会占用太多的次数，应该不会为Flash烧写有什么担忧。同时，w．D本人也极力推荐使用后一种方法。笔者建议，
除非是U-BOot移植资深人士或有强有力的技术支
持， 建议采用第二种移植方法。
1
2