qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Powerpc regressions?


From: Rob Landley
Subject: Re: [Qemu-devel] Powerpc regressions?
Date: Thu, 9 Jul 2009 06:49:47 -0500
User-agent: KMail/1.11.2 (Linux/2.6.28-13-generic; KDE/4.2.2; x86_64; ; )

On Wednesday 08 July 2009 08:24:56 Lennart Sorensen wrote:
> On Tue, Jul 07, 2009 at 05:48:02PM -0500, Rob Landley wrote:
> > If you grab this tarball:
> >
> > http://impactlinux.com/fwl/downloads/binaries/system-image/system-image-p
> >owerpc.tar.bz2
> >
> > Extract it, and ./run-emulator.sh.
> >
> > This ran fine under svn 6657 (which is git 2d18e637e5ec).  The next
> > commit screwed up openbios, but reverting openbios worked for a while.
> >
> > In the last couple months, two problems have cropped up:
> >
> > 1) -hda sets /dev/hdc instead of /dev/hda (which is the cdrom).
>
> It seems to me that qemu 0.9.x did it one way, then 0.10.x did it the
> reverse, and now the current development version does it the 0.9.x
> way again.

I don't think 0.9.x had a g3beige, or at least I didn't get it to work.  I 
booted a patched prep kernel under that (with a custom boot rom feeding in a 
custom device tree).  I went to a vanilla unpatched kernel as soon as I was 
able.

> Does make things a bit annoying I must admit.

Device layout varying randomly between different qemu versions is kind of 
annoying, yes.  Especially since the linux kernel needs init=/dev/blah to boot 
directly from a filesystem image, so the kernel command line needed to boot now 
varies between qemu versions.

Also, if the argument wasn't called "-hda", or if the last version that 
actually worked hadn't associated -hda with /dev/hda, the change wouldn't be 
so obviously silly.

But that one's easy enough to work around.  The "panic shortly after init 
runs" isn't.

> > I note that this is the same kernel binary and same system image that
> > used to run fine, only qemu changed. I can try to tweak the kernel
> > .config to work around this, but I don't know what the actual problem
> > is...
> >
> > Suggestions?
>
> Hmm, I haven't seen that.  Of course I am just running a debian lenny
> install in qemu, while I believe you are booting with a kernel passed to
> qemu from the outside (unless you have changed firmware-linux recently
> to use bootloaders, which I doubt).

Still using -kernel.  The tarball I pointed at includes the boot shell script, 
which calls qemu with:

qemu-system-ppc -M g3beige -nographic -no-reboot -kernel "zImage-powerpc" 
  -hdc "image-powerpc.ext2" -append "root=/dev/hda rw init=/usr/sbin/init.sh
  panic=1 PATH=/usr/bin console=ttyS0 $KERNEL_EXTRA"

(Feeding in the ext2 image file as -hdc is the workaround for qemu being unable 
to keep hda and hdc straight on powerpc anymore.  On debian, I expect it boots 
to an initramfs that fires up HAL to look at all partitions on all devices and 
would happily mount a USB flash key as hda if it had the right UUID.  Which 
somebody's going to exploit one of these days, but oh well.)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds




reply via email to

[Prev in Thread] Current Thread [Next in Thread]