Re: [Qemu-ppc] [PATCH] mac99: Bring memory layout closer to real hardware

[Alexander Graf]

On 12.04.14 11:59, BALATON Zoltan wrote:
> On Fri, 11 Apr 2014, Programmingkid wrote:
> > > The "real" fix would be to create a new machine model that models
> > > *exactly* a real system from scratch.
> >
> > So what happens to the mac99 target? Delete or abandon it? Emulating 
> > another real Macintosh does sound like a good idea, but that would 
> > take a lot of work. Wouldn't it be easier to just adjust the mac99 
> > target instead of starting from scratch?
>
> I agree with adjusting the mac99 model instead of starting from 
> scratch not only because it's less work but also because there's not 
> much point in keeping a machine called mac99 that does not match any 
> real Mac. I'll send my current patch with minimal changes to make the 
> memory layout better match what's seen on PowerMac3,1.

I can't apply that without changing OpenBIOS as well. And OpenBIOS 
doesn't get the memory layout from the machine, it only gets an 
identifier that says "I'm machine numer X, use me".

So we would have to add a new machine type in fw_cfg for this machine, 
as otherwise we would render newer OpenBIOS incompatible with older QEMU 
at which point we can as well just call the whole thing a new machine.

> With this and some OpenBIOS changes (that I'll send to that list) 
> MorphOS seems to almost boot but it still crashes before starting up. 
> There are two problems I know about:
>
> 1. OpenBIOS uses the DSI and ISI exceptions for memory management so 
> it enables the corresponding bits in the MSR but MorphOS changes the 
> exception vectors without disabling these bits and it gets a DSI when 
> the exception vector is still pointing to the wrong place.
>
> 2. Eventually MorphOS runs into this invalid instruction and crashes:
>
> IN:
> 0x0041cbcc:  lwzx    r7,r2,r9
> 0x0041cbd0:  lwz     r8,24(r5)
> 0x0041cbd4:  cmpw    r7,r8
> 0x0041cbd8:  beqlr
>
> invalid bits: 00000001 for opcode: 1f - 17 - 04 (7d02492f) 0041cbdc
> IN:
> 0x0041cbdc:  .long 0x7d02492f

It's stwx with the lowest bit set:

   4:    7d 02 49 2e     stwx    r8,r2,r9

which usually would be the Rc bit in this form of instruction encoding. 
You could try to issue an instruction like this on a machine with the 
same CPU as the one you're trying to emulate and see if the CPU happens 
to ignore Rc (or maybe even sets CR!)

> The whole subroutine seems to be:
>
>   41cbcc:       7c e2 48 2e     lwzx    r7,r2,r9
>   41cbd0:       81 05 00 18     lwz     r8,24(r5)
>   41cbd4:       7c 07 40 00     cmpw    r7,r8
>   41cbd8:       4d 82 00 20     beqlr
>   41cbdc:       7d 02 49 2f     .long 0x7d02492f

If we assume that this is the stwx instruction from above, I'd say the 
code flow makes sense. It almost looks like a spin lock?


Alex