嵌入式系統 Boot Loader 技術(shù)內幕(1)

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

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

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

2. Linux 內核。特定于嵌入式板子的定制內核以及內核的啟動(dòng)參數。

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

4. 用戶(hù)應用程序。特定于用戶(hù)的應用程序。有時(shí)在用戶(hù)應用程序和內核層之間可能還會(huì )包括一個(gè)嵌入式圖形用戶(hù)界面。常用的嵌入式 GUI 有：MicroWindows 和 MiniGUI 懂。

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

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

本文將從 Boot Loader 的概念、Boot Loader 的主要任務(wù)、Boot Loader 的框架結構以及 Boot Loader 的安裝等四個(gè)方面來(lái)討論嵌入式系統的 Boot Loader。

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

通常，Boot Loader 是嚴重地依賴(lài)于硬件而實(shí)現的，特別是在嵌入式世界。因此，在嵌入式世界里建立一個(gè)通用的 Boot Loader 幾乎是不可能的。盡管如此，我們仍然可以對 Boot Loader 歸納出一些通用的概念來(lái)，以指導用戶(hù)特定的 Boot Loader 設計與實(shí)現。

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

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

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

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

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

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

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

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

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

最常見(jiàn)的情況就是，目標機上的 Boot Loader 通過(guò)串口與主機之間進(jìn)行文件傳輸，傳輸協(xié)議通常是 xmodem／ymodem／zmodem 協(xié)議中的一種。但是，串口傳輸的速度是有限的，因此通過(guò)以太網(wǎng)連接并借助 TFTP 協(xié)議來(lái)下載文件是個(gè)更好的選擇。

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

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