Here's some ideas i've been getting:
firmware debugger: perhaps using romcc, a minimal debugger would allow trying different ram initialization sequences rapidly.
If it were treated as a stub, it would be possible to run make on the controlling machine, and (with some line from the serial port to the reset line on the target board) have it compile the IPL ram init sequence, reset the board, upload it, then test it. By keeping VI open in another window, you could try new code every few seconds.
Where would it store this code? Well there's Eric's Cache-as-ram trick, where available, and I was thinking about all those video cards that aren't used with Linuxbios... don't almost all video cards have static ram on them? What would it take to execute code from there?
I wonder how much the gdb kernel stub depends on the kernel? A serial console api could be useful there and elsewhere, to avoid duplicating the serial code in the various payloads.
other ideas... it would be swell to have an IPL that could accept downloads (zmodem?) via the serial console port, and (re)flash the payload, though it would require reimplementing the flashing code. Probably nicer to use the MTD drivers in Linux.
Regards,
Jeremy