移動(dòng)終端Ｂｏｏｔｌｏａｄｅｒ的開(kāi)發(fā)與設(shè)計(jì)

摘要：為了縮短系統(tǒng)的響應(yīng)時(shí)間和提高文件的下載速度，基于U－Boot設(shè)計(jì)和開(kāi)發(fā)了CrystalBoot引導(dǎo)程序。通過(guò)在Bootloader中增加開(kāi)機(jī)動(dòng)畫(huà)顯示、充電管理和基于USB的文件下載功能，CrystalBoot能夠快速地對(duì)用戶的開(kāi)機(jī)和充電操作進(jìn)行響應(yīng)，提高代碼下載和調(diào)試效率，更好地滿足了用戶及開(kāi)發(fā)人員的需求。

關(guān)鍵詞：引導(dǎo)程序； U－Boot； CrystalBoot； 移動(dòng)終端； 嵌入式系統(tǒng)

中圖分類號(hào)：TP311.5

文獻(xiàn)標(biāo)志碼：A

文章編號(hào)：1001－3695(2008)06－1917－04

隨著智能手機(jī)、PDA等移動(dòng)終端設(shè)備的功能越來(lái)越豐富，其內(nèi)核代碼和系統(tǒng)軟件的規(guī)模越來(lái)越大，導(dǎo)致操作系統(tǒng)的加載和啟動(dòng)時(shí)間延長(zhǎng)，系統(tǒng)從上電復(fù)位開(kāi)始要經(jīng)過(guò)較長(zhǎng)時(shí)間才能就緒，不能及時(shí)響應(yīng)用戶的操作。按照日常使用習(xí)慣，用戶希望按下開(kāi)機(jī)鍵后很快看到動(dòng)態(tài)的畫(huà)面，說(shuō)明系統(tǒng)在正常運(yùn)行。如果能在內(nèi)核啟動(dòng)前就顯示開(kāi)機(jī)動(dòng)畫(huà)，用戶體驗(yàn)會(huì)大為改善。同樣，用戶在關(guān)機(jī)狀態(tài)下給終端充電也希望馬上看到充電畫(huà)面。Bootloader是在系統(tǒng)加電后運(yùn)行的第一段程序，代碼尺寸小、運(yùn)行速度快。將開(kāi)機(jī)動(dòng)畫(huà)和關(guān)機(jī)充電顯示功能集成到Bootloader中，可以縮短兩者的啟動(dòng)時(shí)間。另一方面，由于開(kāi)發(fā)階段需要經(jīng)常下載內(nèi)核和文件系統(tǒng)進(jìn)行調(diào)試，傳統(tǒng)的低速串口下載方式已經(jīng)不適合日漸增大的代碼規(guī)模，而移動(dòng)終端又沒(méi)有其他嵌入式系統(tǒng)常見(jiàn)的以太網(wǎng)口，必須采用新的高速下載方案。USB是一個(gè)很好的選擇。在Bootloader中通過(guò)USB進(jìn)行文件下載，可以不依賴于上層系統(tǒng)軟件下載文件到設(shè)備端內(nèi)存中，既可以在開(kāi)發(fā)階段用于下載調(diào)試，也可以在產(chǎn)品化階段用于系統(tǒng)軟件升級(jí)。本文在基于OMAP平臺(tái)的移動(dòng)終端系統(tǒng)上對(duì)U－Boot進(jìn)行功能擴(kuò)充，開(kāi)發(fā)了CrystalBoot。CrystalBoot在滿足引導(dǎo)操作系統(tǒng)這一基本功能需求的同時(shí)，增強(qiáng)Bootloader的功能，實(shí)現(xiàn)了顯示開(kāi)機(jī)動(dòng)畫(huà)、充電管理以及基于USB的文件下載功能，在關(guān)機(jī)狀態(tài)下能夠?qū)τ脩舻拈_(kāi)機(jī)和充電操作迅速做出反應(yīng)，同時(shí)通過(guò)USB進(jìn)行文件下載，大大加快了代碼下載速度，提高了研發(fā)效率。

1CrystalBoot的功能與流程

1．1Bootloader的基本功能

Bootloader是系統(tǒng)加電復(fù)位后執(zhí)行的第一段用戶代碼，其最主要的功能就是引導(dǎo)操作系統(tǒng)內(nèi)核。一般為了完成此任務(wù)，還需要執(zhí)行一些必要的硬件初始化工作。有些Bootloader，如Grub、U－Boot等，還提供了一個(gè)用戶交互接口，可以執(zhí)行用戶輸入的命令，在線修改系統(tǒng)配置，實(shí)現(xiàn)系統(tǒng)診斷和調(diào)試功能。這種類型的Bootloader實(shí)質(zhì)上是實(shí)現(xiàn)了一個(gè)Pre－OS的運(yùn)行環(huán)境。關(guān)于Bootloader的基本概念和功能，已經(jīng)有很多文獻(xiàn)[1，2]對(duì)其進(jìn)行了描述，本文不再贅述。

由于與CPU體系結(jié)構(gòu)、硬件平臺(tái)緊密相關(guān)，Bootloader的編寫(xiě)并不是一件簡(jiǎn)單的工作，甚至有些神秘。但開(kāi)源社區(qū)的努力與貢獻(xiàn)已經(jīng)改變了這種狀況。對(duì)于基于ARM的很多嵌入式開(kāi)發(fā)平臺(tái)，U－Boot[3，4]已經(jīng)提供了非常完善的支持，只需要經(jīng)過(guò)很少的代碼修改（有時(shí)甚至無(wú)須任何修改），就可以在相應(yīng)的平臺(tái)上運(yùn)行起來(lái)，完成引導(dǎo)操作系統(tǒng)的基本功能。U－Boot為人們開(kāi)發(fā)和完善Bootloader提供了一個(gè)非常好的基礎(chǔ)，CrystalBoot就是基于U－Boot。

1．2CrystalBoot的主要功能

CrystalBoot是為基于OMAP和嵌入式Linux的移動(dòng)終端開(kāi)發(fā)和設(shè)計(jì)的Bootloader，在實(shí)現(xiàn)Bootloader的基本功能的基礎(chǔ)上進(jìn)行了擴(kuò)展。其主要功能包括：

a)硬件初始化，包括設(shè)置ARM運(yùn)行模式、配置指令和數(shù)據(jù)cache、堆棧初始化、時(shí)鐘設(shè)置、中斷寄存器配置、OMAP引腳配置、SDRAM初始化、NAND flash初始化、串口設(shè)置等，為引導(dǎo)操作系統(tǒng)內(nèi)核構(gòu)建適合的運(yùn)行環(huán)境。

b)引導(dǎo)操作系統(tǒng)。將Linux內(nèi)核從flash拷貝到內(nèi)存地址0x10008000處，從此處引導(dǎo)內(nèi)核。

c)顯示開(kāi)機(jī)動(dòng)畫(huà)。用戶按下開(kāi)機(jī)鍵后，在引導(dǎo)操作系統(tǒng)之前顯示開(kāi)機(jī)動(dòng)畫(huà)，改善用戶體驗(yàn)。

d)支持充電管理。用戶在關(guān)機(jī)狀態(tài)下接入充電器后，可以在不啟動(dòng)操作系統(tǒng)的情況下顯示充電界面，進(jìn)行充電管理。

e)實(shí)現(xiàn)基于USB的文件下載功能，能夠高速地下載文件到移動(dòng)終端的內(nèi)存中，直接進(jìn)行調(diào)試或燒寫(xiě)到flash上。

在上述五項(xiàng)功能中，前兩項(xiàng)屬于Bootloader的基本功能，本文主要對(duì)后三項(xiàng)擴(kuò)充功能進(jìn)行具體描述。

1．3啟動(dòng)流程

由于增加了新的功能，CrystalBoot在啟動(dòng)過(guò)程中不只有一條單一的執(zhí)行路徑，需根據(jù)用戶的不同輸入，執(zhí)行不同的流程。首先，CrystalBoot在完成基本的硬件初始化工作后，檢測(cè)用戶（研發(fā)人員）是否通過(guò)串口終端有按鍵操作，如果有，說(shuō)明用戶要進(jìn)入交互模式，進(jìn)而可以輸入控制臺(tái)命令進(jìn)行各種調(diào)試以及文件下載。U－Boot已經(jīng)實(shí)現(xiàn)了串口中斷檢測(cè)，CrystalBoot在此不用添加新功能。然后，CrystalBoot需要識(shí)別出此次開(kāi)機(jī)的原因。如果是用戶按了開(kāi)機(jī)鍵，則顯示開(kāi)機(jī)動(dòng)畫(huà)、引導(dǎo)操作系統(tǒng)；如果是由于接入充電器或充電數(shù)據(jù)線引起的系統(tǒng)開(kāi)機(jī)，則顯示充電界面，轉(zhuǎn)入充電管理流程。CrystalBoot的啟動(dòng)流程如圖1所示。

2開(kāi)機(jī)動(dòng)畫(huà)

2．1GIF解碼器

2．1．1GIF文件格式

一個(gè)GIF文件的結(jié)構(gòu)可分為文件頭、GIF數(shù)據(jù)流和文件終結(jié)器三個(gè)部分。文件頭包含GIF文件簽名和版本號(hào)；GIF數(shù)據(jù)流由邏輯屏幕描述符、全局顏色表、圖像塊(包括圖像描述符、局部顏色表、圖像數(shù)據(jù))和其他的一些擴(kuò)展塊（圖形控制擴(kuò)展、注釋擴(kuò)展、應(yīng)用擴(kuò)展、文本擴(kuò)展）組成；文件終結(jié)器用一個(gè)值為0x3B的字符表示文件結(jié)束。GIF文件內(nèi)部按塊組織分為控制塊和數(shù)據(jù)塊。控制塊包含各種參數(shù)，控制數(shù)據(jù)塊的行為；數(shù)據(jù)塊包含8位字符流，由它前面的控制塊來(lái)決定它的功能，每個(gè)數(shù)據(jù)塊大小為0~255 Byte，數(shù)據(jù)塊的第一個(gè)字節(jié)指出該數(shù)據(jù)塊的字節(jié)數(shù)。GIF圖像存儲(chǔ)的數(shù)據(jù)不是顏色本身，而是該點(diǎn)的顏色對(duì)應(yīng)于顏色列表的索引值。關(guān)于GIF文件格式的詳細(xì)說(shuō)明，請(qǐng)參閱文獻(xiàn)[6]。

2．1．2Libungif庫(kù)及其移植

Giflib和Libungif[7]是用于處理GIF文件的開(kāi)源項(xiàng)目，提供了一套完整的編解碼庫(kù)函數(shù)和工具包。兩者的功能相當(dāng)，但由于涉及到LZW算法的專利問(wèn)題，如果是商業(yè)軟件開(kāi)發(fā)，應(yīng)采用Libungif庫(kù)。

為了在CrystalBoot中對(duì)GIF文件進(jìn)行解碼，本文基于4.1.0版本的Libungif庫(kù)，將其中的dgif_lib.c和gif_lib.h兩個(gè)文件集成到Bootloader中，最主要的移植工作是將其中的磁盤(pán)文件操作修改為對(duì)內(nèi)存的直接讀寫(xiě)。為此，在打開(kāi)GIF文件前，需要首先將該文件從flash上讀到內(nèi)存緩沖區(qū)中，然后在指定的內(nèi)存位置打開(kāi)文件。具體地，使用一個(gè)新的DGifOpen－File()函數(shù)替代原文件中的DGifOpen－FileName()和DGifOpenFileHandle()兩個(gè)函數(shù)，用于從指定內(nèi)存地址打開(kāi)一個(gè)GIF文件。DGifOpenFile()的函數(shù)原型如下：

GifFileType *DGifOpenFile(unsigned char *addr，

GifFileType *giffile，GifFilePrivateType *gifprivate);

其中：addr為內(nèi)存地址；giffile和gifprivate為原庫(kù)中聲明的數(shù)據(jù)類型；giffile可視為文件操作指針。之后，所有的解碼操作都維持與原文件中的流程和接口一致。

2．2動(dòng)畫(huà)顯示及內(nèi)核加載

為了減少系統(tǒng)的啟動(dòng)時(shí)間，Bootloader在顯示GIF動(dòng)畫(huà)的同時(shí)，從flash上讀取內(nèi)核代碼到內(nèi)存中。讀flash的延遲可用做GIF動(dòng)畫(huà)的幀間間隔，因此，GIF本身的幀間間隔屬性可以忽略。從整體上看，在顯示開(kāi)機(jī)動(dòng)畫(huà)的同時(shí)，Bootloader完成了內(nèi)核的加載工作。該過(guò)程的偽代碼如下：

[第一步，初始化LCD控制器、背光和幀緩沖區(qū)];

[第二步，從flash中將GIF文件加載到內(nèi)存地址addr處]

/* 第三步，從內(nèi)存中“打開(kāi)”文件 */

DGifOpenFile((unsigned char *)addr， GifFile， Private);

/* 第四步，一邊解碼、顯示GIF圖像，一邊加載內(nèi)核 */

do {

DGifGetRecordType(GifFile， RecordType);

switch (RecordType) {

case IMAGE_DESC_RECORD_TYPE:

[讀取并解碼一幀圖像到幀緩沖區(qū)中];

[將緩沖區(qū)中的圖像顯示到LCD上];

[(如果內(nèi)核沒(méi)有加載完)從flash上讀取一段內(nèi)核代碼到指定內(nèi)存地址處];break;

case EXTENSION_RECORD_TYPE:

[跳過(guò)全部擴(kuò)展塊];

break;

case TERMINATE_RECORD_TYPE:

default:

break;

}

} while (RecordType != TERMINATE_RECORD_TYPE);

[第五步，如果內(nèi)核沒(méi)有加載完，將剩余內(nèi)核代碼加載到內(nèi)存中];

[第六步，從內(nèi)存地址0x00008000處執(zhí)行，啟動(dòng)內(nèi)核];

3充電管理

當(dāng)用戶在系統(tǒng)關(guān)機(jī)狀態(tài)下接入電源適配器或充電數(shù)據(jù)線時(shí)，系統(tǒng)會(huì)自動(dòng)開(kāi)機(jī)，啟動(dòng)Bootloader。Bootloader檢測(cè)到存在充電源且開(kāi)機(jī)鍵沒(méi)有被按下，進(jìn)入圖1中的充電流程。Bootloader中的充電管理模塊主要負(fù)責(zé)三個(gè)任務(wù)，包括充電界面顯示、電池電量測(cè)量和用戶操作響應(yīng)。

3．1關(guān)機(jī)狀態(tài)下的充電界面

充電界面主要是給用戶明確的提示，充電是否在進(jìn)行以及是否已經(jīng)充滿。Bootloader通過(guò)在屏幕上顯示一個(gè)分格滾動(dòng)的電量條，向用戶表示系統(tǒng)正在充電。在充電結(jié)束后，電量條停止?jié)L動(dòng)，設(shè)置為滿格。

3．2電池電量測(cè)量

為了判斷電池是否已充滿，需要檢測(cè)電池電量。通常，可以檢測(cè)電池電壓或充電電流，當(dāng)電池電壓高于某一閾值或充電電流低于某一閾值，并超過(guò)一定時(shí)限時(shí)，則可判定電池電量滿，充電過(guò)程結(jié)束。具體的數(shù)值需要結(jié)合電池電芯的充放電特性曲線來(lái)確定。例如TI的TSC2101[8]芯片具有電壓檢測(cè)功能，電壓采樣后保存在TSC2101的BAT寄存器中，通過(guò)如下公式計(jì)算得到電池的實(shí)際電壓值：

VBAT=B/2N×5×VREF

其中：VREF采用內(nèi)部參考電壓為1.25 V；N為控制精度；B為BAT寄存器讀數(shù)。

判斷電池充電結(jié)束還可以采用另外一種方法，即檢測(cè)電源管理芯片的狀態(tài)寄存器，充電結(jié)束時(shí)，相應(yīng)的狀態(tài)位會(huì)置位。但是否可以采用此方法，需要參考特定的硬件設(shè)計(jì)。

此外，在系統(tǒng)啟動(dòng)的初始階段，Bootloader應(yīng)該檢測(cè)當(dāng)前的電池電量。如果電池電量低，提示用戶及時(shí)充電；如果電量過(guò)低，在給出用戶提示后應(yīng)自動(dòng)關(guān)機(jī)，以保護(hù)電池。

3．3響應(yīng)用戶操作

在充電過(guò)程中，需要對(duì)用戶操作進(jìn)行響應(yīng)。如果用戶按下開(kāi)機(jī)鍵，則顯示開(kāi)機(jī)動(dòng)畫(huà)，并加載操作系統(tǒng)內(nèi)核，完成開(kāi)機(jī)操作。該過(guò)程等同于用戶按開(kāi)機(jī)鍵開(kāi)機(jī)，從實(shí)現(xiàn)的角度，就是跳轉(zhuǎn)到圖1中正常開(kāi)機(jī)的流程。如果用戶撥出了電源適配器或充電線，則終止充電界面，執(zhí)行系統(tǒng)關(guān)機(jī)操作。

4文件下載

4．1下載方案設(shè)計(jì)

結(jié)合常見(jiàn)的USB設(shè)備的應(yīng)用方式、實(shí)現(xiàn)復(fù)雜度和使用的方便性，CrystalBoot采用USB NET方式實(shí)現(xiàn)文件下載功能。具體地說(shuō)，在主機(jī)端（PC機(jī)）通過(guò)驅(qū)動(dòng)程序?qū)⒃O(shè)備端（移動(dòng)終端）模擬成網(wǎng)絡(luò)設(shè)備，當(dāng)做以太網(wǎng)卡使用；在設(shè)備端實(shí)現(xiàn)USB數(shù)據(jù)傳輸、以太網(wǎng)組幀及上層網(wǎng)絡(luò)協(xié)議的解析工作，這樣雙方就可以使用標(biāo)準(zhǔn)的網(wǎng)絡(luò)協(xié)議和服務(wù)進(jìn)行通信。開(kāi)源社區(qū)已經(jīng)提供了內(nèi)核補(bǔ)丁[11]，只需要進(jìn)行簡(jiǎn)單的修改和配置即可。主機(jī)端USB驅(qū)動(dòng)的開(kāi)發(fā)工作量很小。為實(shí)現(xiàn)下載功能，設(shè)備端不用開(kāi)發(fā)完整的網(wǎng)絡(luò)協(xié)議棧，只要支持一種簡(jiǎn)單的文件傳輸協(xié)議TFTP。

在開(kāi)始文件傳輸之前，需要對(duì)USB接口進(jìn)行初始化，并對(duì)其各種描述符進(jìn)行配置，如表1所示。此處需要注意的是，CrystalBoot中的設(shè)置必須保證與主機(jī)USB驅(qū)動(dòng)中的設(shè)置一致，以便雙方可以正常通信。

使用時(shí)，在CrystalBoot啟動(dòng)過(guò)程中通過(guò)串口終端使其進(jìn)入交互模式（圖1），然后輸入文件下載命令（4.4節(jié)將介紹命令格式），將執(zhí)行如下操作：

a)根據(jù)命令行中傳遞的文件名，發(fā)出TFTP讀請(qǐng)求包；

b)以輪詢方式響應(yīng)USB設(shè)備控制器的EPn_RX中斷，接收USB數(shù)據(jù)，并將接收的數(shù)據(jù)重組成以太網(wǎng)的數(shù)據(jù)幀；

c)對(duì)以太網(wǎng)數(shù)據(jù)幀進(jìn)行CRC校驗(yàn)，如果通過(guò)，則將其作為一個(gè)有效的TFTP數(shù)據(jù)包接收，并發(fā)送TFTP確認(rèn)包；

d)重復(fù)過(guò)程b)和c)，直到收到一個(gè)實(shí)際數(shù)據(jù)小于512 Byte的TFTP數(shù)據(jù)包，表明已經(jīng)接收到最后一個(gè)數(shù)據(jù)包，文件下載結(jié)束。

4．2中斷處理

USB硬件配置和數(shù)據(jù)傳輸是通過(guò)響應(yīng)USB設(shè)備控制器的中斷請(qǐng)求來(lái)實(shí)現(xiàn)的。由于Bootloader中不支持中斷，改用輪詢方式，通過(guò)循環(huán)讀取OMAP的USB設(shè)備控制器的中斷源寄存器（IRQ_SRC），判斷是否有相應(yīng)的事件產(chǎn)生。如果有，則轉(zhuǎn)入與之對(duì)應(yīng)的中斷處理例程中去處理。處理流程偽碼如下：



if (有中斷事件產(chǎn)生，即寄存器IRQ_SRC的值為非0) {

if (IRQ_SRC.DS_CHG置位) {

//設(shè)備狀態(tài)轉(zhuǎn)移中斷處理函數(shù)

USB Device State Changed Interrupt Handler;

} else if (IRQ_SRC.EP0_RX置位) {

//控制端點(diǎn)接收中斷處理函數(shù)

Endpoint 0 RX Interrupt Handler;

} else if (IRQ_SRC.EP0_TX置位) {

//控制端點(diǎn)發(fā)送中斷處理函數(shù)

Endpoint 0 TX Interrupt Handler;

} else if (IRQ_SRC.SETUP置位) {

//配置中斷處理函數(shù)

Setup Interrupt Handler;

} else if (IRQ_SRC.EPn_RX置位) {

//數(shù)據(jù)接收端點(diǎn)中斷處理函數(shù)

Non－Isochronous Non－Control Endpoint

Receive Interrupt Handler;

} else if (IRQ_SRC.EPn_TX置位) {

//數(shù)據(jù)發(fā)送端點(diǎn)中斷處理函數(shù)

Non－Isochronous Non－Control Endpoint

Transmit Interrupt Handler;

}

}

4．3組幀和TFTP解析

USB數(shù)據(jù)傳輸端點(diǎn)的類型定義為BULK方式，一次傳輸?shù)淖畲髷?shù)據(jù)包大小為64 Byte，而主機(jī)端以太網(wǎng)的MTU定義為1 500 Byte，兩者不一致。向主機(jī)發(fā)送TFTP讀請(qǐng)求和TFTP確認(rèn)等數(shù)據(jù)報(bào)文時(shí)，將其封裝成以太網(wǎng)數(shù)據(jù)幀，添加CRC數(shù)據(jù)，之后將封裝好的數(shù)據(jù)幀分割成多個(gè)USB請(qǐng)求塊（URB）發(fā)送；反之，從主機(jī)接收數(shù)據(jù)時(shí)需進(jìn)行多次USB數(shù)據(jù)接收操作得到一個(gè)完整的數(shù)據(jù)幀，之后再對(duì)其進(jìn)行校驗(yàn)和上層協(xié)議解析，得到TFTP數(shù)據(jù)包。模擬以太網(wǎng)數(shù)據(jù)封裝操作是實(shí)現(xiàn)USB NET文件下載功能的核心步驟。

CrystalBoot采用TFTP作為文件傳輸協(xié)議。一個(gè)有效的TFTP數(shù)據(jù)幀包含有MAC頭、IP頭、UDP頭、TFTP頭、TFTP數(shù)據(jù)以及CRC校驗(yàn)值。其協(xié)議數(shù)據(jù)單元（PDU）格式如圖2所示（括號(hào)中的數(shù)字表示占用字節(jié)數(shù)）。其中，TFTP頭中兩字節(jié)的操作碼指出了五種包類型之一：讀請(qǐng)求（RRQ，1）、寫(xiě)請(qǐng)求（WRQ，2）、數(shù)據(jù)包（DATA，3）、確認(rèn)包（ACK，4）和差錯(cuò)包（ERROR，5）。在明確TFTP的PDU格式后，可以在USB請(qǐng)求塊與TFTP數(shù)據(jù)包之間進(jìn)行格式轉(zhuǎn)換，通過(guò)USB進(jìn)行文件下載。

4．4命令行接口

Bootloader中添加usbload命令，以支持文件下載。該命令的使用格式為

usbload loadAddress loadFilename

其中：loadAddress為內(nèi)存地址；loadFilename為存放在主機(jī)端TFTP服務(wù)器上要下載的文件名稱。

在Bootloader啟動(dòng)過(guò)程中，如果接收到串口中斷，則進(jìn)入交互模式，見(jiàn)圖1。之后可以通過(guò)串口終端輸入usbload命令，下載所需的操作系統(tǒng)內(nèi)核或文件系統(tǒng)映像到內(nèi)存中，直接運(yùn)行調(diào)試或燒寫(xiě)到flash存儲(chǔ)器上。

4．5主機(jī)端USB驅(qū)動(dòng)

主機(jī)端的USB驅(qū)動(dòng)來(lái)自開(kāi)源社區(qū)的USBDNET[11]內(nèi)核補(bǔ)丁。該驅(qū)動(dòng)模塊在初始化過(guò)程中向系統(tǒng)內(nèi)核注冊(cè)USB設(shè)備，通過(guò)id_table數(shù)據(jù)結(jié)構(gòu)識(shí)別要管理的USB設(shè)備。只要保證源文件usbdnet.c中的id_table和Bootloader中提供的描述符信息一致，主機(jī)端就可以正確檢測(cè)到終端設(shè)備并與之通信。具體的修改如下：

#define VENDOR_ID 0xCCAA//廠商ID

#define PRODUCT_ID 0xCCDD//產(chǎn)品ID

#define CDC_DEVICE_CLASS 0x02//通信設(shè)備類

#define DEVICE_CLASS CDC_DEVICE_CLASS

#define INTERFACE_CLASS 0xff//自定義接口類

#define INTERFACE_SUBCLASS 0x02//接口子類

static __devinitdata struct usb_device_id id_table[]={

// 廠商ID，產(chǎn)品ID，設(shè)備類，接口類，接口子類

{MY_USB_DEVICE(VENDOR_ID， PRODUCT_ID， DEVICE_CLASS，

INTERFACE_CLASS，INTERFACE_SUBCLASS)}，

{ } //termination entry

};

完成上述修改后，重新編譯得到USBDNET驅(qū)動(dòng)模塊。當(dāng)移動(dòng)終端通過(guò)USB線與主機(jī)連接時(shí)，主機(jī)自動(dòng)加載驅(qū)動(dòng)并完成網(wǎng)絡(luò)配置，通過(guò)串口終端執(zhí)行usbload命令即可從主機(jī)下載文件到指定內(nèi)存區(qū)域中。經(jīng)測(cè)試，USB下載功能穩(wěn)定，有效下載速率為1.7 Mbps，滿足了開(kāi)發(fā)人員的工作需求。

5結(jié)束語(yǔ)

本文通過(guò)擴(kuò)充Bootloader的基本功能，設(shè)計(jì)和開(kāi)發(fā)了CrystalBoot，構(gòu)造了一個(gè)操作系統(tǒng)加載前的運(yùn)行環(huán)境，更為方便、快捷地響應(yīng)用戶的開(kāi)機(jī)、充電操作。USB下載系統(tǒng)既可以用于開(kāi)發(fā)階段的下載調(diào)試，也可以用于產(chǎn)品階段的系統(tǒng)軟件升級(jí)。隨著移動(dòng)終端的功能越來(lái)越豐富，其系統(tǒng)軟件的規(guī)模和復(fù)雜性也越來(lái)越高，通過(guò)在Bootloader與操作系統(tǒng)之間進(jìn)行合理的功能劃分，使兩者相互配合，可以有效地改善系統(tǒng)整體性能和用戶體驗(yàn)，提高產(chǎn)品的競(jìng)爭(zhēng)力。

參考文獻(xiàn)：

［1］詹榮開(kāi).嵌入式系統(tǒng)Bootloader技術(shù)內(nèi)幕［EB/OL］. (2004－05). http://www.ibm.com/developerworks/cn/linux/l－btloader/index.html.

［2］馬學(xué)文，朱名日，程小輝.嵌入式系統(tǒng)中Bootloader的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)工程，2005，31(7):96－97，196.

［3］Das U－Boot project［EB/OL］. (2004－05). http://sourceforge.net/ projects/u－boot.

［4］The DENX U－Boot and Linux guide (DULG) for TQM8xxL[EB/OL]. (2007－05). http://www.denx.de/wiki/bin/view/DULG/Manual.

［5］OMAP1610 multimedia processor technical reference manual，SWPU062C[R]. [S.l.]: Texas Instruments，2003.

［6］CompuServe Incorporated.Graphics interchange format(sm) version 89a(modified)[S]. 1995.

［7］Libungif Project［EB/OL］. (2004－08). http://sourceforge.net/ projects/Libungif.

［8］TSC2101 data manual，SLAS392B[R]. [S.l.]: Texas Instruments，2004.

［9］Compaq， Intel， Microsoft， et al. Universal serial bus specification (reversion 1.1)[S].1998.

［10］SOLLINS K. RFC1350， The TFTP Protocol(revision 2)[S]. IETF，1992.

［11］Linux USBDNET kernel patch[EB/OL]. (2004－11). http://www.ruault.com/ Zaurus/atches/usbdnet－2.4.20－patch.gz.

注：本文中所涉及到的圖表、注解、公式等內(nèi)容請(qǐng)以PDF格式閱讀原文