[OpenBIOS] Running client with MMU off

[Segher Boessenkool]

> >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).

> >2) 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