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

[BALATON Zoltan]

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? 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?

Regards,
BALATON Zoltan