[Captivate Android Development] Rebellos:
Thank you for starting such thing. Reading that makes everything more clear even for me. :D

@OMAP 36xx secboot: I've been browsing its manual and haven't found anything about secure boot. However, I could miss something (its about 3700 pages), or it can be in different manual (the one I've been browsing is "for public release") Anyway it has got SYS_BOOT pins, and their functionallity is almost the same as S5PC110 OM pins, so unbricking them with the similiar way should be possible also.

I'd need someone to dump OMAP36xx iROM (SGS GT for example). Anybody?

@Definitions: Seems very good to me, btw. BL levels/stages definitions comes from my code analyse, as in CPU manual the booting process is described slighty different, but I think more important is what Samsung did actually released as bootloader than some schema.

Added my comments in <code> tags, didn't modified anything I think...

Definitions

BL0 iROM — true read-only memory; iROM is a boot ROM by the definition in my signature

BL1 IBL — the Initial Bootloader that is really two parts: BL1A and BL1B; While not true ROM, this is not overwritten by Odin for reasons unknown

BL1A — this is "BL1_stage1"; It is physically separated by 0's from BL1B, it comprises part of BL1;

BL1B — this is "BL1_stage2"; it is physically separated by 0's from BL1A. it comprises part of BL1;

BL2 PBL — the Primitive Bootloader. This can be overwritten

BL3 SBL — the Secondary bootloader; this can be overwritten

A few things about the S5PC110 system-on-a-chip, iROM, eFuse

The S5PC110 is also known as the "Hummingbird" processor.

The Hummingbird is speculated to share some components with those found Apple's A4 processor, but arranged in a different manner. In other words, don't expect iOS to run on a Hummingbird chip with no problems

Each firmware (Bada, iOS, WP7, Android) and manufacturer are free to remap the GPIOs meaning buttons, UART and i2C busses may be mapped to different pins by the bootloader currently running.

This above is partially wrong. While UART and I2C pins can be in some cases used as some GPIOs, not any GPIO can be used as UART/I2C and so on.
For example: UART_RX pin can be used as any interrupt source, but EXT_INT pin, which is designed for bringing customisable interrupt source can not be used as any UART pin. In general, a lot of GPIOs of one CPU model are mapped the same on every platform, because a lot of them aren't really General Purpose, as the definition says, but has got very limited functionality. Usually changes are in EXT_INT mapping, as the same pin on one platform may mean "SD_CARD_INSERT" and on other "KEYPAD PRESSED"

The iROM across most, if not all, devices that use Hummingbird are believed to be identical. This includes the Hummingbird processor in Wave devices, Samsung's Galaxy line up, and ODROID devices.

On the SoC (the Hummingbird processor), there are 160 eFuses. Each individual eFuse represents one bit and together they comprise a 160-bit hash of a public RSA key stored the beginning of a Hummingbird devices NAND memory.

While eFuses are largely cited as being the inhibitor to custom bootloaders (and, as a result, custom kernels) on most Motorola devices, they are only used to store configuration information for the boot ROM of their respective device.

eFuses can be modified, but only once. When you blow an eFuse, you have physically broken the fuse, and, depending on the implementation, a blown fuse may represent either a 1 or a 0.

Motorola uses TI's OMAP processors. The TI OMAP does not support secure boot modes. Booting is conducted from an internal NAND.

Thats only an assumption, and only about OMAP3630, so should be changed, also Samsung is widely using OMAP CPUs

The hash is most likely SHA-1 and is truncated to 32 bits leaving a total of 4294967295 possible brute force attacks before collision.

"most likely", is what I like here about truncation, needs deeper investigation, hash is based on multi rounded SHA1 of different RSA (and/or its HMAC, which is also SHA1 hash) parts

If any of the eFuses are blown, the iROM will load the RSA key, hash it, and compare it to the hash represented by the eFuses. If it matches, it will then use the RSA key it hash to verify the digital signature on BL1A. Otherwise, you'll get an error.

If none of the eFuses are blown then the iROM will not attempt to load an RSA key (if any) and will not perform signature checks.

The boot process

Power on.

Some esoteric intermediate stuff happens that is not important.

I think all stuff that happens is setting PC to iROM EntryPoint, I guess it happens as soon as stable oscillator signal is detected and internal clocks gets to their default frequency. But... this can stay aswell. Who knows, maybe there is some microcode in core.

iROM is executed and will check the value of each of the eFuses.

iROM will hash the RSA key and compare to the IBL firmware's(whether it be on an SD card, delivered over USB or UART, or from oneNAND or USB) signature, thus beginning the hardware instantiated "Chain of Trust".

Assuming the values matched, iROM will then use the RSA key to verify the digital signature of BL1A.

Assuming the signature is valid, the HIBL BL1A will jump to a static memory location thus beginning BL1B

BL1B will load the BL2.

BL2 initializes memory and other hardware, then loads BL3 to DRAM and executes

"other hardware" is only oneNAND Controller and pins SetUp, which is also memory

BL3 with massive amounts of space available initializes nearly all remaining hardware on the device and starts the kernel.

Note: the HIBL replaces BL1 and BL2. BL1A handles authentication with the IROM, The HIBL BL1B initializes memory and calls IROM code back to perform a second, insecure download of code. HIBL performs the function of the IBL and PBL within IBL memory space.

All looks nearly perfect to me.