BLOB启动流程分析及引导程序可移植性研究

在嵌入式系统应用中，通过引导程序(Bootloader)可以初始化硬件设备、建立内存空间的映射图、加载内核，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境[1]。Bootloader依赖于实际的硬件和应用环境，对于不同的硬件架构以及相同架构的不同电路板，都需要不同的Bootloader。由于单独开发Bootloader的工作量较大，因此开发人员一般针对固定体系构架开发一种可移植性的Bootloader，使之能够在少量修改后应用于同一体系构架的其他电路板。BLOB就是一种针对ARM体系定制的可移植性良好的嵌入式Linux引导程序。BLOB支持多种CPU，包括SA1100、SA1110、PXA255、PXA270等，用户可以根据目标板的特性进行定制。它能实现以下功能：

(1)引导嵌入式Linux，它可以把Linux、Kernel等从Flash加载到RAM中执行；
(2)命令行下在线更新BLOB、Kernel和ramdisk；
(3)命令行下可以直接对物理寻址空间进行查看和修改。

可见BLOB除了引导系统这个基本功能外，还具备板级支持包(BSP)开发的功能。

1 启动流程分析

系统的启动通常有两种方式，一种是可以直接Flash 启动，另一种是可以将压缩的内存映像文件从Flash中复制、解压到RAM，再从RAM启动。系统上电时，BLOB采用后者，启动过程分两个阶段进行，其中第一阶段在Flash中运行，第二阶段在RAM中运行。图1为BLOB启动流程图。


1.1 第一阶段

第一阶段为从系统上电后在0x00000000 地址开始执行的部分。这部分代码运行在Flash中，其目的是为第二阶段(stage 2)的执行以及随后的Kernel的执行准备好基本的硬件环境[2]。

(1)屏蔽所有的中断
为中断提供服务通常是OS设备驱动程序的责任，因此在Bootloader的执行全过程中不必响应任何中断。中断屏蔽可以通过写CPU的中断屏蔽寄存器或状态寄存器（如ARM的CPSR寄存器）来完成。

(2)设置CPU的速度和时钟频率

(3)RAM初始化
包括正确地设置系统内存控制器的功能寄存器以及各内存库控制寄存器等。

(4)LED初始化
通过GPIO来驱动LED，其目的是表明系统的状态是否正常。如果板子上没有LED，则可以通过初始化UART向串口打印 Bootloader的Logo字符信息来完成。

1．2 第二阶段

第二阶段是C语言执行代码，具体说明如下。

(1)UART设置及初始化
至少初始化一个串口，以便与终端用户进行 I/O 输出信息，初始化计时器等。设备初始化完成后，可以输出一些打印信息、程序名字字符串、版本号等。

(2)设置系统的内存映射
内存映射是指在整个物理地址空间中有哪些地址被分配用来寻址系统的RAM单元。具体的嵌入式系统往往只把CPU预留的全部RAM地址空间中的一部分映射到RAM单元上，而让剩下的部分预留RAM地址空间处于未使用状态。因此Bootloader的 stage 2必须在使用它之前检测整个系统的内存映射情况。在用上述算法检测完系统的内存映射情况后，BLOB将内存映射的详细信息打印到串口。

(3)加载内核映像和根文件系统映像
在规划内存占用的布局时，应包括两个方面：内核映像所占用的内存范围；根文件系统所占用的内存范围。在规划内存占用布局时，主要考虑基地址和映像的大小两个方面。

对于内核映像，一般将其拷贝到从(MEM_START＋0x8000)这个基地址开始的大约1MB大小的内存范围内(嵌入式Linux的内核一般都不超过1MB)。

而对于根文件系统映像，则一般将其拷贝到 MEM_START+0x0010,0000开始的地方。如果用Ramdisk作为根文件系统映像，则其解压后的大小一般是1MB。

(4)设置Linux内核的启动参数。

(5)可以选择直接调用内核或者进入下载模式。

在下载模式下，BLOB将通过串口从主机(Host)下载文件，例如下载内核映像和根文件系统映像等。

2 Bootloader的可移植性研究

大部分Bootloader的总体结构与BLOB类似，一般分为两个阶段运行。其中第一阶段与CPU架构相关，不同架构CPU往往要求不同的Bootloader与之对应[3]，只有少数Bootloader能够适用于多种架构的CPU，如表1。

2.1 相同构架下Bootloader移植

对于相同的CPU构架，Bootloader移植工作大体上可以分为三部分。

(1)目标板驱动部分，针对特定CPU、Flash、SDRAM等对驱动程序进行定制。完成处理器各个I/O口的初始化、Flash描述(包括区块大小及数量)和Flash初始化等。一个必要的工作是Flash分区表的配置，Flash的典型空间分配结构如图2所示。


(2)目标板相关的头文件，文件中包含了目标板配置的宏定义，主要有系统工作频率、GPIO定义、Flash 各分块起始地址及容量、Flash 读/写命令字、SDRAM寄存器配置、SDRAM起始地址及容量、内核装载地址等。其中大部分GPIO设置的目的是在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为例分析了Bootloader的启动流程，并根据该过程对Bootloader的可移植性进行了讨论，并对移植过程的关键技术进行了深入研究，最后还提出了提高可移植性的方案设计。在实验过程中实现了BLOB在PXA255目标板及SA1110目标板的移植。此项研究已经应用在清华大学精密测试技术与仪器国家重点实验室的嵌入式生物特征识别平台上，可以实现BLOB、内核镜像、文件系统镜像的下载及内核的引导。