[Windows Mobile Software Development] joeyhewitt:
I don't know if anyone is following this, but if you are, here's an update on my experiments, and some questions if anyone knows/cares to share the answers.

1) (MAGLDR appears to be closed-source and only supports one device, so I didn't look into it very far.) There is some MTD functionality in XDAndroid 2.2 for the Topaz (and probably other XDAndroid varieties.) After what seemed like an eternity of poking around with the terminal and the soft keyboard, I got telnet set up and was able to modprobe the mtd modules and dump portions of the NAND. There weren't any partitions (or, there was only one partition that appeared to be the full NAND bank), so I wonder if that will be a problem. If I remember correctly, I found a "dd" command that dumped a segment of NAND containing the SPL, however it was hard to consistently seek through NAND, so I either don't understand how the offsets and sizes for "dd" work, or something strange was going on. There was no included nandwrite tool, so I haven't tried flashing anything yet. I may not, because I'm unsure of the safety and merits of an Android-based flasher. It would probably be safest to boot into a dedicated barebones environment for this, and most versatile to have it be independent of a PC and ideally even an SD card -- is there enough terminal support in the kernel to have a limited UI? (Perhaps just to choose which file to flash, or confirm the flash.) It would be cool to flash native unsigned RUU files from a general-purpose Linux tool, but would it really be helpful? For new devices coming out, I imagine the SPL is patched before a Linux port is stable enough to flash unsigned ROMs. For current devices, the SPL is already there and a safer choice. Any thoughts?

2) After more thought than it should have took ;), I figured out a quick-and-dirty way to do relocation. I just replaced every 32-bit value in the SPL binary that fell between the virtual SPL base address and the end (which I'm not sure how far to extend, but am working with 1MB right now), with the rebased value. (Excluding the base address given in the MMU table.) There were about 2,500 occurrences, and I wonder if some of them weren't actually offsets. I'll have to think about a way to automatically detect this, or manually verify that each rebased value in the disassembly is actually an offset. For now, my goal is just to see a soft-loaded tri-colour screen, so I didn't worry too much about whether I rebased things that shouldn't have been. (I guess the tricky part is I may never see that screen if I relocated something wrong.)

After some time trying to debug this, I discovered that JumpSPL seems to be flaky, which would make development a nightmare. The same binary will do different things (like hang in WinMo, hang with screen blacked-out, reboot into stock SPL) on successive runs. Some of this is likely due to an incompletely relocated binary, and intentional hangs or reboots that I was adding to try to diagnose what was going on (writing to the framebuffer didn't seem to work; maybe I have the wrong address), but even with a known-good binary (OliNex's SSPL), JumpSPL won't consistently launch it. I can only guess that's because it was written on the assumption that Windows wouldn't touch the memory it was loading into (historically 0x00000000 -- but does Windows really not use that? if the memory is MPU'd Windows obviously can't write to it, but what about when JumpSPL was originally written?) I can't be entirely certain yet (I only tried 2 or 3 times so far), but it looks like the JumpSPL variant bundled with the HardSPL installers is more stable. I patched in my soft SPL overtop theirs and was getting more consistent results. Any thoughts on JumpSPL'ing a relocated SPL?

I've also tried just patching the MMU table instead of relocating, with no success; possibly due in part to JumpSPL not always working. Cmonex has mentioned this won't work in some cases, though, so I'm not going to invest a lot of time.