[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off
From: |
BALATON Zoltan |
Subject: |
Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off |
Date: |
Thu, 26 Jun 2014 01:36:12 +0200 (CEST) |
User-agent: |
Alpine 2.02 (LMD 1266 2009-07-14) |
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
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, BALATON Zoltan, 2014/06/24
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, Alexander Graf, 2014/06/24
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, BALATON Zoltan, 2014/06/25
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, BALATON Zoltan, 2014/06/25
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, Alexander Graf, 2014/06/25
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off,
BALATON Zoltan <=
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, Alexander Graf, 2014/06/26
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, BALATON Zoltan, 2014/06/26
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, Alexander Graf, 2014/06/26
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, BALATON Zoltan, 2014/06/26
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, Alexander Graf, 2014/06/26
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, BALATON Zoltan, 2014/06/26
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, Alexander Graf, 2014/06/26
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, BALATON Zoltan, 2014/06/26
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, Alexander Graf, 2014/06/26
- Re: [Qemu-ppc] [OpenBIOS] Running client with MMU off, BALATON Zoltan, 2014/06/27