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
 `. `'   address@hidden         | address@hidden
   `-    people.debian.org/~aurel32 | www.aurel32.net