On Sat, 7 Jun 2014, Mark Cave-Ayland wrote:
On 07/06/14 13:28, BALATON Zoltan wrote:
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?)
Silly question, but if the DSI is happening when writing to 0x1000 then surely MorphOS has already overwritten the block 0x0 - 0xfff and so the exception handler at 0x300 won't be pointing to OpenBIOS' handler anyway? If it's not pointing to OpenBIOS' handler then there's no way it can handle the translation.
Right. That's why it fails and because it writes an incorrect vector in the first step that it then replaces with the current location of the handler but if the MMU is enabled then that is not reached due to this exception calling an invalid handler. So either the MMU bits should be off or the area should already be mapped so no exception happens.
I'm not sure how it should work but on real hardware the mapped area seems to be 0x0000-0x3000 while with OpenBIOS it's only 0x1000-0x3000. Could we just modify it to be 0x2000-0x3000 to avoid the exception? Or can we match what's on real hardware?
Regards, BALATON Zoltan