This is the boot chain of the Motorola Milestone, as far as we know1):
| Boot part | Processor | Arch | Dump | Disassembly/Decompilation |
|---|---|---|---|---|
| OMAP boot ROM | OMAP core | armv7-a | OMAP3430 BootROM, OMAP3630 BootROM | rom.idb |
| mbmloader | OMAP3430 core | armv7-a | none | mbmloader.idb.gz |
| mbm | OMAP3430 core | armv7-a | none | mbm.idb |
| lbl | OMAP3430 core | armv7-a | none | none |
| Wrigley arm boot ROM | Wrigley3G ARM core | arm9 | none | none |
| Wrigley dsp boot ROM | Wrigley3G TMS320c55x+ | c55x+ | f00000.gz2) | none |
| Wrigley3G RTXC OS loader | Wrigley3G ARM core | arm? | none | bploader.idb.gz |
| Wrigley RTXC OS | Wrigley3G TMS320c55x+ | c55x+ | none | none |
| Main DSP boot ROM | TMS320C6454 | MIPS (c64x+ edition) | none | none |
| Main DSP firmware | TMS320C6454 | MIPS (c64x+ edition) | baseimage.dof | none |
| WiLink firmware | WiLink 6.0 TPS656905 | arm | wl1271.bin.gz and fw_wlan1271.bin.gz | none |
| Power Manager Boot ROM | TWL5030 | MIPS? | none | none |
| Touch Panel Controller boot ROM | AVR ATmega324P | AVR 8-bit | none | none |
| Linux kernel | OMAP3430 core | arm | none | none |
All recent IDA databases of bootloaders can be found here Gitorious
(!) the CH table can be signed with CSST along with the Initial Software image. Whether Motorola did include it in the signed image or left it unsigned is unknown (and risky to test!). 3)
After kokone has found that the origin mbmloader contained bit errors, the correct mbmloader binary image has been obtained again. That he has been able to validate all the signatures in mbmloader and the CH table is not part of any signed content.
(!!) in fact mbm and mbmbackup are binary identical, so mbmbackup DOES contain certificates. But its certificates are not referenced in the cdt table because it is used directly by the mbmloader (and the mbmloader doesn't use the cdt table, as discovered by yakk). In the Droid mbm and mbmbackup are binary identical, just like in the Milestone (but with a different code version). One Droid user (Orgg) had an incident with his phone in which his mbm partition became corrupt, and the phone wouldn't boot at all after that. This would suggest that the mbmbackup partition is not used for automatic recovery. User [mbm] reports that his Droid originally came with different mbm and mbmbackup, but after an update pushed by Verizon they became identical. In light of this, the mbm_backup_attack was proposed but then found to be flawed and discarded.