[OpenBIOS] Running client with MMU off

[Mark Cave-Ayland]

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.