嵌入式BootLoader技術內幕（二）

三、Boot Loader 的主要任務與典型結構架構

在繼續本節的討論之前，首先我們做一個假定，那就是：假定核心映像與根檔案系統映像都被載入到 RAM 中運行。之所以提出這樣一個假設前提是因為，在嵌入式系統中核心映像與根檔案系統映像也可以直接在 ROM 或 Flash 這樣的固態存放裝置中直接運行。但這種做法無疑是以運行速度的犧牲為代價的。從作業系統的角度看，Boot Loader 的總目標就是正確地調用核心來執行。

另外，由於 Boot Loader 的實現依賴於 CPU 的體繫結構，因此大多數 Boot Loader 都分為 stage1 和 stage2 兩大部分。依賴於 CPU 體繫結構的代碼，比如裝置初始化代碼等，通常都放在 stage1 中，而且通常都用組合語言來實現，以達到短小精悍的目的。而 stage2 則通常用C語言來實現，這樣可以實現給複雜的功能，而且代碼會具有更好的可讀性和可移植性。

Boot Loader 的 stage1 通常包括以下步驟(以執行的先後順序)：
·硬體裝置初始化。
·為載入 Boot Loader 的 stage2 準備 RAM 空間。
·拷貝 Boot Loader 的 stage2 到 RAM 空間中。
·設定好堆棧。
·跳轉到 stage2 的 C 進入點。
Boot Loader 的 stage2 通常包括以下步驟(以執行的先後順序)：
·初始化本階段要使用到的硬體裝置。
·檢測系統記憶體映射(memory map)。
·將 kernel 映像和根檔案系統映像從 flash 上讀到 RAM 空間中。
·為核心設定啟動參數。
·調用核心。

3.1 Boot Loader 的 stage1

3.1.1 基本的硬體初始化

這是 Boot Loader 一開始就執行的操作，其目的是為 stage2 的執行以及隨後的 kernel 的執行準備好一些基本的硬體環境。它通常包括以下步驟（以執行的先後順序）：

1．屏蔽所有的中斷。為中斷提供服務通常是 OS 裝置驅動程式的責任，因此在 Boot Loader 的執行全過程中可以不必響應任何中斷。中斷屏蔽可以通過寫 CPU 的中斷屏蔽寄存器或狀態寄存器（比如 ARM 的 CPSR 寄存器）來完成。

2．設定 CPU 的速度和時鐘頻率。

3．RAM 初始化。包括正確地設定系統的記憶體控制器的功能寄存器以及各記憶體庫控制寄存器等。

4．初始化 LED。典型地，通過 GPIO 來驅動 LED，其目的是表明系統的狀態是 OK 還是 Error。如果板子上沒有 LED，那麼也可以通過初始化 UART 向串口列印 Boot Loader 的 Logo 字元資訊來完成這一點。

5． 關閉 CPU 內部指令／資料 cache。

3.1.2 為載入 stage2 準備 RAM 空間

為了獲得更快的執行速度，通常把 stage2 載入到 RAM 空間中來執行，因此必須為載入 Boot Loader 的 stage2 準備好一段可用的 RAM 空間範圍。

由於 stage2 通常是 C 語言執行代碼，因此在考慮空間大小時，除了 stage2 可執行映象的大小外，還必須把堆棧空間也考慮進來。此外，空間大小最好是 memory page 大小(通常是 4KB)的倍數。一般而言，1M 的 RAM 空間已經足夠了。具體的位址範圍可以任意安排，比如 blob 就將它的 stage2 可執行映像安排到從系統 RAM 起始地址 0xc0200000 開始的 1M 空間內執行。但是，將 stage2 安排到整個 RAM 空間的最頂 1MB(也即(RamEnd-1MB) - RamEnd)是一種值得推薦的方法。

為了後面的敘述方便，這裡把所安排的 RAM 空間範圍的大小記為：stage2_size(位元組)，把起始地址和終止地址分別記為：stage2_start 和 stage2_end(這兩個地址均以 4 位元組邊界對齊)。因此：

stage2_end＝stage2_start＋stage2_size

另外，還必須確保所安排的位址範圍的的確確是可讀寫的 RAM 空間，因此，必須對你所安排的位址範圍進行測試。具體的測試方法可以採用類似於 blob 的方法，也即：以 memory page 為被測試單位，測試每個 memory page 開始的兩個字是否是可讀寫的。為了後面敘述的方便，我們記這個檢測演算法為：test_mempage，其具體步驟如下：

1．先儲存 memory page 一開始兩個字的內容。

2．向這兩個字中寫入任意的數字。比如：向第一個字寫入 0x55，第 2 個字寫入 0xaa。

3．然後，立即將這兩個字的內容讀回。顯然，我們讀到的內容應該分別是 0x55 和 0xaa。如果不是，則說明這個 memory page 所佔據的位址範圍不是一段有效 RAM 空間。

4．再向這兩個字中寫入任意的數字。比如：向第一個字寫入 0xaa，第 2 個字中寫入 0x55。

5．然後，立即將這兩個字的內容立即讀回。顯然，我們讀到的內容應該分別是 0xaa 和 0x55。如果不是，則說明這個 memory page 所佔據的位址範圍不是一段有效 RAM 空間。

6．恢複這兩個字的原始內容。測試完畢。

為了得到一段乾淨的 RAM 空間範圍，我們也可以將所安排的 RAM 空間範圍進行清零操作。

3.1.3 拷貝 stage2 到 RAM 中

拷貝時要確定兩點：(1) stage2 的可執行映象在固態存放裝置的存放起始地址和終止地址；(2) RAM 空間的起始地址。

3.1.4 設定堆棧指標 sp

堆棧指標的設定是為了執行 C 語言代碼作好準備。通常我們可以把 sp 的值設定為(stage2_end-4)，也即在 3.1.2 節所安排的那個 1MB 的 RAM 空間的最頂端(堆棧向下生長)。此外，在設定堆棧指標 sp 之前，也可以關閉 led 燈，以提示使用者我們準備跳轉到 stage2。經過上述這些執行步驟後，系統的實體記憶體布局應該如2所示。

3.1.5 跳轉到 stage2 的 C 進入點

在上述一切都就緒後，就可以跳轉到 Boot Loader 的 stage2 去執行了。比如，在 ARM 系統中，這可以通過修改 PC 寄存器為合適的地址來實現。

圖2 bootloader 的 stage2 可執行映象剛被拷貝到 RAM 空間時的系統記憶體布局

3.2 Boot Loader 的 stage2

正如前面所說，stage2 的代碼通常用 C 語言來實現，以便於實現更複雜的功能和取得更好的代碼可讀性和可移植性。但是與普通 C 語言應用程式不同的是，在編譯和連結 boot loader 這樣的程式時，我們不能使用 glibc 庫中的任何支援函數。其原因是顯而易見的。這就給我們帶來一個問題，那就是從那裡跳轉進 main() 函數呢？直接把 main() 函數的起始地址作為整個 stage2 執行映像的進入點或許是最直接的想法。但是這樣做有兩個缺點：1)無法通過main() 函數傳遞函數參數；2)無法處理 main() 函數返回的情況。一種更為巧妙的方法是利用 trampoline(彈簧床)的概念。也即，用組合語言寫一段trampoline 小程式，並將這段 trampoline 小程式來作為 stage2 可執行映象的執行進入點。然後我們可以在 trampoline 彙編小程式中用 CPU 跳轉指令跳入 main() 函數中去執行；而當 main() 函數返回時，CPU 執行路徑顯然再次回到我們的 trampoline 程式。簡而言之，這種方法的思想就是：用這段 trampoline 小程式來作為 main() 函數的外部包裹(external wrapper)。

下面給出一個簡單的 trampoline 程式樣本(來自blob)：

.text.globl _trampoline_trampoline:blmain/* if main ever returns we just call it again */b_trampoline

可以看出，當 main() 函數返回後，我們又用一條跳轉指令重新執行 trampoline 程式――當然也就重新執行 main() 函數，這也就是 trampoline(彈簧床)一詞的意思所在。

3.2.1初始化本階段要使用到的硬體裝置

這通常包括：（1）初始化至少一個串口，以便和終端使用者進行 I/O 輸出資訊；（2）初始化計時器等。在初始化這些裝置之前，也可以重新把 LED 燈點亮，以表明我們已經進入 main() 函數執行。

裝置初始化完成後，可以輸出一些列印資訊，程式名字字串、版本號碼等。

3.2.2 檢測系統的記憶體映射（memory map）

所謂記憶體映射就是指在整個 4GB 物理地址空間中有哪些位址範圍被分配用來定址系統的 RAM 單元。比如，在 SA-1100 CPU 中，從 0xC000,0000 開始的 512M 地址空間被用作系統的 RAM 地址空間，而在 Samsung S3C44B0X CPU 中，從 0x0c00,0000 到 0x1000,0000 之間的 64M 地址空間被用作系統的 RAM 地址空間。雖然 CPU 通常預留出一大段足夠的地址空間給系統 RAM，但是在搭建具體的嵌入式系統時卻不一定會實現 CPU 預留的全部 RAM 地址空間。也就是說，具體的嵌入式系統往往只把 CPU 預留的全部 RAM 地址空間中的一部分映射到 RAM 單元上，而讓剩下的那部分預留 RAM 地址空間處於未使用狀態。由於上述這個事實，因此 Boot Loader 的 stage2 必須在它想幹點什麼 (比如，將儲存在 flash 上的核心映像讀到 RAM 空間中) 之前檢測整個系統的記憶體映射情況，也即它必須知道 CPU 預留的全部 RAM 地址空間中的哪些被真正映射到 RAM 地址單元，哪些是處於 "unused" 狀態的。

(1) 記憶體映射的描述

可以用如下資料結構來描述 RAM 地址空間中的一段連續(continuous)的位址範圍：

typedef struct memory_area_struct {u32 start; /* the base address of the memory region */u32 size; /* the byte number of the memory region */int used;} memory_area_t;

這段 RAM 地址空間中的連續位址範圍可以處於兩種狀態之一：(1)used=1，則說明這段連續的位址範圍已被實現，也即真正地被映射到 RAM 單元上。(2)used=0，則說明這段連續的位址範圍並未被系統所實現，而是處於未使用狀態。

基於上述 memory_area_t 資料結構，整個 CPU 預留的 RAM 地址空間可以用一個 memory_area_t 類型的數組來表示，如下所示：

memory_area_t memory_map[NUM_MEM_AREAS] = {[0 ... (NUM_MEM_AREAS - 1)] = {.start = 0,.size = 0,.used = 0},};

(2) 記憶體映射的檢測

下面我們給出一個可用來檢測整個 RAM 地址空間記憶體映射情況的簡單而有效演算法：

/* 數組初始化 */for(i = 0; i < NUM_MEM_AREAS; i++)memory_map[i].used = 0;/* first write a 0 to all memory locations */for(addr = MEM_START; addr < MEM_END; addr += PAGE_SIZE)* (u32 *)addr = 0;for(i = 0, addr = MEM_START; addr < MEM_END; addr += PAGE_SIZE) { /* * 檢測從基地址 MEM_START+i*PAGE_SIZE 開始,大小為* PAGE_SIZE 的地址空間是否是有效RAM地址空間。 */ 調用3.1.2節中的演算法test_mempage()； if ( current memory page isnot a valid ram page) {/* no RAM here */if(memory_map[i].used )i++;continue;}/* * 當前頁已經是一個被映射到 RAM 的有效位址範圍 * 但是還要看看當前頁是否只是 4GB 地址空間中某個地址頁的別名？ */if(* (u32 *)addr != 0) { /* alias? *//* 這個記憶體頁是 4GB 地址空間中某個地址頁的別名 */if ( memory_map[i].used )i++;continue;}/* * 當前頁已經是一個被映射到 RAM 的有效位址範圍 * 而且它也不是 4GB 地址空間中某個地址頁的別名。 */if (memory_map[i].used == 0) {memory_map[i].start = addr;memory_map[i].size = PAGE_SIZE;memory_map[i].used = 1;} else {memory_map[i].size += PAGE_SIZE;}} /* end of for (…) */

在用上述演算法檢測完系統的記憶體映射情況後，Boot Loader 也可以將記憶體映射的詳細資料列印到串口。

3.2.3 載入核心映像和根檔案系統映像

(1) 規劃記憶體佔用的布局

這裡包括兩個方面：(1)核心映像所佔用的記憶體範圍；（2）根檔案系統所佔用的記憶體範圍。在規劃記憶體佔用的布局時，主要考慮基地址和映像的大小兩個方面。

對於核心映像，一般將其拷貝到從(MEM_START＋0x8000) 這個基地址開始的大約1MB大小的記憶體範圍內(嵌入式 Linux 的核心一般都不操過 1MB)。為什麼要把從 MEM_START 到 MEM_START＋0x8000 這段 32KB 大小的記憶體空出來呢？這是因為 Linux 核心要在這段記憶體中放置一些全域資料結構，如：啟動參數和核心頁表等資訊。

而對於根檔案系統映像，則一般將其拷貝到 MEM_START+0x0010,0000 開始的地方。如果用 Ramdisk 作為根檔案系統映像，則其解壓後的大小一般是1MB。

（2）從 Flash 上拷貝

由於像 ARM 這樣的嵌入式 CPU 通常都是在統一的記憶體位址空間中定址 Flash 等固態存放裝置的，因此從 Flash 上讀取資料與從 RAM 單元中讀取資料並沒有什麼不同。用一個簡單的迴圈就可以完成從 Flash 裝置上拷貝映像的工作：

while(count) {*dest++ = *src++; /* they are all aligned with word boundary */count -= 4; /* byte number */};

3.2.4 設定核心的啟動參數

應該說，在將核心映像和根檔案系統映像拷貝到 RAM 空間中後，就可以準備啟動 Linux 核心了。但是在調用核心之前，應該作一步準備工作，即：設定 Linux 核心的啟動參數。

Linux 2.4.x 以後的核心都期望以標記列表(tagged list)的形式來傳遞啟動參數。啟動參數標記列表以標記 ATAG_CORE 開始，以標記 ATAG_NONE 結束。每個標記由標識被傳遞參數的 tag_header 結構以及隨後的參數值資料結構來組成。資料結構 tag 和 tag_header 定義在 Linux 核心源碼的include/asm/setup.h 標頭檔中：

/* The list ends with an ATAG_NONE node. */#define ATAG_NONE0x00000000struct tag_header {u32 size; /* 注意，這裡size是字數為單位的 */u32 tag;};……struct tag {struct tag_header hdr;union {struct tag_corecore;struct tag_mem32mem;struct tag_videotextvideotext;struct tag_ramdiskramdisk;struct tag_initrdinitrd;struct tag_serialnrserialnr;struct tag_revisionrevision;struct tag_videolfbvideolfb;struct tag_cmdlinecmdline;/* * Acorn specific */struct tag_acornacorn;/* * DC21285 specific */struct tag_memclkmemclk;} u;};

在嵌入式 Linux 系統中，通常需要由 Boot Loader 設定的常見啟動參數有：ATAG_CORE、ATAG_MEM、ATAG_CMDLINE、ATAG_RAMDISK、ATAG_INITRD等。比如，設定 ATAG_CORE 的代碼如下：

params = (struct tag *)BOOT_PARAMS;params->hdr.tag = ATAG_CORE;params->hdr.size = tag_size(tag_core);params->u.core.flags = 0;params->u.core.pagesize = 0;params->u.core.rootdev = 0;params = tag_next(params);

其中，BOOT_PARAMS 表示核心啟動參數在記憶體中的起始基地址，指標 params 是一個 struct tag 類型的指標。宏 tag_next() 將以指向當前標記的指標為參數，計算緊臨當前標記的下一個標記的起始地址。注意，核心的根檔案系統所在的裝置ID就是在這裡設定的。

下面是設定記憶體映射情況的範例程式碼：

for(i = 0; i < NUM_MEM_AREAS; i++) {if(memory_map[i].used) {params->hdr.tag = ATAG_MEM;params->hdr.size = tag_size(tag_mem32);params->u.mem.start = memory_map[i].start;params->u.mem.size = memory_map[i].size;params = tag_next(params);}}

可以看出，在 memory_map［］數組中，每一個有效記憶體段都對應一個 ATAG_MEM 參數標記。

Linux 核心在啟動時可以以命令列參數的形式來接收資訊，利用這一點我們可以向核心提供那些核心不能自己檢測的硬體參數資訊，或者重載(override)核心自己檢測到的資訊。比如，我們用這樣一個命令列參數字串"console=ttyS0,115200n8"來通知核心以 ttyS0 作為控制台，且串口採用 "115200bps、無同位、8位元據位"這樣的設定。下面是一段設定調用核心命令列參數字串的範例程式碼：

char *p;/* eat leading white space */for(p = commandline; *p == ' '; p++);/* skip non-existent command lines so the kernel will still * use its default command line. */if(*p == '/0')return;params->hdr.tag = ATAG_CMDLINE;params->hdr.size = (sizeof(struct tag_header) + strlen(p) + 1 + 4) >> 2;strcpy(params->u.cmdline.cmdline, p);params = tag_next(params);

請注意在上述代碼中，設定 tag_header 的大小時，必須包括字串的終止符'/0'，此外還要將位元組數向上圓整4個位元組，因為 tag_header 結構中的size 成員表示的是字數。

下面是設定 ATAG_INITRD 的範例程式碼，它告訴核心在 RAM 中的什麼地方可以找到 initrd 映象(壓縮格式)以及它的大小：

params->hdr.tag = ATAG_INITRD2;params->hdr.size = tag_size(tag_initrd);params->u.initrd.start = RAMDISK_RAM_BASE;params->u.initrd.size = INITRD_LEN;params = tag_next(params);

下面是設定 ATAG_RAMDISK 的範例程式碼，它告訴核心解壓後的 Ramdisk 有多大（單位是KB）：

params->hdr.tag = ATAG_RAMDISK;params->hdr.size = tag_size(tag_ramdisk);params->u.ramdisk.start = 0;params->u.ramdisk.size = RAMDISK_SIZE; /* 請注意，單位是KB */params->u.ramdisk.flags = 1; /* automatically load ramdisk */params = tag_next(params);

最後，設定 ATAG_NONE 標記，結束整個啟動參數列表：

static void setup_end_tag(void){params->hdr.tag = ATAG_NONE;params->hdr.size = 0;}

3.2.5 調用核心

Boot Loader 調用 Linux 核心的方法是直接跳轉到核心的第一條指令處，也即直接跳轉到 MEM_START＋0x8000 地址處。在跳轉時，下列條件要滿足：

1． CPU 寄存器的設定：
·R0＝0；
@R1＝機器類型 ID；關於 Machine Type Number，可以參見 linux/arch/arm/tools/mach-types。
@R2＝啟動參數標記列表在 RAM 中起始基地址；

2． CPU 模式：
·必須禁止中斷（IRQs和FIQs）；
·CPU 必須 SVC 模式；

3． Cache 和 MMU 的設定：
·MMU 必須關閉；
·指令 Cache 可以開啟也可以關閉；
·資料 Cache 必須關閉；

如果用 C 語言，可以像下列範例程式碼這樣來調用核心：

void (*theKernel)(int zero, int arch, u32 params_addr) = (void (*)(int, int, u32))KERNEL_RAM_BASE;……theKernel(0, ARCH_NUMBER, (u32) kernel_params_start);

注意，theKernel()函數調用應該永遠不返回的。如果這個調用返回，則說明出錯。

四、 關於串口終端

在 boot loader 程式的設計與實現中，沒有什麼能夠比從串口終端正確地收到列印資訊能更令人激動了。此外，向串口終端列印資訊也是一個非常重要而又有效調試手段。但是，我們經常會碰到串口終端顯示亂碼或根本沒有顯示的問題。造成這個問題主要有兩種原因：(1) boot loader 對串口的初始化設定不正確。(2) 運行在 host 端的終端模擬程式對串口的設定不正確，這包括：傳輸速率、同位、資料位元和停止位等方面的設定。

此外，有時也會碰到這樣的問題，那就是：在 boot loader 的運行過程中我們可以正確地向串口終端輸出資訊，但當 boot loader 啟動核心後卻無法看到核心的啟動輸出資訊。對這一問題的原因可以從以下幾個方面來考慮：

(1) 首先請確認你的核心在編譯時間配置了對串口終端的支援，並配置了正確的串口驅動程式。

(2) 你的 boot loader 對串口的初始化設定可能會和核心對串口的初始化設定不一致。此外，對於諸如 s3c44b0x 這樣的 CPU，CPU 時鐘頻率的設定也會影響串口，因此如果 boot loader 和核心對其 CPU 時鐘頻率的設定不一致，也會使串口終端無法正確顯示資訊。

(3) 最後，還要確認 boot loader 所用的核心基地址必須和核心映像在編譯時間所用的運行基地址一致，尤其是對於 uClinux 而言。假設你的核心映像在編譯時間用的基地址是 0xc0008000，但你的 boot loader 卻將它載入到 0xc0010000 處去執行，那麼核心映像當然不能正確地執行了。

五、 結束語

Boot Loader 的設計與實現是一個非常複雜的過程。如果不能從串口收到那激動人心的

"uncompressing linux.................. done, booting the kernel……"

核心啟動資訊，恐怕誰也不能說："嗨，我的 boot loader 已經成功地轉起來了！"。

---------------------------------------

本文轉載於IBM DW，作者：詹榮開，研究興趣包括：嵌入式 Linux、Linux 核心、驅動程式、檔案系統等。您可以通過 zhanrk@sohu.com 連繫他。