Windows Phone 7 has standardized the bootloader requirements for OEMs. No longer will an OEM be allowed to implement it's own design for ROM deployment (such as HTC with the .nbh/RUU system, .dz/LGMDP with LG, etc.)
The image format will be B000FF/.bin, which receives only minor changes from CE5, and so our current tools should work fine with this. The major change is in the way the bootloader handles image deployment. For Samsung and a handful of other manufacturers, this won't change too much, as they already utilize the B000FF system for deployment. The filesystem inside will be IMGFS - no longer will BinFS be used for NK/XIP section (now IMGFS will all partitions on device, NK and OS just being split by package rather than a seperate FS)
The physical flash layout will look as follows:
Only the User Store (Which uses new Transaction-Safe ExFAT filesystem) will be user-writeable, all other areas will only be writable during an update operation. The Partition Table, DBSP, DPP, USP, and User Store are all not updateable during an update operation, only during a full-flash scenario. B00FF images are signed and checksummed, and passed through to the bootloader via ethernet over usb. The connection will most likely be encrypted, using the same flashing utility as Zune HD. (This is currently used to deploy images to the DevKits)
.ffu (Full Flash Update) file format (XML) will be used to pass information to the Zune software on which partitions are to be updated, etc. FFUs are signed just as .cabs are signed and only an .ffu which passes validation against the certificates on-device will be allowed to update a device.
Updates can also be done on a per-package basis, using the ImageUpdate process, which I have described in length @ the XDA WinMo Software Development forum. This process is largely unchanged from WinMo 6.x with the addition of a policy xml file containing security policy settings related to the .cab.pkg being deployed.
As such, I would recommend anyone interested in cracking the bootloader and creating a "HardSPL" take a good hard look at the Zune HD.
Similar to CE5/WinMo 6.x, There is a BLDR (Base Boot Loader) which makes the initial determination to boot up to the ULDR or to the WP7 OS. The OEM implements alternate boot parameters to trigger this and/or a button press combination. If ULDR is triggered, it checks the battery and power source to ensure that there is enough life remaining to successfully complete the flash, then awaits the flash download. There are redundant ULDR partitions (ULDR1/ULDR2) to facilitate failsafe recovery in the event of a failed ULDR flash (ULDR provides a basic level of functionality to enable a recovery flash even in the event of power failure during a flash)
MSFT is pushing it's Phone Update service much harder this time - it is intended to be used as the primary method for distributing phone updates. These can be deployed both over-the-air and through a USB connection with the Zune software.
The image format will be B000FF/.bin, which receives only minor changes from CE5, and so our current tools should work fine with this. The major change is in the way the bootloader handles image deployment. For Samsung and a handful of other manufacturers, this won't change too much, as they already utilize the B000FF system for deployment. The filesystem inside will be IMGFS - no longer will BinFS be used for NK/XIP section (now IMGFS will all partitions on device, NK and OS just being split by package rather than a seperate FS)
The physical flash layout will look as follows:
- Reserved Regions, updateable only through a special oem-written driver to allow access to this area (size varies)
- Partition Table (1KB)
- BLDR (1MB)
- DBSP (Device Boot State Partition, 256KB)
- DPP (Device Provisioning Partition, 256KB)
- USP (Update State Partition, 2MB)
- ULDR1 (>=6MB)
- ULDR2 (>=6MB)
- NK (IMGFS, >=4.5MB) - At least 1MB free space for updates
- OS (IMGFS, >=181MB) - At least 20% free space for updates
- User Store (TexFAT)
Only the User Store (Which uses new Transaction-Safe ExFAT filesystem) will be user-writeable, all other areas will only be writable during an update operation. The Partition Table, DBSP, DPP, USP, and User Store are all not updateable during an update operation, only during a full-flash scenario. B00FF images are signed and checksummed, and passed through to the bootloader via ethernet over usb. The connection will most likely be encrypted, using the same flashing utility as Zune HD. (This is currently used to deploy images to the DevKits)
.ffu (Full Flash Update) file format (XML) will be used to pass information to the Zune software on which partitions are to be updated, etc. FFUs are signed just as .cabs are signed and only an .ffu which passes validation against the certificates on-device will be allowed to update a device.
Updates can also be done on a per-package basis, using the ImageUpdate process, which I have described in length @ the XDA WinMo Software Development forum. This process is largely unchanged from WinMo 6.x with the addition of a policy xml file containing security policy settings related to the .cab.pkg being deployed.
As such, I would recommend anyone interested in cracking the bootloader and creating a "HardSPL" take a good hard look at the Zune HD.
Similar to CE5/WinMo 6.x, There is a BLDR (Base Boot Loader) which makes the initial determination to boot up to the ULDR or to the WP7 OS. The OEM implements alternate boot parameters to trigger this and/or a button press combination. If ULDR is triggered, it checks the battery and power source to ensure that there is enough life remaining to successfully complete the flash, then awaits the flash download. There are redundant ULDR partitions (ULDR1/ULDR2) to facilitate failsafe recovery in the event of a failed ULDR flash (ULDR provides a basic level of functionality to enable a recovery flash even in the event of power failure during a flash)
MSFT is pushing it's Phone Update service much harder this time - it is intended to be used as the primary method for distributing phone updates. These can be deployed both over-the-air and through a USB connection with the Zune software.
Last edited by a moderator: