On Mon, 3 Mar 2014, Mark Cave-Ayland wrote:
Yes indeed, this looks much better - please let us know how you get on further with your MorphOS work! :)
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 ;