[OpenBIOS] [Qemu-ppc] Running client with MMU off
Alexander Graf
agraf at suse.de
Thu Jun 26 12:50:48 CEST 2014
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?
> If I change this to 0 I get closer and it survives zeroing the sr
> registers but it cannot survive zeroing SDR1 and crashes after that
> happens:
>
> IN:
> 0x0041cde0: lwz r0,60(r3)
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1
> hash=000000000000041c
>
> 0x0041cde4: sync
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1
> hash=000000000000041c
>
> 0x0041cde8: mtsr 15,r0
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1
> hash=000000000000041c
>
> 0x0041cdec: isync
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1
> hash=000000000000041c
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash
> 0000000000000697
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1
> hash=0000000000000697
> found PTE at offset 0000a5e0
> PTE access granted !
>
> helper_store_sr: reg=15 00000000 2000000f
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1
> hash=000000000000041c
> found PTE at offset 00000728
> PTE access granted !
>
> IN:
> 0x0041cdf0: sync
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1
> hash=000000000000041c
>
> 0x0041cdf4: mtsdr1 r6
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1
> hash=000000000000041c
>
> 0x0041cdf8: isync
>
> htab_base 000000000fe00000 htab_mask 000000000000ffff hash
> 000000000000041c
> 0 htab=000000000fe00000/000000000000ffff vsid=0 ptem=1
> hash=000000000000041c
>
> ppc_store_sdr1: 00000000
>
> htab_base 0000000000000000 htab_mask 000000000000ffff hash
> 000000000000041c
> 0 htab=0000000000000000/000000000000ffff vsid=0 ptem=1
> hash=000000000000041c
> 1 htab=0000000000000000/000000000000ffff vsid=0 api=1
> hash=fffffffffffffbe3
> Raise exception at 0041cdfc => 00000003 (40000000)
> IN:
> 0x00000400: mtsprg 2,r2
>
> What comes after this is loading some values from the stack then
> disabling MMU bits in MSR (then putting the values loaded into BAT
> regs). If I could get these run without getting an ISI inbetween it
> would boot:
>
> 41ce0c: 82 84 00 14 lwz r20,20(r4)
> 41ce10: 82 a4 00 10 lwz r21,16(r4)
> 41ce14: 82 c4 00 1c lwz r22,28(r4)
> 41ce18: 82 e4 00 18 lwz r23,24(r4)
> 41ce1c: 83 05 00 04 lwz r24,4(r5)
> 41ce20: 83 25 00 00 lwz r25,0(r5)
> 41ce24: 83 45 00 0c lwz r26,12(r5)
> 41ce28: 83 65 00 08 lwz r27,8(r5)
> 41ce2c: 83 85 00 14 lwz r28,20(r5)
> 41ce30: 83 a5 00 10 lwz r29,16(r5)
> 41ce34: 83 c5 00 1c lwz r30,28(r5)
> 41ce38: 83 e5 00 18 lwz r31,24(r5)
> 41ce3c: 7c 00 04 ac sync
> 41ce40: 7c 00 00 a6 mfmsr r0
> 41ce44: 70 00 ff cf andi. r0,r0,65487
> 41ce48: 7c 00 04 ac sync
> 41ce4c: 7c 00 01 24 mtmsr r0
> 41ce50: 4c 00 01 2c isync
>
> Why are we getting ISIs on QEMU and why can this work on real hardware
> without crashing?
We are getting ISIs because the HTAB is now 0 bytes long, so it doesn't
contain any entries. Maybe it works on real hardware by accident because
the translations are still in the TLB?
I think with MorphOS you're best off detecting that you are running
MorphOS somehow (checksum over loaded files, specific client interface
calls only it does) and set MSR.DR=0 and MSR.IR=0.
Alex
More information about the OpenBIOS
mailing list