From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ila1o-0002N2-1y for qemu-devel@nongnu.org; Fri, 26 Oct 2007 20:59:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ila1k-0002Js-Pl for qemu-devel@nongnu.org; Fri, 26 Oct 2007 20:59:49 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ila1k-0002Jj-2c for qemu-devel@nongnu.org; Fri, 26 Oct 2007 20:59:48 -0400 Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5] helo=grelber.thyrsus.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ila1j-00066h-Ni for qemu-devel@nongnu.org; Fri, 26 Oct 2007 20:59:47 -0400 Received: from landley.net (localhost [127.0.0.1]) by grelber.thyrsus.com (Postfix) with ESMTP id 8AB6273938 for ; Fri, 26 Oct 2007 21:02:20 -0400 (EDT) From: Rob Landley Subject: Re: [Qemu-devel] PreP kernels boot using Qemu Date: Fri, 26 Oct 2007 20:59:20 -0500 References: <1193038567.16781.108.camel@rapid> <1193044980.31445.40.camel@jma4.dev.netgem.com> In-Reply-To: <1193044980.31445.40.camel@jma4.dev.netgem.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710262059.20332.rob@landley.net> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Monday 22 October 2007 4:23:00 am Jocelyn Mayer wrote: > > 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 > > >r.bz2> > > >r.bz2> > > >r.bz2> The thing is, that's done with ARCH=3Dppc and the Linux kernel is migrating= to=20 ARCH=3Dpowerpc. (This is apparently fallout from merging the 32-bit and 64= =2Dbit=20 PowerPC architecture sources.) ARCH=3Dppc is deprecated and going away some time next year, they're migrat= ing=20 everything over to the new infrastructure in ARCH=3Dpowerpc. =46rom an immediate practical standpoint, I can't use ARCH=3Dppc to build a= system=20 because that architecture doesn't support the "make headers_install" target= =20 so I can extract appropriate architecture-specific Linux kernel headers=20 defining the system calls I can build a C library against. There's a series of 20+ patches to add proper prep support to arch=3Dpowerp= c,=20 but when those are applied the result runs on real prep hardware but not=20 under qemu (due to the prep residual data in qemu not matching the Linux=20 kernel's expectations). Rather than update the residual data qemu is generating so the linux kernel= =20 can parse it to add entries to a device tree, Milton just created a "qemu=20 target" with the same set of hardware as a prep system but minus the boot=20 logic. Instead he created a device tree data structure in the format Linu= x=20 wants it, and a boot room that could feed that device tree to the Linux=20 kernel directly. This was much simpler and mostly involved removing code=20 rather than adding any. Getting the kernel to build a "qemu target" that runs on prep but doesn't h= ave=20 the prep packaging, boot wrapper, or residual data parsing logic, was 1 pat= ch=20 instead of 20+. Rob =2D-=20 "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.