So it turned out that glibc sucks a lot and i could not get ANYTHING to work that I compiled with it, not even a "hello, world!" program. So, I tried "diet libc", and it worked fine. Turns out my rom dumper program was correct as originally written.
Here's the scoop (so far) on the boot rom:
Code section: 0x0 - 0x9a38 (39480 bytes). Of this, the first 7k are code to set up the processor, intialize the hard drive and read files out of the fat32 filesystem. Yes, you got it -- they used a whole 32k for the friggin' entirety of RSAREF, to do the crypto checking.
Data section: 0x9a38 - 0x1095c (28452 bytes)
The first 300ish bytes are just miscellaneous data, containing the following strings: 'BOOTLOADLOG', 'BOOT0-0', 'BOOT0-1', 'Failed', 'BOOTo-2', 'BOOT0', 'Successful', 'rc.sh', 'rc.sig', 'BOOT9-X', 'BOOT9', 'phatd', 'phatd.sig', 'BOOTB-X', 'BOOTB', 'linux', 'linux.sig', 'BOOTF-X', 'BOOTF', 'ramdisk', 'ramdisk.sig', 'BOOT*-X', 'BOOT*', 'init=/bin/bash'.
There are then 100 RSA public keys (like we've seen in several other spots), and another 800ish bytes of data that look like a table of some sort -- they might even be a logo or a bitmap? hard to say.
It's empty (0xFFFFFFFF....) until 0x20000, where it repeats -- I guess maybe they didn't hook up one of the address lines?
From here, my first attempt at breaking this is going to be to patch the crypto verify function to always return true -- but that's not until A. I get a user-mode flasher working and B. I decode enough of this code to verify that it's not going to checksum itself somewhere and lock up so I can't ever reflash it and have a dead board.
-b