基于VxWorks的bootrom代碼改進
發布時間：2010-11-16 15:58
發布者：eetech
|
在Wind River公司開發的VxWorks嵌入式操作系統平臺上，改進交換機產品bootrom軟件的實現方式；給出實現方法和改進目的，為BSP開發人員提供一套全新的bootrom實現方案。 1 問題的提出 VxWorks是Wind River公司開發的一種嵌入式操作系統，具有強大的功能和友好的用戶界面。VxWorks軟件應用非常廣泛，不僅應用在網絡設備、家用電器當中，而且還應用在航天、導彈等高端領域。在網絡設備應用領域中，通常利用VxWorks來開發bootrom代碼、BSP（Boadr Support Packet）代碼以及上層的網絡協議代碼。 通常，Bootrom軟件有以下功能：①通過串口下載操作系統映像；②通過串口升級自身映像；③通過串口下載系統配置文件、系統信息文件；④加載操作系統映像，使其正常啟動；⑤其它的輔助功能，如地址內容查看功能、址內容修改功能和bootrom菜單顯示信息控制的功能等。對于通常的bootrom代碼編譯，大多數用戶選擇使用GNU make的DOS命令來進行。因為如果bootrom不提供網口功能的話，單純的CPU驅動部分代碼量是不大的；但如果提供網口功能的話，代碼量相對較大，文件之間的內在關系比較復雜，因此，系統使用GNU make的DOS命令來編譯生成bootrom就顯得有點麻煩。Makefile文件主要是由“目標”（target）、“依賴性”（dependencies）和“動作”組成的一系列規則，而VxWorks提供的GNU make工具就是根據Makefile指定的規則來編譯和鏈接程序的。Makefile基本結構雖然簡單，但正確、靈活地運用這些規則并不是那么輕松的事情。即使根據GNU Makefile規則書寫出適當的Makefile文件，但隨著代碼的改變，Makefile還需要經常修改，這就增加了BSP開發人員的負擔。而且，對于交換產品而言，其成本控制是非常嚴格的。對于存放bootrom軟件的Flash來說，通常要求大小為512KB，這樣就需要考慮到容量的限制。 因此，必須使用新的方法來簡化bootrom代碼編譯，而且要在保證提供網口功能的情況下，系統提供的bootrom軟件小于512KB。 2 實現方法 2.1 通過建立工程生成bootrom映像 采用建立工程的方式可以有效地解決這個問題。首先依據bootrom中的BSP代碼來新建一個工程，然后將網中驅動代碼加入到建好的工程中。這樣就可以通過編譯工程實現帶有網口下載功能的bootrom軟件。但對于VxWorks嵌入式系統而言，它有自己一套規范，求bootrom軟件在加電后必須從romInit（）函數開始運行，而建立工程所得的入口函數為sysInit()。因此需要增加一個系統殼代碼，這個殼代碼所要完成的任務就是加載bootrom工程的映像，并從romInit（）開始執行bootrom代碼。通過建立工程來調試bootrom代碼有以下優點。 （1）責任分明 開發產品是一個復雜的工程，需要多人合作完成。對于CPU子系統和網口驅動系統這兩塊內容來說，更需要責任明確。通過建立工程來調試代碼，可以準確地定位錯誤文件和函數的位置。是BSP代碼出現問題，還是網口驅動代碼出現問題，可以一目了然，做到責任明確。 （2）提高效率 通過建立工程可以節省書寫Makefile文件時間，并可以讓VxWorks軟件的友好圖形界面這優點得到更好的體現。另外，建立工程也可以減少文件編譯排錯的難度，方便工程文件的調試以及功能的驗證，從而大大提高工作效率，加快工作進度。 2.2 編寫殼代碼并實現加載 建立工程生成映像文件的入口函數為sysInit（），而VxWorks規范中要求系統加電后要從romInit（）函數開始運行。因此，需要設計一個方案來加載編譯工程得到的映像，而且要具備初始化CPU和SDRAM存儲空間的功能。 首先，系統從romInit（）函數中開始運行，完成CPU和SDRAM初始化，跳轉到函數romStart()運行。然后，加載第二份bootrom代碼到系統的低地址處，運行殼代碼中的sysInit（）函數，并調用自己構造的解壓函數usrInit（），將壓縮后的工程映像文件解壓縮到系統高地址處，之后系統繼續運行解壓后的bootrom代碼。此時，系統開始運行sysInit（）函數，調用VxWorks系統中的usrInit（）函數，開始初始化系統硬件、內核以及其它外圍設備。 殼函數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為系統低地址，是操作系統運行的起始地址，但bootrom可以利用低地址來實現在系統高地址的運行。宏ROM_OFFSET用于準確定位函數地址，因為bootrom中運行的代碼要求以相對地址方式來尋址，而不能以絕對地址方式尋址。_binArrayStart為壓縮后二進制代碼的開始符，_binArrayEnd為壓縮后二進制代碼的結束符。Inflate()是VxWorks軟件的解壓縮函數，用于解壓縮由deflate()壓縮函數壓縮的二進制文件映像。同時，需要將下述代碼添加到編譯規則文件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()為解壓軟件入口函數。上述語句的功能：第一行完成殼文件的編譯，第二、三行完成殼目標代碼與第二份bootrom代碼的鏈接。這樣，一個具有解壓功能的殼函數就被鏈接到第二份bootrom映像中了。 圖1、圖2是修改前的系統運行方式與修改后系統運行方式比較。 通過這兩種方式的比較可以看出，修改前系統運行式與修改后的運行方式有下面兩點差異；①第一份bootrom啟動后，前者存在解壓縮自射映像的操作，而后者沒有；②對于第二份bootrom，前者沒有殼代碼，而后者有。 2.3 縮減文件長度 通常第一份bootrom代碼只有兩個文件，一個是包含CPU和SDRAM初始化文件romInit.s，另外就是包含romStart()函數的bootInit.c文件。另外，根據需要還可以添加提供串口輪詢顯示功能的文件。對于第一份bootrom代碼，通常只有10KB左右（這是針對系統修改后的方式），而對于包含殼函數代碼的，通過建立工程并編譯而生成的第二份bootrom比較大，通常為570KB左右。（注意：這幾個數值是通過特定的產品來得出的結論，并不應用于所有產品，但遇到類似的情況可以借鑒處理。）而其后面的一部分完全是0，可以考慮去掉這些0，但不能影響軟件的功能。經過測試得出結論：去掉后面的0對系統功能和性能沒有任何影響。 通過文件的操作來實現兩份bootrom合并，合并后的大小要求小于或等于512KB。如果不采用任何措施，直接將兩個文件合并起來要在580KB左右，大于512KB，這是很多系統不能滿足的。第二份bootrom映像的后面部分的內容類似表1所列的信息。 表1 bootrom映像部分二進制內容 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值了。這樣可以通過對文件內容的操作將0x00078240后面的內容全部剔除，從而可將合并后的bootrom代碼控制在512KB以內。當然，我們通常會選擇一個整數值進行操作，即將0x0007824后的所有值去掉即可。 這樣處理，可以減少維護和開發的工作量。如果按照以往的做法，bootrom軟件對外將有第一份和第二份的區別，無論是生產、上層軟件調試還是開發，都需要分別對待，這樣維護量和開發量將會加大。而經過修改后，可把區別只控制在開發階段，在線升級時，可以按照一個軟件來通過串口或網口來進行升級。通過對bootrom最后生成文件大小的控制，可以簡化生產流程，加快生產進度。 3 小結 在嵌入式操作系統中進行程序開發，需要經常開辟新的思路，以一些簡單的實現方式代替復雜易錯的方式。在本次產品開發過程中，將bootrom映像生成方式由慣用的GNU make命令行實現，修改為按照新建工程的方式來實現，是一個相對好的方法，對整個產品的后續批量生產、用戶維護和后續開發都奠定了一個良好的基礎。 |
網友評論