[Defy Q&A, Help & Troubleshooting] Teedub:
Defy boot process

Here's a summary of what I've learnt so far about the Defy boot process, from the many great posts on this forum and various other sites including the droid-developers wiki:

SoC:

- Defy SoC is Texas Instruments OMAP3630, locked by eFuse in HS (high security) mode, JTAG is disabled

- OMAP contains core boot ROM that runs first to start the boot chain

- OMAP contains Motorola 128-bit RSA public key hash programmed in eFuses, used to validate external bootstrap code (mbmloader)

- OMAP supports booting from external memory (MMC, NAND, NOR) and peripheral booting (USB, UART3)

- OMAP boot sequence is set by sys_boot pins, Defy configured boot sequence is 0b00101, ie. MMC2 then USB (only)

Storage:

- External flash is Sandisk SDIN5D2-2G (2GB eMMC, BGA package) connected to OMAP MMC2 interface, mapped as mmcblk1 in linux

- eMMC device is physically located under the metal can between the connectors for SIM card and battery

- eMMC behaves as conventional 512-byte sector hard disk and is partitioned with FAT MBR

- eMMC does not use separate ECC area, unlike the NAND flash used on the Droid, ECC is handled transparently by eMMC device

- SD card is connected to OMAP MMC1 interface, mapped as mmcblk0 in linux

The Defy (stock) power-on reset boot process works as follows:

- OMAP boot ROM code starts

- OMAP reads boot configuration 0b00101 from sys_boot pins

- MMC2 boot is selected

- OMAP reads first eMMC sector (the MBR)

- OMAP finds the first valid partition entry in the MBR

- OMAP reads the first eMMC partition (which is the Defy CG63/mbmloader) as a raw image (not a filesystem)

- OMAP processes the CH table (OMAP clock and SDRAM settings) from the first sector of the image (possibly unsigned)

- OMAP validates the public keys, PPA and ISW stored in the image, using the eFuse key hash

- OMAP copies the ISW (which is MLO, or the actual Motorola mbmloader bootstrap executable) into internal RAM

- mbmloader (if validated) is executed from RAM, otherwise the boot process skips to USB (below)

- mbmloader validates and loads mbm (the Motorola bootloader) from the second eMMC partition

- mbm detects the "volume up" button if pressed to interrupt boot and display the bootloader screen

- mbm displays the boot logo and loads lbl (linux bootloader)

- lbl loads the stock linux (android) kernel (or the stock recovery kernel, if the "volume down" button is pressed)

- linux kernel displays the startup animation

If MMC2 boot fails (no valid MBR/mbmloader):

- USB boot is selected

- USB is initialised (device is now detectable as TI OMAP3630 for 3 seconds)

- OMAP sends ASIC ID

- OMAP waits 300ms for response

- If no response, OMAP halts (infinite loop)

- USB host can send command to change boot device or upload (signed) boot image (unknown format) for execution in RAM

Therefore if the device is trying to boot via USB, it probably means that the eMMC MBR or the first partition (containing mbmloader) is corrupt, or the eMMC is blank. Presumably if the mbm (and mbmbackup?) partition is corrupt, the device will hang with screen off and no USB boot (unless mbmloader can exit to OMAP USB boot), and if lbl or the kernel is corrupt then mbm will stop and display the bootloader screen.

eMMC partition table for Defy (start/end sectors), based on a dump of mmcblk1 from a working Defy, noting respective CGs for SBF:

Device Boot Start End Blocks Id System CG ID Function
0 255 128 64 mbr FAT MBR
1 * 256 511 128 83 Linux 63 mbmloader Motorola bootstrap
2 1024 2047 512 83 Linux 30 mbm Motorola bootloader
3 2048 3071 512 83 Linux 55 mbmbackup
4 3072 31358975 15677952 5 Extended 65 ebr FAT EBR
5 4096 5119 512 83 Linux 56 bploader
6 5120 6143 512 83 Linux 31 cdt.bin CG table
7 6144 14335 4096 83 Linux 38 pds
8 14336 15359 512 83 Linux 34 lbl Linux bootloader
9 15360 16383 512 83 Linux 57 lbl_backup
10 16384 18431 1024 83 Linux 42 logo.bin mbm startup logo
11 18432 22527 2048 83 Linux 41 sp
12 22528 23551 512 83 Linux 61 devtree
13 23552 24575 512 83 Linux 62 devtree_backup
14 24576 32767 4096 83 Linux 45 bpsw
15 32768 49151 8192 83 Linux 35 boot Stock android kernel and ramdisk
16 49152 65535 8192 83 Linux 47 recovery Stock recovery kernel and ramdisk
17 65536 94207 14336 83 Linux 33 cdrom
18 94208 95231 512 83 Linux 44 misc
19 95232 96255 512 83 Linux 43 cid
20 96256 104447 4096 83 Linux 53 kpanic
21 104448 774143 334848 83 Linux 39 system
22 774144 775167 512 83 Linux 32 prek
23 775168 776191 512 83 Linux 46 pkbackup
24 776192 1185791 204800 83 Linux 40 cache
25 1185792 31358975 15086592 83 Linux 37 userdata

My understanding is that if the eMMC is blank, I need to flash an SBF that contains at least the RAM downloader, CG64, CG63, CG30, CG65 and CG31 to reinstate the eMMC partition structure and bootloader. I think RSDLite should be capable of this (with "TI Blank Flash" enabled), unless the flash loader (RAM downloader) somehow depends on some content of the eMMC containing valid data. I don't know if such an SBF exists, and in any case RSDLite so far fails with "Error sending TI ROM data packet request", and I don't know why (tested under XP and Windows 7/8).

Awesome references:

http://xdaforums.com/showthread.php?t=1443678

http://www.droid-developers.org/wiki/Booting_chain

http://www.droid-developers.org/wiki/Mbmloader

http://blog.opticaldelusion.org/search/label/sbf_flash

https://docs.google.com/spreadsheets/d/1jF8LjoS1yiMxn775QDm-cn5kxpoYw_biIC70uf9_ldY/pub?single=true&gid=0&output=html