BLOB启动流程与Bootloader程序可移植性研究

板载开发，这项功能不是必需的。而CPU频率及Flash的设置则直接影响到系统能否启动。对于采用Ramdisk技术的系统开发，SDRAM的配置也直接关系到Kernel的加载。因此，各头文件的代码修改是移植过程的重点。

(3)Bootloader总体配置文件修改，包括目标板声明、指定目标板头文件、定制文件关联关系等。

图3以BLOB在PXA255[4]的目标板上移植为例表现了需要增、改的关键文件之间的内在联系。

图3中：

(1)src/blob/PXA255.c：笔者编写的针对PXA255目标板驱动文件，这里是采用默认设置的最简情况，必要时还需对文件如Flash.c等进行修改。

(2)include/blob/arch/PXA255.h：目标板头文件，它必须通过arch.h及config.h进行指定，最终反映在configure.in中。

(3)configure.in：添加目标板声明，如果已有目标板类型，则无需修改该文件;如果没有，则需要根据情况添加目标板名称、CPU型号、必需的.o文件，如：

PXA255)

AC_MSG_RESULT(Ipaq PXA255)

AC_DEFINE(PXA255)

AC_DEFINE(USE_SERIAL3)

BLOB_PLATFORM_OBJ=″PXA255.o″

BLOB_FLASH_OBJS=″nullflash.o″

use_cpu=″PXA255″

use_lcd=″no″

(4)Makefile.am：由于添加了PXA255.c和PXA255.h，所以要在它们所在目录的Makefile.am中进行登记，保证configure.in和Makefile.am在进行./configure处理时能够生成正确的Makefile文件，最终在执行Make命令后生成BLOB的可执行文件。

需要注意的是Linux内核必须根据目标板硬件情况作相应的设置[5]，这里不展开论述。

2.2 不同构架下Bootloader移植

根据Bootloader的启动流程可知，对于不同架构的CPU，尽管处理流程相似，但是实现方法不同，主要体现在启动的第一阶段对CPU的设置上。所以这部分的硬件相关代码基本上要重新编写。

多数Bootloader在stage1的代码不易由C语言实现，因而大多采用汇编语言实现。以U-boot为例，stage1代码主要位于start.S、IO.S、Cache.S中，其中最重要的是start.S。该代码主要针对特定处理器，对其内部各个寄存器进行设置并初始化CPU。主要完成设置处理器工作模式、初始化缓冲区、设置堆栈、设置中断向量、内存控制器初始化[6]。

完成stage1代码编写之后，还需要按照相同构架下Bootloader移植的方法对相关代码进行编写。

2.3 提高可移植性的方案设计

目前影响Bootloader可移植性的因素主要有：CPU不同架构，同一架构不同CPU型号，目标板硬件不同结构。针对以上问题提出了几点提高可移植性的方案设计。

(1)对于遵从GPL协议的开源Bootloader，可以根据不同架构和不同硬件定制相应的驱动文件，如各种.c和.h文件。考虑到目前嵌入式硬件种类非常多，需要大量开源软件开发者的支持，尽管不能覆盖所有硬件，但在一定范围内可以大大减少嵌入式系统开发的工作量。

(2)在上一步的基础上，采用类似Linux内核配置的方法(如make menuconfig或make xconfig)，用终端式的配置菜单对具体硬件进行设置，减少移植过程中代码级的修改。

在实验过程中实现了BLOB在PXA255目标板及SA1110目标板的移植。此项研究已经应用在清华大学精密测试技术与仪器国家重点实验室的嵌入式生物特征识别平台上，可以实现BLOB、内核镜像、文件系统镜像的下载及内核的引导。