From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MPB2t-0005jv-TC for qemu-devel@nongnu.org; Fri, 10 Jul 2009 04:01:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MPB2t-0005id-2l for qemu-devel@nongnu.org; Fri, 10 Jul 2009 04:01:27 -0400 Received: from [199.232.76.173] (port=60689 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MPB2s-0005iA-CH for qemu-devel@nongnu.org; Fri, 10 Jul 2009 04:01:26 -0400 Received: from mx20.gnu.org ([199.232.41.8]:4738) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MPB2r-0006TI-Qf for qemu-devel@nongnu.org; Fri, 10 Jul 2009 04:01:25 -0400 Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5] helo=grelber.thyrsus.com) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MPB2r-0002oq-0V for qemu-devel@nongnu.org; Fri, 10 Jul 2009 04:01:25 -0400 From: Rob Landley Subject: Re: [Qemu-devel] Powerpc regressions? Date: Thu, 9 Jul 2009 22:55:22 -0500 References: <200907071748.03623.rob@landley.net> <200907090649.47895.rob@landley.net> <20090709134648.GS15751@csclub.uwaterloo.ca> In-Reply-To: <20090709134648.GS15751@csclub.uwaterloo.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907092255.23771.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 Thursday 09 July 2009 08:46:48 Lennart Sorensen wrote: > On Thu, Jul 09, 2009 at 06:49:47AM -0500, Rob Landley wrote: > > 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. > > Hmm, well I think 0.9.1 worked OK when I used the debian lenny kernel > (never worked with 2.6.18 from etch though). Of course I might be > remembering a development snapshot from between 0.9.1 and 0.10.0. I do > remember the drive order changing at some point and having to change hda > to hdc to boot my images, and now with 0.10.50 (git checkout) having to > change it back again. The 0.9.x series used Open Hackware, not Open Bios. Among its many limitations was the refusal to allow -kernel to boot a kernel if you didn't feed in a _partitioned_ hda so it could set the "boot partition" field. (Thus if your -hda was an ext2 image created by genext2fs, and thus didn't _have_ a partition table, every other qemu target could boot that but powerpc couldn't due to open hackware limitations.) > > 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. > > Bad enough that some linux kernel versions changed the order of devices > at times. The Linux SCSI layer does have a regrettable tendency to throw all devices of all transport types asynchronously into the same bucket and give it a stir, so your USB devices get mixed in with your SATA devices and the order they show up in depends on module load order and a couple of fun race conditions. According to Ted Tso, this is to force the "Linux on the desktop" people to confront and hopefully solve the device enumeration problems of IBM mainframes with thousands of devices. Apparently, if desktop linux users feel the pain of mainframe users, they'll buy macintoshes and this will solve the problem somehow. However, since you generally have to rebuild to trigger random changes in scsi enumeration behavior, and you can control it by only HAVING one type of transport in the system you're emulating, it doesn't break existing binary images. Moving the hardware addresses around under the covers does. > > 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. > > Yeah I am not sure who is changing it. Most recently it changed when they moved from hardwired built-in device tree to querying openbios for this information. Apparently, the device tree openbios provides is not the same device tree that qemu was synthesizing when it was hardwired in. That's what I get from a very cursory read of the patch that changed it, anyway. I can't really say I have a deep understanding of any of this, it's really not my area. > > But that one's easy enough to work around. The "panic shortly after init > > runs" isn't. > > No that would be much worse. It is, yeah. > > 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.) > > Well if I was using UUIDs then yes it would probably not mind, but I am > not at the moment. Still need to know which /dev/hd* to install the > boot loader to of course. Using uuids requires using initramfs, in which case having a root partition is sort of optional. It also requires feeding the virtual machine a bit more than the default 128 megs of ram. Mainly, what I'm trying to do is get an arm system, a mips system, an x86-64 system, an sh4 system, and so on that all work in the same way. Building the same kernel and same root filesystem from the same source, using the same build scripts, just for different targets. Considering that a mips system _can't_ have more than 256 megs of physical memory (due to the top 3 bits of their addresses being used for some kind of strange mode flags and half the rest kept for I/O memory mappings), I need an actual block device that can mount an ext2 root filesystem image to fit a useful native toolchain and enough space to build anything. Initramfs just doesn't give me enough space on that target. I note that lots of other targets have size limitations in how big a kernel image they'll load and decompress before falling off the end of one of their memory mappings. An initramfs with 40 megs of files in it wasn't really the intent of initramfs, and is not that well tested. So yeah, root=/dev/hda isn't actually obsolete. Some of us find it very useful. Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds