[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:
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