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

[Mark Cave-Ayland]

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.