BootLoader 又名：啟動裝載

背景介紹

　　Bootloader是嵌入式系統(tǒng)在加電后執(zhí)行的第一段代碼，在它完成CPU和相關硬件的初始化之后，再將操作系統(tǒng)映像或固化的嵌入式應用程序裝在到內(nèi)存中然后跳轉(zhuǎn)到操作系統(tǒng)所在的空間，啟動操作系統(tǒng)運行。

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

　　反過來，大部分Bootloader仍然具有很多共性，某些Bootloader也能夠支持多種體系結(jié)構(gòu)的嵌入式系統(tǒng)。例如，U-Boot就同時支持PowerPC、ARM、MIPS和X86等體系結(jié)構(gòu)，支持的板子有上百種。通常，它們都能夠自動從存儲介質(zhì)上啟動，都能夠引導操作系統(tǒng)啟動，并且大部分都可以支持串口和以太網(wǎng)接口。

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

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

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

　　3、 文件系統(tǒng)。包括根文件系統(tǒng)和建立于Flash內(nèi)存設備之上文件系統(tǒng)。通常用ramdisk來作為rootfs。

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

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

操作模式

　　1.自啟動模式：在這種模式下，bootloader從目標機上的某個固態(tài)存儲設備上將操作系統(tǒng)加載到RAM中運行，整個過程并沒有用戶的介入。

　　2.交互模式：在這種模式下，目標機上的bootloader將通過串口或網(wǎng)絡等通行手段從開發(fā)主機（Host）上下載內(nèi)核映像等到RAM中。可以被bootloader寫到目標機上的固態(tài)存儲媒質(zhì)中，或者直接進入系統(tǒng)的引導。也可以通過串口接收用戶的命令。

啟動過程

　　Bootloader啟動大多數(shù)都分為兩個階段。第一階段主要包含依賴于CPU的體系結(jié)構(gòu)硬件初始化的代碼，通常都用匯編語言來實現(xiàn)。這個階段的任務有：

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

　　為第二階段準備RAM空間。

　　如果是從某個固態(tài)存儲媒質(zhì)中，則復制Bootloader的第二階段代碼到RAM。

　　設置堆棧。

　　在第一階段中為什么要關閉Cache？通常使用Cache以及寫緩沖是為了提高系統(tǒng)性能，但由于Cache的使用可能改變訪問主存的數(shù)量、類型和時間，因此Bootloader通常是不需要的。

　　跳轉(zhuǎn)到第二階段的C程序入口點。

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

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

　　檢測系統(tǒng)內(nèi)存映射。

　　將內(nèi)核映像和根文件系統(tǒng)映像從Flash讀到RAM。

　　為內(nèi)核設置啟動參數(shù)。

　　調(diào)用內(nèi)核。

常見的Bootloader

Redboot

　　Redboot是Redhat公司隨eCos發(fā)布的一個BOOT方案，是一個開源項目。

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

　　Redboot支持的處理器構(gòu)架有ARM，MIPS，MN10300，PowerPC， Renesas SHx，v850，x86等，是一個完善的嵌入式系統(tǒng)Boot Loader。

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

　　- 支持ECOS，Linux操作系統(tǒng)引導

　　- 在線讀寫Flash

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

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

　　Redboot是標準的嵌入式調(diào)試和引導解決方案，支持幾乎所有的處理器構(gòu)架以及大量的外圍硬件接口，并且還在不斷地完善過程中。

ARMboot

　　ARMboot是一個ARM平臺的開源固件項目，它特別基于PPCBoot，一個為PowerPC平臺上的系統(tǒng)提供類似功能的姊妹項目。鑒于對PPCBoot的嚴重依賴性，已經(jīng)與PPCBoot項目合并，新的項目為U-Boot。

　　ARMboot發(fā)布的最后版本為ARMboot-1.1.0，2002年ARMboot終止了維護。

　　ARMboot支持的處理器構(gòu)架有StrongARM ，ARM720T ，PXA250 等，是為基于ARM或者StrongARM CPU的嵌入式系統(tǒng)所設計的。

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

　　-支持多種類型的FLASH；

　　-允許映像文件經(jīng)由BOOTP、DHCP、TFTP從網(wǎng)絡傳輸；

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

　　-允許內(nèi)存的顯示及修改；

　　-支持jffs2文件系統(tǒng)等。

　　Armboot對S3C44B0板的移植相對簡單，在經(jīng)過刪減完整代碼中的一部分后，僅僅需要完成初始化、串口收發(fā)數(shù)據(jù)、啟動計數(shù)器和FLASH操作等步驟，就可以下載引導uClinux內(nèi)核完成板上系統(tǒng)的加載?？偟脕碚f，ARMboot介于大、小型Boot Loader之間，相對輕便，基本功能完備，缺點是缺乏后續(xù)支持。

U-Boot

　　U-Boot是由開源項目PPCBoot發(fā)展起來的，ARMboot并入了PPCBoot，和其他一些arch的Loader合稱U-Boot。2002年12月17日第一個版本U-Boot-0.2.0發(fā)布，同時PPCBoot和ARMboot停止維護。

　　U-Boot自發(fā)布以后已更新6次,最新版本為U-Boot-1.1.1，U-Boot的支持是持續(xù)性的。

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

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

　　-SCC/FEC以太網(wǎng)支持

　　-BOOTP/TFTP引導

　　-IP，MAC預置功能

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

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

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

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

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

　　-支持WatchDog，LCD logo，狀態(tài)指示功能等

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

Blob

　　Blob(Boot Loader Object)是由Jan-Derk Bakker and Erik Mouw發(fā)布的，是專門為StrongARM 構(gòu)架下的LART設計的Boot Loader。

　　Blob的最后版本是blob-2.0.5。

　　Blob支持SA1100的LART主板，但用戶也可以自行修改移植。

　　Blob也提供兩種工作模式，在啟動時處于正常的啟動加載模式，但是它會延時 10 秒等待終端用戶按下任意鍵而將 Blob 切換到下載模式。如果在 10 秒內(nèi)沒有用戶按鍵，則 Blob 繼續(xù)啟動 Linux內(nèi)核。其基本功能為：

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

　　-引導Linux內(nèi)核并提供ramdisk

　　- 給LART下載一個內(nèi)核或者ramdisk

　　-給FLASH片更新內(nèi)核或者ramdisk

　　-測定存儲配置并通知內(nèi)核

　　-給內(nèi)核提供一個命令行

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

Bios-lt

　　Bios-lt是專門支持三星（Samsung）公司ARM構(gòu)架處理器S3C4510B的Loader，可以設置CPU/ROM/SDRAM/EXTIO，管理并燒寫FLASH，裝載引導uClinux內(nèi)核。這是國內(nèi)工程師申請GNU通用公共許可發(fā)布的。

　　Bios-lt的最新版本是Bios-lt-0.74，另外還提供了S3C4510B的一些外圍驅(qū)動。

Bootldr

　　Bootldr是康柏（Compaq）公司發(fā)布的，類似于compaq iPAQ Pocket PC，支持SA1100芯片。它被推薦用來引導Llinux,支持串口Y-modem協(xié)議以及jffs文件系統(tǒng)。

　　Bootldr的最后版本為Bootldr-2.19。

vivi

　　vivi是韓國mizi 公司開發(fā)的bootloader, 適用于ARM9處理器。Vivi有兩種工作模式：啟動加載模式和下載模式。啟動加載模式可以在一段時間后（這個時間可更改）自行啟動linux內(nèi)核，這是vivi的默認模式。在下載模式下，vivi為用戶提供一個命令行接口，通過接口可以使用vivi提供的一些命令，如下：

　　命令

　　功能

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

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

　　Param　設置參數(shù)

　　Boot　啟動系統(tǒng)

　　Flash　管理Flash，如刪除Flash的數(shù)據(jù)

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

　　Vivi主要包括下面幾個目錄：

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

　　drivers：其中包括了引導內(nèi)核需要的設備的驅(qū)動程序（MTD和串口）。

　　MTD目錄下分map、nand和nor三個目錄。

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

　　lib：一些平臺公共的接口代碼，比如time.c里的udelay()和mdelay()。

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

　　DSP的BootLoader

　　一般[2]  的DSP都采用常見的BootLoader程序工作方式來實現(xiàn)用戶程序的上電自舉：

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

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

　　2.8位或16位并行EPROM方式

　　--通過DSP內(nèi)核的DMA通道實現(xiàn)上電自舉；

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

　　--通過DSP芯片的片外并行I/O接口實現(xiàn)上電自舉；

　　4.8位或16位串行口方式

　　--通過DSP芯片的串行端口實現(xiàn)上電自舉。

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

　　各種方式的BootLoader程序都有其固定格式的Boot表，用來實現(xiàn)用戶程序的上電自舉。16位并行EPROM方式的Boot表如表所示:

　　項1：存放BootLoader

　　程序工作方式控制字，用于DS芯片上電或復位時確認該Boot表是否為16位并行EPROM工作方式的Boot表。該表項內(nèi)容為10AAH，表示DSP內(nèi)核認為該Boot表是16位并行EPROM工作方式的BootLoader程序的Boot表；否則DSP內(nèi)核認為該Boot表不是16位并行EPROM的方式的Boot表；

　　Boot表

　　項2：

　　存放DSP特殊寄存器SWWSR在上電或復位時被賦予的初始化數(shù)值；

　　項3：

　　存放DSP特殊寄存器BSCR在上電或復位時被賦予的初始化數(shù)值；

　　項4：

　　存放用戶程序?qū)⒁淮娣旁贒SP核內(nèi)程序空間的頁地址；

　　項5：

　　存放用戶程序?qū)⒁淮娣诺紻SP核內(nèi)程序空間的頁內(nèi)偏移地址；

　　項6：

　　開始依次存放用戶程序第m段代碼的長度N。用戶程序第m段代碼將要被存放到DSP核內(nèi)程序空間的頁地址，用戶程序第m段代碼將要被存放到DSP核內(nèi)程序空間的頁內(nèi)偏移地址，用戶程序第m段代碼的第1個字，第2個字，……，第N個字；Boot表的最后表項存放Boot表結(jié)束字0000H，表示Boot表到此結(jié)束。因此DSP內(nèi)核要實現(xiàn)BootLoader程序，在上電復位后首先要申請到片外數(shù)據(jù)、地址總線的控制權(quán)，然后再根據(jù)Boot表完成用戶程序上電自舉過程。

　　多核DSP的BootLoader程序的實現(xiàn)

　　在實現(xiàn)多核DSP上電自舉時，每一個子核都需要申請片外總線的控制權(quán)。對于單核DSP

　　而言，只有一個DSP內(nèi)核，對應一個BootLoader程序，DSP核可以永遠擁有片外總線的控制權(quán)。但對于多核DSP而言，由于只有一套片外總線，所以片外總線的控制權(quán)不允許也不可能永遠被其中的某一個DSP子核所擁有。因此，多核DSP需要片外總線仲裁機制，以避免片外總線沖突。DSP核的BootLoader程序總是在DSP核上電或復位時啟動，且一啟動

　　BootLoader程序，對應的DSP核就要申請核外的總線控制權(quán)。因此為了避免多核DSP的各個DSP子核啟動BootLoader程序時引起的片外總線沖突，可通過控制每個DSP子核的復位過程，使每個DSP子核在不同的時間內(nèi)啟動自身的BootLoader程序來解決片外總線沖突的問題。