|
在Wind River公司開發(fā)的VxWorks嵌入式操作系統(tǒng)平臺上，改進(jìn)交換機(jī)產(chǎn)品bootrom軟件的實現(xiàn)方式；給出實現(xiàn)方法和改進(jìn)目的，為BSP開發(fā)人員提供一套全新的bootrom實現(xiàn)方案。 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)雖然簡單，但正確、靈活地運用這些規(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ù)開始運行，而建立工程所得的入口函數(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ù)開始運行。因此，需要設(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è)備。 殼函數(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)運行的起始地址，但bootrom可以利用低地址來實現(xiàn)在系統(tǒng)高地址的運行。宏ROM_OFFSET用于準(zhǔn)確定位函數(shù)地址，因為bootrom中運行的代碼要求以相對地址方式來尋址，而不能以絕對地址方式尋址。_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)運行方式與修改后系統(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é)論，并不應(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)容 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)。當(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ǔ)。 |
