Re: [Qemu-devel] svn 6658 broke powerpc.

[Blue Swirl <blauwirbel@gmail.com>]

On 3/18/09, Rob Landley <rob@landley.net> wrote:
> On Wednesday 18 March 2009 03:41:05 Alexander Graf wrote:
>  > On 18.03.2009, at 00:57, Rob Landley wrote:
>  > > Up through svn 6657, I could boot a powerpc kernel with -kernel.
>  > > That commit
>  > > changed it so now it says:
>  > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f00 1
>  > > invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f04 1
>  > > invalid/unsupported opcode: 00 - 0c - 06 (00009198) 00009214 0
>  > >
>  > > And dies.
>  > >
>  > > You can grab a test kernel from http://landley.net/zImage-powerpc
>  > > and try
>  > > booting it (out of the qemu source directory, this is assuming
>  > > you've built it
>  > > but haven't installed it yet) via:
>  > >
>  > > ppc-softmmu/qemu-system-ppc -kernel zImage-powerpc \
>  > >  -append "console=ttyS0 panic=1" -nographic -no-reboot -L pc-bios
>  > >
>  > > With svn 6657, it works.  (You get kernel boot messages up until it
>  > > panics and
>  > > dies because it can't find the root filesystem).  With 6658 it dies
>  > > immediately with the above error message.
>  > >
>  > > Unfortunately, this means that the 0.10.0 release doesn't work for
>  > > powerpc for
>  > > me, but svn a couple days _before_ the release did.
>  >
>  > That specific commit shouldn't have changed anything with respect to
>  > ppc32 emulation. The one where your command broken is the openBIOS
>  > update.
>
>
> The commit I pointed to is the openbios update, yes.
>
>
>  > Please try again without -nographic.
>
>
> It does indeed work without nographic.  (It doesn't do anything _useful_ for
>  me without nographic, since I'm scripting the emulated kernel's behavior
>  through stdin and stdout, but allowing it to pop up an SDL window does make it
>  out of openbios and into the kernel.)

The kernel makes the equivalent of the following calls to OF interface:
finddevice("/") = 0x11d5c
finddevice("/chosen") = 0x1197c
finddevice("/openprom") = 0x11b3c
getprop(0x11b3c, "model", 0x78efeb0, 0x40) = 0xf
getprop(0x11d5c, "stdout", 0x78efea0, 0x4) = 0x4
instance-to-path(0x86ea0, 0x12ad0dc, 0xff) where it crashes because
memmove overwrites all memory.

But where does this 0x86ea0 come from?