BLOB啟動(dòng)流程分析及引導程序可移植性研究

在嵌入式系統應用中，通過(guò)引導程序(Bootloader)可以初始化硬件設備、建立內存空間的映射圖、加載內核，從而將系統的軟硬件環(huán)境帶到一個(gè)合適的狀態(tài)，以便為最終調用操作系統內核準備好正確的環(huán)境[1]。Bootloader依賴(lài)于實(shí)際的硬件和應用環(huán)境，對于不同的硬件架構以及相同架構的不同電路板，都需要不同的Bootloader。由于單獨開(kāi)發(fā)Bootloader的工作量較大，因此開(kāi)發(fā)人員一般針對固定體系構架開(kāi)發(fā)一種可移植性的Bootloader，使之能夠在少量修改后應用于同一體系構架的其他電路板。BLOB就是一種針對ARM體系定制的可移植性良好的嵌入式Linux引導程序。BLOB支持多種CPU，包括SA1100、SA1110、PXA255、PXA270等，用戶(hù)可以根據目標板的特性進(jìn)行定制。它能實(shí)現以下功能：

(1)引導嵌入式Linux，它可以把Linux、Kernel等從Flash加載到RAM中執行；
(2)命令行下在線(xiàn)更新BLOB、Kernel和ramdisk；
(3)命令行下可以直接對物理尋址空間進(jìn)行查看和修改。

可見(jiàn)BLOB除了引導系統這個(gè)基本功能外，還具備板級支持包(BSP)開(kāi)發(fā)的功能。

1 啟動(dòng)流程分析

系統的啟動(dòng)通常有兩種方式，一種是可以直接Flash 啟動(dòng)，另一種是可以將壓縮的內存映像文件從Flash中復制、解壓到RAM，再從RAM啟動(dòng)。系統上電時(shí)，BLOB采用后者，啟動(dòng)過(guò)程分兩個(gè)階段進(jìn)行，其中第一階段在Flash中運行，第二階段在RAM中運行。圖1為BLOB啟動(dòng)流程圖。


1.1 第一階段

第一階段為從系統上電后在0x00000000 地址開(kāi)始執行的部分。這部分代碼運行在Flash中，其目的是為第二階段(stage 2)的執行以及隨后的Kernel的執行準備好基本的硬件環(huán)境[2]。

(1)屏蔽所有的中斷
為中斷提供服務(wù)通常是OS設備驅動(dòng)程序的責任，因此在Bootloader的執行全過(guò)程中不必響應任何中斷。中斷屏蔽可以通過(guò)寫(xiě)CPU的中斷屏蔽寄存器或狀態(tài)寄存器（如ARM的CPSR寄存器）來(lái)完成。

(2)設置CPU的速度和時(shí)鐘頻率

(3)RAM初始化
包括正確地設置系統內存控制器的功能寄存器以及各內存庫控制寄存器等。

(4)LED初始化
通過(guò)GPIO來(lái)驅動(dòng)LED，其目的是表明系統的狀態(tài)是否正常。如果板子上沒(méi)有LED，則可以通過(guò)初始化UART向串口打印 Bootloader的Logo字符信息來(lái)完成。

1．2 第二階段

第二階段是C語(yǔ)言執行代碼，具體說(shuō)明如下。

(1)UART設置及初始化
至少初始化一個(gè)串口，以便與終端用戶(hù)進(jìn)行 I/O 輸出信息，初始化計時(shí)器等。設備初始化完成后，可以輸出一些打印信息、程序名字字符串、版本號等。

(2)設置系統的內存映射
內存映射是指在整個(gè)物理地址空間中有哪些地址被分配用來(lái)尋址系統的RAM單元。具體的嵌入式系統往往只把CPU預留的全部RAM地址空間中的一部分映射到RAM單元上，而讓剩下的部分預留RAM地址空間處于未使用狀態(tài)。因此Bootloader的 stage 2必須在使用它之前檢測整個(gè)系統的內存映射情況。在用上述算法檢測完系統的內存映射情況后，BLOB將內存映射的詳細信息打印到串口。

(3)加載內核映像和根文件系統映像
在規劃內存占用的布局時(shí)，應包括兩個(gè)方面：內核映像所占用的內存范圍；根文件系統所占用的內存范圍。在規劃內存占用布局時(shí)，主要考慮基地址和映像的大小兩個(gè)方面。

對于內核映像，一般將其拷貝到從(MEM_START＋0x8000)這個(gè)基地址開(kāi)始的大約1MB大小的內存范圍內(嵌入式Linux的內核一般都不超過(guò)1MB)。

而對于根文件系統映像，則一般將其拷貝到 MEM_START+0x0010,0000開(kāi)始的地方。如果用Ramdisk作為根文件系統映像，則其解壓后的大小一般是1MB。

(4)設置Linux內核的啟動(dòng)參數。

(5)可以選擇直接調用內核或者進(jìn)入下載模式。

在下載模式下，BLOB將通過(guò)串口從主機(Host)下載文件，例如下載內核映像和根文件系統映像等。

2 Bootloader的可移植性研究

大部分Bootloader的總體結構與BLOB類(lèi)似，一般分為兩個(gè)階段運行。其中第一階段與CPU架構相關(guān)，不同架構CPU往往要求不同的Bootloader與之對應[3]，只有少數Bootloader能夠適用于多種架構的CPU，如表1。

2.1 相同構架下Bootloader移植

對于相同的CPU構架，Bootloader移植工作大體上可以分為三部分。

(1)目標板驅動(dòng)部分，針對特定CPU、Flash、SDRAM等對驅動(dòng)程序進(jìn)行定制。完成處理器各個(gè)I/O口的初始化、Flash描述(包括區塊大小及數量)和Flash初始化等。一個(gè)必要的工作是Flash分區表的配置，Flash的典型空間分配結構如圖2所示。


(2)目標板相關(guān)的頭文件，文件中包含了目標板配置的宏定義，主要有系統工作頻率、GPIO定義、Flash 各分塊起始地址及容量、Flash 讀/寫(xiě)命令字、SDRAM寄存器配置、SDRAM起始地址及容量、內核裝載地址等。其中大部分GPIO設置的目的是在Bootloader下做板載開(kāi)發(fā)，這項功能不是必需的。而CPU頻率及Flash的設置則直接影響到系統能否啟動(dòng)。對于采用Ramdisk技術(shù)的系統開(kāi)發(fā)，SDRAM的配置也直接關(guān)系到Kernel的加載。因此，各頭文件的代碼修改是移植過(guò)程的重點(diǎn)。

(3)Bootloader總體配置文件修改，包括目標板聲明、指定目標板頭文件、定制文件關(guān)聯(lián)關(guān)系等。

圖3以BLOB在PXA255[4]的目標板上移植為例表現了需要增、改的關(guān)鍵文件之間的內在聯(lián)系。

圖3中：
(1)src/blob/PXA255.c：筆者編寫(xiě)的針對PXA255目標板驅動(dòng)文件，這里是采用默認設置的最簡(jiǎn)情況，必要時(shí)還需對文件如Flash.c等進(jìn)行修改。

(2)include/blob/arch/PXA255.h：目標板頭文件，它必須通過(guò)arch.h及config.h進(jìn)行指定，最終反映在configure.in中。

(3)configure.in：添加目標板聲明，如果已有目標板類(lèi)型，則無(wú)需修改該文件；如果沒(méi)有，則需要根據情況添加目標板名稱(chēng)、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中進(jìn)行登記，保證configure.in和Makefile.am在進(jìn)行./configure處理時(shí)能夠生成正確的Makefile文件，最終在執行Make命令后生成BLOB的可執行文件。

需要注意的是Linux內核必須根據目標板硬件情況作相應的設置[5]，這里不展開(kāi)論述。

2.2 不同構架下Bootloader移植

根據Bootloader的啟動(dòng)流程可知，對于不同架構的CPU，盡管處理流程相似，但是實(shí)現方法不同，主要體現在啟動(dòng)的第一階段對CPU的設置上。所以這部分的硬件相關(guān)代碼基本上要重新編寫(xiě)。

多數Bootloader在stage1的代碼不易由C語(yǔ)言實(shí)現，因而大多采用匯編語(yǔ)言實(shí)現。以U-boot為例，stage1代碼主要位于start.S、IO.S、Cache.S中，其中最重要的是start.S。該代碼主要針對特定處理器，對其內部各個(gè)寄存器進(jìn)行設置并初始化CPU。主要完成設置處理器工作模式、初始化緩沖區、設置堆棧、設置中斷向量、內存控制器初始化[6]。

完成stage1代碼編寫(xiě)之后，還需要按照相同構架下Bootloader移植的方法對相關(guān)代碼進(jìn)行編寫(xiě)。

2.3 提高可移植性的方案設計

目前影響B(tài)ootloader可移植性的因素主要有：CPU不同架構，同一架構不同CPU型號，目標板硬件不同結構。針對以上問(wèn)題提出了幾點(diǎn)提高可移植性的方案設計。

(1)對于遵從GPL協(xié)議的開(kāi)源Bootloader，可以根據不同架構和不同硬件定制相應的驅動(dòng)文件，如各種.c和.h文件?？紤]到目前嵌入式硬件種類(lèi)非常多，需要大量開(kāi)源軟件開(kāi)發(fā)者的支持，盡管不能覆蓋所有硬件，但在一定范圍內可以大大減少嵌入式系統開(kāi)發(fā)的工作量。

(2)在上一步的基礎上，采用類(lèi)似Linux內核配置的方法(如make menuconfig或make xconfig)，用終端式的配置菜單對具體硬件進(jìn)行設置，減少移植過(guò)程中代碼級的修改。

本文以BLOB為例分析了Bootloader的啟動(dòng)流程，并根據該過(guò)程對Bootloader的可移植性進(jìn)行了討論，并對移植過(guò)程的關(guān)鍵技術(shù)進(jìn)行了深入研究，最后還提出了提高可移植性的方案設計。在實(shí)驗過(guò)程中實(shí)現了BLOB在PXA255目標板及SA1110目標板的移植。此項研究已經(jīng)應用在清華大學(xué)精密測試技術(shù)與儀器國家重點(diǎn)實(shí)驗室的嵌入式生物特征識別平臺上，可以實(shí)現BLOB、內核鏡像、文件系統鏡像的下載及內核的引導。