BootLoader

Bootloader是嵌入式系統在加電後執行的第一段代碼，在它完成CPU和相關硬件的初始化之後，再將操作系統映像或固化的嵌入式應用程序裝載到內存中然後跳轉到操作系統所在的空間，啓動操作系統運行 ^[2]  。

對於嵌入式系統，Bootloader是基於特定硬件平台來實現的。因此，幾乎不可能為所有的嵌入式系統建立一個通用的Bootloader，不同的處理器架構都有不同的Bootloader。Bootloader不但依賴於CPU的體系結構，而且依賴於嵌入式系統板級設備的配置。對於2塊不同的嵌入式板而言，即使它們使用同一種處理器，要想讓運行在一塊板子上的Bootloader程序也能運行在另一塊板子上，一般也都需要修改Bootloader的源程序 ^[2]  。

反過來，大部分Bootloader仍然具有很多共性，某些Bootloader也能夠支持多種體系結構的嵌入式系統。例如，U-Boot就同時支持PowerPC、ARM、MIPS和X86等體系結構，支持的板子有上百種。通常，它們都能夠自動從存儲介質上啓動，都能夠引導操作系統啓動，並且大部分都可以支持串口和以太網接口 ^[2]  。

通常，BootLoader是嚴重地依賴於硬件而實現的，特別是在嵌入式平台。因此，在嵌入式平台裏建立一個通用的BootLoader幾乎是不可能的。儘管如此，我們仍然可以對bootloader歸納出一些通用的概念來，以指導用户特定的BootLoader設計與實現 ^[3]  。

在專用的嵌入式板子運行GNU/Linux系統已經變得越來越流行。一個嵌入式Linux系統從軟件的角度看通常可以分為四個層次：

1、 引導加載程序:包括固化在固件(firmware)中的boot代碼(可選)，和BootLoader兩大部分 ^[3]  。

2、Linux內核:特定於嵌入式板子的定製內核以及內核的啓動參數 ^[3]  。

3、 文件系統:包括根文件系統和建立於Flash內存設備之上文件系統。通常用ramdisk來作為rootfs ^[3]  。

4、 用户應用程序:特定於用户的應用程序。有時在用户應用程序和內核層之間可能還會包括一個嵌入式圖形用户界面。常用的嵌入式GUI有：MicroWindows和MiniGUI等 ^[3]  。

大多數Bootloader都包含兩種不同的操作模式 ^[3]  ：

(1)啓動加載模式

在這種模式下，Bootloader從目標機的某個固態存儲設備上將操作系統加載到RAM中運行，整個過程並沒有用户的介入。這種模式是Bootloader的正常工作模式，因此在嵌入式產品發佈時，Bootloader必須工作在這種模式下 ^[3]  。

(2)下載模式

在這種模式下，目標機上的Bootloader將通過串口或網絡等通信手段從開發主機(Host)上下載內核映像和根文件系統映像等到RAM中，然後可再被Bootloader寫到目標機上的固態存儲媒質中，或者直接進行系統的引導 ^[3]  。

啓動加載模式通常用於第一次燒寫內核與根文件系統到固態存儲媒質時或者以後的系統更新時使用；下載模式多用於開發人員在前期開發的過程中，工作於這種模式下的Bootloader通常都會向它的終端用户提供一個簡單的命令行接口 ^[3]  。

Bootloader啓動大多數都分為兩個階段。第一階段主要包含依賴於CPU的體系結構硬件初始化的代碼，通常都用匯編語言來實現。這個階段的任務有 ^[4]  ：

基本的硬件設備初始化（屏蔽所有的中斷、關閉處理器內部指令/數據Cache等）。

為第二階段準備RAM空間。

如果是從某個固態存儲媒質中，則複製Bootloader的第二階段代碼到RAM ^[4]  。

設置堆棧。

在第一階段中為什麼要關閉Cache？通常使用Cache以及寫緩衝是為了提高系統性能，但由於Cache的使用可能改變訪問主存的數量、類型和時間，因此Bootloader通常是不需要的 ^[4]  。

跳轉到第二階段的C程序入口點 ^[4]  。

第二階段通常用C語言完成，以便實現更復雜的功能，也使程序有更好的可讀性和可移植性。這個階段的任務有 ^[4]  ：

初始化本階段要使用到的硬件設備。

檢測系統內存映射。

將內核映像和根文件系統映像從Flash讀到RAM。

為內核設置啓動參數。

調用內核 ^[4]  。

Redboot是Redhat公司隨eCos發佈的一個BOOT方案，是一個開源項目 ^[5]  。

當前Redboot的最新版本是Redboot-2.0.1，Redhat公司將會繼續支持該項目。

Redboot支持的處理器構架有ARM，MIPS，MN10300，PowerPC， Renesas SHx，v850，x86等，是一個完善的嵌入式系統Boot Loader ^[5]  。

Redboot是在ECOS的基礎上剝離出來的，繼承了ECOS的簡潔、輕巧、可靈活配置、穩定可靠等品質優點。它可以使用X-modem或Y-modem協議經由串口下載，也可以經由以太網口通過BOOTP/DHCP服務獲得IP參數，使用TFTP方式下載程序映像文件，常用於調試支持和系統初始化（Flash下載更新和網絡啓動）。Redboot可以通過串口和以太網口與GDB進行通信，調試應用程序，甚至能中斷被GDB運行的應用程序。Redboot為管理FLASH映像，映像下載，Redboot配置以及其他如串口、以太網口提供了一個交互式命令行接口，自動啓動後，REDBOOT用來從TFTP服務器或者從Flash下載映像文件加載系統的引導腳本文件保存在Flash上。當前支持單板機的移植版特性有 ^[5]  ：

- 支持ECOS，Linux操作系統引導

- 在線讀寫Flash

- 支持串行口kermit，S-record下載代碼

- 監控(minitor)命令集:讀寫I/O，內存，寄存器、 內存、外設測試功能等

Redboot是標準的嵌入式調試和引導解決方案，支持幾乎所有的處理器構架以及大量的外圍硬件接口，並且還在不斷地完善過程中 ^[5]  。

ARMboot是一個ARM平台的開源固件項目，它特別基於PPCBoot，一個為PowerPC平台上的系統提供類似功能的姊妹項目。鑑於對PPCBoot的嚴重依賴性，已經與PPCBoot項目合併，新的項目為U-Boot。

ARMboot發佈的最後版本為ARMboot-1.1.0，2002年ARMboot終止了維護 ^[5]  。

ARMboot支持的處理器構架有StrongARM ，ARM720T ，PXA250 等，是為基於ARM或者StrongARM CPU的嵌入式系統所設計的 ^[5]  。

ARMboot的目標是成為通用的、容易使用和移植的引導程序，非常輕便地運用於新的平台上。ARMboot是GPL下的ARM固件項目中唯一支持Flash閃存，BOOTP、DHCP、TFTP網絡下載，PCMCLA尋線機等多種類型來引導系統的。特性為：

-支持多種類型的FLASH；

-允許映像文件經由BOOTP、DHCP、TFTP從網絡傳輸；

-支持串行口下載S-record或者binary文件；

-允許內存的顯示及修改；

-支持jffs2文件系統等 ^[5]  。

Armboot對S3C44B0板的移植相對簡單，在經過刪減完整代碼中的一部分後，僅僅需要完成初始化、串口收發數據、啓動計數器和FLASH操作等步驟，就可以下載引導uClinux內核完成板上系統的加載。總得來説，ARMboot介於大、小型Boot Loader之間，相對輕便，基本功能完備，缺點是缺乏後續支持 ^[5]  。

U-Boot是由開源項目PPCBoot發展起來的，ARMboot併入了PPCBoot，和其他一些arch的Loader合稱U-Boot。2002年12月17日第一個版本U-Boot-0.2.0發佈，同時PPCBoot和ARMboot停止維護 ^[5]  。

U-Boot自發布以後已更新6次,最新版本為U-Boot-1.1.1，U-Boot的支持是持續性的 ^[5]  。

U-Boot支持的處理器構架包括PowerPC (MPC5xx，MPC8xx，MPC82xx，MPC7xx，MPC74xx，4xx)， ARM （ARM7，ARM9，StrongARM，Xscale），MIPS (4Kc，5Kc)，x86等等， U-Boot（Universal Bootloader）從名字就可以看出，它是在GPL下資源代碼最完整的一個通用Boot Loader ^[5]  。

U-Boot提供兩種操作模式：啓動加載（Boot loading）模式和下載（Downloading）模式,並具有大型Boot Loader的全部功能。主要特性為 ^[5]  ：

-SCC/FEC以太網支持；

-BOOTP/TFTP引導；

-IP，MAC預置功能；

-在線讀寫FLASH，DOC, IDE，IIC，EEROM，RTC；

-支持串行口kermit，S-record下載代碼；

-識別二進制、ELF32、pImage格式的Image，對Linux引導有特別的支持；

-監控(minitor)命令集:讀寫I/O，內存，寄存器、內存、外設測試功能等；

-腳本語言支持（類似BASH腳本）；

-支持WatchDog，LCD logo，狀態指示功能等 ^[5]  。

U-Boot的功能是如此之強大，涵蓋了絕大部分處理器構架，提供大量外設驅動，支持多個文件系統，附帶調試、腳本、引導等工具，特別支持Linux,為板級移植做了大量的工作。U-Boot1.1.1版本特別包含了對SA1100和44B0芯片的移植，所以44B0移植主要是針對Board 的移植，包括FLASH、內存配置以及串口波特率等等。U-Boot的完整功能性和後續不斷的支持，使系統的升級維護變得十分方便 ^[5]  。

Blob(Boot Loader Object)是由Jan-Derk Bakker and Erik Mouw發佈的，是專門為StrongARM 構架下的LART設計的Boot Loader ^[5]  。

Blob的最後版本是blob-2.0.5。

Blob支持SA1100的LART主板，但用户也可以自行修改移植 ^[5]  。

Blob也提供兩種工作模式，在啓動時處於正常的啓動加載模式，但是它會延時 10 秒等待終端用户按下任意鍵而將 Blob 切換到下載模式。如果在 10 秒內沒有用户按鍵，則 Blob 繼續啓動 Linux內核。其基本功能為 ^[5]  ：

初始化硬件（CPU速度，存儲器，中斷，RS232串口）

-引導Linux內核並提供ramdisk；

- 給LART下載一個內核或者ramdisk；

-給FLASH片更新內核或者ramdisk；

-測定存儲配置並通知內核；

-給內核提供一個命令行 ^[5]  。

Blob功能比較齊全，代碼較少，比較適合做修改移植，用來引導Liunx，目前大部分S3C44B0板都用Blob修改移植後來加載uClinux ^[5]  。

Bios-lt是專門支持三星（Samsung）公司ARM構架處理器S3C4510B的Loader，可以設置CPU/ROM/SDRAM/EXTIO，管理並燒寫FLASH，裝載引導uClinux內核。這是國內工程師申請GNU通用公共許可發佈的 ^[5]  。

Bios-lt的最新版本是Bios-lt-0.74，另外還提供了S3C4510B的一些外圍驅動 ^[5]  。

Bootldr是康柏（Compaq）公司發佈的，類似於compaq iPAQ Pocket PC，支持SA1100芯片。它被推薦用來引導Llinux,支持串口Y-modem協議以及jffs文件系統 ^[5]  。

Bootldr的最後版本為Bootldr-2.19 ^[5]  。

vivi是韓國mizi 公司開發的bootloader, 適用於ARM9處理器。Vivi有兩種工作模式：啓動加載模式和下載模式。啓動加載模式可以在一段時間後（這個時間可更改）自行啓動linux內核，這是vivi的默認模式。在下載模式下，vivi為用户提供一個命令行接口，通過接口可以使用vivi提供的一些命令，如下 ^[5]  ：

命令

功能

Load　把二進制文件載入Flash或RAM

Part　操作MTD分區信息。顯示、增加、刪除、復位、保存MTD分區

Param　設置參數

Boot　啓動系統

Flash　管理Flash，如刪除Flash的數據

vivi代碼分析　vivi的代碼包括arch，init，lib，drivers和include等幾個目錄，共200多條文件 ^[5]  。

Vivi主要包括下面幾個目錄 ^[5]  ：

arch：此目錄包括了所有vivi支持的目標板的子目錄，例如s3c2410目錄。

drivers：其中包括了引導內核需要的設備的驅動程序（MTD和串口）。

MTD目錄下分map、nand和nor三個目錄 ^[5]  。

init：這個目錄只有main.c和version.c兩個文件。和普通的C程序一樣，vivi將從main函數開始執行。

lib：一些平台公共的接口代碼，比如time.c裏的udelay()和mdelay() ^[5]  。

include：頭文件的公共目錄，其中的s3c2410.h定義了這塊處理器的一些寄存器。Platform/smdk2410.h定義了與開發板相關的資源配置參數，我們往往只需要修改這個文件就可以配置目標板的參數，如波特率、引導參數、物理內存映射等 ^[5]  。

一般的DSP都採用常見的BootLoader程序工作方式來實現用户程序的上電自舉 ^[6]  ：

1.處理器通信口(主端口)HPI方式

--通過DSP芯片與PC機或DSP芯片與其它DSP芯片之間的主機通信端口實現上電自舉；

2.8位或16位並行EPROM方式

--通過DSP內核的DMA通道實現上電自舉；

3.8位或16位並行I/O方式

--通過DSP芯片的片外並行I/O接口實現上電自舉；

4.8位或16位串行口方式

--通過DSP芯片的串行端口實現上電自舉 ^[6]  。

在以上四種工作方式中，最常用的是16位並行EPROM方式。即在DSP芯片上電或復位時，通過DMA通道將存儲在核外EPROM中的程序以16位形式存儲到核內的程序空間中 ^[6]  。

各種方式的BootLoader程序都有其固定格式的Boot表，用來實現用户程序的上電自舉。16位並行EPROM方式的Boot表如表所示 ^[6]  ：

項1：存放BootLoader

程序工作方式控制字，用於DSP芯片上電或復位時確認該Boot表是否為16位並行EPROM工作方式的Boot表。該表項內容為10AAH，表示DSP內核認為該Boot表是16位並行EPROM工作方式的BootLoader程序的Boot表；否則DSP內核認為該Boot表不是16位並行EPROM的方式的Boot表 ^[6]  ；

Boot表

項2：

存放DSP特殊寄存器SWWSR在上電或復位時被賦予的初始化數值 ^[6]  ；

項3：

存放DSP特殊寄存器BSCR在上電或復位時被賦予的初始化數值 ^[6]  ；

項4：

存放用户程序將要被存放在DSP核內程序空間的頁地址 ^[6]  ；

項5：

存放用户程序將要被存放到DSP核內程序空間的頁內偏移地址 ^[6]  ；

項6：

開始依次存放用户程序第m段代碼的長度N。用户程序第m段代碼將要被存放到DSP核內程序空間的頁地址，用户程序第m段代碼將要被存放到DSP核內程序空間的頁內偏移地址，用户程序第m段代碼的第1個字，第2個字，……，第N個字；Boot表的最後表項存放Boot表結束字0000H，表示Boot表到此結束。因此DSP內核要實現BootLoader程序，在上電覆位後首先要申請到片外數據、地址總線的控制權，然後再根據Boot表完成用户程序上電自舉過程 ^[6]  。

在實現多核DSP上電自舉時，每一個子核都需要申請片外總線的控制權。對於單核DSP而言，只有一個DSP內核，對應一個BootLoader程序，DSP核可以永遠擁有片外總線的控制權。但對於多核DSP而言，由於只有一套片外總線，所以片外總線的控制權不允許也不可能永遠被其中的某一個DSP子核所擁有。因此，多核DSP需要片外總線仲裁機制，以避免片外總線衝突。DSP核的BootLoader程序總是在DSP核上電或復位時啓動，且一啓動BootLoader程序，對應的DSP核就要申請核外的總線控制權。因此為了避免多核DSP的各個DSP子核啓動BootLoader程序時引起的片外總線衝突，可通過控制每個DSP子核的復位過程，使每個DSP子核在不同的時間內啓動自身的BootLoader程序來解決片外總線衝突的問題 ^[6]  。

Bootloader廣泛用於有操作系統的手持終端設備、智能家電及機頂盒等嵌入式設備上，它負責完成硬件初始化、操作系統引導和系統配製等，相當於PC機上的BIOS對於一個嵌入式的Linux系統而言，Bootloader是整個系統運行的基礎。但是對於不同的ARM平台而言所使用的Bootloader都會有所不同。完成 Bootloader的移植是在特定的硬件平台上實現系統構建和運行的至關重要的一個步驟 ^[7]  。