Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[J. Mayer]

On Thu, 2007-10-18 at 19:12 -0500, Rob Landley wrote:
> The easy way to reproduce this is go to "http://landley.net/hg/firmware", 
> download tip, and "./build.sh powerpc".  When it finishes building 
> everything, cd build and "./run-powerpc.sh".
> 
[...]

> The downside is that the result boots fine under qemu-0.9.0, but is broken 
> with current cvs.  I tracked it down to the specific patch with "git bisect", 
> and it's this one:
> 
> http://git.kernel.dk/?p=qemu.git;a=commit;h=36f447f730f61ac413c5b1c4a512781f5dea0c94
> 
> author  j_mayer <j_mayer>
> 	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)
> committer  j_mayer <j_mayer>
> 	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)

What is strange is that it was reported as unable to boot long before
this patch. It was broken when the Qemu PCI architecture has been
redesigned and have never been reported booting since then (2 years ago,
if I remember well). In march 2007, I did test and reported that PreP
and heathrow target were unable to boot, not receiving any IRQ from PCI
(in fact, adding traces proves there are even no IRQ generated in the
PCI code). Someone reported the faulty patch during this summer (but
I've not been unable to find the mail in the mailing list archive
tonight).
I have to admit I never put the focus on trying to solve this issue, has
I usually use Mac99 or PowerPC 405 targets for tests and that PreP
machines are long obsolete and the heathrow target does not reflect any
real machine. But this is to be solved, for sure.

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

[Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Rob Landley]

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

The easy way to reproduce this is go to "http://landley.net/hg/firmware", 
download tip, and "./build.sh powerpc".  When it finishes building 
everything, cd build and "./run-powerpc.sh".

What I did is build a new ppc_rom.bin (attached, source code is at 
http://landley.net/hg/firmware/raw-diff/92f89c9c9495/sources/toys/make-ppc_rom.tar.bz2 ) 
which was written by Milton Miller.  I use that firmware as the boot rom 
(point -L at the directory it's in) instead of Open Hackware, which still 
doesn't work for me.

Then I build a 2.6.23 kernel with this patch: 
http://landley.net/hg/firmware/raw-diff/fdb6ddd4c3b7/sources/patches/linux-ppcqemu.patch
which adds a "qemu" target.

I then boot with the following command line (modulo wordwrap damage):

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=ttyS0' -L ../sources/toys

And I get a shell prompt inside qemu!  (After almost _two_years_ of trying, 
I'm kind of happy about this.)

The downside is that the result boots fine under qemu-0.9.0, but is broken 
with current cvs.  I tracked it down to the specific patch with "git bisect", 
and it's this one:

http://git.kernel.dk/?p=qemu.git;a=commit;h=36f447f730f61ac413c5b1c4a512781f5dea0c94

author  j_mayer <j_mayer>
	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)
committer  j_mayer <j_mayer>
	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)

 Implement embedded IRQ controller for PowerPC 6xx/740 & 750.
 Fix PowerPC external interrupt input handling and lowering.
 Fix OpenPIC output pins management.
 Fix multiples bugs in OpenPIC IRQ management.
 Fix OpenPIC CPU(s) reset function.
 Fix Mac99 machine to properly route OpenPIC outputs to the PowerPC input 
pins.
 Fix PREP machine to properly route i8259 output to the PowerPC external
   interrupt pin.

Versions before that patch went in work fine.  Versions since then hang 
halfway through IDE controller initialization:

  Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
  ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
  hda: QEMU HARDDISK, ATA DISK drive
  hda: IRQ probe failed (0x0)
  hdb: IRQ probe failed (0x0)
  hdb: IRQ probe failed (0x0)
  hdb: QEMU CD-ROM, ATAPI CD/DVD-ROM drive
  hdb: IRQ probe failed (0x0)
  <-- hangs here with the patch
  ide0 at 0x1f0-0x1f7,0x3f6 on irq 13
  hda: max request size: 512KiB
  hda: 4194304 sectors (2147 MB) w/256KiB Cache, CHS=4161/255/63
  hda: set_multmode: status=0x41 { DriveReady Error }
  hda: set_multmode: error=0x04 { DriveStatusError }
  ide: failed opcode was: 0xef
  hda: cache flushes supported
  hda: unknown partition table
  mice: PS/2 mouse device common for all mice

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

[-- Attachment #2: ppc_rom.bin --]
[-- Type: application/octet-stream, Size: 4096 bytes --]

[Qemu-devel] Re: I got a kernel booted under qemu-system-ppc !

[Milton Miller]

I saw a reply in the archives ... if you forward it to me so i can get 
the message for threading I'll reply.

milton

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Aurelien Jarno]

Rob Landley a écrit :
> The easy way to reproduce this is go to "http://landley.net/hg/firmware", 
> download tip, and "./build.sh powerpc".  When it finishes building 
> everything, cd build and "./run-powerpc.sh".
> 
> What I did is build a new ppc_rom.bin (attached, source code is at 
> http://landley.net/hg/firmware/raw-diff/92f89c9c9495/sources/toys/make-ppc_rom.tar.bz2 ) 
> which was written by Milton Miller.  I use that firmware as the boot rom 
> (point -L at the directory it's in) instead of Open Hackware, which still 
> doesn't work for me.
> 
> Then I build a 2.6.23 kernel with this patch: 
> http://landley.net/hg/firmware/raw-diff/fdb6ddd4c3b7/sources/patches/linux-ppcqemu.patch
> which adds a "qemu" target.
> 
> I then boot with the following command line (modulo wordwrap damage):
> 
> 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=ttyS0' -L ../sources/toys
> 
> And I get a shell prompt inside qemu!  (After almost _two_years_ of trying, 
> I'm kind of happy about this.)

It also works here (with a Debian chroot). Thanks a lot for this work!

> The downside is that the result boots fine under qemu-0.9.0, but is broken 
> with current cvs.  I tracked it down to the specific patch with "git bisect", 
> and it's this one:
> 
> http://git.kernel.dk/?p=qemu.git;a=commit;h=36f447f730f61ac413c5b1c4a512781f5dea0c94
> 
> author  j_mayer <j_mayer>
> 	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)
> committer  j_mayer <j_mayer>
> 	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)
> 
>  Implement embedded IRQ controller for PowerPC 6xx/740 & 750.
>  Fix PowerPC external interrupt input handling and lowering.
>  Fix OpenPIC output pins management.
>  Fix multiples bugs in OpenPIC IRQ management.
>  Fix OpenPIC CPU(s) reset function.
>  Fix Mac99 machine to properly route OpenPIC outputs to the PowerPC input 
> pins.
>  Fix PREP machine to properly route i8259 output to the PowerPC external
>    interrupt pin.
> 

It looks like the interrupts are (partly) broken even with QEMU 0.9.0. I
have tried to enable the NE2000 ISA card in the kernel (a small tweak is
needed in a KConfig a file), but I wasn't successful.

The card is not fully detected when the module is loaded, so I had to
give the IRQ number by hand. Then the ethernet device is recognized, the
MAC address is also recognized, but when I want to transmit data I only
get timeout messages from the kernel...

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Aurelien Jarno]

On Thu, Oct 18, 2007 at 07:12:57PM -0500, Rob Landley wrote:
> The easy way to reproduce this is go to "http://landley.net/hg/firmware", 
> download tip, and "./build.sh powerpc".  When it finishes building 
> everything, cd build and "./run-powerpc.sh".
> 
> What I did is build a new ppc_rom.bin (attached, source code is at 
> http://landley.net/hg/firmware/raw-diff/92f89c9c9495/sources/toys/make-ppc_rom.tar.bz2 ) 
> which was written by Milton Miller.  I use that firmware as the boot rom 
> (point -L at the directory it's in) instead of Open Hackware, which still 
> doesn't work for me.
> 
> Then I build a 2.6.23 kernel with this patch: 
> http://landley.net/hg/firmware/raw-diff/fdb6ddd4c3b7/sources/patches/linux-ppcqemu.patch
> which adds a "qemu" target.
> 
> I then boot with the following command line (modulo wordwrap damage):
> 
> 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=ttyS0' -L ../sources/toys
> 
> And I get a shell prompt inside qemu!  (After almost _two_years_ of trying, 
> I'm kind of happy about this.)
> 
> The downside is that the result boots fine under qemu-0.9.0, but is broken 
> with current cvs.  I tracked it down to the specific patch with "git bisect", 
> and it's this one:
> 
> http://git.kernel.dk/?p=qemu.git;a=commit;h=36f447f730f61ac413c5b1c4a512781f5dea0c94
> 
> author  j_mayer <j_mayer>
> 	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)
> committer  j_mayer <j_mayer>
> 	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)
> 
>  Implement embedded IRQ controller for PowerPC 6xx/740 & 750.
>  Fix PowerPC external interrupt input handling and lowering.
>  Fix OpenPIC output pins management.
>  Fix multiples bugs in OpenPIC IRQ management.
>  Fix OpenPIC CPU(s) reset function.
>  Fix Mac99 machine to properly route OpenPIC outputs to the PowerPC input 
> pins.
>  Fix PREP machine to properly route i8259 output to the PowerPC external
>    interrupt pin.
> 
> Versions before that patch went in work fine.  Versions since then hang 
> halfway through IDE controller initialization:
> 
>   Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
>   ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
>   hda: QEMU HARDDISK, ATA DISK drive
>   hda: IRQ probe failed (0x0)
>   hdb: IRQ probe failed (0x0)
>   hdb: IRQ probe failed (0x0)
>   hdb: QEMU CD-ROM, ATAPI CD/DVD-ROM drive
>   hdb: IRQ probe failed (0x0)
>   <-- hangs here with the patch
>   ide0 at 0x1f0-0x1f7,0x3f6 on irq 13
>   hda: max request size: 512KiB
>   hda: 4194304 sectors (2147 MB) w/256KiB Cache, CHS=4161/255/63
>   hda: set_multmode: status=0x41 { DriveReady Error }
>   hda: set_multmode: error=0x04 { DriveStatusError }
>   ide: failed opcode was: 0xef
>   hda: cache flushes supported
>   hda: unknown partition table
>   mice: PS/2 mouse device common for all mice
> 

The small patch below fixes the IDE problem, but not the NE2000 ISA one.
Please apply.

Index: hw/i8259.c
===================================================================
RCS file: /sources/qemu/qemu/hw/i8259.c,v
retrieving revision 1.25
diff -u -d -p -r1.25 i8259.c
--- hw/i8259.c	17 Sep 2007 08:09:46 -0000	1.25
+++ hw/i8259.c	19 Oct 2007 15:17:22 -0000
@@ -164,7 +164,7 @@ void pic_update_irq(PicState2 *s)
     }
 
 /* all targets should do this rather than acking the IRQ in the cpu */
-#if defined(TARGET_MIPS)
+#if defined(TARGET_MIPS) || defined(TARGET_PPC)
     else {
         qemu_irq_lower(s->parent_irq);
     }

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Jocelyn Mayer]

On Fri, 2007-10-19 at 17:19 +0200, Aurelien Jarno wrote:
> On Thu, Oct 18, 2007 at 07:12:57PM -0500, Rob Landley wrote:
> > The easy way to reproduce this is go to "http://landley.net/hg/firmware", 
> > download tip, and "./build.sh powerpc".  When it finishes building 
> > everything, cd build and "./run-powerpc.sh".
> > 
> > What I did is build a new ppc_rom.bin (attached, source code is at 
> > http://landley.net/hg/firmware/raw-diff/92f89c9c9495/sources/toys/make-ppc_rom.tar.bz2 ) 
> > which was written by Milton Miller.  I use that firmware as the boot rom 
> > (point -L at the directory it's in) instead of Open Hackware, which still 
> > doesn't work for me.
> > 
> > Then I build a 2.6.23 kernel with this patch: 
> > http://landley.net/hg/firmware/raw-diff/fdb6ddd4c3b7/sources/patches/linux-ppcqemu.patch
> > which adds a "qemu" target.
> > 
> > I then boot with the following command line (modulo wordwrap damage):
> > 
> > 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=ttyS0' -L ../sources/toys
> > 
> > And I get a shell prompt inside qemu!  (After almost _two_years_ of trying, 
> > I'm kind of happy about this.)
> > 
> > The downside is that the result boots fine under qemu-0.9.0, but is broken 
> > with current cvs.  I tracked it down to the specific patch with "git bisect", 
> > and it's this one:
> > 
> > http://git.kernel.dk/?p=qemu.git;a=commit;h=36f447f730f61ac413c5b1c4a512781f5dea0c94
> > 
> > author  j_mayer <j_mayer>
> > 	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)
> > committer  j_mayer <j_mayer>
> > 	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)
> > 
> >  Implement embedded IRQ controller for PowerPC 6xx/740 & 750.
> >  Fix PowerPC external interrupt input handling and lowering.
> >  Fix OpenPIC output pins management.
> >  Fix multiples bugs in OpenPIC IRQ management.
> >  Fix OpenPIC CPU(s) reset function.
> >  Fix Mac99 machine to properly route OpenPIC outputs to the PowerPC input 
> > pins.
> >  Fix PREP machine to properly route i8259 output to the PowerPC external
> >    interrupt pin.
> > 
> > Versions before that patch went in work fine.  Versions since then hang 
> > halfway through IDE controller initialization:
> > 
> >   Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> >   ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> >   hda: QEMU HARDDISK, ATA DISK drive
> >   hda: IRQ probe failed (0x0)
> >   hdb: IRQ probe failed (0x0)
> >   hdb: IRQ probe failed (0x0)
> >   hdb: QEMU CD-ROM, ATAPI CD/DVD-ROM drive
> >   hdb: IRQ probe failed (0x0)
> >   <-- hangs here with the patch
> >   ide0 at 0x1f0-0x1f7,0x3f6 on irq 13
> >   hda: max request size: 512KiB
> >   hda: 4194304 sectors (2147 MB) w/256KiB Cache, CHS=4161/255/63
> >   hda: set_multmode: status=0x41 { DriveReady Error }
> >   hda: set_multmode: error=0x04 { DriveStatusError }
> >   ide: failed opcode was: 0xef
> >   hda: cache flushes supported
> >   hda: unknown partition table
> >   mice: PS/2 mouse device common for all mice
> > 
> 
> The small patch below fixes the IDE problem, but not the NE2000 ISA one.
> Please apply.

Interesting, thanks. I'll test this and apply or check for more fixes if
needed... I'll also try to check what's happening with the NE2000. Could
it be the ne2000_irq table in ppc_prep.c would not be correct ? It may
also be usefull to be able to use PCI network devices, if the target
runs properly, isn't it ?
If the proposed ROM image is best suitable to make PreP target run (and
as I don't spend a lot of time hacking OHW those days), it may also be
interesting to add a ppc_prep_rom.bin to the repository... In fact, it
was maybe not a good idea to try to use the same BIOS image on all
PowerPC targets...

> Index: hw/i8259.c
> ===================================================================
> RCS file: /sources/qemu/qemu/hw/i8259.c,v
> retrieving revision 1.25
> diff -u -d -p -r1.25 i8259.c
> --- hw/i8259.c	17 Sep 2007 08:09:46 -0000	1.25
> +++ hw/i8259.c	19 Oct 2007 15:17:22 -0000
> @@ -164,7 +164,7 @@ void pic_update_irq(PicState2 *s)
>      }
>  
>  /* all targets should do this rather than acking the IRQ in the cpu */
> -#if defined(TARGET_MIPS)
> +#if defined(TARGET_MIPS) || defined(TARGET_PPC)
>      else {
>          qemu_irq_lower(s->parent_irq);
>      }
> 

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Milton Miller]

On Oct 18, 2007, at 6:46 PM, J. Mayer wrote:
> On Thu, 2007-10-18 at 19:12 -0500, Rob Landley wrote:
>> The easy way to reproduce this is go to  
>> "http://landley.net/hg/firmware",
>> download tip, and "./build.sh powerpc".  When it finishes building
>> everything, cd build and "./run-powerpc.sh".
>>
> [...]
>
>> The downside is that the result boots fine under qemu-0.9.0, but is  
>> broken
>> with current cvs.  I tracked it down to the specific patch with "git  
>> bisect",
>> and it's this one:
>>
>> http://git.kernel.dk/?p=qemu.git;a=commit; 
>> h=36f447f730f61ac413c5b1c4a512781f5dea0c94
>>
>> author  j_mayer <j_mayer>
>> 	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)
>> committer  j_mayer <j_mayer>
>> 	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)
>
> What is strange is that it was reported as unable to boot long before
> this patch. It was broken when the Qemu PCI architecture has been
> redesigned and have never been reported booting since then (2 years  
> ago,
> if I remember well).

My job includes getting the linux kernel to run on various PowerPC  
hardware.  While searching for a small file system, I came across Rob's  
work and it was close to what I needed so I started working with it.   
Rob was having trouble getting the kernel to build and run on qemu with  
Open Hackware.

I took the approach of treating qemu as another embedded board and  
describing the hardware to the kernel.  I quickly got ide and serial  
working, and later got pci config working.  I haven't gotten pci memory  
working yet; I don't know if that is the emulation or the description.   
Since hackware can initialize the video, its probably the later.   
Here's some history.

In the linux kernel, the ppc arch is being replaced by the powerpc  
arch, which has already replaced the ppc64 arch and supports all  
powerpc processors.  The ppc arch is slated to be removed by June 2008,  
having been in process over two years.  Part of the merge process,  
however, is to standardize the entry requirements of the kernel.  The  
ppc port had been accepting data from random firmwares in random  
structures, and it promoted drivers that only worked on one platform.   
The powerpc kernel requires that this information be translated to a  
device tree, similar to that provided by Open Firmware.  By forcing the  
device tree, the drivers are loaded based on the platform supplied data  
instead of knowing the platform and searching for data.  Instead of  
requiring a client interface however, a powerpc kenrel will accept the  
information as a data structure known as the flat device tree.  In  
fact, when booted with a client interface, after interacting with  
firmware (including storing some properties in the tree ond opening  
video cards to initialize them), the kernel builds this data structure  
and restarts itself with it.  The kernel tree also provides a library  
of boot code, called the wrapper or zImage, for translating random  
firmware structures into a flattened device tree.  It also provides  
support for loading compressed kernels and combining an initrd with the  
kernel into a single image.

Rob was complaining he needed arch ppc to boot prep qemu but  
kernel_headers only worked on powerpc.  Rob choose prep because the  
header on the prep kernel was the only one that satisfied Open Hackware  
when supplied to -kernel.  About this time Dave Gibson started code to  
run prep hardware under powerpc.  It had several assumptions on what  
the machine looked like.  As I remember it, I tried Dave's port on the  
qemu 0.6.2 found on the Knoppix 4.0.2 dvd and caused qemu to segv.  I  
was not prepared to debug qemu; I assumed the assumptions were not met.

Taking a look at Open Hackware 0.4, it appears that it treats the  
memory given to -kernel as a block device.  That makes no sense to me.   
I would expect it to treat the memory as the file loaded from the block  
device.  Seeing that no updates to Open Hackware had been made in  
years, and that it only pretended to have a open firmware client  
interface and contained a mostly useless rtas (eg no pci config  
methods), I decided to try bypassing it and just give the kernel what  
it was looking for: a description of the hardware.

I choose to continue with prep because I knew the expected hardware  
much better than pmac (the heathrow emulation).  I started by mining  
Open Hackware 0.4 for information describing the hardware and its  
startup.  I found the entry point was 0xfffffffc and after a bit of  
experimentation I found qemu required the rom to be 512k and was read  
only.  I found that since there were no caches I could do IO to serial  
in real mode, which meant I didn't have to decide what to map via bats.  
  Since the zImage code runs where it starts execution, I wrote some  
code to copy the rom to ram and start it there.  With only 512k the  
zImage couldn't contain the kernel, even compressed, to support  
something like kboot or petiboot (where the first kenrel is used with  
kexec to become a bootloader), but I already had patches to use the  
kernel loaded elsewhere.  I found the code in hackware to read nvram to  
find the memory size, loaded kernel, initrd, and command line and  
taught zImage to fetch the info from nvram and modify a device tree.  I  
used David's device tree and port as a baseline to modify.  When I  
didn't find code to describe an openpic or mpic, I decided to try using  
the 8259 as the interrupt controller.  After cutting down Dave's prep  
kernel code and changing its expectations to match the device tree, I  
quickly had interrupts, serial, and ide working.

http://patchwork.ozlabs.org/linuxppc/patch?person=79&id=13140

After a peek at qemu I got the right address for pci config and had  
that working. Rob complained my instructions were too hard to follow  
and had too much unmerged code, so I split and rebased them.  The  
kernel code patched cleanly against 2.6.23 but but the zImage code  
required patches queued for 2.6.24 and about 4 more not yet accepted.   
After looking at what the wrapper was doing, I decided it was was  
easier to just write the assembly code to copy the device tree to ram,  
copy the nvram to ram, and patch the 5 or so items based on the nvram.   
That resulted in the code for the rom that Rob posted.

> In march 2007, I did test and reported that PreP
> and heathrow target were unable to boot, not receiving any IRQ from PCI
> (in fact, adding traces proves there are even no IRQ generated in the
> PCI code). Someone reported the faulty patch during this summer (but
> I've not been unable to find the mail in the mailing list archive
> tonight).

As I stated, I haven't gotten pci memory working yet; my attempt at  
using -usb on under Q 0.9.0 (the os X compiled qemu) had the linux code  
failing to reset the chip.  However, since Open Hackware can initialize  
the graphics card, its probably an error in my description of the  
memory map in the device tree.  The linux driver for the video card  
also dies, I don't know if its because of no bios, the memory map, or  
other issues.

> I have to admit I never put the focus on trying to solve this issue,  
> has
> I usually use Mac99 or PowerPC 405 targets for tests and that PreP
> machines are long obsolete and the heathrow target does not reflect any
> real machine. But this is to be solved, for sure.

 From the patch description you inserted a openpic between the 8259 and  
the cpu.  If this is true, at a minimum it will require this to be  
described to be in the device tree for linux (or in the prep residual  
data in general for hackware).  My qemu linux code wasn't expecting an  
openpic so it would need to adjust; or perhaps David's kernel code  
would now work.

 From a linux on powerpc standpoint, I don't care if we found the  
hardware with the same platform code as a real machine or if a custom  
platform and boot code to create the device tree was used.  If the  
device tree matches the standard firmware, I can use the standard linux  
platform code.  If not, I can still use all the drivers.  If qemu  
misses a piece of hardware in the platform, I can choose to modify an  
existing one or create a new one.  However, I see being able to test  
the zImage with -kernel as a requirement (be it the standard platform  
zImage or a custom one customized to qemu), and if hackware is getting  
in the way it needs to be fixed or replaced.

I can help you debug from the linux side, but I have no interest in  
debugging qemu.  To complete the port to the 0.9 prep, I need to learn  
a bit more about the actual emulated machine and how its pci is hooked  
up.

The rom I provided was aimed at running linux on the hardware I knew,  
bypassing broken firmware.  I took advantage of the hardware being  
setup (eg ram working) and do the minimum to start the loaded linux.   
This means I support the image being an elf with a single load segment  
and the entry point can run where the file is loaded.  The code could  
be extended to check the platform and jump to another copy of itself  
when it doesn't match, meaning that through chaining it would search  
until it found the device tree for the platform being emulated and then  
start the kernel with that tree.  This would allow a rom to be built  
supporting several platforms, but it requires the kernel to be loaded  
via -kernel (as I don't have any floppy or hard drive code in it).   
This approach doesn't support booting from file systems, but an  
approach using kexec with kernel in rom could.

milton

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Milton Miller]

On Oct 19, 2007, at 12:39 PM, Jocelyn Mayer wrote:
> On Fri, 2007-10-19 at 17:19 +0200, Aurelien Jarno wrote:
>> The small patch below fixes the IDE problem, but not the NE2000 ISA 
>> one.
>> Please apply.
>
> Interesting, thanks. I'll test this and apply or check for more fixes 
> if
> needed... I'll also try to check what's happening with the NE2000. 
> Could
> it be the ne2000_irq table in ppc_prep.c would not be correct ?

I started to look at ne2k also but don't remember the details.  
Evenutally the driver shoudl learn the interrupt thorugh the 
information in the device tree but I'm sure the isa driver does not 
presently.

> It may
> also be usefull to be able to use PCI network devices, if the target
> runs properly, isn't it ?

It would mean the interrupt code could eb discovered easily, once we 
get pci to fully work.

> If the proposed ROM image is best suitable to make PreP target run (and
> as I don't spend a lot of time hacking OHW those days), it may also be
> interesting to add a ppc_prep_rom.bin to the repository... In fact, it
> was maybe not a good idea to try to use the same BIOS image on all
> PowerPC targets...

The code has drawbacks, as I mentioned.  Its very linux specific and 
the only error it finds is no load segement in the presumed elf header. 
  It wouldn't be that hard to add some error checking and even print 
error to the serial.  The code itself is not platform specific but the 
device tree attached to it is.  As I said, we could link multiple 
copies together (one for each platform) and search until we got the 
right one; or just search trees based on the platform with the fixups 
in code specific to that tree.   In that regard, this would be an 
option to use when using -kernel instead of being tied to the prep 
platform.

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Aurelien Jarno]

On Fri, Oct 19, 2007 at 07:39:47PM +0200, Jocelyn Mayer wrote:
> > The small patch below fixes the IDE problem, but not the NE2000 ISA one.
> > Please apply.
> 
> Interesting, thanks. I'll test this and apply or check for more fixes if
> needed... I'll also try to check what's happening with the NE2000. Could
> it be the ne2000_irq table in ppc_prep.c would not be correct ? It may
> also be usefull to be able to use PCI network devices, if the target
> runs properly, isn't it ?

Well the problem is actually in the kernel, MIPS got the exact same
problem a few times ago. The same fix apply for PowerPC:

Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>

diff --git a/arch/powerpc/sysdev/i8259.c b/arch/powerpc/sysdev/i8259.c
index ad87adc..9134b2e 100644
--- a/arch/powerpc/sysdev/i8259.c
+++ b/arch/powerpc/sysdev/i8259.c
@@ -138,6 +138,7 @@ static void i8259_unmask_irq(unsigned int irq_nr)
 static struct irq_chip i8259_pic = {
 	.typename	= " i8259    ",
 	.mask		= i8259_mask_irq,
+	.disable	= i8259_mask_irq,
 	.unmask		= i8259_unmask_irq,
 	.mask_ack	= i8259_mask_and_ack_irq,
 };


I will submit it later this week-end.


> If the proposed ROM image is best suitable to make PreP target run (and
> as I don't spend a lot of time hacking OHW those days), it may also be
> interesting to add a ppc_prep_rom.bin to the repository... In fact, it
> was maybe not a good idea to try to use the same BIOS image on all
> PowerPC targets...

I would say that the main avantage of this proposed ROM is that it is
plainly functional with a recent kernel. I think that it is something
really important, as it will bring more users who will improve qemu ppc
by reporting bugs or even submitting patches. 

And if a better ROM image (e.g. OpenBIOS) that matches real hardware
comes later it would be possible to change that again.


I have used QEMU CVS with a Debian Sid image. It basically works, I am
even able to login via SSH, but I have noticed two problems:

- Some process hang, stay into "D" state and become unkillable. It seems
  it can happen to all processes, but it is always reproducible with
  uptime or top. I still don't know if it is a problem of the kernel or
  if it comes from the emulation.
- The target CPU never gets into idle loop, so the host CPU is always
  used at 100%

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Aurelien Jarno]

Aurelien Jarno a écrit :
> - The target CPU never gets into idle loop, so the host CPU is always
>   used at 100%
> 

This is actually not a problem. The default CPU (604) does not support
DOZE or NAP. Switching to a 603 CPU, the target CPU correctly goes
into idle loop.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Rob Landley]

On Friday 19 October 2007 3:33:52 pm Aurelien Jarno wrote:
> Aurelien Jarno a écrit :
> > - The target CPU never gets into idle loop, so the host CPU is always
> >   used at 100%
>
> This is actually not a problem. The default CPU (604) does not support
> DOZE or NAP. Switching to a 603 CPU, the target CPU correctly goes
> into idle loop.

This would be adding "-cpu 603" to the command line?

Is there a web page listing all the powerpc processors somewhere?  I'm still 
at the "everything is 7xx except for 4xx and 8xx" stage...

I found this:
http://www.power.org/resources/devcorner/roadmap

But it groups by manufacturer rather than capabilities or software 
compatability...

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Rob Landley]

On Friday 19 October 2007 10:19:16 am Aurelien Jarno wrote:
> The small patch below fixes the IDE problem, but not the NE2000 ISA one.
> Please apply.
>
> Index: hw/i8259.c
> ===================================================================
> RCS file: /sources/qemu/qemu/hw/i8259.c,v
> retrieving revision 1.25
> diff -u -d -p -r1.25 i8259.c
> --- hw/i8259.c	17 Sep 2007 08:09:46 -0000	1.25
> +++ hw/i8259.c	19 Oct 2007 15:17:22 -0000
> @@ -164,7 +164,7 @@ void pic_update_irq(PicState2 *s)
>      }
>
>  /* all targets should do this rather than acking the IRQ in the cpu */
> -#if defined(TARGET_MIPS)
> +#if defined(TARGET_MIPS) || defined(TARGET_PPC)
>      else {
>          qemu_irq_lower(s->parent_irq);
>      }

Ack.  This fixed it for me.

Off to try the network one...

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[J. Mayer]

On Sat, 2007-10-20 at 01:08 -0500, Rob Landley wrote:
> On Friday 19 October 2007 3:33:52 pm Aurelien Jarno wrote:
> > Aurelien Jarno a écrit :
> > > - The target CPU never gets into idle loop, so the host CPU is always
> > >   used at 100%
> >
> > This is actually not a problem. The default CPU (604) does not support
> > DOZE or NAP. Switching to a 603 CPU, the target CPU correctly goes
> > into idle loop.

Sleep mode is currently implemented only for a few CPUs. I should add
all the currently emulated cores. For this, I would have to emulate the
HID registers, in most case, which is still not done.

> This would be adding "-cpu 603" to the command line?

Yes

> 
> Is there a web page listing all the powerpc processors somewhere?  I'm still 
> at the "everything is 7xx except for 4xx and 8xx" stage...
> 
> I found this:
> http://www.power.org/resources/devcorner/roadmap
> 
> But it groups by manufacturer rather than capabilities or software 
> compatability...

I could do this, as Qemu has definitions for most PowerPC cores (even if
most are still not available).
For now, you can take a look in target-ppc/translate_init.c. Most
PowerPC are referenced here:
- there's a big table with all the PVR I know (but there's still a lot
missing)
- the ppc_defs table contains most PowerPC definitions, with their
features defined.
I will think of doing a reference table on my web pages, to have a more
readable PowerPC reference document. Of course, any information about
missing PVRs or PowerPC implementation in welcome !

You can also take a look at the file target-ppc/STATUS file to figure
out all cores emulation working in Qemu.
And you can get the list of all CPUs emulated by Qemu with the '-cpu ?'
switch.

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

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[J. Mayer]

On Fri, 2007-10-19 at 17:19 +0200, Aurelien Jarno wrote: 
> On Thu, Oct 18, 2007 at 07:12:57PM -0500, Rob Landley wrote:
> > The easy way to reproduce this is go to "http://landley.net/hg/firmware", 
> > download tip, and "./build.sh powerpc".  When it finishes building 
> > everything, cd build and "./run-powerpc.sh".
> > 
> > What I did is build a new ppc_rom.bin (attached, source code is at 
> > http://landley.net/hg/firmware/raw-diff/92f89c9c9495/sources/toys/make-ppc_rom.tar.bz2 ) 
> > which was written by Milton Miller.  I use that firmware as the boot rom 
> > (point -L at the directory it's in) instead of Open Hackware, which still 
> > doesn't work for me.
> > 
> > Then I build a 2.6.23 kernel with this patch: 
> > http://landley.net/hg/firmware/raw-diff/fdb6ddd4c3b7/sources/patches/linux-ppcqemu.patch
> > which adds a "qemu" target.
> > 
> > I then boot with the following command line (modulo wordwrap damage):
> > 
> > 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=ttyS0' -L ../sources/toys
> > 
> > And I get a shell prompt inside qemu!  (After almost _two_years_ of trying, 
> > I'm kind of happy about this.)
> > 
> > The downside is that the result boots fine under qemu-0.9.0, but is broken 
> > with current cvs.  I tracked it down to the specific patch with "git bisect", 
> > and it's this one:
> > 
> > http://git.kernel.dk/?p=qemu.git;a=commit;h=36f447f730f61ac413c5b1c4a512781f5dea0c94
> > 
> > author  j_mayer <j_mayer>
> > 	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)
> > committer  j_mayer <j_mayer>
> > 	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)
> > 
> >  Implement embedded IRQ controller for PowerPC 6xx/740 & 750.
> >  Fix PowerPC external interrupt input handling and lowering.
> >  Fix OpenPIC output pins management.
> >  Fix multiples bugs in OpenPIC IRQ management.
> >  Fix OpenPIC CPU(s) reset function.
> >  Fix Mac99 machine to properly route OpenPIC outputs to the PowerPC input 
> > pins.
> >  Fix PREP machine to properly route i8259 output to the PowerPC external
> >    interrupt pin.
> > 
> > Versions before that patch went in work fine.  Versions since then hang 
> > halfway through IDE controller initialization:
> > 
> >   Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> >   ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> >   hda: QEMU HARDDISK, ATA DISK drive
> >   hda: IRQ probe failed (0x0)
> >   hdb: IRQ probe failed (0x0)
> >   hdb: IRQ probe failed (0x0)
> >   hdb: QEMU CD-ROM, ATAPI CD/DVD-ROM drive
> >   hdb: IRQ probe failed (0x0)
> >   <-- hangs here with the patch
> >   ide0 at 0x1f0-0x1f7,0x3f6 on irq 13
> >   hda: max request size: 512KiB
> >   hda: 4194304 sectors (2147 MB) w/256KiB Cache, CHS=4161/255/63
> >   hda: set_multmode: status=0x41 { DriveReady Error }
> >   hda: set_multmode: error=0x04 { DriveStatusError }
> >   ide: failed opcode was: 0xef
> >   hda: cache flushes supported
> >   hda: unknown partition table
> >   mice: PS/2 mouse device common for all mice
> > 
> 
> The small patch below fixes the IDE problem, but not the NE2000 ISA one.
> Please apply.

This patch makes the PreP target run for me, using OpenHackWare, and I
got NE2000 working too.
2.4 vanilla kernels runs perfectly, as well as old 2.6 ones. But there
still seems to be problems with recent 2.6 kernels not using the frame
buffer properly: I can see the kernel entering user mode, from the
messages on the serial console, but I got no more messages from here.
But I guess it's booting as I can see the CPU entering sleep mode a few
seconds after reaching this point, the same way it does when I can see
it waiting for the user login.
So I will apply the patch. I also added PCI network devices but still
haven't validated them.

> 
> Index: hw/i8259.c
> ===================================================================
> RCS file: /sources/qemu/qemu/hw/i8259.c,v
> retrieving revision 1.25
> diff -u -d -p -r1.25 i8259.c
> --- hw/i8259.c	17 Sep 2007 08:09:46 -0000	1.25
> +++ hw/i8259.c	19 Oct 2007 15:17:22 -0000
> @@ -164,7 +164,7 @@ void pic_update_irq(PicState2 *s)
>      }
>  
>  /* all targets should do this rather than acking the IRQ in the cpu */
> -#if defined(TARGET_MIPS)
> +#if defined(TARGET_MIPS) || defined(TARGET_PPC)
>      else {
>          qemu_irq_lower(s->parent_irq);
>      }
> 
-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Aurelien Jarno]

J. Mayer a écrit :
> On Fri, 2007-10-19 at 17:19 +0200, Aurelien Jarno wrote: 
>> On Thu, Oct 18, 2007 at 07:12:57PM -0500, Rob Landley wrote:
>>> The easy way to reproduce this is go to "http://landley.net/hg/firmware", 
>>> download tip, and "./build.sh powerpc".  When it finishes building 
>>> everything, cd build and "./run-powerpc.sh".
>>>
>>> What I did is build a new ppc_rom.bin (attached, source code is at 
>>> http://landley.net/hg/firmware/raw-diff/92f89c9c9495/sources/toys/make-ppc_rom.tar.bz2 ) 
>>> which was written by Milton Miller.  I use that firmware as the boot rom 
>>> (point -L at the directory it's in) instead of Open Hackware, which still 
>>> doesn't work for me.
>>>
>>> Then I build a 2.6.23 kernel with this patch: 
>>> http://landley.net/hg/firmware/raw-diff/fdb6ddd4c3b7/sources/patches/linux-ppcqemu.patch
>>> which adds a "qemu" target.
>>>
>>> I then boot with the following command line (modulo wordwrap damage):
>>>
>>> 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=ttyS0' -L ../sources/toys
>>>
>>> And I get a shell prompt inside qemu!  (After almost _two_years_ of trying, 
>>> I'm kind of happy about this.)
>>>
>>> The downside is that the result boots fine under qemu-0.9.0, but is broken 
>>> with current cvs.  I tracked it down to the specific patch with "git bisect", 
>>> and it's this one:
>>>
>>> http://git.kernel.dk/?p=qemu.git;a=commit;h=36f447f730f61ac413c5b1c4a512781f5dea0c94
>>>
>>> author  j_mayer <j_mayer>
>>> 	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)
>>> committer  j_mayer <j_mayer>
>>> 	Mon, 9 Apr 2007 22:45:36 +0000 (22:45 +0000)
>>>
>>>  Implement embedded IRQ controller for PowerPC 6xx/740 & 750.
>>>  Fix PowerPC external interrupt input handling and lowering.
>>>  Fix OpenPIC output pins management.
>>>  Fix multiples bugs in OpenPIC IRQ management.
>>>  Fix OpenPIC CPU(s) reset function.
>>>  Fix Mac99 machine to properly route OpenPIC outputs to the PowerPC input 
>>> pins.
>>>  Fix PREP machine to properly route i8259 output to the PowerPC external
>>>    interrupt pin.
>>>
>>> Versions before that patch went in work fine.  Versions since then hang 
>>> halfway through IDE controller initialization:
>>>
>>>   Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
>>>   ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
>>>   hda: QEMU HARDDISK, ATA DISK drive
>>>   hda: IRQ probe failed (0x0)
>>>   hdb: IRQ probe failed (0x0)
>>>   hdb: IRQ probe failed (0x0)
>>>   hdb: QEMU CD-ROM, ATAPI CD/DVD-ROM drive
>>>   hdb: IRQ probe failed (0x0)
>>>   <-- hangs here with the patch
>>>   ide0 at 0x1f0-0x1f7,0x3f6 on irq 13
>>>   hda: max request size: 512KiB
>>>   hda: 4194304 sectors (2147 MB) w/256KiB Cache, CHS=4161/255/63
>>>   hda: set_multmode: status=0x41 { DriveReady Error }
>>>   hda: set_multmode: error=0x04 { DriveStatusError }
>>>   ide: failed opcode was: 0xef
>>>   hda: cache flushes supported
>>>   hda: unknown partition table
>>>   mice: PS/2 mouse device common for all mice
>>>
>> The small patch below fixes the IDE problem, but not the NE2000 ISA one.
>> Please apply.
> 
> This patch makes the PreP target run for me, using OpenHackWare, and I
> got NE2000 working too.
> 2.4 vanilla kernels runs perfectly, as well as old 2.6 ones. But there
> still seems to be problems with recent 2.6 kernels not using the frame
> buffer properly: I can see the kernel entering user mode, from the
> messages on the serial console, but I got no more messages from here.
> But I guess it's booting as I can see the CPU entering sleep mode a few
> seconds after reaching this point, the same way it does when I can see
> it waiting for the user login.
> So I will apply the patch. I also added PCI network devices but still
> haven't validated them.
> 

Would it be possible to share your configuration file for 2.6 kernels
and OpenHackWare? I would like to give a try and see if the problem of
processes hanging in "D" state is also present.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Aurelien Jarno]

Aurelien Jarno a écrit :

> I have used QEMU CVS with a Debian Sid image. It basically works, I am
> even able to login via SSH, but I have noticed two problems:
> 
> - Some process hang, stay into "D" state and become unkillable. It seems
>   it can happen to all processes, but it is always reproducible with
>   uptime or top. I still don't know if it is a problem of the kernel or
>   if it comes from the emulation.

This problem arise when using floating point instructions. It can be
easily triggered by running the following testcase:

#include <stdio.h>

int main()
{
        double a = 1.34;
        printf("%.2f", a);
        return 0;
}

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Aurelien Jarno]

Aurelien Jarno a écrit :
> Aurelien Jarno a écrit :
> 
>> I have used QEMU CVS with a Debian Sid image. It basically works, I am
>> even able to login via SSH, but I have noticed two problems:
>>
>> - Some process hang, stay into "D" state and become unkillable. It seems
>>   it can happen to all processes, but it is always reproducible with
>>   uptime or top. I still don't know if it is a problem of the kernel or
>>   if it comes from the emulation.
> 
> This problem arise when using floating point instructions. It can be
> easily triggered by running the following testcase:
> 
> #include <stdio.h>
> 
> int main()
> {
>         double a = 1.34;
>         printf("%.2f", a);
>         return 0;
> }
> 

This is actually not enough to trigger the bug. The testcase works if
the bug has already been trigger in another process before, for example
uptime.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Aurelien Jarno]

Aurelien Jarno a écrit :
> Aurelien Jarno a écrit :
>> Aurelien Jarno a écrit :
>>
>>> I have used QEMU CVS with a Debian Sid image. It basically works, I am
>>> even able to login via SSH, but I have noticed two problems:
>>>
>>> - Some process hang, stay into "D" state and become unkillable. It seems
>>>   it can happen to all processes, but it is always reproducible with
>>>   uptime or top. I still don't know if it is a problem of the kernel or
>>>   if it comes from the emulation.
>> This problem arise when using floating point instructions. It can be
>> easily triggered by running the following testcase:
>>
>> #include <stdio.h>
>>
>> int main()
>> {
>>         double a = 1.34;
>>         printf("%.2f", a);
>>         return 0;
>> }
>>
> 
> This is actually not enough to trigger the bug. The testcase works if
> the bug has already been trigger in another process before, for example
> uptime.
> 

I finally found a testcase that trigger the bug in any case:

#include <stdio.h>

int main()
{
	printf("%d %f\n", 7, 0.40);
	return 0;
}

The bug could also be trigger with sprintf(), so this is not directly
related to I/O. It happens when printing an integer followed by a float,
even when the two are printed in two different calls to printf().

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[J. Mayer]

On Sat, 2007-10-20 at 23:49 +0200, Aurelien Jarno wrote:
> Aurelien Jarno a écrit :
> > Aurelien Jarno a écrit :
> >> Aurelien Jarno a écrit :
> >>
> >>> I have used QEMU CVS with a Debian Sid image. It basically works, I am
> >>> even able to login via SSH, but I have noticed two problems:
> >>>
> >>> - Some process hang, stay into "D" state and become unkillable. It seems
> >>>   it can happen to all processes, but it is always reproducible with
> >>>   uptime or top. I still don't know if it is a problem of the kernel or
> >>>   if it comes from the emulation.
> >> This problem arise when using floating point instructions. It can be
> >> easily triggered by running the following testcase:
> >>
> >> #include <stdio.h>
> >>
> >> int main()
> >> {
> >>         double a = 1.34;
> >>         printf("%.2f", a);
> >>         return 0;
> >> }
> >>
> > 
> > This is actually not enough to trigger the bug. The testcase works if
> > the bug has already been trigger in another process before, for example
> > uptime.
> > 
> 
> I finally found a testcase that trigger the bug in any case:
> 
> #include <stdio.h>
> 
> int main()
> {
> 	printf("%d %f\n", 7, 0.40);
> 	return 0;
> }
> 
> The bug could also be trigger with sprintf(), so this is not directly
> related to I/O. It happens when printing an integer followed by a float,
> even when the two are printed in two different calls to printf().

OK, thanks. I'll do test with this program. It seems that floats are OK
when running 2.4 kernels, it maybe a difference in recent glibc. I'll
try to investigate more about it.

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

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Rob Landley]

On Saturday 20 October 2007 3:50:52 am J. Mayer wrote:
> Sleep mode is currently implemented only for a few CPUs. I should add
> all the currently emulated cores. For this, I would have to emulate the
> HID registers, in most case, which is still not done.

Getting it to exit in response to a shut down attempt would be really nice 
too.  (It may already do so, but I have no idea how to trigger it and neither 
did Milton last I checked.)

> And you can get the list of all CPUs emulated by Qemu with the '-cpu ?'
> switch.

I did that, but it -cpu ? gives output like:

  PowerPC 7448             PVR 80040201
  PowerPC 7448v1.0         PVR 80040100
  PowerPC 7448v1.1         PVR 80040101
  PowerPC 7448v2.0         PVR 80040200
  PowerPC 7448v2.1         PVR 80040201

I prefer the result of "-M ?" which makes it slightly clearer which field you 
need to feed qemu as an argument.  (For the record, -cpu seems to want filed 
$2 of the -cpu ? output.)  Also, that doesn't tell me what the differences 
between any of them are.

From earlier research, I know that if you configure a toolchain for "7xx" all 
major PowerPC variants except two will run that, it's more or less "-mcpu 
386" of the powerpc world.

The two that won't run it (Motorola's 8xx and IBM's 4xx) are both embedded 
subsets of powerpc that have had instructions removed, and thus need their 
own toolchains.  (Of course those two removed DIFFERENT instructions, 
sigh...)

My random and confused notes about various hardware platforms are 
at "http://landley.net/ols/ols2007/platforms.txt", which has a largeish 
section on ppc that probably makes sense to nobody but me. :)

I don't actually have any _background_ in embedded hardware.  Busybox, uClibc, 
and qemu all dragged me into it, and I've been trying to pick things up as I 
go along...

Rob

P.S.  I removed you from the CC: list because your ISP is still bouncing my 
emails as spam, and I don't know if the list sends you a copy if you're cc'd.
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[J. Mayer]

On Sun, 2007-10-21 at 04:55 -0500, Rob Landley wrote:
> On Saturday 20 October 2007 3:50:52 am J. Mayer wrote:
> > Sleep mode is currently implemented only for a few CPUs. I should add
> > all the currently emulated cores. For this, I would have to emulate the
> > HID registers, in most case, which is still not done.
> 
> Getting it to exit in response to a shut down attempt would be really nice 
> too.  (It may already do so, but I have no idea how to trigger it and neither 
> did Milton last I checked.)

Well, if it does not exit, that means that there should be something
emulated in the chipset to do so and that the Linux kernel just enter an
infinite loop instead of shuting down / reseting the board.

> > And you can get the list of all CPUs emulated by Qemu with the '-cpu ?'
> > switch.
> 
> I did that, but it -cpu ? gives output like:
> 
>   PowerPC 7448             PVR 80040201
>   PowerPC 7448v1.0         PVR 80040100
>   PowerPC 7448v1.1         PVR 80040101
>   PowerPC 7448v2.0         PVR 80040200
>   PowerPC 7448v2.1         PVR 80040201
> 
> I prefer the result of "-M ?" which makes it slightly clearer which field you 
> need to feed qemu as an argument.  (For the record, -cpu seems to want filed 
> $2 of the -cpu ? output.)  Also, that doesn't tell me what the differences 
> between any of them are.

The idea of showing the name of the model and the PVR (processor version
register) is that it can be useful to give Qemu a PVR instead of a name,
even if this possibility is not properly implemented in the commited
version. It's sometime more relevant to provide a PVR than a core name,
imho...
I will put a dump of the CPU features for all cores emulated by Qemu on
line soon.

> >From earlier research, I know that if you configure a toolchain for "7xx" all 
> major PowerPC variants except two will run that, it's more or less "-mcpu 
> 386" of the powerpc world.
>
> The two that won't run it (Motorola's 8xx and IBM's 4xx) are both embedded 
> subsets of powerpc that have had instructions removed, and thus need their 
> own toolchains.  (Of course those two removed DIFFERENT instructions, 
> sigh...)

Those two ones do not have any hardware floating point implemented and
lack the support of some optional instructions. If you want to compile
executables that would run on any PowerPC core, you have to use the
switch '-many' or '-mcom'. This is supposed to generate code that would
even run on the original RS/6000 architecture. The '-mppc' generates
code for 603/604 which should be a better PowerPC insns subset than the
750 one, for portability. If you want all programs to also run on
4xx/8xx/82xx, you may also add '-msoft-float' so no hardware floating
point instructions will be used.
But you may not care about those cores as they are used only in
microcontrollers so I need to implement at least a subset of their
internal devices to make them usable in the full-system emulation.

> My random and confused notes about various hardware platforms are 
> at "http://landley.net/ols/ols2007/platforms.txt", which has a largeish 
> section on ppc that probably makes sense to nobody but me. :)
> 
> I don't actually have any _background_ in embedded hardware.  Busybox, uClibc, 
> and qemu all dragged me into it, and I've been trying to pick things up as I 
> go along...
> 
> Rob
> 
> P.S.  I removed you from the CC: list because your ISP is still bouncing my 
> emails as spam, and I don't know if the list sends you a copy if you're cc'd.

Strange, my ISP does not tag your mails as spams, when I receive them.
But it's not a problem for me not to be CCed...

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

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[J. Mayer]

On Sun, 2007-10-21 at 12:24 +0200, J. Mayer wrote:
> On Sun, 2007-10-21 at 04:55 -0500, Rob Landley wrote:
> > On Saturday 20 October 2007 3:50:52 am J. Mayer wrote:
[...]
> > > And you can get the list of all CPUs emulated by Qemu with the '-cpu ?'
> > > switch.
> > 
> > I did that, but it -cpu ? gives output like:
> > 
> >   PowerPC 7448             PVR 80040201
> >   PowerPC 7448v1.0         PVR 80040100
> >   PowerPC 7448v1.1         PVR 80040101
> >   PowerPC 7448v2.0         PVR 80040200
> >   PowerPC 7448v2.1         PVR 80040201
> > 
> > I prefer the result of "-M ?" which makes it slightly clearer which field you 
> > need to feed qemu as an argument.  (For the record, -cpu seems to want filed 
> > $2 of the -cpu ? output.)  Also, that doesn't tell me what the differences 
> > between any of them are.
> 
> The idea of showing the name of the model and the PVR (processor version
> register) is that it can be useful to give Qemu a PVR instead of a name,
> even if this possibility is not properly implemented in the commited
> version. It's sometime more relevant to provide a PVR than a core name,
> imho...

Something I forgot to say is that this output is supposed to give a help
to the end-user. It seems to me that showing the CPU family (ie PowerPC)
can be useful when POWER and RS64 families will be emulated too, in
order to help the user choose which CPU to emulate.

> I will put a dump of the CPU features for all cores emulated by Qemu on
> line soon.

Here you'll find a reference for all PowerPC CPUs / cores /
microcontrollers available with the Qemu -cpu switch. Hope I did not
forget anything.
<http://perso.magic.fr/l_indien/qemu-ppc/PowerPC_ref/PowerPC_ref.html>
For each CPU, you get:
- its name, as provided with the Qemu -cpu switch
- its PVR (processor version register)
- the bits defined in the MSR (machine state register)
- its MMU model and the TLB model when relevant
- its exception handling model
- its input bus model
- the specific features provided by the MSR
- its complete instructions set (only one insn is dumped when 2
instructions share the same opcode)
- the complete list of SPRs (special purpose registers) with access
rights in supervisor and user mode

[...]

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

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[Rob Landley]

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

On Sunday 21 October 2007 5:24:34 am J. Mayer wrote:
> > P.S.  I removed you from the CC: list because your ISP is still bouncing
> > my emails as spam, and I don't know if the list sends you a copy if
> > you're cc'd.
>
> Strange, my ISP does not tag your mails as spams, when I receive them.

If you receive them, they're not tagged as spam.  They _bounce_ as spam, 
before you ever see them.  (See attachment.)

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

[-- Attachment #2: temp.txt --]
[-- Type: text/plain, Size: 3223 bytes --]

Return-Path: <>
X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on 
	dell.linuxdev.us.dell.com
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,NO_RELAYS 
	autolearn=ham version=3.1.7-deb
X-Original-To: rob@landley.net
Delivered-To: landley@grelber.thyrsus.com
Received: by grelber.thyrsus.com (Postfix)
	id A220973947; Sun, 21 Oct 2007 09:29:32 -0400 (EDT)
Date: Sun, 21 Oct 2007 09:29:32 -0400 (EDT)
From: MAILER-DAEMON@grelber.thyrsus.com (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: rob@landley.net
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report;
  report-type=delivery-status;
  boundary="3554073945.1192973372/grelber.thyrsus.com"
Content-Transfer-Encoding: 8bit
Message-Id: <20071021132932.A220973947@grelber.thyrsus.com>

This is a MIME-encapsulated message.

--3554073945.1192973372/grelber.thyrsus.com
Content-Description: Notification
Content-Type: text/plain; charset=us-ascii

This is the mail system at host grelber.thyrsus.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<l_indien@magic.fr>: host mxs.magic.fr[62.210.158.52] said: 550 5.0.0 SPAM! (in
    reply to MAIL FROM command)

--3554073945.1192973372/grelber.thyrsus.com
Content-Description: Delivery report
Content-Type: message/delivery-status

Reporting-MTA: dns; grelber.thyrsus.com
X-Postfix-Queue-ID: 3554073945
X-Postfix-Sender: rfc822; rob@landley.net
Arrival-Date: Sun, 21 Oct 2007 09:29:31 -0400 (EDT)

Final-Recipient: rfc822; l_indien@magic.fr
Original-Recipient: rfc822;l_indien@magic.fr
Action: failed
Status: 5.0.0
Remote-MTA: dns; mxs.magic.fr
Diagnostic-Code: smtp; 550 5.0.0 SPAM!

--3554073945.1192973372/grelber.thyrsus.com
Content-Description: Undelivered Message
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit

Received: from landley.net (localhost [127.0.0.1])
	by grelber.thyrsus.com (Postfix) with ESMTP id 3554073945
	for <l_indien@magic.fr>; Sun, 21 Oct 2007 09:29:31 -0400 (EDT)
From: Rob Landley <rob@landley.net>
Organization: Boundaries Unlimited
To: "J. Mayer" <l_indien@magic.fr>
Subject: Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !
Date: Sun, 21 Oct 2007 08:26:36 -0500
User-Agent: KMail/1.9.6
References: <200710181912.57825.rob@landley.net> <200710210455.51059.rob@landley.net> <1192962274.16781.62.camel@rapid>
In-Reply-To: <1192962274.16781.62.camel@rapid>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200710210826.36908.rob@landley.net>

On Sunday 21 October 2007 5:24:34 am you wrote:
> Strange, my ISP does not tag your mails as spams, when I receive them.
> But it's not a problem for me not to be CCed...

Huh, did that get fixed recently?

Testing...

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

--3554073945.1192973372/grelber.thyrsus.com--

Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc !

[J. Mayer]

Hi,

Sorry for the delay...

On Fri, 2007-10-19 at 12:57 -0500, Milton Miller wrote: 
> On Oct 18, 2007, at 6:46 PM, J. Mayer wrote:
> > On Thu, 2007-10-18 at 19:12 -0500, Rob Landley wrote:
[...]
> Rob was complaining he needed arch ppc to boot prep qemu but  
> kernel_headers only worked on powerpc.  Rob choose prep because the  
> header on the prep kernel was the only one that satisfied Open Hackware  
> when supplied to -kernel.  About this time Dave Gibson started code to  
> run prep hardware under powerpc.  It had several assumptions on what  
> the machine looked like.  As I remember it, I tried Dave's port on the  
> qemu 0.6.2 found on the Knoppix 4.0.2 dvd and caused qemu to segv.  I  
> was not prepared to debug qemu; I assumed the assumptions were not met.
> 
> Taking a look at Open Hackware 0.4, it appears that it treats the  
> memory given to -kernel as a block device.  That makes no sense to me.   
> I would expect it to treat the memory as the file loaded from the block  
> device.

This seems very common and useful to me to treat memory the same way you do with any block device. You can then have RAM disks, MTD, ... That's the idea behind it, even if the current implementation may not properly reflect it.
It's even more logical to treat the PreP kernel image as a bloc device as it is exactly a bloc device image dump...

>   Seeing that no updates to Open Hackware had been made in  
> years, and that it only pretended to have a open firmware client  
> interface and contained a mostly useless rtas (eg no pci config  
> methods), I decided to try bypassing it and just give the kernel what  
> it was looking for: a description of the hardware.

OpenFirmware should not be required to boot a PreP system, as it is only
an option of the platform. The residual data should be sufficient for
any OS, if we follow the specification. RTAS is not used on PreP, as far
as I know, it seems to be useful mostly when running in a virtual
partition but this is not supported by Qemu for now.

> 
> I choose to continue with prep because I knew the expected hardware  
> much better than pmac (the heathrow emulation).  I started by mining  
> Open Hackware 0.4 for information describing the hardware and its  
> startup.  I found the entry point was 0xfffffffc and after a bit of  
> experimentation I found qemu required the rom to be 512k and was read  
> only.  I found that since there were no caches I could do IO to serial  
> in real mode, which meant I didn't have to decide what to map via bats.  

I guess you found most of the useful informations, there !

[...]


> > I have to admit I never put the focus on trying to solve this issue,  
> > has
> > I usually use Mac99 or PowerPC 405 targets for tests and that PreP
> > machines are long obsolete and the heathrow target does not reflect any
> > real machine. But this is to be solved, for sure.
> 
>  From the patch description you inserted a openpic between the 8259 and  
> the cpu.  If this is true, at a minimum it will require this to be  
> described to be in the device tree for linux (or in the prep residual  
> data in general for hackware).  My qemu linux code wasn't expecting an  
> openpic so it would need to adjust; or perhaps David's kernel code  
> would now work.

There is no OpenPIC in the Qemu PreP target. There could be one, but
currently, there is only one i8259, when there should be 2, cascaded...
(maybe some of the IRQ problems we have come from the fact we don't have
this second IRQ controller ?).
The patch did add a description of what I called the 'internal PowerPC
interrupt controller', which in fact is the emulation of the PowerPC bus
interface. For the PreP target, only the 6xx bus is supported. The also
added proper connection between the Mac99 target OpenPIC controller and
the PowerPC input pins and should also provide the connection between
the i8529 output pin and the PowerPC IRQ input pin for the PreP target.
I realized some times ago that the connections between the heathrow PIC
and the PowerPC input pins are not emulated, but there seem to be more
problems in the heathrow emulation.

[....]

> > If the proposed ROM image is best suitable to make PreP target run (and
> > as I don't spend a lot of time hacking OHW those days), it may also be
> > interesting to add a ppc_prep_rom.bin to the repository... In fact, it
> > was maybe not a good idea to try to use the same BIOS image on all
> > PowerPC targets...
> 
> The code has drawbacks, as I mentioned.  Its very linux specific and 
> the only error it finds is no load segement in the presumed elf header. 
>   It wouldn't be that hard to add some error checking and even print 
> error to the serial.  The code itself is not platform specific but the 
> device tree attached to it is.  As I said, we could link multiple 
> copies together (one for each platform) and search until we got the 
> right one; or just search trees based on the platform with the fixups 
> in code specific to that tree.   In that regard, this would be an 
> option to use when using -kernel instead of being tied to the prep 
> platform.

My way of thinking is:
if your BIOS image allows one to take any kernel that would boot on a
real PreP machine and make it boot directly with Qemu without any
modification, we have to use it. If you need to use a hacked kernel in
order to be able to boot it, then we'd better use OHW that is able to
boot 2.4 and 2.6 kernels, once the bugs to make them build properly for
PreP are fixed.

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