From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOs8N-0007oV-VL for qemu-devel@nongnu.org; Thu, 09 Jul 2009 07:49:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOs8M-0007o8-Oq for qemu-devel@nongnu.org; Thu, 09 Jul 2009 07:49:51 -0400 Received: from [199.232.76.173] (port=51204 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOs8M-0007o3-J8 for qemu-devel@nongnu.org; Thu, 09 Jul 2009 07:49:50 -0400 Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:47251 helo=grelber.thyrsus.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MOs8M-0005xE-3W for qemu-devel@nongnu.org; Thu, 09 Jul 2009 07:49:50 -0400 From: Rob Landley Subject: Re: [Qemu-devel] Powerpc regressions? Date: Thu, 9 Jul 2009 06:49:47 -0500 References: <200907071748.03623.rob@landley.net> <20090708132456.GP15751@csclub.uwaterloo.ca> In-Reply-To: <20090708132456.GP15751@csclub.uwaterloo.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907090649.47895.rob@landley.net> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lennart Sorensen Cc: qemu-devel@nongnu.org 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