U-BOOT全線移植分析系列之一
――――BOOTLOADER介紹
Sailor_forever [email protected] 轉載請注明
http://blog.csdn.net/sailor_8318/archive/2008/08/04/2768049.aspx
【摘要】本節介紹了bootloader的基本概念。首先分析了為什麼要針對特定的CPU和開發闆移植bootloader的必要性。然後介紹了兩種如何在裸闆中燒寫bootloader的方法以及如何确定燒寫位址。其次介紹了産品釋出的啟動加載模式和開發使用的下載下傳模式（更新核心檔案系統及bootloader自身）。最後介紹了bootloader的兩個通用啟動階段的流程及代碼特性和運作位置。
【關鍵詞】bootloader，燒寫，複位位址，固化loader，啟動加載，stage1，位置無關
一 bootloader介紹
1.1 Bootloader移植的必要性
Bootloader是與系統硬體環境高度相關的初始化軟體，它擔負着初始化硬體和引導作業系統的雙重責任。一些ARM平台可以共用同一種Bootloader，但是總的說來，每一個特定系統的Bootloader都會有所不同。Bootloader廣泛用于有作業系統的手持終端裝置、智能家電及機頂盒等嵌入式裝置上，它負責完成硬體初始化、作業系統引導和系統配制等。Bootloader移植是在特定硬體平台上作業系統移植至關重要的一步。
1.2 BootLoader所支援的CPU和嵌入式系統闆
每種不同的CPU體系結構都有不同的BootLoader。有些BootLoader也支援多種體系結構的CPU，比如U-BOOT就同時支援ARM、MIPS、POWERPC等體系結構。除了依賴于CPU的體系結構外，BootLoader實際上也依賴于具體的嵌入式闆級裝置的配置。也就是說，對于兩塊不同的嵌入式闆而言，即使它們是基于同一種CPU而建構的，要想讓運作在一塊闆子上的BootLoader程式也能運作在另一塊闆子上，通常也都需要修改BootLoader的源程式。
1.3. Boot Loader的燒錄和存儲
系統加電或複位後，所有的CPU通常都從某個由CPU制造商預先安排的位址上取指令。比如，at91rm9200的CPU在複位時通常都從位址0x00000000取它的第一條指令。而MPC8260高端啟動則時從0xfff00000開始取指。這個位址依據特定的CPU而定。通常片外啟動時，基于CPU建構的嵌入式系統通常都有某種類型的固态儲存設備（EEPROM或FLASH等，at91rm9200是0x10000000)被映射到這個預先安排的位址上。是以在系統加電後，CPU将首先執行Boot Loader程式。
那麼bootloader最初是怎麼燒寫到flash中的呢？對于一個裸闆怎麼讓它跑起來呢?有兩種方式：
² 通過片内固化的loader加載bootloader：通常某些CPU内部ROM中固化了一段程式可以用于最初的程式下載下傳，如AT91RM9200。這時下載下傳的程式是在内部RAM中運作的，大小有一定限制，然後由這段程式繼續互動下載下傳真正要燒寫到flash中的程式，将其儲存在外部RAM中，最終燒寫到flash中。
² 通過JTAG或者仿真器下載下傳：通常這些燒錄工具可以直接操作flash，對其進行程式設計燒錄。需要專門的工具。這種情況多用于那些沒有固化loader的CPU，如三星系列。
上圖是一個同時裝有Boot Loader、核心的啟動參數、核心映像和根檔案系統映像的固态儲存設備的典型空間配置設定結構圖。上述順序是可變的，但bootloader首位址一定要在CPU複位取指的位址上。
1.4 Boot Loader的操作模式(Operation Mode)
主機和目标機之間一般通過序列槽建立連接配接，BootLoader軟體在執行時通常會通過序列槽來進行資料傳輸，如輸出列印資訊到序列槽，從序列槽讀取使用者控制字元。
大多數Boot Loader都包含兩種不同的操作模式：啟動加載模式和下載下傳模式，這種差別僅對于開發人員才有意義。從最終使用者的角度看，BootLoader的作用就是用來加載作業系統，而并不存在所謂的啟動加載模式與下載下傳工作模式的差別。
² 啟動加載(Boot loading)模式：這種模式也稱為自主模式bootstrap。也即Boot Loader将存儲在目标闆Flash中的核心和檔案系統的鏡像裝載到SDRAM中，整個過程無需使用者的介入。這種模式是BootLoader的正常工作模式，是以在嵌入式産品釋出的時候，BootLoader顯然必須工作在這種模式下。
² 下載下傳Downloading模式：在這種模式下，目标機上的BootLoader将通過序列槽連接配接或網絡連接配接等通信手段從主控端Host下載下傳檔案，比如下載下傳核心映像和根檔案系統映像等。從主機下載下傳的檔案通常首先被BootLoader儲存到目标機的RAM中，然後再被BootLoader寫到目标機上的FLASH類固态儲存設備中。BootLoader的這種模式通常在第一次安裝核心與根檔案系統時被使用；此外，以後的系統更新（bootloader自身也可以這樣更新）也會使用Boot Loader的這種工作模式。工作于這種模式下的BootLoader通常都會向它的終端使用者提供一些簡單的指令行接口。
像U-BOOT等這樣功能強大的BootLoader通常同時支援這兩種工作模式，而且允許使用者在這兩種工作模式之間進行切換。比如，U-BOOT在啟動時處于正常的啟動加載模式，但是它會延時幾秒(在配置檔案中可以設定)等待終端使用者按下任意鍵而将其切換到下載下傳模式（相當于bios下按del鍵可進入系統配置界面一樣，設定從CD光牒啟動可進行重裝），如果在給定時間内沒有使用者按鍵，則U-BOOT繼續啟動，進行正常的啟動加載。
1.5 Bootloader與主機之間進行檔案傳輸所用的通信裝置及協定
最常見的情況就是，目标機上的BootLoader通過序列槽與主機之間進行檔案傳輸，傳輸協定通常是kermit / xmodem / ymodem協定中的一種。但是，序列槽傳輸的速度是有限的，是以如果該Bootloader對目标闆的網卡支援良好，還可以通過以太網連接配接并借助TFTP (Trivial File Transfer Protocol)協定來下載下傳檔案是個更好的選擇。此時，主機方所用的軟體也要考慮，比如，在通過以太網連接配接和TFTP協定來下載下傳檔案時，主機方必須有一個軟體用來提供TFTP服務，如Windows平台上的tftpd.exe等或Linux下面的tftp伺服器。
1.6 Bootloader 的通用執行流程從作業系統的角度看，Bootloader的總目标就是正确地調用核心來執行。另外，由于Bootloader的實作依賴于 CPU的體系結構，是以大多數Bootloader都分為stagel和stage2兩大部分。依賴于CPU體系結構的代碼，比如裝置初始化代碼等，通常都放在stagel中，而且通常都用彙編語言來實作，以達到短小精悍和高效的目的。而stage2則通常用C語言來實作，這樣可以實作更複雜的功能，而且代碼會具有更好的可讀性和可移植性。
Bootloader的stagel為位置無關代碼，通常在FLASH中運作。所有的指令為相對尋址，可以在任何位置運作。通常包括以下步驟(以執行的先後順序)：
Ø 硬體裝置初始化（配置SDRAM存儲控制器及IO），中斷初始化；
Ø 為加載Bootloader的stage2準備RAM空間（這個位址由連結腳本指定，為運作域位址，通常為RAM的高端位址），測試記憶體空間是否有效；
Ø 拷貝Bootloader的stage2到RAM空間中；
Ø 設定好堆棧；
Ø 跳轉到stage2的C入口點。
Bootloader的stage2通常被拷貝到RAM中運作，這樣可以提高運作速度。通常包括以下步驟(以執行的先後順序)：
Ø 初始化本階段要使用到的硬體裝置；
Ø 檢測系統記憶體映射(memory map)；
Ø 沒有使用者幹預時将kernel映像和根檔案系統映像從flash讀到RAM空間中；
Ø 為核心設定啟動參數；
Ø 調用核心。
![linux-svn解除安裝與安裝[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)