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: Rob Landley
Subject: Re: [Qemu-devel] PreP kernels boot using Qemu
Date: Fri, 26 Oct 2007 20:59:20 -0500
User-agent: KMail/1.9.6

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
> > <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.4.35-prep.ta
> >r.bz2>
> > <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.12-prep.ta
> >r.bz2>
> > <http://perso.magic.fr/l_indien/qemu-ppc/linux-tests/linux-2.6.22-prep.ta
> >r.bz2>

The thing is, that's done with ARCH=ppc and the Linux kernel is migrating to 
ARCH=powerpc.  (This is apparently fallout from merging the 32-bit and 64-bit 
PowerPC architecture sources.)

ARCH=ppc is deprecated and going away some time next year, they're migrating 
everything over to the new infrastructure in ARCH=powerpc.

From an immediate practical standpoint, I can't use ARCH=ppc to build a system 
because that architecture doesn't support the "make headers_install" target 
so I can extract appropriate architecture-specific Linux kernel headers 
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=powerpc, 
but when those are applied the result runs on real prep hardware but not 
under qemu (due to the prep residual data in qemu not matching the Linux 
kernel's expectations).

Rather than update the residual data qemu is generating so the linux kernel 
can parse it to add entries to a device tree, Milton just created a "qemu 
target" with the same set of hardware as a prep system but minus the boot 
logic.  Instead he created a  device tree data structure in the format Linux 
wants it, and a boot room that could feed that device tree to the Linux 
kernel directly.  This was much simpler and mostly involved removing code 
rather than adding any.

Getting the kernel to build a "qemu target" that runs on prep but doesn't have 
the prep packaging, boot wrapper, or residual data parsing logic, was 1 patch 
instead of 20+.

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.




reply via email to

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