【IT168專稿】近期，公司讓我負責一個嵌入式消費產品的開發項目。此產品原來的操作系統是WinCE 5.0，現在因應市場需求不但要增加功能更加強大的硬件，而且公司也要求把操作系統升級為WinCE 6.0。在接手此項目后，我立即開始進行操作系統的定制開發，但結果卻是欲速則不達。

   后來，我在時間和成本的多重壓力因素下反思時，發現我犯了一個致命的錯誤，就是為了更快的把產品推向市場，在開發過程應該是移植操作系統而不是重新定制操作系統。本文根據我在此項目上得到的經驗和總結，先分析BSP移植對WinCE的重要性和影響，然后在此基礎上通過對Bootloader、OAL和驅動程序的移植來具體探討BSP的移植過程。

 什么是WinCE操作系統移植？

   （1）為什么要進行操作系統移植？
   目前嵌入式系統應用變得越來越廣泛了，嵌入式產品充斥著許多領域，如日常生活的手機、MP4、PDA等都屬于典型的嵌入式系統。隨著技術和消費者需求的變化，即使是同一類型的嵌入式產品也會存在著硬件平臺的變化，或會存在著軟件平臺的更新換代。因此，為了更快的適應市場需求，在實際開發過程更傾向于移植操作系統而不是重新開發操作系統。這樣不但可以節省時間，還能大大提高開發效率。

   由于嵌入式系統是一個軟硬件緊密結合的系統，因此操作系統移植包含兩個層面上的工作：一個層面是CPU級的，另一個層面是板級的。由于WinCE操作系統幾乎完全是用C語言編寫的,所以可移植到眾多的32位微處理器上。這其中包括ARM、x86、MIPS和SHx等，而且CPU級的移植通常由微軟或芯片制造商來完成，這會極大地減輕0EM廠商開發過程中移植操作系統的工作量，但板級層面的移植則還是需要由OEM廠商來完成的。

   一般來說，一個WinCE系統包括四層結構：應用程序、WinCE內核映像、板級支持包（BSP）、硬件平臺。而基本軟件平臺則主要由WinCE系統內核映像（OS Image）和板卡支持包（BSP）兩部分組成。因為WinCE系統是一個軟硬件緊密結合的系統，因此即使CPU處理器相同，但是如果開發板上的外圍硬件不相同，這個時候還是需要修改BSP來完成一個新的BSP。因此換句話說，就是WinCE的移植過程主要是改寫BSP的過程。

   （2）什么是板級BSP移植？
   一般來說，從零開始開發和定制WinCE BSP是需要相當長的時間，BSP的定制開發在整個嵌入式產品開發時間上占了很大比例。所以，快速的BSP移植是適應激烈競爭的市場環境的一個捷徑。BSP(Board Support Packet——板級支持包)是介于底層硬件和上層軟件之間的底層軟件開發包，它主要的功能是給上層提供統一接口，同時屏蔽各種硬件底層的差異，以及提供操作系統的驅動及硬件驅動。簡單的說，就是BSP包含了所有與硬件有關的代碼，為操作系統提供了硬件平臺無關性。因此，通過BSP系統，就能將CPU的硬件系統與Windows CE的軟件系統聯系為一個整體。

   從WinCE開發文檔中我們可知，BSP是一個包括啟動程序Bootloader、OEM適配層程序(OAL)、標準開發板(SDB)和相關硬件設備的驅動程序和配置文件的軟件包。其中Bootloader是加電即運行的一段程序，它能初始化硬件，建立系統的內存空間映射，為最終調用系統內核做準備。主要用于下載和啟動鏡像nk.bin。而OAL則是邏輯上駐留在Windows CE內核與目標設備之間的代碼層，OEM廠商使用這些代碼把WinCE適配到自己的硬件上；在物理上OAL是與內核庫連接在一起產生內核可執行文件。OAL簡化了操作系統與目標代碼之間的通信，OAL代碼用來處理中斷、記時器、電源管理、通用I/O控制等。最后，設備驅動程序是指本機驅動程序以及流接口驅動程序。本機驅動程序有GEWS.exe加載的鼠標、鍵盤、觸摸屏、顯示驅動等；而流接口驅動程序使用一組流函數來實現，通常由Device.exe加載，如網卡、聲卡、USB等

WinCE BSP移植的流程和步驟

   從前文分析我們可以知道，WinCE系統移植的重點是BSP 的移植。而BSP移植主要包括啟動程序Bootloader、OEM適配層程序OAL、標準開發板(SDB)本地驅動程序以及一些文件配置的修改。以下是WinCE BSP移植的主要內容和流程步驟：

   （1）啟動程序Bootloader的移植步驟
   修改Bootloader是移植Win CE系統第一步，也是關鍵的一步。只有得到一個穩定工作的啟動程序，才能夠進一步完成WinCE BSP的移植。Bootloader主要用來管理目標平臺的啟動過程，它是一段單獨的程序代碼，通過這段小程序可以初始化硬件設備、建立內存空間的映射圖和下載操作系統的映像文件等，從而將系統的軟硬件環境帶到一個合適的狀態，它一般存放于目標平臺的非易失存儲介質中，如ROM或Flash。

   一般來說，對于Bootloader的功能,不同的場合區別很大。比如，在桌面Windows版的PC硬件平臺上，由于硬件啟動根本就不通過Bootloader（而是通過BIOS），所以Bootloader就無需對CPU加電后的初始化做任何工作；而在嵌入式WinCE平臺上，Bootloader是最先被執行的程序，所以就必須包括加電初始化程序，同時通常Bootloader必須包含下載WinCE映像文檔的功能。由于Bootloader會涉及到基本的硬件操作，如CPU的結構、指令等，也會又涉及到以太網下載協議和映像文檔格式。因此，從零開發實現的話會需要相當長的過程，通常的做法是利用微軟為每種類型的CPU提供的某種標準研發板的Bootloader例程。

   根據我在這次項目移植得到的經驗，Bootloader的移植步驟主要是：①是修改相應的dir、source文件；②是修改makefile.inc；③是修改boot.bib，使其不與config.bib中的內存分配造成沖突；④是改進eboot，因為eboot燒寫NK.BIN的時候會查找BINFS分區，然后把下載的image燒寫到BINFS分區。

   （2）OAL的移植步驟
   OAL的全稱是OEM Adaption Layer，即原始設備制造商適配層。它是位于Windows CE內核和目標硬件平臺之間的一個代碼層，OAL主要負責Windows CE與硬件通信，它與CPU、中斷、內存、時鐘和調試口等核心設備相關，也是OAL各個模塊代碼被編譯后（.lib）和其它內核庫鏈接到一起形成Windows CE的內核可執行文檔NK.EXE的關鍵。簡單的說，OAL就是用來屏蔽CPU平臺的細節和抽象硬件功能，以實現操作系統內核的可移植性。

   從邏輯結構上看，OAL位于WinCE操作系統的內核與硬件之間，是連接WinCE系統與硬件的樞紐；從功能上看，OAL頗似桌面PC上的BIOS，具有初始化設備、引導操作系統以及抽象硬件功能等作用。但與B10S不同的是，0AL隸屬于操作系統，是操作系統的一部分。

   從我在這次項目中得到的經驗來看，Windows CE安裝目錄的子目錄中都包含有OAL的部分源碼。OAL的移植實現應是在fwxsc1.s、main.c、Flash.c、Edeviceinit.c等文件中，可根據實際需要修改相應的代碼。在OAL移植過程中，主要是修改這幾個函數：修改Startup.s函數、修改串口調試函數、修改OEMInit函數、修改系統時鐘函數和修改中斷處理函數等。實際上，大多數情況下開發工程師對OAL只要修改即可，甚至無需修改。