[HTC Wildfire S] no.human.being:
With "stock" I mean "unmodified Linux or Android kernel", not neccessarily "kernel from HTC stock ROM". I'm not aware of any kernel that's currently ignoring the flags. We'll have to take an existing kernel that successfully builds from source for and runs on our device and then modify its mtd driver to either ignore the out of band area or to treat it in a way the Radio expects it.

Where did you get that table from and what do the values mean exactly? It seems to contain the physical offset of what is where inside the Radio partition. E. g. it says APSBL at 0x02400000 - 0x024c0000. We know that APSBL is the same as HBOOT and 0x02400000 - 0x024c0000 is the physical address where HBOOT lies on our devices. At least these with the "new" memory layout, there seems to be a different memory layout which has the HBOOT at 0x02b00000 - 0x02bc0000. My phone has this "older" layout. We're not sure why there are two different layouts though. We first thought that this is due to the Radio version, however there are some "counter examples", devices featuring the "new" layout but the "old" Radio version or vice versa, so the two probably don't go hand in hand.

I think the PBL is not on the NAND at all. I expect it to be "hard programmed" to the controller during manufacturing (meaning the "program" lies in the semiconducture structure of the processor itself, so it's not really "software").

Apart from the partitions you see while the phone is booted up, there is one "unmapped region" (what we call "Radio partition"), that holds the REX with UMTS transceiver firmware and the HBOOT (APSBL), as well as some firmware for the WiFi transceiver. Personally, I would say the WiFi thing is part of the REX as well, as I expect it to run on the ARM9 processor, where the rest of the transceiver stuff runs. However, the memory layout is that there's first the mobile network (GSM/UMTS) transceiver firmware (lowest addresses), then HBOOT (APSBL, higher addresses), then WiFi transceiver firmware (highest addresses) and then the unmapped region ends and the visible partitions begin. So it's ARM9 (UMTS transceiver, lowest physical addresses) --> ARM11 (HBOOT) --> ARM9 (WiFi transceiver) --> ARM11 (visible partitions, highest physical addresses). The "interleaving" of code that's destined to run on the baseband (ARM9) and application (ARM11) processor looks quite arbitrary. Therefore I think that the distinction between ARM9 and ARM11 is not all that important and I treat this area as one "contiguous firmware image" that I call "Radio partition", as that's what takes up most of the space on this partition.

For patching the HBOOT, we don't map the entire "Radio partition" as an mtd device, but only the physical addresses that actually contain the HBOOT code. This is because the REX contains even more corrupted memory pages that cause the NAND erase procedure not only to skip over them, but to actually

abort

at some point, claiming the memory is bad. When reading, this "extremely corrupted region" does not cause any problems, but it might cause severe problems when erasing and writing, so I avoid it by not mapping the entire Radio partition, but only the pages that actually contain the HBOOT code. This one is also "corrupted", but the corruption is not as bad as it is in some parts of the REX. :D

Yeah, it's already some pages back. :D