[Qemu-devel] Just to add one single point

[Qemu-devel] Just to add one single point

[J. Mayer]

The main problem here is that the less one can do when collaborating to
a project is to respect others work.
Then nobody should ever commit anything that touch the code he's not in
charge without previously formally do a proposal, wait for reactions and
discuss, taking care of others remarks, especially when this code might
break some features that are used and mandatory. If no reaction, yes the
thing can be commited with no modification. If there are reactions, they
have to be taken in care or at least discussed (the contradictors may be
wrong, for sure).

There were no proposal sent on this list. I did not received even a
single mail telling me there'll be changes in the code I maintain. Don't
say "it was discussed a lot and approved" when you did not even try to
contact one of the main developpers.
Apart the fact that the commited code implements broken concepts, if one
is not able to respect other people and their work, he just have to
start its own project and work on its own, not to pretend collaborating.

Mr Paul Brook did break the PREP and heathrow machines while doing
changes in the PCI code. There were some posts on this list reporting
this and he never even tried to fix what he broke. And now he's
complaining "I cannot test as it does not work". Looks like a bad joke,
no ?
Today, he's breaking more features without even taking care of the
implications of he's doing. Am I supposed to think this attitude is a
normal and respectuous one ? I'm sorry that I can't. This way of doing
is to be fixed or the project is dead or will become Mr Paul Brook
exclusive toy. If this is what he wants, he has to tell it, do not allow
anybody else to make any change in its "personal code" and let me remove
all the contributions I've made for years.

Regards.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

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

[Thiemo Seufer]

J. Mayer wrote:
[snip]
> Mr Paul Brook did break the PREP and heathrow machines while doing
> changes in the PCI code. There were some posts on this list reporting
> this and he never even tried to fix what he broke. And now he's
> complaining "I cannot test as it does not work". Looks like a bad joke,
> no ?

Actually, I believe it was a commit of mine (patch IIRC by Aurelien
Jarno) which broke PREP. See
http://lists.nongnu.org/archive/html/qemu-devel/2007-01/msg00166.html


Thiemo

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

[J. Mayer]

On Sun, 2007-04-08 at 15:11 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> [snip]
> > Mr Paul Brook did break the PREP and heathrow machines while doing
> > changes in the PCI code. There were some posts on this list reporting
> > this and he never even tried to fix what he broke. And now he's
> > complaining "I cannot test as it does not work". Looks like a bad joke,
> > no ?
> 
> Actually, I believe it was a commit of mine (patch IIRC by Aurelien
> Jarno) which broke PREP. See
> http://lists.nongnu.org/archive/html/qemu-devel/2007-01/msg00166.html

Then, sorry for asserting this. Someone reported me that the patche that
breaks PREP was this one:
<http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/prep_pci.c?sortby=date&r2=1.3&r1=1.2>
I have to admit I dit took the time to check, so...

-- 
J. Mayer <l_indien@magic.fr>
Never organized

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

[Paul Brook]

> Mr Paul Brook did break the PREP and heathrow machines while doing
> changes in the PCI code. There were some posts on this list reporting
> this and he never even tried to fix what he broke. And now he's
> complaining "I cannot test as it does not work". Looks like a bad joke,
> no ?

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.

I stand by my original statement.
A machine that requires building a custom kernel, maybe hacking a bootloader, 
and creating a bootable filesystem from scratch is untestable.

Paul

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 254 bytes --]

On Sunday 08 April 2007, Paul Brook wrote:
> I stand by my original statement.
> A machine that requires building a custom kernel, maybe hacking a
> bootloader, and creating a bootable filesystem from scratch is untestable.

seems reasonable to me
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

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

[J. Mayer]

On Mon, 2007-04-09 at 00:19 +0100, Paul Brook wrote:
> > Mr Paul Brook did break the PREP and heathrow machines while doing
> > changes in the PCI code. There were some posts on this list reporting
> > this and he never even tried to fix what he broke. And now he's
> > complaining "I cannot test as it does not work". Looks like a bad joke,
> > no ?
> 
> 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.

So you never did use it.
I never had to use a custom kernel to boot the PowerPC target, apart in the very first step of developments.
PREP, heathrow and Mac99 machine used to run standard Linux distributions, from install CDROMs and installed hard disk drives.
Mac99 still does.

> I stand by my original statement.
> A machine that requires building a custom kernel, maybe hacking a bootloader, 
> and creating a bootable filesystem from scratch is untestable.

True. But that's not Qemu-PPC you are talking about.
It did boot some standard Linux distributions 3 years ago and still does (just the Mac99 machine, for now).
I don't say it boots every OS for PowerPC machines, but it does boot at least quite a lot of Linux distros.
Even if I do just test 3 because I'm working more on the core emulation, those days, and my care is not to introduce regressions.
And because it's already quite long to check 3 distributions.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

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

[Rob Landley]

On Sunday 08 April 2007 7:19 pm, Paul Brook wrote:
> > Mr Paul Brook did break the PREP and heathrow machines while doing
> > changes in the PCI code. There were some posts on this list reporting
> > this and he never even tried to fix what he broke. And now he's
> > complaining "I cannot test as it does not work". Looks like a bad joke,
> > no ?
> 
> 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.

Right now, my build scripts are building a PowerPC kernel and ext2 filesystem 
image, using a procedure that works on arm, mips, x86, and x86-64.  It's 
producing a _result_, but I have no idea if it actually works.  I do know 
that I can't run it under qemu the way I can all the others.  (Even sparc at 
least _boots_, I think its problem is a uClibc issue.)

http://landley.net/code/firmware/downloads/image

Shell scripts to build all that from source (plus cross compilers and a 
tarball of the files in the ext2 image) are one level up.

> I stand by my original statement.
> A machine that requires building a custom kernel, maybe hacking a
> bootloader, and creating a bootable filesystem from scratch is untestable.

Well, it's certainly inconvenient.  The custom kernel I can do, the filesystem 
I've got.  But bootloaders are a bit of a weak spot with me...

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

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

[J. Mayer]

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.
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).
Test images are available. Read the STATUS file to see what I use to
check regressions.
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'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.

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.

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

So please, don't say Qemu-PPC does not work. 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.
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...

[...]

-- 
J. Mayer <l_indien@magic.fr>
Never organized

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

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 <l_indien@magic.fr>
Never organized

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

[Jason Wessel]

[-- Attachment #1: Type: text/plain, Size: 2429 bytes --]

J. Mayer wrote:
> On Wed, 2007-04-11 at 17:49 -0400, Rob Landley wrote: 
>   
>> 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.
>   
If you do not modify the prep loader, then it is impossible to pass 
arguments or load a kernel that expands to > 4meg.  With respect to  
using an unmodified prep loader, you have to build the boot arguments 
you want into the kernel itself with the .config file options.
> [...] 
>   
>>> 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 !).
>
> [...]
>
>   
> you may try to boot kernels in PREP format as they look like regular boot partitions...
> It may help.
>
>   

While I am sure folks have the objective to be able to boot something 
that is not modified, my objective was to modify the kernel to work with 
qemu until that first objective is met.  If you use a 2.6.21rc candidate 
you can use the attached patches to boot.  I provided a .config file as 
well.  The frame buffer is definitely broken, but I had not really 
looked into why because I was more interested in simply using the ppc 
instruction sets.

Note I startup with the following and it works perfectly fine with my 
modified kernels:
qemu-system-ppc -nographic -kernel zImage.prep -s -M prep -append 
"console=ttyS0 ip=dhcp root=/dev/nfs nfsroot=10.0.2.2:/export/ppc rw 
netdev=9,0x300,eth0"

There is a new regression between Apr 9 and Apr 10 in the QEMU CVS HEAD 
where tcp checksums are failing again.  :-(

If it would help, I can certainly provide some of my zImage files which 
run with several different 2.6.x kernels.

Jason.



[-- Attachment #2: dot_config.gz --]
[-- Type: application/x-gzip, Size: 9903 bytes --]

[-- Attachment #3: qemu_prep_loader.patch --]
[-- Type: text/x-patch, Size: 3984 bytes --]

Adjust prep loader to deal with larger kernel images.

signed-off-by: Jason Wessel <jason.wessel@windriver.com>

Index: linux-2.6.21-rc3/arch/ppc/boot/simple/misc.c
===================================================================
--- linux-2.6.21-rc3.orig/arch/ppc/boot/simple/misc.c
+++ linux-2.6.21-rc3/arch/ppc/boot/simple/misc.c
@@ -17,6 +17,7 @@
 #include <linux/types.h>
 #include <linux/string.h>
 
+#include <asm/residual.h>
 #include <asm/page.h>
 #include <asm/mmu.h>
 #include <asm/bootinfo.h>
@@ -27,6 +28,7 @@
 
 #include "nonstdio.h"
 
+#define CONFIG_RUNTIME_CMDLINE 0x17ff000
 /* Default cmdline */
 #ifdef CONFIG_CMDLINE
 #define CMDLINE CONFIG_CMDLINE
@@ -53,7 +55,7 @@
 char *avail_ram;
 char *end_avail;
 char *zimage_start;
-char cmd_preset[] = CMDLINE;
+char cmd_preset[256] = CMDLINE;
 char cmd_buf[256];
 char *cmd_line = cmd_buf;
 int keyb_present = HAS_KEYB;
@@ -91,9 +93,11 @@ get_mem_size(void)
 #endif
 
 struct bi_record *
-decompress_kernel(unsigned long load_addr, int num_words, unsigned long cksum)
+decompress_kernel(unsigned long load_addr, int num_words, unsigned long cksum
+,RESIDUAL *residual, void *OFW_interface)
 {
 #ifdef INTERACTIVE_CONSOLE
+    int do_console = 0;
 	int timer = 0;
 	char ch;
 #endif
@@ -120,9 +124,12 @@ decompress_kernel(unsigned long load_add
 	 * and we must have the correct file linked in here.
 	 */
 	TotalMemory = get_mem_size();
+	puts("TotalMemory: "); puthex(TotalMemory); puts("\n");
+	puts("TotalResid: "); puthex(residual->TotalMemory); puts("\n");
+	puts("Resid at: "); puthex((unsigned int)residual); puts("\n");
 
-	/* assume the chunk below 8M is free */
-	end_avail = (char *)0x00800000;
+	/* assume the chunk below 10M is free */
+	end_avail = (char *)0x00A00000;
 
 	/*
 	 * Reveal where we were loaded at and where we
@@ -139,6 +146,13 @@ decompress_kernel(unsigned long load_add
 		puts("\n");
 	}
 
+	if (residual) {
+		puts("board data at: "); puthex((unsigned long)residual);
+		puts(" ");
+		puthex((unsigned long)((unsigned long)residual +
+					sizeof(RESIDUAL)));
+		puts("\n");
+	}
 	/*
 	 * We link ourself to 0x00800000.  When we run, we relocate
 	 * ourselves there.  So we just need __image_begin for the
@@ -167,15 +181,21 @@ decompress_kernel(unsigned long load_add
 	}
 
 #ifndef CONFIG_40x /* don't overwrite the 40x image located at 0x00400000! */
-	avail_ram = (char *)0x00400000;
+	avail_ram = (char *)0x00500000;
 #endif
-	end_avail = (char *)0x00800000;
+	end_avail = (char *)0x00A00000;
 	puts("avail ram:     "); puthex((unsigned long)avail_ram); puts(" ");
 	puthex((unsigned long)end_avail); puts("\n");
 
 	if (keyb_present)
 		CRT_tstc();  /* Forces keyboard to be initialized */
 
+#ifdef CONFIG_RUNTIME_CMDLINE
+    if (*(char *)CONFIG_RUNTIME_CMDLINE != '\0')
+    {
+        memcpy (cmd_preset, (char *)CONFIG_RUNTIME_CMDLINE, sizeof(cmd_preset));
+    }
+#endif
 	/* Display standard Linux/PPC boot prompt for kernel args */
 	puts("\nLinux/PPC load: ");
 	cp = cmd_line;
@@ -187,7 +207,7 @@ decompress_kernel(unsigned long load_add
 	 * If they have a console, allow them to edit the command line.
 	 * Otherwise, don't bother wasting the five seconds.
 	 */
-	while (timer++ < 5*1000) {
+	while (do_console && timer++ < 5*1000) {
 		if (tstc()) {
 			while ((ch = getc()) != '\n' && ch != '\r') {
 				/* Test for backspace/delete */
@@ -215,8 +235,9 @@ decompress_kernel(unsigned long load_add
 #endif
 	puts("\n");
 
-	puts("Uncompressing Linux...");
-	gunzip(NULL, 0x400000, zimage_start, &zimage_size);
+	puts("Compressed size: "); puthex((unsigned long)(zimage_size));
+	puts("\nUncompressing Linux...");
+	gunzip(NULL, 0x500000, zimage_start, &zimage_size);
 	puts("done.\n");
 
 	/* get the bi_rec address */
@@ -274,5 +295,5 @@ load_kernel(unsigned long load_addr, int
 		void *ign1, void *ign2)
 {
 		board_isa_init();
-		return decompress_kernel(load_addr, num_words, cksum);
+		return decompress_kernel(load_addr, num_words, cksum, ign1, ign2);
 }

[-- Attachment #4: qemu_ppc_irq_chip_fix.patch --]
[-- Type: text/x-patch, Size: 719 bytes --]

Workaround for QEMU ppc 32 to force interrupt acknoledgement

signed-off-by: Jason Wessel <jason.wessel@windriver.com>

Index: linux-2.6.21-rc1/kernel/irq/chip.c
===================================================================
--- linux-2.6.21-rc1.orig/kernel/irq/chip.c
+++ linux-2.6.21-rc1/kernel/irq/chip.c
@@ -225,11 +225,17 @@ static void default_enable(unsigned int 
 	desc->status &= ~IRQ_MASKED;
 }
 
+#define IRQ_DELAYED_DISABLE    0x10000000      /* IRQ disable (masking) happens delayed. */
+
 /*
  * default disable function
  */
 static void default_disable(unsigned int irq)
 {
+	struct irq_desc *desc = irq_desc + irq;
+
+	if (!(desc->status & IRQ_DELAYED_DISABLE))
+		desc->chip->mask(irq);
 }
 
 /*

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

[Jason Wessel]

Jason Wessel wrote:
>
> There is a new regression between Apr 9 and Apr 10 in the QEMU CVS 
> HEAD where tcp checksums are failing again.  :-(
>

I stand corrected it not the TCP check sums.  The new PPC pic code does 
not work so as to allow the ethernet device driver to receive packets.  
I guess the question should be is if we would have expected more to work 
than breaks or if different cases actually work now with the new PPC pic 
code, or if they are all broken.

Jason.

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

[J. Mayer]

On Thu, 2007-04-12 at 10:49 -0500, Jason Wessel wrote:
> J. Mayer wrote:
> > On Wed, 2007-04-11 at 17:49 -0400, Rob Landley wrote: 
> >   
> >> 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.
> >   
> If you do not modify the prep loader, then it is impossible to pass 
> arguments 

You can compile the kernel arguments you need into the CONFIG_CMDLINE
kernel option. No need for a patch for this to work.

> or load a kernel that expands to > 4meg.  With respect to  
> using an unmodified prep loader, you have to build the boot arguments 
> you want into the kernel itself with the .config file options.

A kernel > 4 MB ? Even on my amd64 I usually have kernels smaller than
this. Is there any need to have such a big kernel for anyone ?

> > [...] 
> >   
> >>> 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 !).
> >
> > [...]
> >
> >   
> > you may try to boot kernels in PREP format as they look like regular boot partitions...
> > It may help.
> >
> >   
> 
> While I am sure folks have the objective to be able to boot something 
> that is not modified, my objective was to modify the kernel to work with 
> qemu until that first objective is met.  If you use a 2.6.21rc candidate 
> you can use the attached patches to boot.  I provided a .config file as 
> well.  The frame buffer is definitely broken, but I had not really 
> looked into why because I was more interested in simply using the ppc 
> instruction sets.

The problem with the frame-buffer is quite simple: it works (well, it
used to work, I did not check with such a recent kernel...) but the
kernel uses a black font on a black background.
Unfortunatelly, the reason of this bug seems not obvious (or I was not
so lucky to find it !).

> Note I startup with the following and it works perfectly fine with my 
> modified kernels:
> qemu-system-ppc -nographic -kernel zImage.prep -s -M prep -append 
> "console=ttyS0 ip=dhcp root=/dev/nfs nfsroot=10.0.2.2:/export/ppc rw 
> netdev=9,0x300,eth0"
> 
> There is a new regression between Apr 9 and Apr 10 in the QEMU CVS HEAD 
> where tcp checksums are failing again.  :-(

> I stand corrected it not the TCP check sums.  The new PPC pic code
does 
> not work so as to allow the ethernet device driver to receive packets.  
> I guess the question should be is if we would have expected more to work 
> than breaks or if different cases actually work now with the new PPC pic 
> code, or if they are all broken.

Did it really work before this patch ? Because IRQs were broken _before_ the IRQ scheme patches, for the PREP platform, which is the reason I cannot test it.
It seem to have been broken in September and the problem seems to be somewhere in the PCI bridge code...

[...]

-- 
J. Mayer <l_indien@magic.fr>
Never organized

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

[Jason Wessel]

J. Mayer wrote:
> On Thu, 2007-04-12 at 10:49 -0500, Jason Wessel wrote:
>   
> A kernel > 4 MB ? Even on my amd64 I usually have kernels smaller than
> this. Is there any need to have such a big kernel for anyone ?
>   

Maybe no one else has the need but me...  I built a kernel with nearly 
all built in code, and it just got too big, so I upped the limit.

>
> The problem with the frame-buffer is quite simple: it works (well, it
> used to work, I did not check with such a recent kernel...) but the
> kernel uses a black font on a black background.
> Unfortunatelly, the reason of this bug seems not obvious (or I was not
> so lucky to find it !).
>
>   
Then the frame buffer is probably grinding along just fine,  eventually 
it will probably be fixed by someone who has the interest.
> Did it really work before this patch ? Because IRQs were broken _before_ the IRQ scheme patches, for the PREP platform, which is the reason I cannot test it.
> It seem to have been broken in September and the problem seems to be somewhere in the PCI bridge code...
>   


Yes I have been able to boot the prep machine all with 2.6 kernels, 
since last May.  My question is do you have it working now with some 
image on the prep machine? 

It is entirely possible that the 2.6.x kernel's implentation for talking 
to QEMU is wrong, but it was not obvious to me how it subtly changed so 
as to look where to fix it with the newly merged pic logic.

Jason.

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

[Rob Landley]

I'm fighting with cvs and haven't been able to update my build directory yet.  
(I've been spoiled by mercurial, where doing an update on a directory with 
modifications in it doesn't _eat_ the directory.  And my attempt to create a 
mercurial copy of the cvs history with tailor so I could tracck development 
more easily revealed an interesting bug tailor that ate an afternoon without 
fixing anything.  Sigh, buried in tangents...)

You've given me some more avenues to pursue and I hope to get to it this 
weekend, but in the meantime lemme catch up with the thread...

On Thursday 12 April 2007 3:56 am, J. Mayer wrote:
> > 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...

If qemu is built for Linux, why would it be launching BSD programs?  Possibly 
an #ifdef is called for here?

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

On BSD, that may be.  (I don't use it.)  But when running Linux programs, it 
doesn't match the real, documented, and consistent behavior of the Linux 
kernel that other software (like uClibc) has come to rely on.  On Linux, it 
may be compliant with a theoretical standard, but it simply doesn't match 
reality.

Again, this sounds like a job for an #ifdef.

To quote from http://wall.riscom.net/books/proc/ppc/cwg/a_abi.html

> IBM has defined three ABIs for the PowerPC architecture: the AIX ABI for
> big-endian 32-bit PowerPC processors and the Windows NT and Workplace ABIs
> for little-endian 32-bit PowerPC processors. Other PowerPC users have
> defined other ABIs. As a practical matter, ABIs tend to be associated with
> a particular operating system or family of operating systems. Programs
> compiled for one ABI are frequently incompatible with programs compiled for
> another ABI because of the low-level strategic decisions required by an
> ABI.

What the kernel does is set r3 to the return value of the exec call (and argc 
in r1), then the dynamic linker shuffles things around so r3 points to argc.  
When a program is statically linked, it gets r3 zeroed, as explained here:

  http://sources.redhat.com/ml/libc-alpha/2003-03/msg00272.html

It's quite possible that command line arguments don't work when the program 
_is_ dynamically linked because the shuffling the dynamic linker does is 
going to overwrite r3 with r1.  I don't know, "hello world" doesn't look at 
argc and my script only uses application emulation as a smoke test for my new 
cross compiler toolchain.

Google brings up this as the abi document:

  http://refspecs.freestandards.org/elf/elfspec_ppc.pdf

Which describes the registers on page 30-32.  Page 38 says the return value is 
in r3 (and Linux is putting the return value of "exec" into r3, which is why 
they expect it to be 0 when exec worked).  Page 44 does talk about the 
register layout you mention later, but on Linux the dynamic linker is what 
sets this up, not the kernel.  (Whether or not the kernel should leave this 
to the dynamic linker is immaterial: reality is that it does.  And it's been 
doing it this way long enough that it's not likely to change.)

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

Neither is mine, alas.

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

My problem is that none of the other platforms I've gotten the kernel booting 
on (so far arm, mips, x86, x86_64, and sparc) work like this.  I got them all 
booting kernel + unpartitioned ext2 filesystem image.  I'm reluctant to go 
back and change all the other platforms because PowerPC currently has unique 
requirements due to options like -kernel not working.  So far I've just 
deferred adding PowerPC support.

I can make a partitioned image for manual testing, but I haven't yet because I 
can't check that into my build system without a major rewrite of unrelated 
things that work as they are.

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

I don't use proprietary firmware.  I haven't got any, and it would only 
interest me if I was being paid to be interested.  I have pondered using 
u-boot, but it's way down on the todo list...

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

I can do that, but with -kernel it wasn't handing over control to the kernel 
at all so I hadn't noticed that part.

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

Did you launch them under BSD, or under Linux?

If QEMU application emulation can launch BSD programs under Linux, but can't 
launch Linux programs, something is wrong.

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

As far as I can tell, the exec syscall returns what other syscalls return, and 
the dynamic linker shuffles stuff around to where the ABI says main() should 
expect them.

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

I'll try it.  My attempts to make my own prep kernel with menuconfig didn't 
produce a zImage (still dunno why), but the kernel has a default prep config 
I can start from...

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

I'm trying to test Linux on as many different platforms as I can, and create a 
unified cross-platform Linux build environment.  (Which is why I do as little 
cross compiling as possible before getting a native build environment running 
under qemu, and then build natively under emulation the rest of the way.  
Much much much less to debug that way.  It's slow, but I can teach the thing 
to call out to the cross compiler via distcc to do the heavy lifting, in 
which case it's still doing ./configure and make and #include resolution and 
library linking inside the emulator so 95% of the suckage of cross compiling 
goes away...)

Now that I've gotten a few platforms building "hello world" I've paused on the 
depth-first bit of building a whole gentoo system in there (and getting the 
distcc thing working), and I'm going breadth-first a bit to try to add lots 
of platforms and get them to build "hello world" natively inside qemu.

It's a bit frustrating in places, but most of it's been off in 
gcc/binutils/uClibc/linux land.  (All of which I've broken more than once.)  
My general approach to qemu has generally been "ask a couple of dumb 
questions and wait for the next release", because development here is a bit 
rapid for me to keep up with in the amount of time I have to spend on it.

This is why I've been approaching it from "ok, all these these other platforms 
work this way, but powerpc doesn't".

Thanks,

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

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

[Rob Landley]

On Thursday 12 April 2007 11:49 am, Jason Wessel wrote:
> J. Mayer wrote:
> > On Wed, 2007-04-11 at 17:49 -0400, Rob Landley wrote: 
> >   
> >> 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.
> >   
> If you do not modify the prep loader, then it is impossible to pass 
> arguments or load a kernel that expands to > 4meg.  With respect to  
> using an unmodified prep loader, you have to build the boot arguments 
> you want into the kernel itself with the .config file options.

Any chance of pushing that loader patch back upstream?  (At least into -mm?)

> While I am sure folks have the objective to be able to boot something 
> that is not modified, my objective was to modify the kernel to work with 
> qemu until that first objective is met.  If you use a 2.6.21rc candidate 
> you can use the attached patches to boot. I provided a .config file as  
> well.

Applying said .config to 2.6.20.6 and running make oldconfig 
was...  "interesting".  Ah!  You're using ARCH=ppc to build the kernel and 
I've been using ARCH=powerpc.  I totally do not understand the difference 
between them, but I can adjust to that if it's a condition of making things 
work...  (Switch _off_ CONFIG_LOCALVERSION_AUTO "Hang the build indefinitely 
waiting for git to do who knows what"...)

Hey, I got a zImage.prep!

> > The frame buffer is definitely broken, but I had not really   
> looked into why because I was more interested in simply using the ppc 
> instruction sets.
> 
> Note I startup with the following and it works perfectly fine with my 
> modified kernels:
> qemu-system-ppc -nographic -kernel zImage.prep -s -M prep -append 
> "console=ttyS0 ip=dhcp root=/dev/nfs nfsroot=10.0.2.2:/export/ppc rw 
> netdev=9,0x300,eth0"

Uncompressing Linux... Segmentation fault.  But hey, it's progress.  (It got 
that far!  This is a first for me.)

This is using a 2-week old qemu cvs snapshot and not using the 2.6.21-rc you 
mentioned, and I haven't applied your patches yet, so I'll try all that next.  
But I got it to say "Uncompressing Linux..."!  This is progress!)

Thank you.

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

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

[Rob Landley]

On Thursday 12 April 2007 11:49 am, Jason Wessel wrote:
> J. Mayer wrote:
> > On Wed, 2007-04-11 at 17:49 -0400, Rob Landley wrote: 
> >   
> >> qemu-system-ppc -M prep -nographic -kernel zImage-powerpc -append \
> >>   "console=/dev/ttyS0"
...
> While I am sure folks have the objective to be able to boot something 
> that is not modified, my objective was to modify the kernel to work with 
> qemu until that first objective is met.  If you use a 2.6.21rc candidate 
> you can use the attached patches to boot.  I provided a .config file as 
> well.  The frame buffer is definitely broken, but I had not really 
> looked into why because I was more interested in simply using the ppc 
> instruction sets.

Ok, using a qemu CVS snapshot from this morning, I built 2.6.20.6 for powerpc 
using the config you attached to the message I'm replying to (ran make 
oldconfig on it and hit "enter", and then removed CONFIG_LOCALVERSION_AUTO, 
then built with "make ARCH=ppc CROSS_COMPILE=powerpc-" using the cross 
compiler I pointed to earlier which is configured for powerpc-unknown-linux.)

Then ran the above qemu line, and qemu segfaulted trying to decompress the 
Linux kernel.  (Is qemu supposed to segfault?  I can reproduce this quite 
easily...)

Thinking this might be the "decompresses to >4 megs" problem (your config 
produces a HUGE krenel), I then applied your patches to the kernel (the 
second is already there in .6, the first needed one hunk fixed up by hand)...

Nope, still segfaults.

> Note I startup with the following and it works perfectly fine with my 
> modified kernels:
> qemu-system-ppc -nographic -kernel zImage.prep -s -M prep -append 
> "console=ttyS0 ip=dhcp root=/dev/nfs nfsroot=10.0.2.2:/export/ppc rw 
> netdev=9,0x300,eth0"
> 
> There is a new regression between Apr 9 and Apr 10 in the QEMU CVS HEAD 
> where tcp checksums are failing again.  :-(
> 
> If it would help, I can certainly provide some of my zImage files which 
> run with several different 2.6.x kernels.

This seems to be a qemu issue.  (It really shouldn't segfault, no matter what 
the code it's emulating does.)

What qemu version are you using to run this with?

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