[HTC Wildfire S] no.human.being:
Ok ... I'll recapitulate what we've found out so far and explain where we're currently standing so that you get a basic understanding of what we're doing and how we've come there but then we'll get back to topic, ok?

There is a protocol called Fastboot (and a corresponding utility in the Android SDK that can make your computer "talk" it) that you can use to load a boot image into the phone's RAM and get it booted. That boot image is created via a utility called "mkbootimg" (makebootimage) that comes with the Android SDK. It basically takes two other files, a kernel and a so-called initrd, packs them together into an image file and probably adds some meta-information. When you have such an image, you can transfer it to the phone via Fastboot and it will get executed on the device as an operating system. It will not get flashed ("installed") on the device, so it will not persist a reboot. Think of Fastboot as the equivalent of "booting a LiveCD" in the embedded world.

Now our plan is to build a GNU/Linux operating system for our phone (so Linux kernel with GNU system utilities around) and boot in on the device via Fastboot since, contrary to Android, this will not restrict access to the device's persistent memory (NAND) at all but the current status is that our kernels either don't build or build and lock up the device so you can say our kernels suck badly (which is why we require more kernel development expertise here).

In the phone's persistent memory there's a lot of interesting stuff. All the "mtd partitions" you can see from within Android reside in the persistent memory. However, some of the persistent memory is inaccessible from within Android (even for Android itself). These memory regions contain code that is critical for the device to operate, such as controller initialization code, Radio firmware and HBOOT bootloader. We call such memory regions "unmapped", as they are made inaccessible by the Android kernel removing the mapping between virtual (what software sees) and physical (what hardware sees) addresses during the boot process. As software has no way of addressing this memory afterwards (remember it doesn't have a virtual address assigned any more), we cannot access it by conventional means (which means while Android is booted).

However, using the Fastboot protocol we can try to boot an operating system on the device that does not "unmap" the memory during the device's boot process, therefore leaving it "unprotected" and as such accessible for our software. That's why we're currently trying to get "vanilla" (which means "unaltered", we need to make this destinction as Android is also based on Linux, but it has been heavily modified by Google and as such is no longer "vanilla") Linux built for and booted on the device. Once we've got that, we can create an application which runs on Linux and flicks the secu_flag in the Radio firmware, therefore turning the device S-OFF, and reboots the device back into the Android firmware afterwards. We then package that application code into the initrd of our firmware image so that it gets loaded into RAM along with the Linux kernel and is executed as soon as the kernel has finished initializing.

In order to flick the flag in the Radio firmware, we have to know exactly where it resides in the device's persistent (NAND) memory, which means we'll have to find its physical address in the perstistent storage. We've identified some code inside HBOOT that "grabs into" some memory region lying outside HBOOT's own code segment and retrieves some values from there which point to the flag. However, when HBOOT is running, it is running off volatile (RAM) memory and all these reads happen in volatile (RAM) memory. But we need to flick the flag in persistent (NAND) memory so that it persists device reboots. This is why we definitely need to have a look at how a physical device initializes and we're going to do this via a so called "on-chip-debugger" that directly talks to the phone's processor using a special protocol called JTAG. For interfacing with the processor we need two things, a JTAG interface (which does the electrical signalling that the phone's processor requires) and a JTAG adapter (which provides the physical electrical connectivity to the phone's processor). I've already got the first one (interface) here, but the second one (adapter) hasn't shipped yet.

Now did this clear it up for you? :D