[OpenBIOS] [Qemu-ppc] Running client with MMU off

[BALATON Zoltan]

On Thu, 26 Jun 2014, Alexander Graf wrote:
> On 26.06.14 01:36, BALATON Zoltan wrote:
>> On Wed, 25 Jun 2014, Alexander Graf wrote:
>>> On 25.06.14 12:40, BALATON Zoltan wrote:
>>>> On Wed, 25 Jun 2014, BALATON Zoltan wrote:
>>>>> ppc_store_sdr1: 0fe00000
>>>>> helper_store_sr: reg=0 20000400 00000000
>>>> [...]
>>>>> helper_store_sr: reg=0 00000000 20000400
>>>>> Raise exception at 0041cd00 => 00000003 (40000000)
>>>>> 
>>>>> ^^^ This exception should not happen. It is trying to handle it but the 
>>>>> handlers are not working yet and gets in an infinite loop. It boots if 
>>>>> MMU is disabled while this part runs but MorphOS does not disable it yet 
>>>>> and according to my oftest results they are enabled on Apple too. How 
>>>>> does it work on real hardware and why does it fail on QEMU? (Note the 
>>>>> the value of sr0 is identical to the one set by OpenBIOS and SDR1 is 
>>>>> unchanged so translations via the page table should still work, 
>>>>> shouldn't it?)
>>>> 
>>>> I was mistaken about the values being the same as it is zeroing sr0. So 
>>>> can this explain why translation via the page table fails after this and 
>>>> why an ISI is generated? Why are the sr registers set up with the values 
>>>> above by OpenBIOS? Could they be 0 instead?
>>> 
>>> SR registers are used to translate EAs to VAs. If you set them all to 0 
>>> they would end up getting the same VSID.
>> 
>> OK but why is SEGR_BASE defined as 0x0400 in arch/ppc/qemu/ofmem.c? 
>
> I guess to make it easier to debug vs empty SR registers and to make sure it 
> doesn't collide with a guest that sets SR registers to 0 temporarily?
>
> What does real Apple firmware use for their VSIDs?

I updated oftest to print sr registers too. From a test on iMac,1 it seems 
the values are just sr0=0, sr1=1, ... sr15=15.

Regards,
BALATON Zoltan