Join us in a fun Sunday Debate on Cyanogen Inc. Come with your opinions and feel free to read some of our thoughts, then pick your side or play devil’s advocate to get your voice heard and engage in friendly discussion. You can read our food-for-thought or jump straight into the fray below! CyanogenMod is widely recognized across XDA for its solid performance, great feature set and far-reaching (and also long-lasting) support for all sorts of devices, from...
Windows Phone 7 Facts: How About ROM Cooking?
This is part 2 of the Windows Phone 7 Facts series. In the following weeks, we will be covering the more technical side of the currently unreleased Windows Phone 7 OS by Microsoft. In the previous article, we were talking about the new installation package called .xap to replace the .cab files.
All information is based on some interesting, XDA-Developers.com exclusive information from XDA member and moderator Da_G. There will be some more changes to the way we were working with Windows Mobile.
One thing that interests most Windows Mobile ‘power’ users, is the ROM.
So will we be still working with the knowm .NBH files when the first HTC WP7 devices come out? The answer is No. Every OEM uses his own design for ROM deployment. HTC uses .nbh files and the RUU system. LG uses .dz/LGMDP files system. No longer this custom design is allowed. There will be standardized requirements for OEMs for Windows Phone 7 Devices.
So you might be shocked thinking that we would have to develop new kitchens, new tools, etc. Fortunately, the tools we are currently working with will work flawlessly with the new ROM format, B000FF or .bin. The image format will only get some minor changes when compared to CE5 images.
The way the boot loader handles image deployment will change significantly though:
Originally posted by Da_G
For Samsung and a handful of other manufacturers, this (read: ‘image deployment’) 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)
Don’t worry if you don’t get this, to summarize: The image deployment of WP7 will be different from older versions of Windows Mobile.
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 (read ‘Native Kernel’) (IMGFS, >=4.5MB) – At least 1MB free space for updates
- OS (IMGFS, >=181MB) – At least 20% free space for updates
- User Store (TexFAT)
The User Storage are all the files you can explore using a file explorer (For example /Windows, /Program Files, etc.). Thus these files are user-writeable. All other parts are ‘invisible’, and are only writeable during an update operation. The images will be transfered to the bootloader via ethernet over USB. The connection will most likely be encrypted, and probably with the same kind of encryption as the Zune HD. Fortunately the Zune HD has been hacked recently, so let’s hope they’ll be able to hack WP7 too.
There are still some more similarities to CE5 / Windows Mobile 6.x. The BLDR, Base Boot Loader, will not change; OEMs can still choose their own buttons to trigger various actions. The ULDR will still be available for a recovery flash when for instance a power failure shows up:
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)
As you can see, Microsoft will be very active in trying to get its Phone Update Service the primary method for distributing phone updates. These updates can be deployed over-the-air and through a USB connection using Zune Software.
Concluding, ROM cooking won’t be the problem, only getting the ROMs on your Windows Phone 7 phone will be a real challenge. View the original thread if you have questions or if you want some more information.
Want something on the XDA Portal? Send us a tip!
There are tons of choices to choose from when looking for a great alarm app for Android. While the stock Clock app for AOSP does the job, it may lack some of the more advanced features from competitors. Let us know what your favorite alarm clock app is for Android and why.
Did you watch Apple's VP draw on his wrist during the Apple Watch announcement and wonder "why can't my Wear watch do that?" In typical XDA fashion, one enterprising forum member has brought similar functionality to Android Wear with a twist; it works on phones and watches alike, with other platforms on the way! The app is called Pinsy, and its release debut is a strong proof of concept with plenty of room to grow. You may remember the developer behind this project, XDA...