[HTC Wildfire S] no.human.being:
The boot process is as follows.

Phase 1: Initialization

1. ARM9 (baseband processor) is running, ARM11 (application processor) is halted (has not executed a single instruction).

2. ARM9 executes PBL (Primary Boot Loader) from on-chip ROM.

Phase 2: PBL active

3. PBL verifies signature of OSBL (Operating System Boot Loader).

4. PBL performs hardware initialization.

5. PBL loads DBL (Device Boot Loader) into RAM and executes it.

Phase 3: DBL active

6. DBL verifies signature of OSBL (Operating System Boot Loader).

7. DBL loads OSBL into RAM and executes it.

Phase 4: OSBL active

8. OSBL loads REX (Realtime Executive, aka "Radio firmware", consisting of Pistachio + Iguana + AMSS) into RAM and executes it.

Phase 5: REX active

9. REX initializes the baseband processor, auxilliary processors (MicroP's) and the DSPs.

10. REX "gives up control" over NAND and "signals ready". The latter allows the ARM11 to start executing code.

11. REX runs the AMSS (Advanced Mobile Subscriber Software).

Phase 6: REX + APSBL active

12. The ARM11 loads the APSBL (Application Processor Secondary Boot Loader, aka HBOOT) into RAM and executes it. HBOOT is based on some kind of "reference bootloader" that Google has released some time. "Based" is an extreme understatement. HBOOT and this "reference bootloader" are basically the same code. All the debug symbols released by Google perfectly map to HBOOT. Sadly, this "reference bootloader" is no longer available to the public, but only under NDA.

13. The APSBL (HBOOT) further initializes the controller (setting up some page tables), then loads the operating system image (kernel + initrd) into RAM and executes it.

Phase 7: REX + Android active

14. Android is running alongside the REX (Radio firmware). All the other software components have "disappeared" at this stage. They were only used for initialization.

Phase 1 to 4 are all firmware by ARM Ltd. It's nothing that's in any way device specific or specific to Android. Phase 5 to 7 are all code that's in some way either licensed by Google (phase 5, REX was developed by University Karlsruhe, then licensed by Google) or directly developed by Google (phase 6 and 7, bootloader and Android kernel were developed by Google, bootloader was then licensed by HTC and other manufacturers to include in their devices). We can modify everything that's phase 5 onwards, as they all reside in NAND that we can access when our operating system is booted. And the phase 1 to 4 components (the ones we cannot modify) never verify any of the phase 5 onwards components, they only verify each other "among themselves" (so they verify other phase 1 to 4 components) and this is not a problem, since we can't change this software anways. No one can modify it. HTC can't modify it either. It's "burned" to the controller during manufacturing and cannot be changed anyhow. So the signature verification is moot. All it does is verify that components, that can't be changed anyways (as they reside in a ROM, a

read only memory

), actually weren't changed. :D

And no, the ARM9 (baseband processor) cannot prevent us from writing to NAND, as our ARM11 (application processor) is having (exclusive) physical access to the chip at this stage. In fact, our kernel on the ARM11 could prevent the Radio firmware on the ARM9 from accessing the NAND or provide false data to it should we have any reason to do so, since the ARM9 must not access the NAND itself. Instead it relies on remote procedure calls to the Android/Linux kernel on the ARM11 to make the application processor access NAND on the Radio's (or baseband processor's) behalf.

Also remember that HBOOT can flash the Radio and also the HBOOT itself, e. g. when flashing an RUU. HBOOT is running on ARM11 (application processor) just like our kernel is. Therefore our kernel is able to do

at least

everything that HBOOT is able to do.