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

1. PBL (primary bootloader)

2. DBL (device bootloader)

3. OSBL (operating system bootloader)

4. REX (radio executive)

5. AMSS (advanced mobile subscriber software)

6. APSBL (application processor secondary bootloader) aka HBOOT

7. Android kernel

1 - 3 is processor specific firmware by ARM Ltd. Yes OSBL is by ARM Ltd. as well. It does not belong to REX, which is the operating system that it loads. It acts as some kind of "virtual machine monitor" doing very processor-specific stuff. See more below.

4 and 5 are designed by NICTA (an Australian research corporation) and licensed by Google for distribution with Android. 4 is the operating system. It consists of an operating system called Iguana and a kernel called Pistachio. (Both open-source btw!) This is a very very stripped-down operating system. Basically it's just doing scheduling and some memory management. No driver interface, no privilege separation, nothing. Processes running on this OS have full control over the hardware, like if they were running on "bare metal". 5 is the software that's being run on the operating system. I haven't found any sources for 5 yet, so it seems to be proprietary.

6 is HBOOT. It is based on the Android reference bootloader from Google with modifications by HTC. HBOOT is definitely proprietary. I think the reference bootloader is under NDA, so it's also not accessible.

7 is GPLed software by Google.

In fact 4 and 6 are loaded into memory by 3 and run concurrently. So 3 is basically like a very stripped-down "virtual machine monitor" which allows two system-level programs (initially REX and HBOOT) to run concurrently.

At the beginning, REX has exclusive control over persistent memory and HBOOT is loaded into memory, but halted (its virtual machine has not yet executed any instruction). REX then loads AMSS and all it requires into volatile memory (RAM) and then "gives up control" over the perstistent storage (Flash). When this is done, it "signals ready" to the virtual machine monitor, which then "unlocks" execution on the other virtual machine as well, so that REX and HBOOT run concurrently from this point, with HBOOT claiming full control over the Flash memory for loading Android into RAM and passing execution to it. Finally, REX and Android run concurrently with Android having full control over the Flash memory.

REX has an RPC-like mechanism to ask the Android kernel to push data from Flash into RAM or put it back from RAM into Flash, as it is no longer allowed to directly access the Flash as soon as HBOOT has started executing and of course this policy is still in place when the Android kernel is run. Communication between the two system-level processes running in parallel (REX <--> HBOOT or REX <--> Android) occurs via shared volatile memory.

Exactly.

I don't think so either. Luckily, HBOOT is out of control as soon as a kernel is run. Currently "my" kernel is not configured to map in any portion of NAND. At the moment it just runs software from the initrd, which lies in RAM. This is also to ensure that we're not accidently damaging any firmware by a kernel that's trying to "mount something" from the NAND that "looks like a file system". So in this sense it's currently not designed to "violate any policy", if there were one in place.