[HTC Pico (Explorer)] no.human.being:
It is definitely locked by Iguana (mARM). When you "map" the "unmapped region" into CWM and then try to erase it using "nand_erase" utility from "mtdutils" (I've built them from source some time ago - may put them up here in case you're interested) it will fail (and your device won't brick ;) ).

The questions are:

1) What will happen if an "erase"/"write" command is set off by the (Linux) kernel running on aARM that hits a page that is locked by the (L4/Pistachio) kernel running on mARM?

2) What will happen if an "unlock" command is set off by the (Linux) kernel running on aARM that hits a page that is locked by the (L4/Pistachio) kernel running on mARM?

3) Then how comes that HBOOT can write to locked pages?

The answers are:

1) It is probably blocked by the MMU as the purpose of the "locked" flag is to keep the contents of a page from being altered. We haven't directly tested it though, since an unmodified Linux kernel will check whether the page is locked first and then not set off the "erase" command.

2) It is probably blocked by the MMU as the pages can probably only be unlocked by the instance that locked them in the first place. We haven't directly tested this though, since setting off an "unlock" command on an MSM chip is not implemented in Linux, probably because Linux never needs to "lock"/"unlock" pages itself.

3) Probably because it somehow "authenticates" with Iguana first, which then takes its locks off the pages, so that HBOOT can perform write operations on them. HBOOT then somehow "commits" that it has completed its changes and Iguana locks the pages again. We don't know how this "authentication" works, since we have never seen it happen. We just have the reason to believe that "some kind of mechanism is in place", otherwise the entire memory protection thing wouldn't make a lot of sense.

My question to you: Why do you think that it's easier to step through CWM recovery and find the code? The recovery is based on a Linux kernel which has a code base that's several times larger than that of HBOOT, and, being as "modular" as Linux is, will use lots and lots of "abstractions" and "indirections" to accomplish these things, which is what makes Linux portable across architectures. HBOOT on the other hand can have a relatively simple architecture that works for MSM chips only, since it was never designed to run on anything else. Take a look at the code base of a Linux kernel. It's extremely extensive. Then take a look at the code base of UBOOT (the bootloader for embedded Linux). It's a lot less extensive. HBOOT is even smaller than UBOOT, since it lacks lots of advanced features that UBOOT has.

And before you ask why we don't use UBOOT as a bootloader: First, it hasn't been ported to the MSM7227/MSM7225A processor yet and we can't port it since this requires a lot of knowledge about the internal workings of UBOOT and of the MSM7227/MSM7225A processor which we both don't have to that extent. Second, UBOOT is designed to boot a Linux kernel, not an Android kernel. While Android is based on Linux, it has a few "tweaks", among them a different kernel binary format. This means that we would either sacrifice the ability to boot "normal" Android kernels (that every ROM/Recovery uses) and we'd have to build special ROMs/Recoveries for "Wildfire S (UBOOT)" and "Explorer (UBOOT)" as if they were devices that were "distinct" from "Wildfire S" and "Explorer" (which is bad and will prevent people from migrating to UBOOT) or we would have to create a "fork" of UBOOT that can boot Android kernels (which we don't have the knowledge and manpower to do).

I'm not saying that we will never port UBOOT, but mind that this is a HUGE project and I don't know a lot about it yet. In case you're still interested and motivated after we have patched the devices S-OFF, I'll be happy to take it on, just because it's "the next big challenge", but it's not the thing we should take on first, as this can literally take ages. UBOOT can actually do A LOT of cool stuff that would be VERY useful for devs, but this comes at a price and this is greater complexity.