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


The droiddevelopers website has some information on trying to use bugs run free software on several Motorola devices.

Device SOC
Motorola Milestone OMAP 3430
Motorola Milestone 2 OMAP 3630
Motorola Defy OMAP3630?
Motorola Defy+ (MB526) OMAP3 (which one?)
That website has many information:
  • It has documentation on the structure of signed MLOs
  • 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.
  • Learn more about the following (from #replicant on Freenode):
    sensiblemn: "X-Loader can be signed by Texas Instruments IFT and installed to Nand flash to achieve Nand booting." 
    sensiblemn: [...] There's also this curious part... "download the MShield signing tool and use the commands below. Contact your TI representative to get access to this tool." 


  • 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

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.

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.

For some SOCs like the Allwinner A20, it looks relatively easy to do . That is probably not the case for every SOCs as simply soldering a SOC can be really complicated sometimes (look for reballing for more details on how things can go wrong, and how it's typically repaired).

  • Identify the very precise SOC.
  • Make sure that POP is not needed. It's a pain to find factories that still know how to do that. See the issue that the GTA04 and the Neo900 are having with that. Note that this can sometimes be seen in the bootloader the source code in the code that tries to identify the device or RAM chip. if the eMMC and the RAM chips are together in the same package, it's then possible to identify the RAM chip simply by identifying which eMMC is there (eMMC have vendor and product IDs among other information).
  • Make sure it's easy enough to do for people doing microsoldering board level repairs.
  • Ideally make sure that the SOC replacement is safe for the environment (RHOS, CE, no lead, etc)
  • Find a way to test the device once the SOC has been replaced for the very first time: We can compile the Xloader source code and load that, and get some prints on the UART, however we need to make sure that we can work in tandem with the person doing the SOC swap in order to validate that everything works together. If not, that person might just restore the normal bootloader and declare the "reparation" a success for instance. Or the person might expect the display to work or to have the stock bootloader which might not even work in GP mode because we don't have TrustZone there. The downstream Linux might not even work either because of TrustZone and the upstream Linux might lack a display driver for instance.
  • 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: If we buy only 1 OMAP and do a lot of work, and when the work is done we can't find any anymore, it would not be a good idea. If we buy a lot and nobody does the work it won't be a good idea either. We don't want to force people to work on things either as it would be a very strong attack on their freedom.
To find a suitable device, the following characteristics are relevant:
  • To have a SOC in a package that is very easy to find new (so which is likely unsigned). This is probably not easy as smartphones manufacturers are trying to make thinner and thinner smartphones over time, but we might as well be lucky and find one.
  • Having a microSD slot could be handy to try bootloaders on microSD
  • If the UART is easy to access and documented it can make the bootloader port much much easier
  • If there is an easy way to recover, like the ability to boot through USB, it could be handy, but we could also boot and make sure the SOC reboots to the microSD slot if there is one.
  • To have Replicant 6.0 support is not that important because if we get rid of TrustZone we will probably not be able to run the downstream kernel.


Device Markings on the chip package that contains the SOC Other relevant features
GT-I9100G_CHN_CHN KMVYLOOOLM-B503 * MicroSD slot
* UART exposed through the USB connector and well documented
* Configured to boot through USB first
GT-I9250?[1] KMVYL000LM2 * No microSD slot
* UART exposed through the USB connector and well documented
* Configured to boot through USB first

1 We need to check which exact model variant it is. Ifixit usually use the generic model like Galaxy SII instead. And on some variant even the SOC can differ.

2 See the Step 12 of the Galaxy Nexus Teardown by Ifixit

If the chip is in a custom package like with the GT-I9100G_CHN_CHN and Galaxy Nexus:
  • If the replacement chip comes from broken devices, then it'll most likely already be signed
  • If the replacement chip is new (it could for instance comes from over production or other means) it'll probably not be signed. The rationale behind that is that devices are typically fused in the factory. To do that they typically load the first software through USB or other external means which can then flash the bootloader and fuse the SOC. This is documented in various technical reference manual of system on a chip like various I.MX6 manuals where they talk about loading code for the first time which is then used to program the fuses, which in this SOC family can also configure the boot media.

The issue with these custom packages is that they might not be as available in low and large quantities as regular OMAP SOCs, which are probably already old and so harder to find.

  • hpagseddy on #replicant on Freenode is interested in working on the hardware parts of it.


Updated by Denis 'GNUtoo' Carikli about 4 years ago · 23 revisions

Also available in: PDF HTML TXT