OMAPBootrom » History » Revision 11
Revision 10 (Denis 'GNUtoo' Carikli, 03/29/2020 12:29 AM) → Revision 11/23 (Denis 'GNUtoo' Carikli, 03/29/2020 12:31 AM)
h1. OMAPBootrom h2. Generic documentation TODO: Read the various TRM and push the info to wikidata: * check the various SOCs the sram size limit in the TRM. * check the load address / memory mapping of MLO in case of USB boot or boot from eMMC in the TRM. * Check mmc1 booting constraint (card size, look if < 4GiB works) in the TRM Also: * Read the TRM sections about SYS_BOOT and booting and document that, ideally write a tool for it, or upstream the code in some other tool. h2. Documentation The "droiddevelopers website":http://droiddevelopers.org has some information on trying to use bugs run free software on several Motorola devices. | Device | SOC | | "Motorola Milestone":https://en.wikipedia.org/wiki/Motorola_Milestone | OMAP 3430 | | "Motorola Milestone 2":https://en.wikipedia.org/wiki/Motorola_Milestone_2| OMAP 3630 | | "Motorola Defy (MB525)":https://en.wikipedia.org/wiki/Motorola_Defy | OMAP3630? | | Motorola Defy+ (MB526) | OMAP3 (which one?) | That website has many information: * It has documentation on the structure of signed MLOs TODO: * Read droiddevelopers more to understand restricted boot better. * Also the OMAP wiki might have some information on OMAP restricted boot. * Also look if there is substancial information in the Technical Reference Manual (TRM) about fuses but that's unlikely. h2. Code * As march 2020, there are no fuses driver or code for any OMAP in either u-boot, Barebox, Linux, or crucible. * U-boot documentation mention TI tools that have to be obtained after signing an NDA * TODO: check if chipsec has infos on OMAP fuses h2. Possible attacks * Even if it's unlikely, once we understand the OMAP restricted boot better, we could check if some devices are signed but not in enforcing mode. h2. Other ideas * On IRC there was some interest in replacing the SOC by simply unsoldering it and resoldering a GP OMAP. ** TODO: check if the stock bootloader still work with that or how to make sure that the device is working after the SOC has been replaced for the first time ever. For instance we have Example: run the xloader source code for most of the supported devices stock bootloader on a single board computer with an OMAP SOC, so we can get UART output. But could the people replacing the SOC know about how to check if the device works with such unsual constraints? UART. ** TODO: Write code that init the display and probably does a complete test of the device to make it easier for people that swap the OMAPs to check if the device works. ** Find how to handle the amount of work combined with the insecurity of the supply chain for the OMAPs ** Make sure that POP are not needed!!! IT's a pain to find factories that still know how to do that. See the issues the GTA04 and the Neo900 had with that. h2. Links * http://www.droid-developers.org : This attempts to run user code on several Motorolla smartphones. It includes analysis of the boot chain: ** "Application_Processor_Boot_ROM":http://www.droid-developers.org/wiki/Application_Processor_Boot_ROM ** "Booting_chain":http://www.droid-developers.org/wiki/Booting_chain