[Captivate Android Development] Master Melab:
Rebellos and AdamOutler,

I would like to post a comprehensive explanation of how the boot process works up until the second stage bootloader.

Definitions

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

BL1 — the first stage bootloader that is really two parts: BL1A and BL1B; this can be overwritten

BL1A — this is what Rebellos refers to as "BL1_stage1"; along with BL1B, it comprises BL1; this can be overwritten

BL1B — this is what Rebellos refers to as "BL1_stage2"; along with BL1A, it comprises BL1; this can be overwritten

BL2 — the second stage bootloader; this can be overwritten

Read this: The above definitions may or may not be what Samsung uses. Also, what is occasionally referred to as IBL, PBL, or SBL may or may not be the same as some of the above terms.

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

the S5PC110 is also known as "Hummingbird".

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.

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. This doesn't mean that a Hummingbird processor cannot be ordered with a custom iROM.

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. Motorola uses TI's OMAP processors.

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.

Back to the 160-bit hash. The hash is most likely SHA-1.

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.

iROM (whether executed in place or copied to iRAM) will check to see if any of the eFuses blown.

Since the applicable devices have blown eFuses, iROM will hash the RSA key (whether it be on an SD card, delivered over USB or UART, or from oneNAND; I know for sure an RSA key is in oneNAND, not entirely sure about UART, USB, and SD cards).

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

Assuming the signature is valid, BL1A will load BL1B, without checking for a signature.

BL1B loads BL2.

In short, BL1B is what Rebellos modified.