Re: [Qemu-devel] Powerpc regressions?

[Lennart Sorensen]

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.

> 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.

> 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.

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

No that would be much worse.

> 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.

-- 
Len Sorensen