On 07/06/14 20:31, BALATON Zoltan wrote:
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?
The only way an exception won't happen here is if the mapping is already in the TLB, and my understanding is that being able to lock a TLB entry in place is *not* a standard feature of PPC CPUs so you're reliant on the inbuilt LRU algorithm.
It might be that MorphOS just got lucky that this works on real hardware without faulting (similar to the bug I had for SPARC64) but some further analysis would help. Does QEMU ppc have a DEBUG_TLB or similar option so you can see when the eviction is triggered? Sadly I think the options here are quite limited :/
ATB,
Mark.