本文詳細地介紹了基于嵌入式系統(tǒng)中的 OS 啟動加載程序 ―― Boot Loader 的概念、軟件設(shè)計的主要任務(wù)以及結(jié)構(gòu)框架等內(nèi)容。

在專用的嵌入式板子運行 GNU/Linux 系統(tǒng)已經(jīng)變得越來越流行。一個嵌入式 Linux 系統(tǒng)從軟件的角度看通?？梢苑譃樗膫€層次：

1. 引導(dǎo)加載程序。包括固化在固件(firmware)中的 boot 代碼(可選)，和 Boot Loader 兩大部分。

2. Linux 內(nèi)核。特定于嵌入式板子的定制內(nèi)核以及內(nèi)核的啟動參數(shù)。

3. 文件系統(tǒng)。包括根文件系統(tǒng)和建立于 Flash 內(nèi)存設(shè)備之上文件系統(tǒng)。通常用 ram disk 來作為 root fs。

4. 用戶應(yīng)用程序。特定于用戶的應(yīng)用程序。有時在用戶應(yīng)用程序和內(nèi)核層之間可能還會包括一個嵌入式圖形用戶界面。常用的嵌入式 GUI 有：MicroWindows 和 MiniGUI 懂。

引導(dǎo)加載程序是系統(tǒng)加電后運行的第一段軟件代碼。回憶一下 PC 的體系結(jié)構(gòu)我們可以知道，PC 機中的引導(dǎo)加載程序由 BIOS(其本質(zhì)就是一段固件程序)和位于硬盤 MBR 中的 OS Boot Loader（比如，LILO 和 GRUB 等）一起組成。BIOS 在完成硬件檢測和資源分配后，將硬盤 MBR 中的 Boot Loader 讀到系統(tǒng)的 RAM 中，然后將控制權(quán)交給 OS Boot Loader。Boot Loader 的主要運行任務(wù)就是將內(nèi)核映象從硬盤上讀到 RAM 中，然后跳轉(zhuǎn)到內(nèi)核的入口點去運行，也即開始啟動操作系統(tǒng)。

而在嵌入式系統(tǒng)中，通常并沒有像 BIOS 那樣的固件程序（注，有的嵌入式 CPU 也會內(nèi)嵌一段短小的啟動程序），因此整個系統(tǒng)的加載啟動任務(wù)就完全由 Boot Loader 來完成。比如在一個基于 ARM7TDMI core 的嵌入式系統(tǒng)中，系統(tǒng)在上電或復(fù)位時通常都從地址 0x00000000 處開始執(zhí)行，而在這個地址處安排的通常就是系統(tǒng)的 Boot Loader 程序。

本文將從 Boot Loader 的概念、Boot Loader 的主要任務(wù)、Boot Loader 的框架結(jié)構(gòu)以及 Boot Loader 的安裝等四個方面來討論嵌入式系統(tǒng)的 Boot Loader。

簡單地說，Boot Loader 就是在操作系統(tǒng)內(nèi)核運行之前運行的一段小程序。通過這段小程序，我們可以初始化硬件設(shè)備、建立內(nèi)存空間的映射圖，從而將系統(tǒng)的軟硬件環(huán)境帶到一個合適的狀態(tài)，以便為最終調(diào)用操作系統(tǒng)內(nèi)核準備好正確的環(huán)境。

通常，Boot Loader 是嚴重地依賴于硬件而實現(xiàn)的，特別是在嵌入式世界。因此，在嵌入式世界里建立一個通用的 Boot Loader 幾乎是不可能的。盡管如此，我們?nèi)匀豢梢詫?Boot Loader 歸納出一些通用的概念來，以指導(dǎo)用戶特定的 Boot Loader 設(shè)計與實現(xiàn)。

每種不同的 CPU 體系結(jié)構(gòu)都有不同的 Boot Loader。有些 Boot Loader 也支持多種體系結(jié)構(gòu)的 CPU，比如 U-Boot 就同時支持 ARM 體系結(jié)構(gòu)和MIPS 體系結(jié)構(gòu)。除了依賴于 CPU 的體系結(jié)構(gòu)外，Boot Loader 實際上也依賴于具體的嵌入式板級設(shè)備的配置。這也就是說，對于兩塊不同的嵌入式板而言，即使它們是基于同一種 CPU 而構(gòu)建的，要想讓運行在一塊板子上的 Boot Loader 程序也能運行在另一塊板子上，通常也都需要修改 Boot Loader 的源程序。

系統(tǒng)加電或復(fù)位后，所有的 CPU 通常都從某個由 CPU 制造商預(yù)先安排的地址上取指令。比如，基于 ARM7TDMI core 的 CPU 在復(fù)位時通常都從地址 0x00000000 取它的第一條指令。而基于 CPU 構(gòu)建的嵌入式系統(tǒng)通常都有某種類型的固態(tài)存儲設(shè)備(比如：ROM、EEPROM 或 FLASH 等)被映射到這個預(yù)先安排的地址上。因此在系統(tǒng)加電后，CPU 將首先執(zhí)行 Boot Loader 程序。

下圖1就是一個同時裝有 Boot Loader、內(nèi)核的啟動參數(shù)、內(nèi)核映像和根文件系統(tǒng)映像的固態(tài)存儲設(shè)備的典型空間分配結(jié)構(gòu)圖。

主機和目標機之間一般通過串口建立連接，Boot Loader 軟件在執(zhí)行時通常會通過串口來進行 I/O，比如：輸出打印信息到串口，從串口讀取用戶控制字符等。

通常多階段的 Boot Loader 能提供更為復(fù)雜的功能，以及更好的可移植性。從固態(tài)存儲設(shè)備上啟動的 Boot Loader 大多都是 2 階段的啟動過程，也即啟動過程可以分為 stage 1 和 stage 2 兩部分。而至于在 stage 1 和 stage 2 具體完成哪些任務(wù)將在下面討論。

大多數(shù) Boot Loader 都包含兩種不同的操作模式：啟動加載模式和下載模式，這種區(qū)別僅對于開發(fā)人員才有意義。但從最終用戶的角度看，Boot Loader 的作用就是用來加載操作系統(tǒng)，而并不存在所謂的啟動加載模式與下載工作模式的區(qū)別。

啟動加載（Boot loading）模式：這種模式也稱為自主（Autonomous）模式。也即 Boot Loader 從目標機上的某個固態(tài)存儲設(shè)備上將操作系統(tǒng)加載到 RAM 中運行，整個過程并沒有用戶的介入。這種模式是 Boot Loader 的正常工作模式，因此在嵌入式產(chǎn)品發(fā)布的時侯，Boot Loader 顯然必須工作在這種模式下。

下載（Downloading）模式：在這種模式下，目標機上的 Boot Loader 將通過串口連接或網(wǎng)絡(luò)連接等通信手段從主機（Host）下載文件，比如：下載內(nèi)核映像和根文件系統(tǒng)映像等。從主機下載的文件通常首先被 Boot Loader 保存到目標機的 RAM 中，然后再被 Boot Loader 寫到目標機上的FLASH 類固態(tài)存儲設(shè)備中。Boot Loader 的這種模式通常在第一次安裝內(nèi)核與根文件系統(tǒng)時被使用；此外，以后的系統(tǒng)更新也會使用 Boot Loader 的這種工作模式。工作于這種模式下的 Boot Loader 通常都會向它的終端用戶提供一個簡單的命令行接口。

像 Blob 或 U-Boot 等這樣功能強大的 Boot Loader 通常同時支持這兩種工作模式，而且允許用戶在這兩種工作模式之間進行切換。比如，Blob 在啟動時處于正常的啟動加載模式，但是它會延時 10 秒等待終端用戶按下任意鍵而將 blob 切換到下載模式。如果在 10 秒內(nèi)沒有用戶按鍵，則 blob 繼續(xù)啟動 Linux 內(nèi)核。

最常見的情況就是，目標機上的 Boot Loader 通過串口與主機之間進行文件傳輸，傳輸協(xié)議通常是 xmodem／ymodem／zmodem 協(xié)議中的一種。但是，串口傳輸?shù)乃俣仁怯邢薜?，因此通過以太網(wǎng)連接并借助 TFTP 協(xié)議來下載文件是個更好的選擇。

此外，在論及這個話題時，主機方所用的軟件也要考慮。比如，在通過以太網(wǎng)連接和 TFTP 協(xié)議來下載文件時，主機方必須有一個軟件用來的提供 TFTP 服務(wù)。

在討論了 BootLoader 的上述概念后，下面我們來具體看看 BootLoader 的應(yīng)該完成哪些任務(wù)。