qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [OpenBIOS] MorphOS 4.x on QEMU


From: Mark Cave-Ayland
Subject: Re: [Qemu-ppc] [OpenBIOS] MorphOS 4.x on QEMU
Date: Tue, 04 Mar 2014 22:41:47 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

On 04/03/14 01:22, BALATON Zoltan wrote:

Here is some progress. It turns out that I get much farther with the
patch at the end of this message. This corrects the names of CPU cache
parameters that seem to be missing a dash compared to the device tree
dump I've referred to before and this is why MorphOS could not find them
while looking for them. Apart from that I also had to change the model
string to a newer one that is supported by MorphOS for it to continue
and it seems that it looks for the name of the / node and expects it to
be called device-tree on a Mac so I had to change this too. With these
it gets over its initial boot and starts to initialise devices (I also
got some messages on the debug serial port). Then it hits an exception
again that seems to be due to some memory corruption like the 0x80 issue
right at the beginning that prevents it from booting still. This time it
may be a null pointer issue but I'll need to debug it further to know
what's happening. This is how far it gets now:

IN:
0x00441bc8: lwz r0,0(r4)
0x00441bcc: stw r0,0(r3)
0x00441bd0: lwz r9,4(r4)
0x00441bd4: stw r9,4(r3)
0x00441bd8: lwz r0,8(r4)
0x00441bdc: stw r0,8(r3)
0x00441be0: lwz r9,12(r4)
0x00441be4: stw r9,12(r3)
0x00441be8: lwz r0,16(r4)
0x00441bec: stw r0,16(r3)
0x00441bf0: lwz r9,20(r4)
0x00441bf4: stw r9,20(r3)
0x00441bf8: lwz r0,24(r4)
0x00441bfc: stw r0,24(r3)
0x00441c00: lwz r9,28(r4)
0x00441c04: stw r9,28(r3)
0x00441c08: addi r4,r4,32
0x00441c0c: addi r3,r3,32
0x00441c10: bdnz+ 0x441bc8

Raise exception at 00441bcc => 00000002 (00)
IN:
0x00000300: b 0xffffc3a0

invalid/unsupported opcode: 00 - 00 - 00 (00000000) ffffc3a0 0
IN:
0xffffc3a0: .long 0x0

Raise exception at ffffc3a4 => 00000006 (21)
IN:
0x00000700: mtsprg 2,r2
0x00000704: li r2,7
0x00000708: b 0xffffe0f0

invalid/unsupported opcode: 00 - 00 - 00 (00000000) ffffe0f0 0
IN:
0xffffe0f0: .long 0x0

Raise exception at ffffe0f4 => 00000006 (21)
Raise exception at ffffe0f4 => 00000006 (21)

Something seems to overwrite the vector at 0x300 (which was set to
0x238c before this point) but the new value seems to point to the wrong
place.

What do you think about the patch below?

Regards,
BALATON Zoltan

Index: arch/ppc/qemu/init.c
===================================================================
--- arch/ppc/qemu/init.c (revision 1271)
+++ arch/ppc/qemu/init.c (working copy)
@@ -241,32 +241,32 @@

PUSH(cpu->dcache_size);
fword("encode-int");
- push_str("dcache-size");
+ push_str("d-cache-size");
fword("property");

PUSH(cpu->icache_size);
fword("encode-int");
- push_str("icache-size");
+ push_str("i-cache-size");
fword("property");

PUSH(cpu->dcache_sets);
fword("encode-int");
- push_str("dcache-sets");
+ push_str("d-cache-sets");
fword("property");

PUSH(cpu->icache_sets);
fword("encode-int");
- push_str("icache-sets");
+ push_str("i-cache-sets");
fword("property");

PUSH(cpu->dcache_block_size);
fword("encode-int");
- push_str("dcache-block-size");
+ push_str("d-cache-block-size");
fword("property");

PUSH(cpu->icache_block_size);
fword("encode-int");
- push_str("icache-block-size");
+ push_str("i-cache-block-size");
fword("property");

PUSH(fw_cfg_read_i32(FW_CFG_PPC_TBFREQ));
@@ -745,12 +745,12 @@

/* model */

- push_str("PowerMac2,1");
+ push_str("PowerMac3,1");
fword("model");

/* compatible */

- push_str("PowerMac2,1");
+ push_str("PowerMac3,1");
fword("encode-string");
push_str("MacRISC");
fword("encode-string");
Index: forth/device/tree.fs
===================================================================
--- forth/device/tree.fs (revision 1271)
+++ forth/device/tree.fs (working copy)
@@ -11,7 +11,7 @@

\ root node
new-device
- " OpenBiosTeam,OpenBIOS" device-name
+ " device-tree" device-name
1 encode-int " #address-cells" property
: open true ;
: close ;

These patches basically look okay, although would it be possible to submit them as separate patches? The reason for this is to allow bisection e.g. in the case that renaming the CPU properties suddenly means a guest OS can find them, and it then breaks as a result.

- The CPU property renaming patch looks good

- The PowerMac model name change is stylistically fine, however I don't know enough about PPC to know whether bumping the model from PowerMac2 to PowerMac3 violates the -M mac99 QEMU machine - Alex Graf is probably the person to ask about this one

- The root node rename is stylistically okay, however it's a pretty stupid thing to do to locate the root node of the tree based upon it's name (which *isn't* given in the spec) - finddevice("/") is your friend. Perhaps the best way here is to move the OpenBIOS property to a different name so that it can be detected another way if required?


ATB,

Mark.



reply via email to

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