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