[OpenBIOS] [Qemu-devel] svn 6658 broke powerpc.
Blue Swirl
blauwirbel at gmail.com
Thu Mar 19 18:48:09 CET 2009
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.
About the OpenBIOS problem, I've done further debugging. The crash can
be reproduced with (-nographic -prom-env auto-boot?=false):
0 > cd /chosen ok
0 > .properties
name "chosen"
stdin 86904
stdout 86a08
memory 86da0
mmu 867e8
display 86660
nvram 86750
rtc 86d3c
ok
0 > 86904 get-instance-path type invalid/unsupported opcode: 00 - 00
- 00 (00000000) fff18f04 1
invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f08 1
invalid bits: 00400000 for opcode: 0b - 19 - 15 (2d746572) 00009230
But other nodes crash too:
0 > 86da0 get-instance-path type /memory at 0 ok
0 > 86660 get-instance-path type /pci at 80000000/QEMU,VGA at 1 ok
0 > 86750 get-instance-path type invalid/unsupported opcode: 00 - 00
- 00 (00000000) fff18f04 1
invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f08 1
invalid bits: 00400000 for opcode: 0b - 19 - 15 (2d746572) 00009230
0 > 86d3c get-instance-path type invalid/unsupported opcode: 00 - 00
- 00 (00000000) fff18f04 1
invalid/unsupported opcode: 00 - 00 - 00 (00000000) fff18f08 1
invalid bits: 00400000 for opcode: 0b - 19 - 15 (2d746572) 00009230
Sparc32 doesn't crash:
0 > cd /chosen ok
0 > .properties
name "chosen"
stdin ffda1824
stdout ffda18c0
memory ffda1a88
mmu 0
screen ffda1a28
ok
0 > ffda1824 get-instance-path type /obio/zs at 0,100000:a ok
0 > ffda18c0 get-instance-path type /obio/zs at 0,100000:a ok
0 > ffda1a28 get-instance-path type
/iommu at 0,10000000/sbus at 0,10001000/SUNW,tcx at 3,800000 ok
0 > ffda1a88 get-instance-path type /memory at 0,0 ok
More information about the OpenBIOS
mailing list