Yep I'm perfectly aware of that. I initially thought it was because the interrupt controller was not working properly but that can't be the case because the boot process breaks before unmasking any interrupts. I for the life of me can't figure what unimplemented system is causing the failure to boot.

Debugging with gdb does not provide anything too useful as the fault occurs far from where the code hangs.

We're emulating at a level much lower than the syscall level, we're emulating the hardware the syscalls run on.

Ah, OK, because in an earlier post, it was stated that it wasn't going to be a hardware emulator, but a syscall level emulator. That makes more sense. Emulating the hardware allows the system rom file to be used.....makes much more sense...
Thks
-D

It's been way too long (NumWorks is kinda distracting me these days), but there should be 32 MiB at 0x30000000 and 64 KiB at 0x0. The DRAM controller can map up to 128 MiB of memory.

Not sure why the official firmware would want to poke beyond 0x32000000. It could be memory prodding/detection (unlikely), GPIO/hardware registers not having the right values or plain old sloppiness. I can poke memory around with the Rip'Em GDB stub over serial if you need.

I checked and I have everything at hand in my flat. I'll perform the hex dumps tomorrow.

Hey guys, just a quick update. I recently tinkered with the emulator a bit more and finally got the original prime OS to boot 



I'm using a flash dump done through jtag to boot from posted on one of the formus, don't remeber which. I tried to manually make flash images from the update files but none of them seem to work so far. Still this is good progress. Although everything is just mostly a massive hack at this point. The next challenge will be getting the touch input working. This won't be easy at all since the nt11002 touch controller chip appears to be undocumented except for a few source files for linux drivers. 

So I managed to get ahold of the NT11002 datasheet. Sadly it contains nothing particularly useful. Most of the functionality is determined by the firmware as it's basically a 8051-compatible processor. So I guess we should try to get a dump of the firmware on the prime. There might be something in the update images, if the driver is anything like the linux one, which basically tries to perform a firmware update everytime it intializes the NT11002.

For the images I tried to build them by appending the files in the order you mentioned, one after the other and then using truncate to get the image to 256Megs. Which matches the image I have. But the image refused to boot. So either I appended in the wrong order, different versions don't work or there is other data beyond that supplied in the firmware updates.

I was also unable to get into the diagnostic tool. SInce it requires the reset button to be pressed and the emulator does not implement that yet. This, along with implementing touch and getting video to be more stable should be the two main priorities for the emulator right now.

Edit:
I managed to dump the Touch controller's firmware from the diagnostic utility executable. The challenge will be analyzing it now. If anyone is interested PM me and ill send you a copy.

Apologies, I forgot to commit the last changes to github so you were still running and old version of qemu. Nonetheless, I tried making images that way and I get the same result as yours. I think the problem is that they are missing something that is not included in the update files. The dumped image I have confirms it. Try to boot with it: http://bit.ly/1z6jv9B, you should get to where I got in the screenshot.

I also was not planning of low level emulating the nt11002, but I think the firmware could provide us with good information about the i2c protocol it uses.

Do you happen to know on what pin is the reset switch on the prime?