本文通過一個真實的嵌入式項目進行說明。文中的嵌入式系統用的是arm處理器+WinCE平臺，項目的目的是要把WinCE平臺從舊版本移植到WinCE6.0平臺上。但結果是這個WinCE系統在啟動的時候經常會出現失敗，而且每次失敗的原因都莫明其妙和不盡相同。這使到我們開發團隊每個人在啟動WinCE系統時都心驚肉跳，非常擔心系統又再一次出現讓人意想不到的失敗。這種頻繁的啟動失敗對開發團隊來說顯然是一種讓人難以忍受的折磨。
為什么會出現這種情況呢？經過幾個晚上通宵達旦的加班分析和研究，原來主因是系統的引導過程、內核加載過程、OAL啟動過程和硬件驅動加載過程時都存在可能導致的失敗的隱憂。本文通過對以上因素進行分析，并提出相應的解決辦法。但由于WinCE啟動失敗會非常取決于硬件平臺，因此在具體應用時需要綜合考慮和分析。
一．什么是WinCE啟動過程？
WinCE系統在啟動時一般需要三個基本元素：引導初始化、內核加載和OAL初始化等。它們的作用是要完成引導過程的初始化和操作系統執行環境的初始化。其中引導初始化是由引導工具BootLoader完成，主要是完成板級、片級的初始化。例如，通過設置寄存器來完成硬件的初始化，如設置時鐘、設置中斷控制寄存器、完成內存映射和初始化MMU的工作方式等。內核加載是指將操作系統內核映像從只讀存儲器加載或者拷貝到系統的RAM中并執行。OAL（OEM Adaption Layer，即原始設備制造商適配層）是位于操作系統的內核與硬件之間的適配層，也是連接系統內核與硬件的樞紐，它具有屏蔽硬件設備細節以及抽象硬件功能的作用。而OAL初始化則是指通過一組函數來體現出0AL屏蔽和抽象硬件設備的作用。
此外，如果要WinCE系統成為完整的操作系統，還得加上硬件驅動程序、硬件接口程序和應用程序組。因此，即使在一個簡單的嵌入式系統里，WinCE系統啟動時是需要加載內核和加載許多組件或驅動程序。
現在讓我們來看看WinCE系統在啟動時調用函數的順序：①CPU執行引導向量，跳轉到硬件初始化代碼，即Startup函數。②在start up函數完成最小硬件環境初始化后跳轉到KernelStart函數，來對內核進行初始化。③Kernelstart函數調用OEMInitDebugSerial完成對調試串口的初始化；同時調用0EMInit函數來完成硬件初始化工作以及設置時鐘、中斷；最后，調用OEMGetExtensionDRAM函數來判斷是否還有另外一塊DRAM。至此，內核加載完畢。由此可見，WinCE系統啟動的重中之重是Startup函數的正確加載，如果這個Startup函數調用失敗，則會使到系統在啟動頻繁出錯。WinCE啟動時調用函數順序如下圖所示:
因此，WinCE啟動失敗可能會存在于引導初始化失敗、內核加載失敗、0AL函數初始化失敗、驅動程序加載失敗、組件加載失敗和應用程序加載失敗。也就是說，WinCE啟動失敗一方面可能是在Startup函數的處理上，例如引導初始化和OAL初始化。另一方面還存在于驅動程序和組件自啟動的失敗上，例如基本的驅動程序、注冊表配置或自運行的程序等。
就不能被使用。所以，當注冊表在啟動時加載錯誤或者注冊表配置有錯誤時，也是會導致WinCE系統啟動失敗的。
二．導致WinCE啟動失敗的主因分析
Windows CE在啟動時為什么會失敗呢？這個問題也一直讓我頭痛。因為Windows CE啟動失敗既有軟件因素，也有硬件因素。例如，可能是WinCE的啟動引導過程有問題、也許是內核加載時有問題、也許是OAL函數調用的隱性問題或者硬件設備本身的問題造成的。所以，解決起來比較麻煩和比較耗時間，也是最讓我們頭疼的事情。
一般來說，解決和分析WinCE啟動失敗有一個原則，就是"先軟后硬"的原則，也就是說要先分析軟件因素再到硬件因素。本文主要是在arm微處理器和Windows CE 6.0平臺上進行分析軟件因素造成的失敗。
?。?）引導程序BootLoader導致的失敗
在Windows CE系統中，整個系統的加載啟動任務由BootLoader來完成，BootLoader是在WinCE內核運行之前運行的一段小程序。通過這段小程序，可以初始化硬件設備、建立內存空間的映射圖和初始化MMU等。從而將系統的軟硬件環境帶到一個合適的狀態，為調用操作系統內核準備好環境。因此，只有在引導程序正確的完成自己的任務后，才會將控制權移交給內核。
在WinCE平臺上，引導裝載程序是在硬件上執行的第一段代碼，通常將引導程序放置在不易丟失的存儲器的開始地址或者是系統冷啟動時PC寄存器的初始值。如果這段小程序代碼編寫錯誤，則系統無法完成第一步的引導操作，這是導致啟動系統失敗的第一個因素。
?、貰ootLoader初始化硬件失敗
BootLoader第一個功能是要實現板級和片級初始化硬件，主要是把CPU初始化到一已知狀態。在BootLoader目錄下，會發現一些.s文件，可能會是init.s或者是reset.s等，這樣的文件是CPU加電后最先執行的代碼。StartUp 函數是BootLoader的入口函數。該函數一般是使用匯編語言編寫，與CPU關系非常緊密，能完成初始化CPU、內存等核心硬件。然后，BootLoader在平臺初始化完畢后就可以在不用人工干預的情況下自動加載WinCE內核了。但如果BootLoader在初始化硬件時失敗，就會直接導致系統的啟動失敗了。
?、贐ootLoader加載內核時失敗
一般在平臺調試完畢后，BootLoader就會加載WinCE內核映像，這也是BootLoader的功能之一。WinCE內核映像文件通常叫做nk.bin，它是Windows CE二進制數據格式文件，不僅包含了有效的程序代碼，還有按照一定規則加入的控制信息。
在系統啟動時BootLoader可以通過兩種不同的方式來加載WinCE內核文件nk.bin。一種是下載模式，另一種是本地啟動模式。本地啟動模式也稱為自主模式，即 BootLoader 從目標機上的某個固態存儲設備上將操作系統加載到 RAM 中運行，整個過程并沒有用戶的介入。而下載模式則是目標機上的 BootLoader 將通過串口連接或網絡連接等通信手段從主機（Host）下載文件。當BootLoader正確的把nk.bin解壓到RAM后，就會把CPU控制權交給CE內核。因此，如果Boot Loader處理不當，就可能會造成加載和解壓nk.bin文件的失敗，這樣自然也就會造成系統啟動的失敗了。
?。?）OAL導致的啟動失敗
OAL（OEM Adaptation Layer）是指OEM 適配層，它是位于Windows CE內核和硬件之間的一層適配層，是OAL各個模塊代碼被編譯后（.lib）和其它內核庫鏈接到一起形成Windows CE的內核可執行文檔NK.EXE。OAL包括了和系統硬件通訊的最底層代碼，內核是通過OAL跟硬件進行交互。邏輯上，OAL是介于CE內核和設備硬件之間的一個代碼層，是一個抽象的概念。物理上，OAL和其它一些庫一起鏈接成可執行文件。
與以前的Win CE舊版本不同的是，在Win CE 6.0中內核（Kenerl）和OEM代碼被分成oal.exe、kernel.dll和kitl.dll三個部分，其中啟動代碼（startup）和 OAL層的實現部分不再與內核鏈接生成NK.exe，取而代之的是啟動代碼（startup）和硬件相關且獨立于內核的OAL層的實現部分編譯成 oal.exe；而與內核相關且獨立于硬件的OAL層代碼包含在kernel.dll中，內核無關傳輸層（KITL）的支持代碼從OAL層分離出來編譯成 kitl.dll。因此，WinCE6.0的啟動只與oal.exe和kernel.dll有關。至于kitl.dll，只有將操作系統編譯成具有 KITL功能時才用到。這樣做的好處是可以單獨升級OAL，但整體的OAL結構并沒有改變。
①OAL初始化硬件時失敗
oal.exe是通過Startup函數來完成硬件的初始化。一般來說，OAL的啟動代碼（Startup.s）與該硬件平臺的Bootloader的啟動代碼（Startup.s）是可以共享的。例如，其中PreInit 函數主要完成將arm處理器工作模式切換到管理員模式，同時關閉MMU，并檢測系統啟動原因。如果是熱啟動，即在該函數調用之前已經啟動過 Bootloader的啟動代碼（Startup.s），相當基本硬件初始化已經完成，則可直接跳轉到OALStartUp函數中；否則需要進行硬件中斷屏蔽、內存、系統時鐘頻率、電源管理等硬件的基本初始化過程。
在StartUp 函數初始化CPU等核心硬件并跳轉到Main函數后，系統就會轉入C語言代碼執行環境。這時Main函數分為3個模塊：BLCOMMON、Download Function、FLASH Function。其中BLCOMMON模塊是由微軟提供的，執行一些邏輯上的功能。而Download Function、FLASH Function中的函數與硬件平臺息息相關。因此，對于每種硬件平臺都要將函數的實現進行適當修改，這種修改是需要對硬件非常熟悉的。當修改出現錯誤時，就會導致系統啟動失敗了。
在硬件平臺初始化完成后，oal.exe的啟動任務基本完成，余下的啟動工作由內核相關且獨立于內核的OAL層實現體kernel.dll接管。也就是說，這時Startup會調用OALStartUp函數，OALStartUp函數主要完成將OEMAddressTable表傳遞給內核，然后調用KernelStart函數跳轉到內核。因此，如果此時OAL的啟動Startup函數調用失敗的話，就也會導致系統的啟動失敗了。
這里需要特別注意的是，Bootloader和OAL中均包含啟動Startup函數。它的功能大致相同，都是要初始化最小硬件環境。Bootloader的啟動Startup函數是在為自己的執行準備硬件環境，OAL的啟動Startup函數則是為kernel的執行準備硬件環境。由于這兩種硬件環境要求基本相同，所以它們的代碼也有很大部分可以相互借鑒。但應該明白Bootloader與OAL在物理上是獨立的，它們并不是同一段代碼。當然，如果可以確定這一部分在Bootloader已經初始化過如熱啟動，則在OAL中不必重復執行。
②OAL入口位置定位失誤導致的失敗
從上述WinCE啟動流程可知，在OAL初始化硬件后而在內核啟動前，系統是需要調用KernelStart函數來跳轉到內核。因此，這里有一個要點，就是WinCE需要找到OAL的入口位置，然后才能調用入口函數與全局塊進行指針交換，這樣內核才能使用OAL層中的信息，同樣OAL層也才能訪問內核（kernel）導出的函數。
OAL入口位置函數的調用實際上是通過OEMGLOBAL結構體實現的，實際調用位置為OEMInitDebugSerial和OEMInit。也就是說，OEMGLOBAL結構體構建了內核和OAL層之間進行通信的橋梁。OEMGLOBAL結構體定義了OAL層所有必須的函數，該結構體在oemglobal.c文件中被初始化，并會被編譯在OEMMain.lib和 OEMMain_StaticKITL.lib兩個庫中。如果OAL鏈接這兩個庫，則必須要有正確的該結構體的函數實現體，同時還需要調用ARMSetup來設置物理地址和非緩沖的虛擬內存地址的映像、arm中斷向量以及內核模式所需要的堆棧、調用OEMInitDebugSerial函數初始化調試串口、調用OEMInit進行平臺初始化等。否則，如果OAL入口位置函數有誤，則內核和OAL層之間的訪問就會失敗，也就會導致系統在啟動時出錯和失敗。
三．導致的WinCE啟動失敗的其它相關因素
（1）驅動程序加載錯誤導致的失敗
在調試中，我們還發現系統在啟動時執行到OEMInit時也經常會出現錯誤。一般來說，系統調用OEMInit運行完成之后，就會跳回Private或Public下的代碼繼續運行，然后再啟動device.exe加載各個驅動程序。由于這一段代碼是微軟提供的default代碼，基本上不會有問題。所以，我們就有理由懷疑如果加載的驅動程序出了問題，是也會造成系統啟動失敗的。一般來說，這些加載的驅動程序主要是 BSP中的Audio、Display、SDMMC、Serial、USB等。
（2）啟動時加載配置有誤的注冊表導致的失敗
在WinCE中注冊表在啟動過程中也扮演著非常重要的角色。與桌面Windows一樣，WinCE注冊表（Registry）也是一個系統數據庫,用來保存應用程序、驅動程序、用戶的設定以及其它一些系統的配置信息，通常還存儲著操作系統運作和調用程序的狀態信息。例如，每個用戶的配置文件、安裝的應用程序以及每個應用程序可以創建的文檔類型、文件夾和應用程序圖標的屬性表設置、系統上存在哪些硬件以及正在使用哪些端口等。
因此，對于硬件外設來說注冊表是一個記錄驅動程序設置和位置的數據庫。當WinCE系統在啟動時需要啟動某些必要的硬件設備時，就會需要使用外設驅動程序。但如果在WinCE中這個外設驅動是獨立于操作系統的，WinCE系統就需要知道從哪里找到它們，例如文件名、版本號、其它設置和信息。因此，注冊表上沒有此設備的記錄時，它們就不能被使用。所以，當注冊表在啟動時加載錯誤或者注冊表配置有錯誤時，也是會導致WinCE系統啟動失敗的。