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

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

1 問(wèn)題的提出

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

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

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

2 實(shí)現方法

2.1 通過(guò)建立工程生成bootrom映像

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

（1）責任分明

開(kāi)發(fā)產(chǎn)品是一個(gè)復雜的工程，需要多人合作完成。對于CPU子系統和網(wǎng)口驅動(dòng)系統這兩塊內容來(lái)說(shuō)，更需要責任明確。通過(guò)建立工程來(lái)調試代碼，可以準確地定位錯誤文件和函數的位置。是BSP代碼出現問(wèn)題，還是網(wǎng)口驅動(dòng)代碼出現問(wèn)題，可以一目了然，做到責任明確。

（2）提高效率

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

2.2 編寫(xiě)殼代碼并實(shí)現加載

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

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

殼函數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為系統低地址，是操作系統運行的起始地址，但bootrom可以利用低地址來(lái)實(shí)現在系統高地址的運行。宏ROM_OFFSET用于準確定位函數地址，因為bootrom中運行的代碼要求以相對地址方式來(lái)尋址，而不能以絕對地址方式尋址。_binArrayStart為壓縮后二進(jìn)制代碼的開(kāi)始符，_binArrayEnd為壓縮后二進(jìn)制代碼的結束符。Inflate()是VxWorks軟件的解壓縮函數，用于解壓縮由deflate()壓縮函數壓縮的二進(jìn)制文件映像。同時(shí)，需要將下述代碼添加到編譯規則文件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中包含構造的殼函數usrInit（）。SysInit()為解壓軟件入口函數。上述語(yǔ)句的功能：第一行完成殼文件的編譯，第二、三行完成殼目標代碼與第二份bootrom代碼的鏈接。這樣，一個(gè)具有解壓功能的殼函數就被鏈接到第二份bootrom映像中了。

圖1、圖2是修改前的系統運行方式與修改后系統運行方式比較。

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

2.3 縮減文件長(cháng)度

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

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

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

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

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

3 小結

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