探索Windows Mobile編譯過程

l          New build window wizard是如何配置的?

Build wm的第一步是利用New build window wizard向導産生幾個腳本檔案.向導的中的配置内容來自何處? Bsp.xml.

bsp.xml的内容很簡單, 主要看裡面Supports下的CoreOS uid标簽, 一般有uldr, smartfon和wpc三個.uldr是所有bsp必須包含和支援的.wpc指的是PPC版本, smartfon指的是smartphone版本. bsp.xml内容隻是一個索引.更具體的配置在public下面對應的wpc, smartfon目錄下面的coreos.xml檔案. 使用者選擇後會影響一些環境變量, 最基本的有這幾個:LOCALE, WINCEDEBUG, skutype, dpi, resv, resh……熟悉這些xml後完全可以自己寫腳本.

l          Image Update Mode

    WM使用image update模式産生, 建構, 更新image. 早前ce, image都是鐵闆一塊的nk.bin. nk.nb0. 受制于binfs格式read only限制, 倘若局部修改, 不得不image整體更新一次. ImageUpdate顯然是注意到這個不足. (另外在WINCE6中也見到了Image Update.)使用了Image Update模型後， 将image分割成許多Packages。這些packages可以獨立編譯，然後更新，不再需要對整個image進行更新。

    Image Update優勢和處理流程 : 提供了完全或局部更新image的機制. 将nk.bin, nk.nb0分割成包結構. 允許運作期安裝這些更新包,動态熱更新. 下載下傳更新包到使用者存儲分區. 裝置上的UpdateBin.exe檢查包标記,驗證包内容和版本, 最後設定更新标記, reboot系統. Reboot後, IPL會檢查這個更新标記, 如果要更新自動進入ULDR. ULDR開始搜尋驗證使用者分區的更新包. (如果包資訊記錄在檔案系統, 遇到意外斷電中止的情況,還可以復原更新操作.) 最後更新完畢, 清除更新标記後reboot.

IMGFS

在保留binfs優點上, 設計出更靈活的IMGFS.它的驅動是IMGFS.dll,存在三個版本.進入WM後, IMGFS是隻讀的, 進入ULDR, IMGFS是可讀寫的, 對于遠端工具,IMGFS也是可讀寫的. SYSGEN_IMGFS_WRITE=1

l          存儲分布

有需要花三五分鐘去了解些簡單的xml文法.存儲分區是由memory.cfg.xml決定的, 具體的,是依據partitions标簽下的配置決定的.典型情況是:

Ø          IPL(bootloader)

       IPL是bootloader. IPL位于分區結構之外. 不是一個獨立的分區.

       IPL讀取按鍵和UpdateBin.exe設定的flag,決定是進入ULDR還是正常啟動wm. 預設的,這個flag位于邏輯扇區0位置. IPL使用BP_GetUpdateModeFlag函式來讀取.補充更正：flash flag應該是IMGFS分區的邏輯扇區0位置， 而不是MBR。此外UpdateBin.exe還會設定ram flag， 如果掉電情況下或者讀取ram flag無效情況下才進一步使用BP_GetUpdateModeFlag函數讀取flash flag。是以IPL的流程會是：先判斷某個硬體switcher， 繼而判斷ram flag， 最後判斷flash flag來決定是進入ULDR抑或normal boot。

Ø          ULDR分區

       ULDR=Update Loader.ULDR.功能上, ULDR是一個loader, 但結構上,ULDR是一個獨立的分區. 是ImageUpdate重要一環.

ULDR隻包含小尺寸的必要的代碼,即一個tiny kernel和一個Update Application：updateapp.exe, 可以讀寫系統分區和使用者分區實作動态更新. ULDR隻是在更新時候需要使用,(包括ULDR的自我更新). IPL根據使用者按鍵或者UpdateBin.exe設定,有選擇的進入uldr, 如前述，uldr包含了一個簡化版的os以及一個自啟動的應用程式updateapp.exe + packageinfoapi.dll,這個應用可以處理包的驗證,包的更新等等. ULDR也有圖形界面,它的顯示驅動是uldrui.dll.

ULDR分區是PART_BOOTSECTION（0x20）格式的分區。

Ø          Kernel分區

       也叫nk分區, Kernel分區會連續存儲在一段flash上(允許存在壞塊). 包含nk核心image,并且有能力繼續通路system分區.

Ø          System分區

       是一個IMGFS格式的分區.包含了kernel分區之外剩下的所有元件.

Ø          使用者分區

       使用者存儲區, 是一個tfat分區.

Ø          LOGO分區

[Files目錄下的memory.cfg.xml檔案]

    在ImageUpdae 模型中使用的存儲配置檔案，描述了記憶體和flash的存儲分布。DskImage.exe工具會解析這個檔案，這個檔案相當于config.bib, 最主要包含<hardware>和<partitions>這2個标簽,前面一個描述存儲媒體, 後面一個描述分區結構.

l          Package

Package是image update mode中最重要的概念.是image的構成機關,也是支援熱更新的基礎.包(package)是一組相關元件子產品檔案的集合,可以包含子產品, 檔案,系統資料庫, 在makeimg階段從release目錄建立。

每一個Package都有一個.pkd.xml檔案來描述和定義,稱為包定義檔案.微軟提供的私有包在public的smartfon、wpc目錄裡面， release copy階段會拷貝到release目錄的prebuild。 OEM的包和包定義檔案在bsp的files目錄下。

包隻能安裝或更新到更高版本,如果要删除或者版本後退,隻能重新燒.

包的基本類型有下面三種:

1. Canonical Package File

       普通包. <package name>.cab.pkd. build結束後産生一系列的cab.pkd包.是buildpkg産生的.

2. Delta Package File

       更新包. <package name>.cab.pku對已有包的更新更新包.是PkgDiff.exe産生的.

3.      Super Package File

超級包. <package name>.cab.pks. 是一些普通包和更新包的簡單集合.

制作超級包過程: 把所有包放在一個目錄下, 然後執行buildpks.

此外還有defalut ， metadata  approveupdate  package

文檔還提到buildcab和packageexplorer.exe等工具,沒有找到.

l          包産生過程

l          buildpkg.bat

u         調用OEMGuids.bat; 

u         删除Packages目錄; 删除所有bsm.xml檔案, 删除所有psf.csv檔案;

u         預處理pkd.xml檔案,儲存到postproc目錄.

u         合并packages.cpm.csv.merged,合并packages.crf.merged.

u         Mergepkd.exe合并release/postproc下所有pkd.xml成packages.pdk.xml.merged.

u         Settingscollision.exe對系統資料庫 和這些合并的檔案進行沖突檢測.

u         Dependgen.exe處理元件依賴關系.

u         Shadowordertool.exe産生psm.csv

u         Makergu.exe每個包産生rgu系統資料庫檔案.産生boot.rgu,default.rgu.

u         Rgucomp.exe處理boot.rgu得到boot.hv

u         makePKG.exe産生bsm.xml。 bsm描述了package包含了哪些東西。

u         PackageGenerator.exe根據bsm和pkd産生dsm和cab

u         Diskimage.bat産生image。

l          Diskimage.bat

u         預處理sku.xml檔案，儲存到postproc目錄。

u         Skumerge.exe合并sku檔案得到<bsp>.sku.xml。

u         Makecif處理<bsp>.sku.xml的壓縮标志得到packages.cif。（cif：壓縮資訊檔案）

u         shadowCalcEng處理packages.cif得到packages.sof（sof：shadow order file）

u         RGUComp處理rgu檔案得到default.hv和user.hv。

u         PackageGenerator （metadata.pkd.xml）

u         合并得到 <bsp>.cfg.xml

u         OEMpreDskImage.bat 呼叫SignPackageFiles.cmd

u         最後執行dskimage.exe得到image。

l          Prebuild目錄

如同Windows CE，整個build過程分成4個階段：1.compile。2.sysgen。3.release copy。4.makeimg。第三個階段與CE不同的是Buildrel還拷貝了public/wpc/oak/package目錄到release/prebuild目錄。這些都是微軟提供的私有的已經build好的包。在這些包的基礎上選擇，然後加上oem包就組成了最終image。

       是以release下的prebuild目錄裡面是包是微軟提供的預先build好的包. Makeimg時候先檢查這個目錄裡面是否存在需要的包。

使用prebuilt目錄來儲存穩定版本的packages

l          Build前，子產品和包之間怎麼關聯起來的?

在FILES目錄下面存在.cpm.csv配置檔案 .cpm.csv檔案是用來厘清子產品和包之間的關聯.Cpm即元件和包映射關系, Component Package Mapping file.

這個檔案是<檔案名>,<包名>這樣逐行描述的,指明某個檔案/子產品屬于某個包.除了這種基本格式外還有2種宏的方式,一種是<CE_MODULES_X>,<包名>,這個CE_MODULES_X是子產品名,一般是由SYSGEN階段轉來的環境變量,一般情況是SYSGEN_X得到CE_MODULES_X.第三種是<XIPREGION>,<包名> .  CE_MODULES_X和XIPREGION宏的作用在bib和reg檔案中. 仔細揣摩bib裡面的很多注釋就發現他們的關聯.

; @CESYSGEN IF CE_MODULES_DISPLAY

; @XIPREGION IF <XIPREGION>

另外補充2點, 1)可以在每行描述前可以加<BOOTHIVE>表示系統資料庫安排在boot.hv. 2)為什麼要補充第三種格式? 因為個别檔案如projects.bib,projects.reg不會CEFiltered,是以不能進行CESYSGEN處理,這時要用第三種辦法.

上面說的都是build之前，包和檔案的映射關系，。 如果在makeimg之後會産生bsm.xml檔案，直接就可以表明關系了。

l          修改代碼和配置檔案後怎麼快速打包到image?

分析這麼久其實就是為了找到這個的解決辦法！

makeimg隻需要一次。 和windows CE不同，WM的Makeimg過程是比較漫長難熬的。在第一次makeimg之後産生prebuild，postproc，packages……目錄和檔案以及image。再次厘清了幾個目錄和檔案的作用。

n          Prebuilt目錄儲存了已有的穩定版本的包，如果這裡面沒有才考慮建立新包。

n          Postproc是所有配置檔案預處理後的存儲目錄。因為這些配置檔案包含了很多宏。

n          Packages目錄儲存了最後産生的所有包。

OEM開頭的包都是OEM提供的。其他大部分是微軟提供的。比如驅動部分都是在OEMDrivers包中。如何判斷一個子產品屬于什麼包，或者一個包裡面有什麼子產品，可以查找bsm.xml檔案來判斷。或者更直覺的檢視release目錄下每個建立包有一個目錄<packagesName>_PACKAGE_FILE。

過程：

1.       先确定要修改的是什麼包，比如我們修改驅動，就是OEMDrivers包。

2.       既然prebuild是穩定版的包倉庫， 把packages目錄的包全部拷貝到prebuilt目錄下。

Copy packages/*.cab.pkg prebuilt

3.       OEMDrivers包是我們需要重新産生的，是以從prebuilt目錄删除OEMDrivers.cab.pkg。

4.       執行buildpkg

這樣就可以重新産生image。其他可以優化的考慮

Buildpkg開始階段處理Release目錄下的pkd.xml到postproc，沒有改變的pkd.xml可以删除或者備份到其他目錄節省這個過程花費時間。如果系統已經支援ULDR，那麼可以使用diffpackages工具得到前後2個OEMDrivers包的update包，前提條件是在第四個步驟buildpkg前需要先修改pkd.xml的版本号。以後再結合ULDR分析