[Top][All Lists]
[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
Re: [Qemu-devel] Powerpc regressions?, Rob Landley, 2009/07/12