[Top][All Lists]
[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.
- [Qemu-devel] PreP kernels boot using Qemu, J. Mayer, 2007/10/22
- Re: [Qemu-devel] PreP kernels boot using Qemu, Jocelyn Mayer, 2007/10/22
- Re: [Qemu-devel] PreP kernels boot using Qemu,
Rob Landley <=
- Re: [Qemu-devel] PreP kernels boot using Qemu, Aurelien Jarno, 2007/10/22
- Re: [Qemu-devel] PreP kernels boot using Qemu, J. Mayer, 2007/10/22
- Re: [Qemu-devel] PreP kernels boot using Qemu, Aurelien Jarno, 2007/10/22
- Re: [Qemu-devel] PreP kernels boot using Qemu, J. Mayer, 2007/10/22
- Re: [Qemu-devel] PreP kernels boot using Qemu, Thiemo Seufer, 2007/10/23
- Re: [Qemu-devel] PreP kernels boot using Qemu, J. Mayer, 2007/10/23
- Re: [Qemu-devel] PreP kernels boot using Qemu, Aurelien Jarno, 2007/10/23
- Re: [Qemu-devel] PreP kernels boot using Qemu, J. Mayer, 2007/10/23
- Re: [Qemu-devel] PreP kernels boot using Qemu, Thiemo Seufer, 2007/10/23
Re: [Qemu-devel] PreP kernels boot using Qemu, Rob Landley, 2007/10/27