[Windows Mobile Software Development] Da_G:
More Technical Specifications

The basic ImageUpdate Layout consists of:

[IPL] -- [MBR] -- [ULDR] -- [NK] -- [IMGFS] -- [TFAT]

[IPL] is the "Initial Program Loader" that handles basic init functions and determines if control should be handed over to ULDR, or NK through a flag set by UpdateBin.exe - the IPL is not contained within a partition. The IPL is copied entirely to RAM and executed from there. IPL loads NK into RAM, and also handles any decompression of NK if it's required - some SmartPhone's ive seen use SRPX compression for the NK partition. Once NK is copied to RAM it is then executed. The IPL is handled seperately from the other parts of the operating system, and is not flashed during a normal update.

[MBR] is the "Master Boot Record" and contains partition tables for the below components - it points to NK so when IPL loads the MBR, control is handed over to NK. The MBR contains information on where each partition is located on the flash (memory address), the size of the partition(s), and the type of each partition. The MBR is referenced from many components on the device such as IPL and ULDR in order to facilitate handoff of control between ULDR and NK. The MBR also serves as a boundry between the IPL which is not part of the regular partition structure, and the rest of the flash, which is part of the partitioning structure.

[ULDR] is the "Update Loader" and provides a basic WinMo system so that file operations can be done on the IMGFS partition while it's unmounted. The Update Loader is even able to update itself - during operation it is loaded entirely to RAM. On development workstations the ULDR supports a KITL connection, that can be used to load updates directly from the "Release" folder. It seems it may be possible through this method to flash a new image to the device, possibly opening up the ability to flash to devices that have not yet been flashed with "HardSPL"

[NK] is the "Kernel Partition" - or what we know as xip.bin - This component is updatable by ImageUpdate, and has a pre-defined "free space buffer" with room to grow, which defaults to 512KB. This partition holds only the kernel and drivers necessary to bring up the rest of the filesystem, from which the rest of WinMo is loaded. The Kernel Partition uses the same "Package" format as the IMGFS and is updatable in the same manner.

[IMGFS] is the "System Partition" - running the Image Update filesystem. This component is updatable by ImageUpdate, and has a pre-defined "free space buffer" with room to grow, which defaults to 9.5MB. The IMGFS uses the "Package" format to further split its components.

[TFAT] is the "Transaction Safe FAT File System" which is where all user-writable data goes.

In most Device Designs, there's a single NOR or NAND chip used for flash. This is important as due to the typical layout above, both NK and IMGFS must have a pre-defined amount of free space - because TFAT is the last partition on the drive, and cannot be shifted once flashed to the device. It's possible for the partition layout to be setup differently (Partitions in different order) to help alleviate that problem. The ImageUpdate system would really shine on a device with 2 flash chips, a NOR chip dedicated to the ImageUpdate partition and a NAND chip dedicated to the TFAT, but no OEM has created such a design yet.

Packages

Package Types

There are 3 different types of packages, Canonical, Update, and Super.

Canonical contains the entire contents of the package. It is used for a first-time package install, and if there are any major updates to be issued that would require the complete package. The file extension is .cab.pkg

Update contains a binary delta between a package already on the device, and the updated version of that package. In this manner the limited space is conserved (i.e. if a package change was a simple registry entry - no need to replace the 5mb of .dll and .exe in that package, just alter the .rgu with the new data. These packages are also referred to as "Delta" packages. The concept is similar to the unix implementation of Diff/Patch. The file extension is .cab.pku

Super contains a collection of update and/or canonical packages. This is very useful when you are attempting to bring in a new package that has dependencies on other packages - rather than reboot into ULDR for each individual package in the proper dependency order, they can all be introduced at once. Every package contained inside a super package is validated, and if one fails, the remaining valid updates may still be applied, as dependencies allow. A super package is simply an un-compressed .cab containing other packages, renamed to .cab.pks

The package layout itself is quite basic, it consists of a .dsm which contains all versioning info, association info, and dependency info. It also contains a list of all modules and files inside the package, and a certificate store of all approved certificates that will be allowed to update that package. Alongside the .dsm is an optional .rgu, which defines the registry settings associated with that package. Also optional is a .provxml file, which can be: mxip_[packagename]_[version].provxml, mxipcold_[packagename]_[version].provxml, or mxipupdate_[packagename]_[version].provxml. mxip and mxipcold are effectively treated the same, executed only on a cold boot. mxipupdate_ provxml's will be executed any time that package is updated, in addition to a cold boot - so if you are adding new .cab.pkgs and wish the .provxml to be executed immediately, it would need to be mxipupdate. This may not be desirable in some cases, such as when the provxml might override a user preference - in that case you would only want it to run on a cold boot, in order to avoid "strange" behavior on the user's side of things.

There is a "shadow order" defined in the .dsm as well - this controls what "priority" .rgu's are compiled together into the device registry hive - a package that shadows another package will override any .rgu entries that shadowed package may contain. This is important to consider when utilizing .cab.pkgs in order to obtain your desired end registry. This shadow order also applies to provxmls inside the package - a package that shadows another package will override its provxml settings as well.

The user registry hive is always top-most in the shadow order (except in the case of an mxipupdate_ provxml) - so any changes to .rgu registry settings will not override a user-changed registry setting. (example: You had foobar set to 5 in your initial deployment. At some point after flashing to his/her device, the user modified the registry, changing the value of foobar to 6. Your new .cab.pkg contains an .rgu changing foobar to 7 - on device, foobar will remain set to 6, as the user registry is higher in the shadow order than the .rgu) - in the case of an mxipupdate_ provxml these will override user settings.