[OpenBIOS] [Qemu-devel] svn 6658 broke powerpc.

Thu Mar 19 20:41:55 CET 2009

On 3/19/09, Rob Landley <rob at landley.net> wrote:
> On Thursday 19 March 2009 12:48:09 Blue Swirl wrote:
>  > On 3/19/09, Rob Landley <rob at landley.net> wrote:
>  > > On Wednesday 18 March 2009 14:11:19 Blue Swirl wrote:
>  > >  > On 3/18/09, Rob Landley <rob at 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?
>  > >
>  > > No idea, but it worked with the previous openbios, and without
>  > > --nographic. This is a 2.6.28.8 kernel built with the attached .config.
>  > >
>  > >  By the way, while binary searching the openbios repository to figure out
>  > >  exactly what commit between 450 and 463 actually caused it to stop
>  > > working, and I hit a fun little OpenBios hiccup in the top level Makefile
>  > > of current OpenBios svn:
>  > >
>  > >  build:
>  > >     @printf "Building..."
>  > >     @for dir in $(ODIRS); do \
>  > >         $(MAKE) -C $$dir > $$dir/build.log 2>&1 && echo "ok." || \
>  > >         ( echo "error:"; tail -15 $$$dir/build.log; exit 1 ) \
>  > >     done
>  > >
>  > >  You have one too many $ before dir/build.log in the error message, so
>  > > the error message you get is
>  > >
>  > >   Building...error:
>  > >   tail: cannot open `/build.log' for reading: No such file or directory
>  > >   make: *** [build] Error 1
>  >
>  > I must always have used build-verbose. Should be fixed soon.
>  >
>  > >  Which took about 15 minutes of head scratching for a newbie like me to
>  > > track down.  (The actual problem was that your
>  > > config/examples/cross-ppc_rules.xml hardwires TARGET=powerpc-linux-gnu-
>  > > and my cross compiler just uses powerpc- as the prefix, and overriding
>  > > TARGET on the make command line doesn't work because you use recursive
>  > > make, and you aren't doing the ?= conditional assignments that won't
>  > > overwrite existing environment variable values.  I more or less expected
>  > > it and was running the thing the first time so it would tell me what
>  > > cross compiler name it expected when it died unable to find it.  Easy
>  > > enough to fix by just editing the darn file, but a mention of it in the
>  > > README wouldn't go amiss...)
>  >
>  > But my tools also use different prefix, powerpc-elf-
>  > (powerpc-unknown-elf). I compile using:
>  >
>  > make build-verbose TARGET=powerpc-elf-
>  >
>  > without problems.
>
>
> Eh, maybe I typoed something.  But it would still be nice if the README could
>  mention TARGET.  (Or, for that matter, build-verbose.)
>
>
>  > About the OpenBIOS problem, I've done further debugging. The crash can
>  > be reproduced with (-nographic -prom-env auto-boot?=false):
>
>
> And we are beyond my area of expertise.
>
>  When I grab openbios-qemu.elf built from svn 479, rename it qemu-system-ppc,
>  and then fire up qemu with "-L ." it complains it can't find "video.x".  Ok,
>  fine, add video.x to the current directory (that's powerpc code?) and try
>  again, and it goes:
>
>  >> =============================================================
>  >> OpenBIOS 1.0 [Mar 19 2009 02:56]
>  >> Configuration device id QEMU version 1 machine id 2
>  >> CPUs: 1
>  >> Memory: 128M
>  >> UUID: 00000000-0000-0000-0000-000000000000
>  >> CPU type PowerPC,750
>  Welcome to OpenBIOS v1.0 built on Mar 19 2009 02:56
>
>  >> File not found
>  >> *** Boot failure! No secondary bootloader specified ***
>
>  Which is at least a _different_ error, but I have no idea what I did wrong...

The disk boot attempt did not work.

>  I tried building a known working version, but svn is being stroppy:
>
>  > $ svn update -r 450
>  > svn: Target path does not exist
>
>  No _idea_ what that means, but apparently svn won't back up from current HEAD
>  to target 450 without a fight, and won't explain why either.  Google is not
>  helpful here, it talks about merging branches...

The repository was reorganized at r470, after that the full path has
/trunk component which was not there before.