From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ik5QJ-0007mC-W4 for qemu-devel@nongnu.org; Mon, 22 Oct 2007 18:07:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ik5QJ-0007m0-IK for qemu-devel@nongnu.org; Mon, 22 Oct 2007 18:06:59 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ik5QJ-0007lx-DN for qemu-devel@nongnu.org; Mon, 22 Oct 2007 18:06:59 -0400 Received: from hall.aurel32.net ([88.191.38.19]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ik5QJ-0000Ur-1q for qemu-devel@nongnu.org; Mon, 22 Oct 2007 18:06:59 -0400 Message-ID: <471D1E98.50303@aurel32.net> Date: Tue, 23 Oct 2007 00:05:12 +0200 From: Aurelien Jarno MIME-Version: 1.0 Subject: Re: [Qemu-devel] PreP kernels boot using Qemu References: <1193038567.16781.108.camel@rapid> <20071022162810.GA12778@hall.aurel32.net> <1193087522.16781.121.camel@rapid> In-Reply-To: <1193087522.16781.121.camel@rapid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "J. Mayer" Cc: qemu-devel@nongnu.org J. Mayer a écrit : > 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 >>> >>> >>> >>> >>> 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 -cdrom >>> -kernel >>> /linux-.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. > Is there any technical reason behind that, or is it just a lack of time? -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net