I really don't think that this is the correct way to handle this at all. Firstly I believe that real-mode? is set to false by default on real hardware, e.g. from articles like http://www.dialectronics.com/Words/OF_Part_III.shtml.
From the device trees I've seen this seems to be the case but that does
not mean that the client code is also run with enabled MMU. OF could enable it only during callbacks as my patch tried. Without real hardware I can't find out though.
When you call the client interface you have to restore the MMU to the state OF expects (and then when it returns back to what the OS wants). This is as defined in the PowerPC binding.
And yes, Apple OF runs by default with the MMU on (and it doesn't work properly with it off, fwiw).
It seems to me that if real-mode? is set to false on real hardware, then your hypothesis that MorphOS expects MMU interrupts to be disabled can't be true;
It is impossible to disable MMU exceptions. Well, you can disable the MMU of course ;-)
Except if OF does what I said above. Either that or on real hardware no MMU interrupt is generated while overwriting the vectors until they are correct again for some other reason. (Like because page zero is alredy mapped unlike with OpenBIOS.)
All exceptions are taken in real mode, so that's not it.
I suspect MorphOS simply does the wrong thing, and there is no (sane) working around it; just like it expects a particular name for the root node (which can be worked around easily, as long as MorphOS is the only client with this particular weirdosity).
- Trap table is copied from OpenFirmware directly
Maybe the MorphOS developers have found the address of the default trap table in a real OF ROM and copy those values into the real vectors as a starting point? Then they can just fix up the values into their executable as required while during the transition any "unfixed" traps would be handled by the PROM as before?
Apple OF constructs the exception code at runtime. It is at a fixed address (namely, 0), and it doesn't just copy a table.
I don't think this is what happens (it would also break when the OF ROM is updated so I can't imagine they'd do that). Instead the addresses they copy first is where the final vectors will be after they set up their memory map. But before that they use the vectors from the loaded boot executable and this is what the fixup does. (I've said above the first vectors point to somewhere near the end of the ROM area but this is later replaced with their routines after the MMU is taken over. It just happens to be OpenBIOS ROM at this point.)
If it takes over memory management without using the OF callbacks for that, it can from that point on not call the client interface anymore.
IN: 0x0040091c: rlwinm r0,r26,0,0,19 0x00400920: lis r3,104 0x00400924: lis r4,66 0x00400928: stw r0,40(r2) 0x0040092c: addi r3,r3,-18952 0x00400930: addi r4,r4,4068 0x00400934: li r5,8192 0x00400938: bl 0x41f004
[Is this GDB output? Please use the disas "/r" modifier, it makes things more readable. Thanks!]
It is unclear to me where exactly it faults; it seems to be on a write to 00421084? While the write to four bytes earlier worked? How curious.
Try to get the full context where the DSI happened (all register contents, etc.)
Segher