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