[NTLK] A new ROM board

[Matthias Melcher]

Update on the ROM board:

tl;dr it is possible (and proven) to write the Flash ROM while it is inside the MP, but I don't know yet how.


The long version:

So far, I have improved and accelerated the programmer to write my own ROM versions to it, and it works very nicely. I did manage to patch a ROM and create a backdoor that gets me into supervisor mode from within a NewtonScript function. And yes, in any modern system, this would be a terrible terrible thing.

I put a patched ROM inside Einstein and everything is really peachy! I can read and write to ROM addresses just fine. Of course, Einstein does not emulate a Flash chip at the ROM address, but this proves that writing to ROM is possible without the emulator freaking out.

But how is the real thing going to react?

So I changed the ROM board and uploaded my app to my trusty MP... .

Just a note at this point for folks looking forward to switch between ROMs: the slightest change in the ROM will make our little friend panic. It will give a message that a different ROM was inserted, and it will proceed to erase all user data, sometimes after asking, sometimes without asking. A complete backup is required on every ROM change, and I am not convinced yet that a US backup can be restored onto a German machine and vice versa. (actually, changing ROMs is sometimes the only way to unbrick a MessagePad from a corrupt user memory).

I launched the app that worked so nicely in Einstein, but on the MP, it not only crashes with an error, it crashes the entire machine. That's what I get for playing around in Superuser mode.

Luckily, Hammer, the insanely great Newton debugger, runs very well on BasiliskII and connects flawlessly to the real machine. I have no idea how the heck Hammer does it, but you can single-step through ROM instructions, look at registers, memory, virtual memory, set breakpoints. What a tool!

Looking through Hammer, it even has a function to "Flash a new ROM". Huh. I didn't get my hopes up, because Flash ROM was quite different back then, but nevertheless, I clicked the item, and nothing visible happens.

"Get on with it", I hear you yell.

So I launched the app again. It writes to a specific ROM address, which is something that ROMs ignore, but a Flash device interpret write access as commands, in this case the Get Status command, and returns its status on the next read instead of the ROM content. So as soon as I get 00800080 as a result instead of EA0061A0, I win.

Now in the debugger, I single-step through my code, hoping for the best, or at least to find out why the MP crashes. But nothing. The write seems to be ignored, and the read returns the ROM data, not the status. Sigh.

Single-stepping may mess with our ROM reading, so once more, but with a breakpoint set, but again, no crash, no fuzz, just the ROM content. Bad.

Looking at the write address, I see very different data than what should be in the ROM. How can that be? The memory management unit remaps the lower 1000-2000 block to RAM, and that's just where our command must be written. My write attempt never reached the ROM chip. Going through the lookup table, my address is somewhere completely different.

And that does it. Running my code using the newly found address returns 00800080, the OK status from the Flash chips. This proves that it is physically possible to write to the ROM board while in the MP, and that means that we can reprogram our Flash, add apps, patch bugs, etc. etc. without needing an external programmer.

So super happy, I disconnect Hammer and give it one more try. Bam! The MP crashes as it did earlier. This means that Hammer does something magical that makes the ROM writable, and I have to find out what that is. 

So far, I can disable the Domain Access Control in the coprocessor register #3, but that's not enough.

Any ideas? ( I am aware that I have a maximum of two readers left at this point, but anyway...)

 - Matthias