Replicant

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. Simply replacing the SOC with a GP version

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 the xloader source code for most of the supported devices 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?

* 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.

Devices:

* It's probably easier to start with a Galaxy SII (GT-I9100G) as it has a microSD slot and that the UART is exported through the USB connector. The microSD slot could be used to boot over the microSD easily.

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