[OpenBIOS] Running client with MMU off

[BALATON Zoltan]

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?

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

>>> 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? If I clear 
these bits at the point where MorphOS starts to write to the vectors (just 
when it overwrites the DSI vector) it boots because it will replace and 
fixup the vectors and then enable the bits itself (and not call OF 
functions afterwards). If the bits remain enabled it jumps to an invalid 
vector and crashes.

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

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

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

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

And it doesn't. It calls all calbacks before overwriting the vectors and 
taking over memory management.

>> 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's qemu in_asm debug output. I know of no options there.

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

Breakpoint 2, 0x00000300 in ?? ()
(gdb) bt
#0  0x00000300 in ?? ()
#1  0x0041f034 in ?? ()
#2  0x0040093c in ?? ()
#3  0xfff02604 in ?? ()
(gdb) info registers
r0             0x7c52f2a6	2085810854
r1             0xfde7eb0	266239664
r2             0x684c60	6835296
r3             0x1000	4096
r4             0x421fe4	4333540
r5             0x0	0
r6             0x68507c	6836348
r7             0x6850b8	6836408
r8             0xfde7f60	266239840
r9             0x0	0
r10            0x400000	4194304
r11            0x0	0
r12            0x680000	6815744
r13            0x0	0
r14            0xfff32687	4294125191
r15            0xfde7f60	266239840
r16            0xfde7f20	266239776
r17            0xfde7f64	266239844
r18            0xfde7f24	266239780
r19            0x988000	9994240
r20            0x3030	12336
r21            0x684348	6832968
r22            0x688284	6849156
r23            0x0	0
r24            0x30000	196608
r25            0x688a34	6851124
r26            0x10000000	268435456
r27            0x0	0
r28            0x684c80	6835328
r29            0x67b5f8	6796792
r30            0x420fe4	4329444
r31            0x2000	8192
pc             0x300	0x300
msr            0x1000	4096
cr             0x44002044	1140858948
lr             0x41f034	0x41f034
ctr            0x80	128
xer            0x0	0

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

Regards,
BALATON Zoltan