Re:Qemu-PPC problems (was [Qemu-devel] Just to add one single point)

[J. Mayer]

On Wed, 2007-04-11 at 17:49 -0400, Rob Landley wrote: 
> 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'

I believe you. And I checked, it does not work anymore, you are right.

[...]

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

This is documented in linux-user/elfload.c
The fact is r3 is not zeroed to follow the PowerPC ABI and then be able
to launch BSD program that relies on the kernel following the ABI. If
Linux does not follow the ABI requirements...
Once again, it's been a long time I did not check, but Qemu-PPC used to
be able to launch some BSD programs too.

[....]

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

Cannot do anything about it, the mailserver is not mine.

[...]

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

That's what I do, but using a partitioned file system: I try to act the
same as what I do when using a real PowerPC based machine. So I compile
my kernel, install it and modify the yaboot configuration file to use
it.

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

The binary blurbs I can use for test are flash images. That means that
they completely replace the firmware with proprietary ones. Then, the
-kernel option is not relevant.
The -kernel option is a qemu hack. You cannot do that on real hardware,
so it will never work when using proprietary firmwares.

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

You cannot append anything to the command line this way, with the PPC
firmware...
You can append options when using yaboot, not with the -kernel option.
Then, you should use the CONFIG_CMDLINE kernel option to add the option
you absolutely need to boot.

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

I tried and the kernel seem to hang before reaching the start_kernel
routine. That why I said there may now be a CPU emulation bug that broke
everything.... Must do more checks with a debug kernel (with traces,
this time. Using early_printk may help a lot !).

[...]

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

Great.

[...]
> 
> 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.)

I'm not sure this is a great idea. It would break other things to zero r3 at 
program start. I just checked and I've been able to launch very simple BSD 
programs.
If you change this, it would never have a chance to work.
Linux seem not to follow the ABI but does not zeroes r3 as a result of the exec 
syscall.
The r3 register is zeroed after the fork (which is correct) then the exec 
syscall does not seem to set up its value, which is incorrect.
So, imho, the crt1 code should never rely on the fact r3 is zeroed.

The PowerPC ABI says:
"When a process is first entered (from an exec system call)" ...
"Consequently a program that require registers to have specific values must set 
them explicitely during process initialization. It should not rely on the 
operating system to set all registers to 0"
"Following are the registers whose content is specified:"
"r1: the initial stack pointer" ...
"r3: contains argc" ...
"r4: contains argv" ...
"r5: contains envp" ...
"r6: contains a pointer to the auxillary vector" ...
"r7: contains a termination function pointer" ...

[...]
> > 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?

you may try to boot kernels in PREP format as they look like regular boot 
partitions...
It may help.

> > 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 was thinking about more PowerPC based CPUs, platforms, OSes, ....

[...]

-- 
J. Mayer <address@hidden>
Never organized