摘要：在Wind River公司開發(fā)的VxWorks嵌入式操作系統(tǒng)平臺(tái)上，改進(jìn)交換機(jī)產(chǎn)品bootrom軟件的實(shí)現(xiàn)方式;給出實(shí)現(xiàn)方法和改進(jìn)目的，為BSP開發(fā)人員提供一套全新的bootrom實(shí)現(xiàn)方案。 關(guān)鍵詞：VxWorks bootrom BSP makefile 1 問(wèn)題的提出 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來(lái)開發(fā)bootrom代碼、BSP(Boadr Support Packet)代碼以及上層的網(wǎng)絡(luò)協(xié)議代碼。 通常，Bootrom軟件有以下功能：①通過(guò)串口下載操作系統(tǒng)映像;②通過(guò)串口升級(jí)自身映像;③通過(guò)串口下載系統(tǒng)配置文件、系統(tǒng)信息文件;④加載操作系統(tǒng)映像，使其正常啟動(dòng);⑤其它的輔助功能，如地址內(nèi)容查看功能、址內(nèi)容修改功能和bootrom菜單顯示信息控制的功能等。對(duì)于通常的bootrom代碼編譯，大多數(shù)用戶選擇使用GNU make的DOS命令來(lái)進(jìn)行。因?yàn)槿绻鸼ootrom不提供網(wǎng)口功能的話，單純的CPU驅(qū)動(dòng)部分代碼量是不大的;但如果提供網(wǎng)口功能的話，代碼量相對(duì)較大，文件之間的內(nèi)在關(guān)系比較復(fù)雜，因此，系統(tǒng)使用GNU make的DOS命令來(lái)編譯生成bootrom就顯得有點(diǎn)麻煩。Makefile文件主要是由“目標(biāo)”(target)、“依賴性” (dependencies)和“動(dòng)作”組成的一系列規(guī)則，而VxWorks提供的GNU make工具就是根據(jù)Makefile指定的規(guī)則來(lái)編譯和鏈接程序的。Makefile基本結(jié)構(gòu)雖然簡(jiǎn)單，但正確、靈活地運(yùn)用這些規(guī)則并不是那么輕松的事情。即使根據(jù)GNU Makefile規(guī)則書寫出適當(dāng)?shù)腗akefile文件，但隨著代碼的改變，Makefile還需要經(jīng)常修改，這就增加了BSP開發(fā)人員的負(fù)擔(dān)。而且，對(duì)于交換產(chǎn)品而言，其成本控制是非常嚴(yán)格的。對(duì)于存放bootrom軟件的Flash來(lái)說(shuō)，通常要求大小為512KB，這樣就需要考慮到容量的限制。 因此，必須使用新的方法來(lái)簡(jiǎn)化bootrom代碼編譯，而且要在保證提供網(wǎng)口功能的情況下，系統(tǒng)提供的bootrom軟件小于512KB。

2 實(shí)現(xiàn)方法 2.1 通過(guò)建立工程生成bootrom映像 采用建立工程的方式可以有效地解決這個(gè)問(wèn)題。首先依據(jù)bootrom中的BSP代碼來(lái)新建一個(gè)工程，然后將網(wǎng)中驅(qū)動(dòng)代碼加入到建好的工程中。這樣就可以通過(guò)編譯工程實(shí)現(xiàn)帶有網(wǎng)口下載功能的bootrom軟件。但對(duì)于VxWorks嵌入式系統(tǒng)而言，它有自己一套規(guī)范，求bootrom軟件在加電后必須從 romInit()函數(shù)開始運(yùn)行，而建立工程所得的入口函數(shù)為sysInit()。因此需要增加一個(gè)系統(tǒng)殼代碼，這個(gè)殼代碼所要完成的任務(wù)就是加載 bootrom工程的映像，并從romInit()開始執(zhí)行bootrom代碼。通過(guò)建立工程來(lái)調(diào)試bootrom代碼有以下優(yōu)點(diǎn)。 (1)責(zé)任分明 開發(fā)產(chǎn)品是一個(gè)復(fù)雜的工程，需要多人合作完成。對(duì)于CPU子系統(tǒng)和網(wǎng)口驅(qū)動(dòng)系統(tǒng)這兩塊內(nèi)容來(lái)說(shuō)，更需要責(zé)任明確。通過(guò)建立工程來(lái)調(diào)試代碼，可以準(zhǔn)確地定位錯(cuò)誤文件和函數(shù)的位置。是BSP代碼出現(xiàn)問(wèn)題，還是網(wǎng)口驅(qū)動(dòng)代碼出現(xiàn)問(wèn)題，可以一目了然，做到責(zé)任明確。 (2)提高效率 通過(guò)建立工程可以節(jié)省書寫Makefile文件時(shí)間，并可以讓VxWorks軟件的友好圖形界面這優(yōu)點(diǎn)得到更好的體現(xiàn)。另外，建立工程也可以減少文件編譯排錯(cuò)的難度，方便工程文件的調(diào)試以及功能的驗(yàn)證，從而大大提高工作效率，加快工作進(jìn)度。 2.2 編寫殼代碼并實(shí)現(xiàn)加載 建立工程生成映像文件的入口函數(shù)為sysInit()，而VxWorks規(guī)范中要求系統(tǒng)加電后要從romInit()函數(shù)開始運(yùn)行。因此，需要設(shè)計(jì)一個(gè)方案來(lái)加載編譯工程得到的映像，而且要具備初始化CPU和SDRAM存儲(chǔ)空間的功能。 首先，系統(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代碼。此時(shí)，系統(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)，%26;amp;_binArrayEndbinArrayStart)!=OK) return; absEntry=(FUNCPTR)(RAM_LOW_ADRS); (absEntry)(); } 其中RAM_LOW_ADRS為系統(tǒng)低地址，是操作系統(tǒng)運(yùn)行的起始地址，但bootrom可以利用低地址來(lái)實(shí)現(xiàn)在系統(tǒng)高地址的運(yùn)行。宏 ROM_OFFSET用于準(zhǔn)確定位函數(shù)地址，因?yàn)閎ootrom中運(yùn)行的代碼要求以相對(duì)地址方式來(lái)尋址，而不能以絕對(duì)地址方式尋址。 _binArrayStart為壓縮后二進(jìn)制代碼的開始符，_binArrayEnd為壓縮后二進(jìn)制代碼的結(jié)束符。Inflate()是VxWorks軟件的解壓縮函數(shù)，用于解壓縮由deflate()壓縮函數(shù)壓縮的二進(jìn)制文件映像。同時(shí)，需要將下述代碼添加到編譯規(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ù)。上述語(yǔ)句的功能：第一行完成殼文件的編譯，第二、三行完成殼目標(biāo)代碼與第二份bootrom代碼的鏈接。這樣，一個(gè)具有解壓功能的殼函數(shù)就被鏈接到第二份bootrom映像中了。

圖1、圖2是修改前的系統(tǒng)運(yùn)行方式與修改后系統(tǒng)運(yùn)行方式比較。 通過(guò)這兩種方式的比較可以看出，修改前系統(tǒng)運(yùn)行式與修改后的運(yùn)行方式有下面兩點(diǎn)差異;①第一份bootrom啟動(dòng)后，前者存在解壓縮自射映像的操作，而后者沒(méi)有;②對(duì)于第二份bootrom，前者沒(méi)有殼代碼，而后者有。 2.3 縮減文件長(zhǎng)度 通常第一份bootrom代碼只有兩個(gè)文件，一個(gè)是包含CPU和SDRAM初始化文件romInit.s，另外就是包含romStart()函數(shù)的 bootInit.c文件。另外，根據(jù)需要還可以添加提供串口輪詢顯示功能的文件。對(duì)于第一份bootrom代碼，通常只有10KB左右(這是針對(duì)系統(tǒng)修改后的方式)，而對(duì)于包含殼函數(shù)代碼的，通過(guò)建立工程并編譯而生成的第二份bootrom比較大，通常為570KB左右。(注意：這幾個(gè)數(shù)值是通過(guò)特定的產(chǎn)品來(lái)得出的結(jié)論，并不應(yīng)用于所有產(chǎn)品，但遇到類似的情況可以借鑒處理。)而其后面的一部分完全是0，可以考慮去掉這些0，但不能影響軟件的功能。經(jīng)過(guò)測(cè)試得出結(jié)論：去掉后面的0對(duì)系統(tǒng)功能和性能沒(méi)有任何影響。 通過(guò)文件的操作來(lái)實(shí)現(xiàn)兩份bootrom合并，合并后的大小要求小于或等于512KB。如果不采用任何措施，直接將兩個(gè)文件合并起來(lái)要在580KB左右，大于512KB，這是很多系統(tǒng)不能滿足的。第二份bootrom映像的后面部分的內(nèi)容類似表1所列的信息。 表1 bootrom映像部分二進(jìn)制內(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值了。這樣可以通過(guò)對(duì)文件內(nèi)容的操作將0x00078240后面的內(nèi)容全部剔除，從而可將合并后的 bootrom代碼控制在512KB以內(nèi)。當(dāng)然，我們通常會(huì)選擇一個(gè)整數(shù)值進(jìn)行操作，即將0x0007824后的所有值去掉即可。 這樣處理，可以減少維護(hù)和開發(fā)的工作量。如果按照以往的做法，bootrom軟件對(duì)外將有第一份和第二份的區(qū)別，無(wú)論是生產(chǎn)、上層軟件調(diào)試還是開發(fā)，都需要分別對(duì)待，這樣維護(hù)量和開發(fā)量將會(huì)加大。而經(jīng)過(guò)修改后，可把區(qū)別只控制在開發(fā)階段，在線升級(jí)時(shí)，可以按照一個(gè)軟件來(lái)通過(guò)串口或網(wǎng)口來(lái)進(jìn)行升級(jí)。通過(guò)對(duì) bootrom最后生成文件大小的控制，可以簡(jiǎn)化生產(chǎn)流程，加快生產(chǎn)進(jìn)度。 3 小結(jié) 在嵌入式操作系統(tǒng)中進(jìn)行程序開發(fā)，需要經(jīng)常開辟新的思路，以一些簡(jiǎn)單的實(shí)現(xiàn)方式代替復(fù)雜易錯(cuò)的方式。在本次產(chǎn)品開發(fā)過(guò)程中，將bootrom映像生成方式由慣用的GNU make命令行實(shí)現(xiàn)，修改為按照新建工程的方式來(lái)實(shí)現(xiàn)，是一個(gè)相對(duì)好的方法，對(duì)整個(gè)產(chǎn)品的后續(xù)批量生產(chǎn)、用戶維護(hù)和后續(xù)開發(fā)都奠定了一個(gè)良好的基礎(chǔ)。