Re: [Qemu-devel] Just to add one single point

[Rob Landley]

On Monday 09 April 2007 6:32 pm, J. Mayer wrote:
> On Mon, 2007-04-09 at 17:26 -0400, Rob Landley wrote:
> > On Sunday 08 April 2007 7:19 pm, Paul Brook wrote:
> [...]
>  
> > > AFAIK PPC emulation hasn't *ever* worked well enough to boot without at 
> > least 
> > > building a custom linux kernel. In addition the -kernel commandline 
option 
> > > have no effect, and there is no test image available.
> > 
> > By the way, if this ever _does_ start to work, I'd appreciate hearing 
about 
> > it.
> 
> It's been working with at least 2.4 kernels for the last 3 years.

It's been about 3 years since I built a 2.4 kernel.  It's quite possible my 
kernel's configured wrong, but since I've never manged to get to 
the "decompressing linux..." part, I haven't focused too much on that.

> The -kernel command used to work. If it does not anymore, it means
> someone broke it (and it's not me, I'm absolutely sure but it's been a
> very long time I did not test it).

When I run:

qemu-system-ppc -M prep -nographic -hda image-powerpc.ext2 -kernel 
zImage-powerpc -append 'rw init=/tools/bin/sh panic=1 PATH=/tools/bin 
root=/dev/hda console=/dev/ttyS0'

It goes:

Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal
error, but for better emulation accuracy either use a 2.6 host Linux kernel or
type 'echo 1024 > /proc/sys/dev/rtc/max-user-freq' as root.
init_ppc_proc: PVR 00040000 mask ffffffff => 00040000
register PCI host 'pci-bridge' 'pci' '<null>' 'PREP Host PCI Bridge - Motorola 
Raven'
register 'pci-bridge' 'pci' '<null>' 'PREP Host PCI Bridge - Motorola Raven' 
0x80000000 in 'device-tree' 0xffffffff
Done 582b000 582b880
PCI device '<null>' 0 11 0 has no reg properties:
PCI device '<null>' 0 11 0 has no assigned addresses properties:
register pci device 'Qemu VGA' 0000000c 'display' 'VGA' 'Qemu VGA'
register 'Qemu VGA' 'display' 'VGA' 'Qemu VGA' 0x0000000c in 'pci-bridge' 
0x80000000
Done 582b880 582b980
PCI device 'Qemu VGA' 0 12 0 reg properties:
  addr: 82006010 00000000 f0000000 size: 00000000 00800000
PCI device 'Qemu VGA' 0 12 0 assigned addresses properties:
  addr: 82006010 00000000 f0000000 size: 00000000 00800000
PPC Open Hack'Ware BIOS for qemu version 0.4.1
Build 2005-07-06 23:10:57
Copyright 2003-2005 Jocelyn Mayer

Memory size: 144 MB.
Booting from device m
ide0: drive 0: Hard Disk
ERROR: OF_property_copy cannot get property 'hd' for aliases
ide0: drive 1: CD-ROM
ERROR: OF_property_copy cannot get property 'cd' for aliases
ERROR: ATAPI TEST_UNIT_READY : status 41 != 0x40
ide1: drive 0: none
ide1: drive 1: none
Probe partitions for device c
ERROR: No MSDOS signature (0 0 0 0)
Boot partition: 0 9401fff8 9401fff8 0
Probe partitions for device m
ERROR: No MSDOS signature (38 0 0 0)
Use bloc device as raw partition
Boot partition: 0 9401fff8 9401fff8 0
ERROR: OF_property_copy cannot get property 'alias' for <null>
boot device: 5833180 image 1000000 size 1106380
ERROR: No MSDOS signature (7f 45 0 0)
Use bloc device as raw partition
Boot partition: 0 9401fff8 9401fff8 0
boot device: 5833180
ERROR: Found no boot partition!
ERROR: BUG caught...
BIOS execution exception
nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
Stopping execution

And hangs there.

My most recent attempt to ask for help on this petered out here:
http://lists.gnu.org/archive/html/qemu-devel/2007-04/msg00163.html

Oh, and did you ever get the bug report on qemu-ppc not working with uClibc 
because Linux always zeroes r3 (return value from previous syscall, in this 
case "exec") and qemu application emulation apparently doesn't?
http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00713.html
http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00720.html

I sent it to you directly, but your mailserver bounces messages from mine as 
spam.  (I apparently can't even cc you or you won't get a copy through the 
mailing list.)

> Test images are available. Read the STATUS file to see what I use to
> check regressions.

I hadn't noticed that.  Cool, thanks.

> And there are also informations on the Qemu-PPC web page, which is
> referenced by the official Qemu site. If one do not find the images, it
> seems to me he may not have have searched a lot...

I found partitioned filesystem images.  I'm trying to boot a kernel 
with -kernel, and open hackware is complaining it can't find a boot 
partition.

> I'm sorry but I _never_ use custom kernels for tests, apart if I want to
> add traces to track a really well hiden bug. I always use stock kernels
> delivered with distributions or kernels I recompile under Qemu from the
> vanilla sources located at kernel.org, with absolutely no patch. Not all
> run, that's true. Some may even say that only a few run.

If a stock kernel boots then it should be possible to build a kernel from 
source that will also boot.  I'm happy to debug and document how to do so, 
but I'm not good at debugging firmware or bootloaders.

> I also know that some binary blurbs (Linux and real-time OSes based) for
> embedded PowerPC targets boot and run well under Qemu PPC. Some I
> unfortunately cannot release, some I even don't have, just been reported
> they run by their owners. Hope I will have some freely available one of
> these days.

Do any of these boot and run without a partitioned filesystem image?  In 
theory, I should be able to build an initramfs into the kernel and boot with 
no hard drive:

qemu-system-ppc -M prep -nographic -kernel zImage-powerpc -append \
  "console=/dev/ttyS0"

(Although x86 will inist on -hda /dev/zero so it can hack up a fake boot 
sector for its' -kernel option.  Maybe ppc needs something similar.)

But I can't get as far as the "decompressing linux" message, and what goes in 
the kernel seems a bit of a sideshow until then.  None of the other platforms 
require a _partitioned_ image in order to hand control off to the kernel.

> It also seems that most Linux 2.6 kernels support has been broken. It
> used to run too, with some versions having a great problem in
> frame-buffer mode (writing black on black is not really usable). Using
> the serial console always allowed me to follow the boot until X starts.

I'm trying to use serial console.

> It's nowadays broken but it's clearly not my priority to fix this right
> now. I'll have to find the issue, but this will wait some time (but no
> too long, as the problem may be due to a CPU emulation bug).
> 
> As a general statement, it's not my priority to try to find what has
> been broken in the hardware emulation for now as I'm working on the
> PowerPC core emulation. Those fixes I may track someday for fun but I've
> got more urgent things to achieve. I'm sorry for the kiddies that cannot
> play with the last Linux distros or Mac OS X but I clearly do not care
> about this and feel more important to finish 1/ the targets I want to
> emulate (for fun, but not only), 2/ the targets I've been requested to
> add (not for fun, this time).

I've got build scripts that create my own cross compilers from source, and 
then use them to build a native root filesystem, package it as ext2, and boot 
it up to a shell prompt using qemu.

  http://landley.net/code/firmware
  http://lwn.net/Articles/215941/

I've curerntly got this working for i686, x86-64, i586, armv4l-soft, 
armv5l-vfp, mipsel and mips big endian.  I've got gcc working within qemu 
well enough to build and run "hello world" natively on all those platforms.

I'm also most of the way through sparc (it works if init=/hello_world but not 
if init tries to read from stdin, I think it's a uClibc bug I haven't tracked 
down yet.  Sparc's never been a big priority for me, somebody else 
contributed that .config to the project. :)

PowerPC builds, using the same scripts that work for the other platforms.  I 
get a kernel and an ext2 root filesystem image.  It's possible the 
kernel .config, the uClibc .config, the gcc/binutils options, or the qemu 
invocation are wrong (that's the stuff in the platform configuration files), 
but the rest of it's idential to the stuff that works on all the other 
platforms.

I've patched uClibc and to the Linux kernel to fix several things along the 
way:

Mostly the kernel works (although getting it to run an init file ending in .sh 
took a patch: http://lkml.org/lkml/2007/2/22/281).  I could point you at a 
gazillion uClibc things (I'm using the svn version of that so this is where 
most of the bugs I hit are), here's a few of the more recent:
http://uclibc.org/cgi-bin/viewcvs.cgi?rev=18033&view=rev
http://uclibc.org/cgi-bin/viewcvs.cgi?rev=18035&view=rev
http://uclibc.org/cgi-bin/viewcvs.cgi?rev=18041&view=rev
http://uclibc.org/cgi-bin/viewcvs.cgi?rev=18127&view=rev
http://uclibc.org/cgi-bin/viewcvs.cgi?rev=18129&view=rev
http://uclibc.org/cgi-bin/viewcvs.cgi?rev=18270&view=rev
http://uclibc.org/cgi-bin/viewcvs.cgi?rev=18276&view=rev

My problem trying to poke at QEMU for PPC is the bug doesn't seem to be in 
QEMU itself, it seems to be in Open Hackware.  (At last year's OLS the Cell 
maintainer explained to me how on Power PC the firmware has to tell the 
kernel what the available hardware is.  So I can't just skip the firmware 
entirely unless I statically link a device table into said kernel, which I 
have notes on somewhere but really isn't the approach I want to take.  
Everything else I've tried just works with -kernel, and I'd much rather fix 
that if I had a clue how.)

> The kiddies and Slashdot annoucement 
> contest may come after, if I got time. But be sure, I would thank anyone
> that would try to find and fix those problems in the meantime ! And if
> those regression are fixed, be sure I will try to keep those feature
> working.

I can try to get you a patch for the r3 thing after dinner.  (Actually my cvs 
snapshot's a couple weeks out of date and obviously -stable is still 0.9.0, 
so maybe that one's already been fixed by now.  I'll check.)

> So please, don't say Qemu-PPC does not work.

I'm sure it works for some people, I'm just saying I haven't managed to get it 
to work, and I've been trying on and off for months.

> Say some important features 
> have been broken while changing the Qemu core code without care. But
> there is still a sufficient support to test at least Linux running,
> installing, compiling, with X11 and most application running well, with
> one machine and different CPU models available, which is far from beeing
> a "nothing works" statement, imho.

I've never gotten it to work, and the problem seems to be that open firmware 
wants a partitioned image.  Is a partitioned hard drive image a requirement 
to get it to work?

> It would be great to have a lot of more machines, CPU, OS, ...
> supported. Some things will come, some are the way, but it will take
> time. Feel free to suggest things that you feel that should be a
> priority, it may give great ideas...

I have 8 platform variants booting so far with -kernel.

I've encountered separate bugs running a uClibc "Hello World" under 
application emulation (segfault on exit due to r3 not being zeroed, the 
second half of http://landley.net/notes.html#28-03-2007 was my saga tracking 
down the problem), and booting a kernel under system emulation.  (The third 
problem I encountered was your mail server spam blocking mine, which took a 
while to notice because bounce messages are usually noise from forged spam 
from addresses these days...)

Obviously qemu for ppc works for some people.  But I'm not one of them.  I 
would like to _be_ one of them.

I'll go look at the stuff you pointed me at after dinner.

Thanks,

Rob
-- 
Penguicon 5.0 Apr 20-22, Linux Expo/SF Convention.  Bruce Schneier, Christine 
Peterson, Steve Jackson, Randy Milholland, Elizabeth Bear, Charlie Stross...