qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "J. Mayer" <l_indien@magic.fr>
To: qemu-devel@nongnu.org
Cc: Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] PreP kernels boot using Qemu
Date: Mon, 22 Oct 2007 23:12:02 +0200	[thread overview]
Message-ID: <1193087522.16781.121.camel@rapid> (raw)
In-Reply-To: <20071022162810.GA12778@hall.aurel32.net>

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

  reply	other threads:[~2007-10-22 21:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-22  7:36 [Qemu-devel] PreP kernels boot using Qemu J. Mayer
2007-10-22  9:23 ` Jocelyn Mayer
2007-10-27  1:59   ` Rob Landley
2007-10-22 16:28 ` Aurelien Jarno
2007-10-22 21:12   ` J. Mayer [this message]
2007-10-22 22:05     ` Aurelien Jarno
2007-10-22 22:36       ` J. Mayer
2007-10-23 11:47         ` Thiemo Seufer
2007-10-23 21:53           ` J. Mayer
2007-10-23 21:59             ` Aurelien Jarno
2007-10-23 23:06               ` J. Mayer
2007-10-24  0:08             ` Thiemo Seufer
2007-10-27  8:00   ` Rob Landley
2007-10-27  8:07     ` Aurelien Jarno
2007-10-28 10:25       ` Rob Landley
2007-10-28  9:29         ` Aurelien Jarno
2007-10-28 14:17           ` Rob Landley
2007-10-31  2:30             ` Ed Swierk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1193087522.16781.121.camel@rapid \
    --to=l_indien@magic.fr \
    --cc=aurelien@aurel32.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).