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

[Mark Cave-Ayland]

On 01/03/14 00:49, BALATON Zoltan wrote:

> 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.

Okay I see what's happening here - the reason Olivier's patch doesn't 
make a difference is because the MorphOS bootloader is calling the 
nextprop word via the client interface rather than calling next-property 
directly by passing a Forth string into OpenBIOS.

If you take a look at section 6.3.2.2 of the IEEE1275 specification then 
you will find how the nextprop call should work; it's functionality is 
basically an implementation of the vanilla next-property word with a few 
extras. You can see the code for this in forth/system/ciface.fs within 
the OpenBIOS source.

Now the fact that nextprop returns -1 indicates that the following check 
has failed:

  \ verify that prev exists (overkill...)
  dup if
    2dup r@ get-package-property if
      r> 2drop 2drop -1 exit
    else
      2drop
    then
  then

This means that the client requested the next property after "name" but 
OpenBIOS's get-package-property couldn't find "name" and so returns -1 
back to the caller as shown in your trace.

If I had to guess as to why the "name" property couldn't be found by 
nextprop, it would be that MorphOS is returning the property "name" 
returned by the previous call to getprop in the subsequent nextprop call 
but with an extra NULL (0) byte at the end. However you'll need to dig a 
bit further to see if this is the case or not.

Fortunately OpenBIOS has an in-built source debugger so you should be 
able to step through the code doing something like this:

- Launch qemu-system-ppc with -prom-env 'auto-boot?=false' -nographic
  (this disables auto boot and turns off the VGA console)

- Setup debugging the nextprop word using something like this:

  0 > cd /openprom/client-services  ok
  0 > debug nextprop
  Stepper keys: <space>/<enter> Up Down Trace Rstack Forth
   ok
  0 > cd /  ok
  0 > boot

You should find that OpenBIOS boots your image and then breaks on 
nextprop, allowing you to step through the function examining the stack 
(and input string) to see what is going wrong.

> 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.

That's highly likely; most of the existing properties have probably been 
added by enabling DEBUG_CIF as you have done and then copying the values 
from the example device trees as required. So let's get nextprop fixed 
first and then we can figure out what is needed later.


ATB,

Mark.