[HTC Pico (Explorer)] no.human.being:
So the behaviour is different from a WFS (MSM7227) HBOOT.

1. An MSM7227 HBOOT will always boot into the ROM when no keys are pressed, no matter if SD card is present or not.

2. If Vol-Down is pressed, it will display the HBOOT menu (showing "HBOOT" not "HBOOT USB" meaning USB is not initialized yet). Then a decision is made.

3. If an SD card is present, it will check for a file called "PG76DIAG.nbh", then restore stock HBOOT from the Radio and start over at step 1, which means the restored HBOOT will boot into the ROM when no keys are pressed and it will show its menu when Vol-Down is pressed. The decision is made BEFORE USB is initialized. It will still display "HBOOT" when reverting to stock, not "HBOOT USB".

4. If no SD card is present, it will not check for any files and lock up. The lock up happens BEFORE USB is initialized. It will still display "HBOOT" when freezing, not "HBOOT USB" and the phone is not detected by the host computer (not shown in "lsusb").

At first I had a feeling that the "locking up" is some sort of "waiting condition" (some "busy waiting" stuff like a spinlock) that waits on something that never happens, e. g. waits for a ressource to be released that is never released or waits for an interrupt to occur that never occurs. I thought that it's probably something that happens only once per "proper cold boot" and it's already happened for the "true" HBOOT so it won't happen for the "chainloaded" HBOOT again. I thought that it's probably not a security mechanism, but simply a fact that HBOOT has not been designed to be run twice. However, at least for the WFS HBOOT this cannot be the case, since we can run "normal" HBOOT (1st time HBOOT runs), then "chainloaded" HBOOT (2nd time HBOOT runs), then that "chainloaded" HBOOT realizes that it's been tampered with and restores "normal" HBOOT from Radio and runs it again (3rd time HBOOT runs) and it doesn't lock up. Of course you can let the "3rd HBOOT" run the "chainloader-exploit" again, load a 4th HBOOT, let it restore (5th HBOOT) and so on. You can make the chain as long as you want, it will never lock up. So my "initial feeling" about "only running HBOOT one time per cold boot" is most likely wrong.

On the other hand, the "revert to stock HBOOT" thing that the WFS HBOOT does, definitely looks like a security mechanism and I'm quite positive that the WFS HBOOT would not lock up when this check was bypassed, although I cannot prove it since I don't know where the "reverting routine" is called and I also don't have a device where I could run the WFS HBOOT on.

Last but not least, this behaviour (showing HBOOT menu only when Vol-Down is pressed, otherwise boot into ROM, locking up when no SD card present before USB initialized, reverting to stock HBOOT when SD card present) is ABSOLUTELY consistent among ALL HBOOT versions that are there for the MSM7227 chip. This means that it's probably very basic/fundamental code that has been there since the beginning of HBOOT development by HTC and that was probably never touched/modified again.

Of course, in either case (reverting WFS HBOOT or locking Explorer HBOOT) JTAG access would be absolutely helpful. With JTAG, we could single-step the processor and see when it enters an infinite loop (locks up) and we could probably also see where it restores stock HBOOT since it will query a lot of data (several hundreds of thousands of words) from the "unmapped area" (that is part of memory shared with Iguana/Radio) and write it into the first memory page (this is where HBOOT is loaded to by the OEMSBL before aARM is released from halt).