引言
Bootloader(引導裝載器)是用於初始化目標板硬件，給嵌入式操作系統提供板上硬件資源信息，並進一步裝載、引導嵌入式操作系統運行的固件。在嵌入式系統開發過程中，很多情況都會涉及底層Bootloader的移植問題， 即使在有些已有Bootloader的參考開發板上也存在這種可能。概括來說， 如下情況會考慮進行Bootloader的移植工作。
① 在自主設計的目標板上，用於引導嵌入式操作系統及其應用。
② 在廠家未提供Bootloader源碼的參考板上，遇有如下情形之一：
a．在實際應用中需要添加或修改一些功能；
b．為了給自行設計主板移植Bootloader提供參考，先在參考板上進行移植以積累經驗。
另外，從嵌入式系統實際開發角度講， 嵌入式操作系統的引導、配置甚至應用程序的運行狀況都和bootloader有一定的關聯，可以說，掌握Bootloader移植是順利進行嵌入式系統開發的重要利器。
與常見的嵌入式操作系統板級支持包 BSP 相比，Bootloader 與底層硬件更為相關，即每個不同配置的目標板基本都有不同的 Bootloader。因為 Bootloader 往往更依據量體裁衣、定身製作的原則，以滿足要求的最小化代碼存放在啟動ROM 或Flash中。
雖然，自行編寫Bootloader未嘗不可，但從可利用的資源和實際項目開發考慮，採用移植已有的Bootloader源碼來解決這一問題更符合大多數項目的開發要求。
1. U-Boot簡介
U—Boot，全稱Universal Boot Loader，是遵循GPL條款的開放源碼項目，從FADSROM、8xxROM 、PPCBOOT逐步發展演化而來，其源碼目錄、編譯形式與Linux內核很相似。事實上，不少U—Boot源碼就是相應Linux內核源程序的簡化，尤其是一些設備的驅動程序，從U-Boot源碼的註釋中能體現這一點。但是U-Boot不僅僅支持嵌入式Linux系統的引導，當前，它還支持NetBSD。VxWorks、 QNX、RTEMS、ARTOS、LynxOS嵌入式操作系統。其目前要支持的目標操作系統包括0P enB S D 、NetBSD、FreeBSD、4 4BSD 、Linux、SVR4、Esix、Solaris、Irix、SCO、Dell、NCR、VxWorks、LynxOS、pSOS、QNX、RTEMS 和ARTOS。這是u-Boot中Universal的一層含義。另外一層含義則是U-Boot除了支持PowerPC系列的處理器外，還能支持 MIPS、x86、ARM 、Nios、XScale等諸多常用系列的處理器。這兩個特點正是U-Boot項目的開發目標，即支持儘可能多的嵌入式處理器和嵌入式操作系統。就目前來看，U-Boot對PowerPC系列處理器支持最為豐富， 對Linux的支持最完善。其它系列的處理器和操作系統基本是在2002年1 1月PPCBOOT改名為U-Boot 後逐步擴充的。從PPCBOOT向U—Boot的順利過渡，很大程度上歸功於U-Boot的維護人，德國DENX軟件工程中心的Wolfgang Denk(以下簡稱w．D)本人精湛的專業水平和持著不懈的努力。當前，u-BOOt項目在他的領軍下，眾多有志於開放源碼Boot loader移植工作的嵌入式開發人員， 正如火如荼地將各個不同系列嵌入式處理器的移植工作不斷展開和深入， 以支持更多嵌入式操作系統的裝載與引導。
2. U-Boot主要目錄結構
* board - 目標板相關文件，主要包含SDRAM、Flash驅動；
* common - 獨立於處理器體系結構的通用代碼， 如內存大小探測與故障檢測；
* cpu - 與處理器相關的文件， 如mpc8xx子目錄下含串口、網口、LCD 驅動及中斷初始化等文件；
* driver - 通用設備驅動，如CFI Flash驅動(目前對Intel Flash支持較好)
* doc - U-Boot的說明文檔；
* examples - 可在U-Boot下運行的示例程序；如hello_world.c, timer.c；
* include - U-Boot頭文件，configs子目錄下與目標板相關的配置頭文件是移植過程中經常要修改的文件；
* lib-XXX - 處理器體系相關的文件， 如lib-PPC, lib-arm 目錄分別包含與PowerPC、ARM體系結構相關的文件；
* net - 與網絡功能相關的文件目錄，如bootp、nfs、 tftp；
* post -上電自檢文件目錄， 尚有待於進一步完善；
* rtc - RTC驅動程序；
* tools - 用於創建U-Boot S-Record和BIN image文件的工具。
3. U-Boot支持的主要功能
U-Boot可支持的主要功能如下所列。
系統引導 支持NFS掛載、RAMDISK 系統引導 (壓縮或非壓縮)形式的根文件系統
支持NFS掛載，從Flash中引導壓縮或非壓縮系統內核
基本輔助 強大的操作系統接口功能，可靈活設置、傳遞多個關鍵參數給操作系統， 適合系統在不同開發階段的調試要求與產品發佈，尤其對Linux支持最為功能強勁
支持目標板環境參數的多種存儲方式，如Flash、NVRAM、EEPROM
CRC32校驗，可校驗Flash中內核、RAMDISK image是否完好
設備驅動 串口、SDRAM、Flash、以太網、LCD、NVRAM、EEPROM、鍵盤、USB、PCMCIA、PCI、RTC等驅動支持
上電自檢功能 SDRAM、Flash大小自動檢測；SDRAM 故障檢測；CPU型號
特殊功能 XIP內核引導
4. U-Boot移植過程
① 獲得發佈的最新版本U-Boot源碼，與Linux內核源碼類似，也是bzip2的壓縮格式。可從U-Boot的官方網站 http://sourceforge.net/projects/u-boot 上獲得。
② 閱讀相關文檔，主要是U-Boot源碼根目錄下的README文檔和U-Boot官方網站的DULG(The DENX U-Boot and Linux Guide)文檔(http://www.denx.de/twiki/bin/view/DULG/Manual)。尤其是DULG文檔，對如何安裝建立交叉開發環境和解決U-Boot移植中常見問題，都一一給出了詳盡說明。
③ 訂閱U-Boot用戶郵件列表( http://lists.sourceforge.net/lists/listinfo/u-boot-users)。當在移植U-Boot過程中遇有問題，在參考相關文檔和搜索U-boot-users郵件檔案庫(http://sourceforge.net/mailarchive/forum.php? forum-id=l2898)仍不能解決時，第一時間提交所遇到的問題， 眾多U-Boot開發人員會迅速排查問題，而且W．D本人很有可能會直接參與指導。
④ 在建立的開發環境下進行移植工作。絕大多數的開發環境是交叉開發環境。在這方面，DENX和MontaVi sta均提供了完整的開發工具集。
⑤ 在目標板與開發主機間接入硬件調試器。這是進行U-Boot移植應當具備且非常關鍵的調試工具。因為在整個U-Boot的移植工作中，尤其是初始階段，硬件調試器是我們瞭解目標板真實運行狀態的唯一途徑。在這方面， W ．D 本人和眾多嵌入式開發人員傾向於使用BDI2000。一方面，其價格不如ICE調試器昂貴，同時其可靠性高，功能強大，完全能勝任移植和調試U-Boot。另外， 網上也有不少關於BDI2000調試方面的參考文檔。
⑥ 如果在參考開發板上移植U-Boot，可能需要移除目標板上已有的Boot loader。可以根據板上Boot loader的說明文檔，先著手解決在移除當前Boot loader的情況下，如何進行恢復，以便今後在需要場合能重新裝入原先的Boot loader。
5. U-Boot移植方法
當前，對於U-Boot的移植方法，大致分為兩種。一種是先用BDI2000創建目標板初始運行環境，將U-Boot鏡像文件u-boot.bin下載到目標板 RAM中的指定位置，然後，用BDI2000進行跟蹤調試。其好處是， 不用將Uboot鏡像文件燒寫到Flash中去。但弊端在於，對移植開發人員的移植調試技能要求較高，BDI2000的配置文件較為複雜。另外一種方法是用BDI2000先將U-Boot鏡像文件燒寫到Flash中去，然後利用GDB和BDI2000進行調試。這種方法所用的BDI2000配置文件較為簡單，調試過程與U-Boot移植後運行過程相吻合。即U-Boot先從Flash中運行，再重載至RAM 中相應位置，並從那裡正式投入運行。唯一感到有些麻煩的就是需要不斷燒寫Flash。但考慮到Flash常規擦寫次數基本為l 0萬次左右，作為移植U-Boot，不會佔用太多的次數，應該不會為Flash燒寫有什麼擔憂。同時，w．D本人也極力推薦使用後一種方法。筆者建議，除非是U-BOot移植資深人士或有強有力的技術支持， 建議採用第二種移植方法。
6. U-Boot移植主要修改的文件
從移植U-Boot最小要求，U-Boot能正常啟動的角度出發， 主要考慮修改如下文件。
①
②
③ Flash的驅動程序，如board/RPXlite/flash.c 或 common/cfi-flash.c。可在參考已有Flash驅動的基礎上， 結合目標板Flash數據手冊，進行適當修改；
④ 串口驅動，如修改cpu/mpc8xx/seria1.c串口收發器芯片使能部分。
7. U-Boot移植要點
① BDI2000的配置文件。如果採用第二種移植方法，即先燒入Flash的方法，配置項只需很少幾個，就可以 進行U-Boot的燒寫與調試了。對PPC 8xx系列的主板，可參考DULG文檔中TQM8xx的配置文件進行相應的修改。下面，筆者以美國Embedded Planet公司的RPXlite Dw 板為例，給出在嵌入式Linux交叉開發環境下的BDI2000參考配置文件以作參考。
；bdiGDB configuration file for RPXlite DW or LITE DW
[INIT]
；init core register
WSPR 149 0x2002000F ；DER ：set debug enable ；register
WSPR 149 0x2002000F ；DER ：enable SYSIE for BDI ；Flash Program
WSPR 638 oxFA200000 ；IMMR ：internal memory at ；0xA200000
WM 32 oxFA200004 0xFFFFFF89 ；SYPCR
[TARGET]
CPUCLOCK 4000000 ；the CPU clock rate after processing
；the init list
BDIMODE AGENT ：the BDI WOrking mode
(LOADONLY | AGENT)
BREAKMODE HARD ；SOFT or HARD，HARD uses PPC
；hardware breakpoints
[HOST]
IP l72．16．115．6
FILE ulmage．litedw
FORMAT BIN
LOAD M ANUAL ；load code MANUAL or AUTO after rese
DEBUGPORT 2001
START 0x0100
[FLASH]
CHIPTYPE AM29BX8 ；Flash type(AM29F l AM29BX8
；AM29BX16 f I28BX8 f 128BX16)
CHIPSIZE 0x400000 ；The size of one flash chip in bytes
BUSWIDTH 32 ；The width of the flash memory bus
；inbits(8f 16f 32)
WORKSPACE 0xFA202000 ；RAM buffer for fast flash
；programming
FILE u-boot．bin ；The file to program
FORMAT BIN 0x00000000
ERASE 0x00000000 BLOCK
ERASE OxO0008000 BLOCK
ERASE 0x00010000 BL0CK
ERASE 0x000l8000 BLOCK
[REGS]
DMM 1 OxFA200000
FILE reg823．def
② U-Boot移植參考板，這是進行U-Boot移植首先要明確的。可以根據目標板上CPU、Flash、SDRAM的情況，以儘可能相一致為原則，先找出一個與所移植目標板為同一個或同一系列處理器的u-Boot支持板為移植參考板。如RPXlite DW 板可選擇U-Boot源碼中RPXlite板作為U-Boot移植參考板。對U-Boot移植新手， 建議依照循序漸進的原則，目標板文件名暫時先用移植參考板的名稱，在逐步熟悉U-BOOt移植基礎上，再考慮給目標板重新命名。在實際移植過程中，可用Linux命令查找移植參考板的特定代碼，如grep -r RPXlite ./可確定出在U-Boot中與RPXlite板有關的代碼，依此對照目標板實際進行屏蔽或修改。同時，應不侷限於移植參考板中的代碼， 要廣泛借鑑U-BOOt中已有的代碼， 更好地實現一些具體的功能。
③ U-Boot燒寫地址。不同目標板，對U-Boot在Flash中存放地址的要求不盡相同。事實上，這是由處理器中斷復位向量來決定的，與主板硬件相關。對MPC8xx主板來講，就是由硬件配置字(HRCW)決定的。也就是說，U-Boot燒寫具體位置是由硬件決定的，而不是程序設計來選擇的。程序中相應U-Boot起始地址必須與硬件所確定的硬件復位向量相吻合，如RPXlite DW 板的中斷復位向量設置為0x00000100。因此，U-Boot的BIN image 文件必須燒寫到Flash的起始位置。事實上，大多數的PPC系列的處理器中斷復位向量是0x00000100和0xfff00100。這也是一般所說的高位啟動和低位啟動的Bootloader所在位置。可通過修改u-BOot源碼<目標板>．h頭文件中CFG MONITOR BASE和board／<目標板>／config．mk中的TEX T — BASE的設置來與硬件配置相對應。
④ CPU寄存器參數設置。根據處理器系列、類型不同， 寄存器名稱與作用有一定差別，必須根據目標板的實際進行合理配置。一個較為可行和有效的方法是，借鑑參考移植板的配置，再根據目標板實際，進行合理修改。這是一個較費功夫和考驗耐力的過程，需要仔細對照處理器各寄存器定義、參考設置、目標板實際作出選擇並不斷測試。MPC 8XX處理器較為關鍵的寄存器設置為SIUMCR、PLPRCR、SCCR、BRx和ORx。
⑤ 串口調試。能從串口輸出信息，即使是亂碼，也可以說U．Boot移植取得了實質性突破。依據筆者調試經歷，串口是否有輸出，除了與串口驅動相關外，還與Flash相關的寄存器設置有關。因為U-Boot是從Flash中被引導啟動的，如果Flash設置不正確，U-Boot代碼讀取和執行就會出現一些問題。因此，還需要就Flash的相關寄存器設置進行一些參數調試。同時，要注意串口收發芯片相關引腳工作波形。依據筆者調試情況，如果串口無輸出或出現亂碼， 一種可能就是該芯片損壞或工作不正常。
⑥ 與啟動Flash相關的寄存器BR0、OR0的參數設置，應根據目標板Flash的數據手冊與BR0和OR0的相關位含義進行合理設置。這不僅關係到Flash能否正常工作， 而且與串口調試有直接的關聯。
⑦ 關於CPLD電路。目標板上是否有CPLD電路絲毫不會影響U-Boot的移植與嵌入式操作系統的正常運行。事實上，CPLD電路是一個集中將板上電路的一些邏輯關係可編程設置的一種實現方法。其本身所起的作用就是實現一些目標板所需的脈衝信號和電路邏輯， 其功能完全可以用一些邏輯電路與CPU口線來實現。
⑧ SDRAM的驅動。串口能輸出以後，U-Boot移植是否順利基本取決於SDRAM 的驅動是否正確。與串口調試相比，這部分工作更為重要，難度更大。MPC8xx目標板SDRAM 驅動涉及三部分。一是相關寄存器的設置；二是UPM 表；三是SDRAM 上電初始化過程。任何一部分有問題，都會影響U-Boot、嵌入式操作系統甚至應用程序的穩定、可靠運行。所以說，SDRAM 的驅動不僅關係到U-Boot本身能否正常運行， 而且還與後續部分相關， 是相當關鍵的部分。
⑨ 補充功能的添加。在獲得一個能工作的U-Boot後， 就可以根據目標板和實際開發需要， 添加一些其它功能支持， 如以太網、L CD 、NVRAM 等。與串口和SDRAM 調試相比，在已有基礎之上，添加這些功能還是較為容易的。大多只是在參考現有源碼的基礎上，進行一些修改和配置。另外， 如果是在自主設計的主板上移植U-Boot， 那
麼除了考慮上述軟件因素以外， 還需要排查目標板硬件可能存在的問題， 如原理設計、PCB布線、元件好壞。
在移植過程中， 敏銳判斷出故障態是硬件還是軟件問題， 往往是關係到項目進度甚至移植成敗的關鍵， 相應
難度會增加許多。
結語
完成一個目標板的移植工作後，可考慮將移植結果以補丁的形式發送到U-Boot用戶郵件列表，尤其是一些參考板的移植結果。這是使用GPL代碼並遵循GPL條款的體現。可在閱讀 README相關補丁說明的基礎上，添加適當的註釋，將自己列入光榮榜(CREDITS)。如果願意承擔所移植板的後續更新工作，可以考慮加入維護人員(MAINTAINERS)開發隊伍行列。
在實際的U-Boot移植中，無法避免地會遇到一些難以預料的問題， 甚至出現倒退， 尤其是U-Boot移植新手，更會平添諸多難度。但筆者相信， 在逐步熟悉U-BOOt的移植方法和過程中，隨著自身經驗的不斷積累，加之有眾多熱衷於開放源碼人士的鼎立相助，堅冰終會消融。
參考文獻
1 http://cvs.sourceforge.net/viewcvs.py/u-boot/u-boot/
2 http://www.denx.de/twiki/bin/view/DULG/Manual
3 Motorola．PowerPC MPC823 IJser，S Manual
沒有留言:
張貼留言