BLOB啟動(dòng)流程分析及引導(dǎo)程序可移植性研究
掃描二維碼
隨時(shí)隨地手機(jī)看文章
在嵌入式系統(tǒng)應(yīng)用中,通過引導(dǎo)程序(Bootloader)可以初始化硬件設(shè)備、建立內(nèi)存空間的映射圖、加載內(nèi)核,從而將系統(tǒng)的軟硬件環(huán)境帶到一個(gè)合適的狀態(tài),以便為最終調(diào)用操作系統(tǒng)內(nèi)核準(zhǔn)備好正確的環(huán)境[1]。Bootloader依賴于實(shí)際的硬件和應(yīng)用環(huán)境,對(duì)于不同的硬件架構(gòu)以及相同架構(gòu)的不同電路板,都需要不同的Bootloader。由于單獨(dú)開發(fā)Bootloader的工作量較大,因此開發(fā)人員一般針對(duì)固定體系構(gòu)架開發(fā)一種可移植性的Bootloader,使之能夠在少量修改后應(yīng)用于同一體系構(gòu)架的其他電路板。BLOB就是一種針對(duì)ARM體系定制的可移植性良好的嵌入式Linux引導(dǎo)程序。BLOB支持多種CPU,包括SA1100、SA1110、PXA255、PXA270等,用戶可以根據(jù)目標(biāo)板的特性進(jìn)行定制。它能實(shí)現(xiàn)以下功能:
(1)引導(dǎo)嵌入式Linux,它可以把Linux、Kernel等從Flash加載到RAM中執(zhí)行;
(2)命令行下在線更新BLOB、Kernel和ramdisk;
(3)命令行下可以直接對(duì)物理尋址空間進(jìn)行查看和修改。
可見BLOB除了引導(dǎo)系統(tǒng)這個(gè)基本功能外,還具備板級(jí)支持包(BSP)開發(fā)的功能。
1 啟動(dòng)流程分析
系統(tǒng)的啟動(dòng)通常有兩種方式,一種是可以直接Flash 啟動(dòng),另一種是可以將壓縮的內(nèi)存映像文件從Flash中復(fù)制、解壓到RAM,再?gòu)腞AM啟動(dòng)。系統(tǒng)上電時(shí),BLOB采用后者,啟動(dòng)過程分兩個(gè)階段進(jìn)行,其中第一階段在Flash中運(yùn)行,第二階段在RAM中運(yùn)行。圖1為BLOB啟動(dòng)流程圖。
1.1 第一階段
第一階段為從系統(tǒng)上電后在0x00000000 地址開始執(zhí)行的部分。這部分代碼運(yùn)行在Flash中,其目的是為第二階段(stage 2)的執(zhí)行以及隨后的Kernel的執(zhí)行準(zhǔn)備好基本的硬件環(huán)境[2]。
(1)屏蔽所有的中斷
為中斷提供服務(wù)通常是OS設(shè)備驅(qū)動(dòng)程序的責(zé)任,因此在Bootloader的執(zhí)行全過程中不必響應(yīng)任何中斷。中斷屏蔽可以通過寫CPU的中斷屏蔽寄存器或狀態(tài)寄存器(如ARM的CPSR寄存器)來完成。
(2)設(shè)置CPU的速度和時(shí)鐘頻率
(3)RAM初始化
包括正確地設(shè)置系統(tǒng)內(nèi)存控制器的功能寄存器以及各內(nèi)存庫(kù)控制寄存器等。
(4)LED初始化
通過GPIO來驅(qū)動(dòng)LED,其目的是表明系統(tǒng)的狀態(tài)是否正常。如果板子上沒有LED,則可以通過初始化UART向串口打印 Bootloader的Logo字符信息來完成。
1.2 第二階段
第二階段是C語言執(zhí)行代碼,具體說明如下。
(1)UART設(shè)置及初始化
至少初始化一個(gè)串口,以便與終端用戶進(jìn)行 I/O 輸出信息,初始化計(jì)時(shí)器等。設(shè)備初始化完成后,可以輸出一些打印信息、程序名字字符串、版本號(hào)等。
(2)設(shè)置系統(tǒng)的內(nèi)存映射
內(nèi)存映射是指在整個(gè)物理地址空間中有哪些地址被分配用來尋址系統(tǒng)的RAM單元。具體的嵌入式系統(tǒng)往往只把CPU預(yù)留的全部RAM地址空間中的一部分映射到RAM單元上,而讓剩下的部分預(yù)留RAM地址空間處于未使用狀態(tài)。因此Bootloader的 stage 2必須在使用它之前檢測(cè)整個(gè)系統(tǒng)的內(nèi)存映射情況。在用上述算法檢測(cè)完系統(tǒng)的內(nèi)存映射情況后,BLOB將內(nèi)存映射的詳細(xì)信息打印到串口。
(3)加載內(nèi)核映像和根文件系統(tǒng)映像
在規(guī)劃內(nèi)存占用的布局時(shí),應(yīng)包括兩個(gè)方面:內(nèi)核映像所占用的內(nèi)存范圍;根文件系統(tǒng)所占用的內(nèi)存范圍。在規(guī)劃內(nèi)存占用布局時(shí),主要考慮基地址和映像的大小兩個(gè)方面。
對(duì)于內(nèi)核映像,一般將其拷貝到從(MEM_START+0x8000)這個(gè)基地址開始的大約1MB大小的內(nèi)存范圍內(nèi)(嵌入式Linux的內(nèi)核一般都不超過1MB)。
而對(duì)于根文件系統(tǒng)映像,則一般將其拷貝到 MEM_START+0x0010,0000開始的地方。如果用Ramdisk作為根文件系統(tǒng)映像,則其解壓后的大小一般是1MB。
(4)設(shè)置Linux內(nèi)核的啟動(dòng)參數(shù)。
(5)可以選擇直接調(diào)用內(nèi)核或者進(jìn)入下載模式。
在下載模式下,BLOB將通過串口從主機(jī)(Host)下載文件,例如下載內(nèi)核映像和根文件系統(tǒng)映像等。
2 Bootloader的可移植性研究
大部分Bootloader的總體結(jié)構(gòu)與BLOB類似,一般分為兩個(gè)階段運(yùn)行。其中第一階段與CPU架構(gòu)相關(guān),不同架構(gòu)CPU往往要求不同的Bootloader與之對(duì)應(yīng)[3],只有少數(shù)Bootloader能夠適用于多種架構(gòu)的CPU,如表1。
2.1 相同構(gòu)架下Bootloader移植
對(duì)于相同的CPU構(gòu)架,Bootloader移植工作大體上可以分為三部分。
(1)目標(biāo)板驅(qū)動(dòng)部分,針對(duì)特定CPU、Flash、SDRAM等對(duì)驅(qū)動(dòng)程序進(jìn)行定制。完成處理器各個(gè)I/O口的初始化、Flash描述(包括區(qū)塊大小及數(shù)量)和Flash初始化等。一個(gè)必要的工作是Flash分區(qū)表的配置,F(xiàn)lash的典型空間分配結(jié)構(gòu)如圖2所示。
(2)目標(biāo)板相關(guān)的頭文件,文件中包含了目標(biāo)板配置的宏定義,主要有系統(tǒng)工作頻率、GPIO定義、Flash 各分塊起始地址及容量、Flash 讀/寫命令字、SDRAM寄存器配置、SDRAM起始地址及容量、內(nèi)核裝載地址等。其中大部分GPIO設(shè)置的目的是在Bootloader下做板載開發(fā),這項(xiàng)功能不是必需的。而CPU頻率及Flash的設(shè)置則直接影響到系統(tǒng)能否啟動(dòng)。對(duì)于采用Ramdisk技術(shù)的系統(tǒng)開發(fā),SDRAM的配置也直接關(guān)系到Kernel的加載。因此,各頭文件的代碼修改是移植過程的重點(diǎn)。
(3)Bootloader總體配置文件修改,包括目標(biāo)板聲明、指定目標(biāo)板頭文件、定制文件關(guān)聯(lián)關(guān)系等。
圖3以BLOB在PXA255[4]的目標(biāo)板上移植為例表現(xiàn)了需要增、改的關(guān)鍵文件之間的內(nèi)在聯(lián)系。
圖3中:
(1)src/blob/PXA255.c:筆者編寫的針對(duì)PXA255目標(biāo)板驅(qū)動(dòng)文件,這里是采用默認(rèn)設(shè)置的最簡(jiǎn)情況,必要時(shí)還需對(duì)文件如Flash.c等進(jìn)行修改。
(2)include/blob/arch/PXA255.h:目標(biāo)板頭文件,它必須通過arch.h及config.h進(jìn)行指定,最終反映在configure.in中。
(3)configure.in:添加目標(biāo)板聲明,如果已有目標(biāo)板類型,則無需修改該文件;如果沒有,則需要根據(jù)情況添加目標(biāo)板名稱、CPU型號(hào)、必需的.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文件,最終在執(zhí)行Make命令后生成BLOB的可執(zhí)行文件。
需要注意的是Linux內(nèi)核必須根據(jù)目標(biāo)板硬件情況作相應(yīng)的設(shè)置[5],這里不展開論述。
2.2 不同構(gòu)架下Bootloader移植
根據(jù)Bootloader的啟動(dòng)流程可知,對(duì)于不同架構(gòu)的CPU,盡管處理流程相似,但是實(shí)現(xiàn)方法不同,主要體現(xiàn)在啟動(dòng)的第一階段對(duì)CPU的設(shè)置上。所以這部分的硬件相關(guān)代碼基本上要重新編寫。
多數(shù)Bootloader在stage1的代碼不易由C語言實(shí)現(xiàn),因而大多采用匯編語言實(shí)現(xiàn)。以U-boot為例,stage1代碼主要位于start.S、IO.S、Cache.S中,其中最重要的是start.S。該代碼主要針對(duì)特定處理器,對(duì)其內(nèi)部各個(gè)寄存器進(jìn)行設(shè)置并初始化CPU。主要完成設(shè)置處理器工作模式、初始化緩沖區(qū)、設(shè)置堆棧、設(shè)置中斷向量、內(nèi)存控制器初始化[6]。
完成stage1代碼編寫之后,還需要按照相同構(gòu)架下Bootloader移植的方法對(duì)相關(guān)代碼進(jìn)行編寫。
2.3 提高可移植性的方案設(shè)計(jì)
目前影響B(tài)ootloader可移植性的因素主要有:CPU不同架構(gòu),同一架構(gòu)不同CPU型號(hào),目標(biāo)板硬件不同結(jié)構(gòu)。針對(duì)以上問題提出了幾點(diǎn)提高可移植性的方案設(shè)計(jì)。
(1)對(duì)于遵從GPL協(xié)議的開源Bootloader,可以根據(jù)不同架構(gòu)和不同硬件定制相應(yīng)的驅(qū)動(dòng)文件,如各種.c和.h文件??紤]到目前嵌入式硬件種類非常多,需要大量開源軟件開發(fā)者的支持,盡管不能覆蓋所有硬件,但在一定范圍內(nèi)可以大大減少嵌入式系統(tǒng)開發(fā)的工作量。
(2)在上一步的基礎(chǔ)上,采用類似Linux內(nèi)核配置的方法(如make menuconfig或make xconfig),用終端式的配置菜單對(duì)具體硬件進(jìn)行設(shè)置,減少移植過程中代碼級(jí)的修改。
本文以BLOB為例分析了Bootloader的啟動(dòng)流程,并根據(jù)該過程對(duì)Bootloader的可移植性進(jìn)行了討論,并對(duì)移植過程的關(guān)鍵技術(shù)進(jìn)行了深入研究,最后還提出了提高可移植性的方案設(shè)計(jì)。在實(shí)驗(yàn)過程中實(shí)現(xiàn)了BLOB在PXA255目標(biāo)板及SA1110目標(biāo)板的移植。此項(xiàng)研究已經(jīng)應(yīng)用在清華大學(xué)精密測(cè)試技術(shù)與儀器國(guó)家重點(diǎn)實(shí)驗(yàn)室的嵌入式生物特征識(shí)別平臺(tái)上,可以實(shí)現(xiàn)BLOB、內(nèi)核鏡像、文件系統(tǒng)鏡像的下載及內(nèi)核的引導(dǎo)。