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

[BALATON Zoltan]

On Fri, 28 Feb 2014, BALATON Zoltan wrote:
> On Thu, 27 Feb 2014, Mark Cave-Ayland wrote:
>> FWIW there is a known issue with PPC's next-property iterator being 
>> implemented differently to the standard (see Olivier's tentative patch at 
>> http://www.openfirmware.info/pipermail/openbios/2014-February/008141.html). 
>> It's likely that a broken device tree iteration could be the cause of the 
>> MorphOS bootloader not being able to locate a suitable console mode which 
>> could be related to your issue.
>
> I think I did not hit this one yet at least the console problem is surely not 
> caused by this but by MorphOS only supporting some specific Radeon GPUs that 
> are found in the PPC Macs it is supporting. It is looking for them by their 
> vendor-id:device-id and fails if not found, but tries to continue anyway.

While the next property iterator is not the cause of the console failed 
message it may very well be related to the hang in CPU detection later 
that I'm currently facing. I see the following openbios debug output with 
DEBUG_CIF enabled in libopenbios/client.c while MorphOS tries to detect 
the CPU:

>> finddevice("/cpus") = 0xfff4bbec
>> child(0xfff4bbec) = 0xfff5194c
>> nextprop(0xfff5194c, "", 0x07de7e30) = 1
>> 0x07de7e30  6e __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  n
>> getprop(0xfff5194c, "name", 0x07de7df0, 64) = 11
>> 0x07de7df0  50 6f 77 65 72 50 43 2c 47 34 00 __ __ __ __ __  PowerPC,G4.
>> nextprop(0xfff5194c, "name", 0x07de7e30) = -1
>> child(0xfff5194c) = 0x00000000

and here it gives up and freezes. This is with Olivier's patch applied, 
which does not change anything in the above, I'm seeing this with or 
without this patch. It seems to be a case of nextprop failing which the 
patch does not correct. Any hints how to debug it further? I don't know 
how to test or trace forth so I'd need some help with this.

By the way, if it didn't fail to explore the properties of the CPU it 
seems to be looking for these on the CPU node:

altivec
bus-frequency
clock-frequency
cpu-version
data-streams
d-cache-block-size
d-cache-line-size
d-cache-sets
d-cache-size
i-cache-block-size
i-cache-line-size
i-cache-sets
i-cache-size
performance-monitor
reservation-granule-size
timebase-frequency
tlb-size
tlb-sets

then it tries to go down the tree and explore l2-cache and l3-cache nodes 
(this is the last child call returning NULL in the above). I don't know 
which of these are optional and which are critical but looking at what 
QEMU provides now:

name                      "PowerPC,G4"
device_type               "cpu"
cpu-version               c0209
dcache-size               8000
icache-size               8000
dcache-sets               80
icache-sets               80
dcache-block-size         20
icache-block-size         20
timebase-frequency        3b9aca00
clock-frequency           0
state                     "running"
reg                       00000000
available                 00004000   07c54000
                           07e10000   f80f0000
                           00000000   ffffffff
translations              00001000   00003000   00001000   00000000
                           07c58000   001b8000   07c58000   00000000
                           fff00000   00100000   07f00000   00000000

I expect some problems with these too once we manage to make nextprop 
work. For a start frequency entries are missing or seem to be wrong.

Regards,
BALATON Zoltan