探索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分析

探索Windows Mobile编译过程 .相关推荐

windows mobile 编译（生成镜像）提速
windows mobile 编译镜像总是让人难以忍受的耗时,当然我们不能每次修改一点东西就build All一次. 下面是自己工作中积累的[不同情况下使用的编译命令]来加速生成镜像的过程,不排除有错 ...
GDAL库简介以及在Windows下编译过程
GDAL(Geospatial Data Abstraction Library,地理空间数据抽象库)是一个在X/MIT许可协议下的开源栅格空间数据转换库.官网http://www.gdal.org/ ...
iOS底层探索（二） - 写给小白看的Clang编译过程原理
iOS底层探索(一) - 从零开始认识Clang与LLVM 写在前面编译器是属于底层知识,在日常开发中少有涉及,但在我的印象中,越接近底层是越需要编程基本功,也是越复杂的.但要想提升技术却始终绕不开 ...
FFmpeg在Windows系统下的编译过程
由于FFMpeg是基于Linux开发的开源项目,源代码和Windows下最常见的Visual Studio提供的C/C++编译器不兼容,因此它不能使用MSVC++编译.要想使用FFMpeg,最先要解决 ...
记录 Windows 下编译一个开源 SM9 签名验签 C 程序的过程
注:本文不讨论算法具体实现细节,只介绍如何编译一个现有的程序实现. 在商用密码检测中心( 链接:http://www.scctc.org.cn/index.aspx )的网站上,"下载中心& ...
Dlib简介及在windows7 vs2013编译过程
Dlib是一个C++库,包含了许多机器学习算法.它是跨平台的,可以应用在Windows.Linux.Mac.embedded devices.mobile phones等.它的License是Boos ...
windows mobile做一个摄象头预览程序
zdirectshow的原理大概大家都知道,基本就是用微软封装的接口来实现硬件无关性,但是最终调用的接口都要在驱动层有对应的实现: 为了更清楚地演示directshow的数据传输过程,我必须说明的这个 ...
Windows Mobile 5.0 中为开发人员提供的新功能(3)
Windows Mobile 5.0 中为开发人员提供的新功能(3) Pocket Outlook 增强功能 Pocket Outlook 向用户和应用程序开发人员提供了易于使用的 PIM.将 Poc ...
Windows Mobile与OPhone开发对比
转载自IT168 [ http://www.it168.com/ ] Windows Mobile在经历过最初的Wince系列,pockect pc和smartphone两种版本,到微软最 ...

探索Windows Mobile编译过程 .

探索Windows Mobile编译过程 .相关推荐

最新文章

热门文章