Re: [Qemu-ppc] [OpenBIOS] 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