qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] PreP kernels boot using Qemu


From: J. Mayer
Subject: Re: [Qemu-devel] PreP kernels boot using Qemu
Date: Mon, 22 Oct 2007 23:12:02 +0200

On Mon, 2007-10-22 at 18:28 +0200, Aurelien Jarno wrote:
> On Mon, Oct 22, 2007 at 09:36:07AM +0200, J. Mayer wrote:
> > Hi all,
> > 
> > I've been investigating more about PreP kernel boot using Qemu and I
> > achieved to boot 2.4.35, 2.6.12 and 2.6.22 kernels using Qemu CVS and
> > unmodified OHW.
> > The issues I found in the kernel are:
> > - the OpenFirmware video console driver is broken in recent 2.4 kernels
> > and have been removed from recent 2.6 kernel
> > - I then decided to use the vga16fb console driver but needed to do some
> > patches in order to make it compile properly
> > - the CMOS RTC driver is not available for PPC architecture in 2.6
> > kernels and need some patches in order to be usable
> > - I discovered that the mkprep utility is bugged in 2.4.35 and 2.6.12
> > kernels. The bugs are visible only when cross-compiling from a
> > little-endian and/or 64 bits host.
> > - I got issues (ie process freezing) when using the 2.6.22 kernel with
> > HZ > 100. It seems to run properly when the system timer is set to 100
> > Hz but this needs more tests for confirmation.
> > - I got the 2.6.22 kernel crashing (ie kernel Oops in workqueue code)
> > when it has no RTC available. There is no problem when the RTC is
> > present. This is likely to be a kernel bug: when no RTC is available, it
> > cannot calibrate its timers properly and the kernel timer seems to run
> > very fast. Forcing (with hacks...) the timer to run at nearly real-time
> > seems to prevent the bug to happen.
> > 
> > I then generated some kernels that allow me to boot and use those 3
> > kernels.
> > Here are 3 tarballs with:
> > - a patch to be applied to the vanilla kernel sources to fix the
> > mentionned bugs
> > - the .config file I used to build the kernel
> > - the zImage.prep image
> > <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.4.35-prep.tar.bz2>
> > <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.12-prep.tar.bz2>
> > <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.22-prep.tar.bz2>
> > 
> > I then run Qemu with the following command line template:
> > ./ppc-softmmu/qemu-system-ppc -serial stdio -net nic,model=ne2k_isa -net
> > tap -net nic,model=ne2k_pci -net tap -net nic,model=rtl8139 -net tap
> > -cpu 604 -M prep -L pc-bios/ -hda <my_first_disk> -cdrom <my_cdrom>
> > -kernel
> > <src_base>/linux-<kversion>.patched/arch/ppc/boot/images/zImage.prep
> > 
> > Hope this helps.
> > 
> 
> Yes, this help a lot, thanks! With your config file, I have been able to
> build and boot a 2.6.22 kernel. I have used a Debian sid chroot.
> 
> Here are a few remarks:
> - The NE2000 card doesn't work for the same reason as with the powerpc
>   architecture. The kernel patch below fixes the problem. I will send it
>   later along with the ppc patch.

There's something else strange with the PCI ethernet devices: they got
no IRQ assigned (as if the BIOS does not configure them properly). And
the RTL8139 never has a mac address, never detects the PHY link, then
there may be endianness issues in the emulation (I did not check at
all).

> - The "floating point" problem I reported during the week-end does not
>   exists, probably because of the switch from powerpc to ppc. I still 
>   don't know if it is a kernel problem or a QEMU problem (or both).

There may be issues with the floating point emulation, especially if
some kernel or programs relies on the FPSCR (floating-point status)
register which is never updated in Qemu.

> - PCI is broken. PCI IDs are reported in the wrong endianness:
>   00:00.0 Non-VGA unclassified device: Unknown device 0148:5710 (rev 06)
>   00:01.0 Non-VGA unclassified device: Santa Cruz Operation Unknown device 
> 3412 (rev 03)

This does not happen with 2.4 kernels. Using the 2.4.35 image, all PCI
descriptors are OK and the drivers properly recognize the devices. What
I suspect is that 2.6 kernels tweak the chipset to make it handle the
endian-reverse accesses.

[...]

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]