[OpenBIOS] Running client with MMU off

[Segher Boessenkool]

On Fri, Jun 06, 2014 at 10:13:57PM +0200, BALATON Zoltan wrote:
> On Fri, 6 Jun 2014, Segher Boessenkool wrote:
> >>>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.
> 
> This is what I was trying to do with my patch (at least enabling the MMU 
> and disabling it on return, not restoring the vectors too). Any idea why 
> that does not work?

The OS should do it, not the client interface itself.

> >And yes, Apple OF runs by default with the MMU on (and it doesn't work
> >properly with it off, fwiw).
> 
> The question is not if OF itself runs with the MMU on but if it runs OS 
> boot code also with MMU bits enabled in the MSR or not. Since MorphOS 
> boots on real hardware there the MMU bits are either off or no exception 
> is happening at the point where it does on QEMU.

If real-mode? is false the client program is started with MMU on.

> >>>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 ;-)
> 
> What do you call clearing the MSR_DR and MSR_IR bits then?

"Disabling the MMU".  "Translation off".

> >>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 don't understand this.

Whenever an exception is taken MSR[DR] and MSR[IR] are cleared.  So it
doesn't matter one iota what state the MMU is in when a DSI happens, it
will be handled in the same way always.

But reading again, perhaps you meant it influences whether an exception
hapens at all.  Well, certainly :-)

> >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).
> 
> That may be but they won't fix it and it works on real hardware so there 
> must be a way around it.

If they in fact do things wrong, then they should fix it.  There is not
terribly much that can be done on the OF side here.

> >Apple OF constructs the exception code at runtime.  It is at a fixed
> >address (namely, 0), and it doesn't just copy a table.
> 
> Do you have more details? I could not get how it works from just this.

When PowerPC takes an exception, MSR is written (DR=0 IR=0 EE=0 etc.)
and the program counter is set to e.g. 0x0300 for a DSI.  Apple OF creates
the code at 0x0300 at init time; it is not copied from a block in ROM or
anything.

> >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.
> 
> It says:
> Raise exception at 00441bcc => 00000002 (00)
> 
> Where
> 0x00441bcc:  stw     r0,0(r3)
> 
> part of a memcpy function that writes to the vectors.
> 
> >Try to get the full context where the DSI happened (all register contents,
> >etc.)

[snip]

> r3             0x1000	4096

> Seems like the exception is happening when writing to 0x1000.

Yeah.  So it is writing to that page without having it mapped.  It should
either have it mapped or access it with the MMU off.  AFAIK there is notthing
that requires the OF implementation to have it mapped.


Segher