[OpenBIOS] Running client with MMU off

[BALATON Zoltan]

On Sat, 7 Jun 2014, Segher Boessenkool wrote:
>>> 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.

MorphOS does not change MMU bits before taking over memory management so 
there's nothing to restore and CIF calls work. But the default setting 
does not work on QEMU though during MMU take over.

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

They won't fix it. They did not seem very supportive of the idea of 
MorphOS running on QEMU for unknown reasons. All they ever said is that it 
is not supported. So it must be fixed on the OF side. (And it can be if it 
works on real hardware.)

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

OK, this is an implementation detail that is not important here. It does 
not matter how the vectors end up at their addresses.

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

MorphOS expects the OF implementation to behave as Apple's does and 
apparently it is either mapped there or the MMU is off when the boot 
loader that accesses this page is running. (This is whay I'm saying for 
some time.) MorphOS won't map the page itself but does not expect DSI 
exceptions writing there.

Why should it be already mapped on OpenBIOS too? Well, the device tree 
says:

/cpus/PowerPC,G4
translations
   00001000 00003000 00001000 00000000
   0fc58000 001b8000 0fc58000 00000000
   fff00000 00100000 0ff00000 00000000

So MorphOS can expect it to be mapped. Can this be fixed somehow? Where?

(Mark also said earlier that the whole memory should be mapped one to one 
at startup. If so why MMU exceptions are happening at all?)

Regards,
BALATON Zoltan