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.