基于VxWorks的bootrom代碼改進(jìn)

關(guān)鍵詞：VxWorks bootrom BSP makefile

1 問題的提出

VxWorks是Wind River公司開發(fā)的一種嵌入式操作系統(tǒng)，具有強(qiáng)大的功能和友好的用戶界面。VxWorks軟件應(yīng)用非常廣泛，不僅應(yīng)用在網(wǎng)絡(luò)設(shè)備、家用電器當(dāng)中，而且還應(yīng)用在航天、導(dǎo)彈等高端領(lǐng)域。在網(wǎng)絡(luò)設(shè)備應(yīng)用領(lǐng)域中，通常利用VxWorks來開發(fā)bootrom代碼、BSP（Boadr Support Packet）代碼以及上層的網(wǎng)絡(luò)協(xié)議代碼。

通常，Bootrom軟件有以下功能：①通過串口下載操作系統(tǒng)映像；②通過串口升級自身映像；③通過串口下載系統(tǒng)配置文件、系統(tǒng)信息文件；④加載操作系統(tǒng)映像，使其正常啟動；⑤其它的輔助功能，如地址內(nèi)容查看功能、址內(nèi)容修改功能和bootrom菜單顯示信息控制的功能等。對于通常的bootrom代碼編譯，大多數(shù)用戶選擇使用GNU make的DOS命令來進(jìn)行。因為如果bootrom不提供網(wǎng)口功能的話，單純的CPU驅(qū)動部分代碼量是不大的；但如果提供網(wǎng)口功能的話，代碼量相對較大，文件之間的內(nèi)在關(guān)系比較復(fù)雜，因此，系統(tǒng)使用GNU make的DOS命令來編譯生成bootrom就顯得有點麻煩。Makefile文件主要是由“目標(biāo)”（target）、“依賴性”（dependencies）和“動作”組成的一系列規(guī)則，而VxWorks提供的GNU make工具就是根據(jù)Makefile指定的規(guī)則來編譯和鏈接程序的。Makefile基本結(jié)構(gòu)雖然簡單，但正確、靈活地運(yùn)用這些規(guī)則并不是那么輕松的事情。即使根據(jù)GNU Makefile規(guī)則書寫出適當(dāng)?shù)腗akefile文件，但隨著代碼的改變，Makefile還需要經(jīng)常修改，這就增加了BSP開發(fā)人員的負(fù)擔(dān)。而且，對于交換產(chǎn)品而言，其成本控制是非常嚴(yán)格的。對于存放bootrom軟件的Flash來說，通常要求大小為512KB，這樣就需要考慮到容量的限制。

因此，必須使用新的方法來簡化bootrom代碼編譯，而且要在保證提供網(wǎng)口功能的情況下，系統(tǒng)提供的bootrom軟件小于512KB。

2 實現(xiàn)方法

2.1 通過建立工程生成bootrom映像

采用建立工程的方式可以有效地解決這個問題。首先依據(jù)bootrom中的BSP代碼來新建一個工程，然后將網(wǎng)中驅(qū)動代碼加入到建好的工程中。這樣就可以通過編譯工程實現(xiàn)帶有網(wǎng)口下載功能的bootrom軟件。但對于VxWorks嵌入式系統(tǒng)而言，它有自己一套規(guī)范，求bootrom軟件在加電后必須從romInit（）函數(shù)開始運(yùn)行，而建立工程所得的入口函數(shù)為sysInit()。因此需要增加一個系統(tǒng)殼代碼，這個殼代碼所要完成的任務(wù)就是加載bootrom工程的映像，并從romInit（）開始執(zhí)行bootrom代碼。通過建立工程來調(diào)試bootrom代碼有以下優(yōu)點。

（1）責(zé)任分明

開發(fā)產(chǎn)品是一個復(fù)雜的工程，需要多人合作完成。對于CPU子系統(tǒng)和網(wǎng)口驅(qū)動系統(tǒng)這兩塊內(nèi)容來說，更需要責(zé)任明確。通過建立工程來調(diào)試代碼，可以準(zhǔn)確地定位錯誤文件和函數(shù)的位置。是BSP代碼出現(xiàn)問題，還是網(wǎng)口驅(qū)動代碼出現(xiàn)問題，可以一目了然，做到責(zé)任明確。

（2）提高效率

通過建立工程可以節(jié)省書寫Makefile文件時間，并可以讓VxWorks軟件的友好圖形界面這優(yōu)點得到更好的體現(xiàn)。另外，建立工程也可以減少文件編譯排錯的難度，方便工程文件的調(diào)試以及功能的驗證，從而大大提高工作效率，加快工作進(jìn)度。

2.2 編寫殼代碼并實現(xiàn)加載

建立工程生成映像文件的入口函數(shù)為sysInit（），而VxWorks規(guī)范中要求系統(tǒng)加電后要從romInit（）函數(shù)開始運(yùn)行。因此，需要設(shè)計一個方案來加載編譯工程得到的映像，而且要具備初始化CPU和SDRAM存儲空間的功能。

首先，系統(tǒng)從romInit（）函數(shù)中開始運(yùn)行，完成CPU和SDRAM初始化，跳轉(zhuǎn)到函數(shù)romStart()運(yùn)行。然后，加載第二份bootrom代碼到系統(tǒng)的低地址處，運(yùn)行殼代碼中的sysInit（）函數(shù)，并調(diào)用自己構(gòu)造的解壓函數(shù)usrInit（），將壓縮后的工程映像文件解壓縮到系統(tǒng)高地址處，之后系統(tǒng)繼續(xù)運(yùn)行解壓后的bootrom代碼。此時，系統(tǒng)開始運(yùn)行sysInit（）函數(shù)，調(diào)用VxWorks系統(tǒng)中的usrInit（）函數(shù)，開始初始化系統(tǒng)硬件、內(nèi)核以及其它外圍設(shè)備。

殼函數(shù)usrInit（）代碼如下：

void usrInit（void）{

volatile FUNCPTR absEntry;

if(inflate((UCHAR*)ROM_OFFSET(_binArrayStart),

(UCHAR *)（RAM_LOW_ADRS），_binArrayEndbinArrayStart)!=OK)

return;

absEntry=(FUNCPTR)(RAM_LOW_ADRS);

(absEntry)();

}

其中RAM_LOW_ADRS為系統(tǒng)低地址，是操作系統(tǒng)運(yùn)行的起始地址，但bootrom可以利用低地址來實現(xiàn)在系統(tǒng)高地址的運(yùn)行。宏ROM_OFFSET用于準(zhǔn)確定位函數(shù)地址，因為bootrom中運(yùn)行的代碼要求以相對地址方式來尋址，而不能以絕對地址方式尋址。_binArrayStart為壓縮后二進(jìn)制代碼的開始符，_binArrayEnd為壓縮后二進(jìn)制代碼的結(jié)束符。Inflate()是VxWorks軟件的解壓縮函數(shù)，用于解壓縮由deflate()壓縮函數(shù)壓縮的二進(jìn)制文件映像。同時，需要將下述代碼添加到編譯規(guī)則文件rules.vxWorks中的相應(yīng)部分：

$（CC）-c $(CFLAGS)$(BSP_DIR)/unzip.c-o$(BSP_DIR)/unzip.o

$(LD)$(LDFLAGS)-e sysInit -Ttext $(RAM_LOW_ADRS)o

unzip_obj.o sysALib.o $(BSP_DIR)/unzip.o $(LIBS)flex.z.o

其中，unzip.c中包含構(gòu)造的殼函數(shù)usrInit（）。SysInit()為解壓軟件入口函數(shù)。上述語句的功能：第一行完成殼文件的編譯，第二、三行完成殼目標(biāo)代碼與第二份bootrom代碼的鏈接。這樣，一個具有解壓功能的殼函數(shù)就被鏈接到第二份bootrom映像中了。

圖1、圖2是修改前的系統(tǒng)運(yùn)行方式與修改后系統(tǒng)運(yùn)行方式比較。

通過這兩種方式的比較可以看出，修改前系統(tǒng)運(yùn)行式與修改后的運(yùn)行方式有下面兩點差異；①第一份bootrom啟動后，前者存在解壓縮自射映像的操作，而后者沒有；②對于第二份bootrom，前者沒有殼代碼，而后者有。

2.3 縮減文件長度

通常第一份bootrom代碼只有兩個文件，一個是包含CPU和SDRAM初始化文件romInit.s，另外就是包含romStart()函數(shù)的bootInit.c文件。另外，根據(jù)需要還可以添加提供串口輪詢顯示功能的文件。對于第一份bootrom代碼，通常只有10KB左右（這是針對系統(tǒng)修改后的方式），而對于包含殼函數(shù)代碼的，通過建立工程并編譯而生成的第二份bootrom比較大，通常為570KB左右。（注意：這幾個數(shù)值是通過特定的產(chǎn)品來得出的結(jié)論，并不應(yīng)用于所有產(chǎn)品，但遇到類似的情況可以借鑒處理。）而其后面的一部分完全是0，可以考慮去掉這些0，但不能影響軟件的功能。經(jīng)過測試得出結(jié)論：去掉后面的0對系統(tǒng)功能和性能沒有任何影響。

通過文件的操作來實現(xiàn)兩份bootrom合并，合并后的大小要求小于或等于512KB。如果不采用任何措施，直接將兩個文件合并起來要在580KB左右，大于512KB，這是很多系統(tǒng)不能滿足的。第二份bootrom映像的后面部分的內(nèi)容類似表1所列的信息。

表1 bootrom映像部分二進(jìn)制內(nèi)容

從表1可以看出，在地址0x00078233處就是0值了。這樣可以通過對文件內(nèi)容的操作將0x00078240后面的內(nèi)容全部剔除，從而可將合并后的bootrom代碼控制在512KB以內(nèi)。當(dāng)然，我們通常會選擇一個整數(shù)值進(jìn)行操作，即將0x0007824后的所有值去掉即可。

這樣處理，可以減少維護(hù)和開發(fā)的工作量。如果按照以往的做法，bootrom軟件對外將有第一份和第二份的區(qū)別，無論是生產(chǎn)、上層軟件調(diào)試還是開發(fā)，都需要分別對待，這樣維護(hù)量和開發(fā)量將會加大。而經(jīng)過修改后，可把區(qū)別只控制在開發(fā)階段，在線升級時，可以按照一個軟件來通過串口或網(wǎng)口來進(jìn)行升級。通過對bootrom最后生成文件大小的控制，可以簡化生產(chǎn)流程，加快生產(chǎn)進(jìn)度。

3 小結(jié)

在嵌入式操作系統(tǒng)中進(jìn)行程序開發(fā)，需要經(jīng)常開辟新的思路，以一些簡單的實現(xiàn)方式代替復(fù)雜易錯的方式。在本次產(chǎn)品開發(fā)過程中，將bootrom映像生成方式由慣用的GNU make命令行實現(xiàn)，修改為按照新建工程的方式來實現(xiàn)，是一個相對好的方法，對整個產(chǎn)品的后續(xù)批量生產(chǎn)、用戶維護(hù)和后續(xù)開發(fā)都奠定了一個良好的基礎(chǔ)。