How to load mbmloader from SD card
After software reset, OMAP BootROM checks scratchpad memory at address 0x48002910 where can be address of "software booting configuration".
The software booting configuration is a simple structure at the address stored
at the first location of available scratchpad memory: 0x48002910. There are two sections in this structure:
- The first section provides devices for the booting device list.
- The second section provides clock settings, which are applied before booting.Devices to be put on the device list 0x00: Void, no device 0x01: XIP memory 0x02: NAND 0x03: OneNAND 0x04: DOC 0x05: MMC/SD2 0x06: MMC/SD1 0x07: XIP memory with wait monitoring 0x08 to 0x0F: Reserved 0x10: UART 0x11: HS USB
We will use boot device "0x06: MMC/SD1" to load mbmloader and device "0x11: HS USB" to check if boot from SD was failed.
Prepare file to load
- You need to have original mbmloader from Milestone's NAND (first 128K) in file.
- Then replace string X-LOADER to MLO inside second 512 bytes block.
- Rename file to MLO
- Reduce file up to end of mbmloader code.
- Copy this file to the root directory of SD card. Partition should be "active" and formatted as FAT16/32. I think default formatting of SD card by Milestone is Ok.
Prepare code to software reset the Milestone
We need to create right structure inside scratch memory and to do software reset. I've selected address 0x480029B0 to store booting configuration.
I've used 2ndboot module from yakk to inject my code, because I'm not ready to develop full kernel module yet.
Example of my code:
#define SCRATCH_MEM 0x48002910
#define GLOBAL_REG_PRM 0x48307200
scratch_mem = ioremap(SCRATCH_MEM, 240);
global_reg_prm = ioremap(GLOBAL_REG_PRM, 256);
// Disable IRQ
// Store address of booting configuration structure
__raw_writel(SCRATCH_MEM+0xA0, scratch_mem + 0);
// Header of booting config
__raw_writel(0xCF00AA01, scratch_mem + 0xA0);
// Size of booting config
__raw_writel(0xC, scratch_mem + 0xA4);
// First booting device is 0x06
__raw_writel(0x00060000, scratch_mem + 0xA8);
// Second is 0x06, third is 0x11
__raw_writel(0x00060011, scratch_mem + 0xAC);
// Fourth is 0x11
__raw_writel(0x00000011, scratch_mem + 0xB0);
// software reset
__raw_writel(0x04, global_reg_prm + 0x50);
Here is archive with compiled module and Motorola's mbmloader: File:Boot from sd.gz
Put all of them together
- Copy module 2ndboot_mmc_usb.ko to root of SD card where MLO copied
- Run command: insmode /sdcard/2ndboot_mmc_usb.ko
Your phone should black screen and reboot successfuly, if your MLO file is Ok. If you remove MLO file from SD card and load module again, your phone should be in infinite loop of tries to boot from SD card (unsuccessful) and from USB, so your computer should see tries of USB enumerations every 3-4 seconds. You may "fix" your phone from that state by battery removing only (or maybe you can try to upload some mbmloader through USB, but it should be signed by Motorola).
Why all of this ?
We can try to load changed mbmloader and see which effect it has, without flash the phone. For example: you can try to change CHSETTINGS because it's not signed. Also we can try to break RSA checks in some way.
Follow-up of the process
Although no 3rd party tester has been able to repeat the scene from booting from MLO on Milestone, it is confirmed that(by another user Nothize other than the original writer SergeyZH) (on Windows) the control panel -> system -> hardware -> device manager can be used to monitor the USB enumeration after the phone has entered the software boot device list state.
A standalone module has been written based on the code above to try a boot list of three 0x11(HS USB) and one 0x11 respectively and the response of the USB enumerations comply with these two sets.
The setting for MLO and USB booting should refer to the ROM code memory and peripheral booting guide.