[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexander Graf
Subject: Re: [Qemu-ppc] [PATCH] mac99: Bring memory layout closer to real hardware
Date: Mon, 14 Apr 2014 09:21:34 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

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:

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


reply via email to

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