[Top][All Lists]

[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: Fri, 27 Jun 2014 23:36:13 +0200 (CEST)
User-agent: Alpine 2.02 (LMD 1266 2009-07-14)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]