關鍵詞：VxWorks bootrom BSP makefile
1 問題的提出
VxWorks是Wind River公司開發(fā)的一種嵌入式操作系統(tǒng)，具有強大的功能和友好的用戶界面。VxWorks軟件應用非常廣泛，不僅應用在網(wǎng)絡設備、家用電器當中，而且還應用在航天、導彈等高端領域。在網(wǎng)絡設備應用領域中，通常利用VxWorks來開發(fā)bootrom代碼、BSP（Boadr Support Packet）代碼以及上層的網(wǎng)絡協(xié)議代碼。
通常，Bootrom軟件有以下功能：①通過串口下載操作系統(tǒng)映像；②通過串口升級自身映像；③通過串口下載系統(tǒng)配置文件、系統(tǒng)信息文件；④加載操作系統(tǒng)映像，使其正常啟動；⑤其它的輔助功能，如地址內(nèi)容查看功能、址內(nèi)容修改功能和bootrom菜單顯示信息控制的功能等。對于通常的bootrom代碼編譯，大多數(shù)用戶選擇使用GNU make的DOS命令來進行。因為如果bootrom不提供網(wǎng)口功能的話，單純的CPU驅(qū)動部分代碼量是不大的；但如果提供網(wǎng)口功能的話，代碼量相對較大，文件之間的內(nèi)在關系比較復雜，因此，系統(tǒng)使用GNU make的DOS命令來編譯生成bootrom就顯得有點麻煩。Makefile文件主要是由“目標”（target）、“依賴性”（dependencies）和“動作”組成的一系列規(guī)則，而VxWorks提供的GNU make工具就是根據(jù)Makefile指定的規(guī)則來編譯和鏈接程序的。Makefile基本結(jié)構(gòu)雖然簡單，但正確、靈活地運用這些規(guī)則并不是那么輕松的事情。即使根據(jù)GNU Makefile規(guī)則書寫出適當?shù)腗akefile文件，但隨著代碼的改變，Makefile還需要經(jīng)常修改，這就增加了BSP開發(fā)人員的負擔。而且，對于交換產(chǎ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ù)開始運行，而建立工程所得的入口函數(shù)為sysInit()。因此需要增加一個系統(tǒng)殼代碼，這個殼代碼所要完成的任務就是加載bootrom工程的映像，并從romInit（）開始執(zhí)行bootrom代碼。通過建立工程來調(diào)試bootrom代碼有以下優(yōu)點。
（1）責任分明
開發(fā)產(chǎn)品是一個復雜的工程，需要多人合作完成。對于CPU子系統(tǒng)和網(wǎng)口驅(qū)動系統(tǒng)這兩塊內(nèi)容來說，更需要責任明確。通過建立工程來調(diào)試代碼，可以準確地定位錯誤文件和函數(shù)的位置。是BSP代碼出現(xiàn)問題，還是網(wǎng)口驅(qū)動代碼出現(xiàn)問題，可以一目了然，做到責任明確。
（2）提高效率
通過建立工程可以節(jié)省書寫Makefile文件時間，并可以讓VxWorks軟件的友好圖形界面這優(yōu)點得到更好的體現(xiàn)。另外，建立工程也可以減少文件編譯排錯的難度，方便工程文件的調(diào)試以及功能的驗證，從而大大提高工作效率，加快工作進度。
2.2 編寫殼代碼并實現(xiàn)加載
建立工程生成映像文件的入口函數(shù)為sysInit（），而VxWorks規(guī)范中要求系統(tǒng)加電后要從romInit（）函數(shù)開始運行。因此，需要設計一個方案來加載編譯工程得到的映像，而且要具備初始化CPU和SDRAM存儲空間的功能。
首先，系統(tǒng)從romInit（）函數(shù)中開始運行，完成CPU和SDRAM初始化，跳轉(zhuǎn)到函數(shù)romStart()運行。然后，加載第二份bootrom代碼到系統(tǒng)的低地址處，運行殼代碼中的sysInit（）函數(shù)，并調(diào)用自己構(gòu)造的解壓函數(shù)usrInit（），將壓縮后的工程映像文件解壓縮到系統(tǒng)高地址處，之后系統(tǒng)繼續(xù)運行解壓后的bootrom代碼。此時，系統(tǒng)開始運行sysInit（）函數(shù)，調(diào)用VxWorks系統(tǒng)中的usrInit（）函數(shù)，開始初始化系統(tǒng)硬件、內(nèi)核以及其它外圍設備。
殼函數(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)運行的起始地址，但bootrom可以利用低地址來實現(xiàn)在系統(tǒng)高地址的運行。宏ROM_OFFSET用于準確定位函數(shù)地址，因為bootrom中運行的代碼要求以相對地址方式來尋址，而不能以絕對地址方式尋址。_binArrayStart為壓縮后二進制代碼的開始符，_binArrayEnd為壓縮后二進制代碼的結(jié)束符。Inflate()是VxWorks軟件的解壓縮函數(shù)，用于解壓縮由deflate()壓縮函數(shù)壓縮的二進制文件映像。同時，需要將下述代碼添加到編譯規(guī)則文件rules.vxWorks中的相應部分：
$（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ù)。上述語句的功能：第一行完成殼文件的編譯，第二、三行完成殼目標代碼與第二份bootrom代碼的鏈接。這樣，一個具有解壓功能的殼函數(shù)就被鏈接到第二份bootrom映像中了。
圖1、圖2是修改前的系統(tǒng)運行方式與修改后系統(tǒng)運行方式比較。
通過這兩種方式的比較可以看出，修改前系統(tǒng)運行式與修改后的運行方式有下面兩點差異；①第一份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é)論，并不應用于所有產(chǎn)品，但遇到類似的情況可以借鑒處理。）而其后面的一部分完全是0，可以考慮去掉這些0，但不能影響軟件的功能。經(jīng)過測試得出結(jié)論：去掉后面的0對系統(tǒng)功能和性能沒有任何影響。
通過文件的操作來實現(xiàn)兩份bootrom合并，合并后的大小要求小于或等于512KB。如果不采用任何措施，直接將兩個文件合并起來要在580KB左右，大于512KB，這是很多系統(tǒng)不能滿足的。第二份bootrom映像的后面部分的內(nèi)容類似表1所列的信息。
表1 bootrom映像部分二進制內(nèi)容
| 000 | 210h | EB | E2 | BD | 95 | BD | 15 | 87 | AE | 3C | 74 | FD | 5C | 5F | 6A | FD | 8B |
| 000 | 220h | D6 | BD | 3A | EB | FF | 6F | CF | 2A | D2 | 69 | 95 | E9 | 34 | AE | E7 | EF |
| 000 | 230h | 86 | 94 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 |
| 000 | 240h | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 |
| 000 | 250h | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 |
從表1可以看出，在地址0x00078233處就是0值了。這樣可以通過對文件內(nèi)容的操作將0x00078240后面的內(nèi)容全部剔除，從而可將合并后的bootrom代碼控制在512KB以內(nèi)。當然，我們通常會選擇一個整數(shù)值進行操作，即將0x0007824后的所有值去掉即可。
這樣處理，可以減少維護和開發(fā)的工作量。如果按照以往的做法，bootrom軟件對外將有第一份和第二份的區(qū)別，無論是生產(chǎn)、上層軟件調(diào)試還是開發(fā)，都需要分別對待，這樣維護量和開發(fā)量將會加大。而經(jīng)過修改后，可把區(qū)別只控制在開發(fā)階段，在線升級時，可以按照一個軟件來通過串口或網(wǎng)口來進行升級。通過對bootrom最后生成文件大小的控制，可以簡化生產(chǎn)流程，加快生產(chǎn)進度。
3 小結(jié)
在嵌入式操作系統(tǒng)中進行程序開發(fā)，需要經(jīng)常開辟新的思路，以一些簡單的實現(xiàn)方式代替復雜易錯的方式。在本次產(chǎn)品開發(fā)過程中，將bootrom映像生成方式由慣用的GNU make命令行實現(xiàn)，修改為按照新建工程的方式來實現(xiàn)，是一個相對好的方法，對整個產(chǎn)品的后續(xù)批量生產(chǎn)、用戶維護和后續(xù)開發(fā)都奠定了一個良好的基礎。
下載文檔
