[PATCH 1/2] qemu platform, v2
rob at landley.net
Sun Sep 23 05:16:20 EST 2007
On Saturday 22 September 2007 4:55:46 am Christoph Hellwig wrote:
> On Fri, Sep 21, 2007 at 06:08:31PM -0500, Milton Miller wrote:
> > Here is the second rev of patches to boot a arch powerpc kernel on
> > qemu with the prep architecture.
> So if this is supposed to be prep why do you need additional kernel
> support? And if you really needed why isn't it under platforms/prep?
The device tree provided by qemu's open hackware violates some of the
assumptions the Linux kernel is making? (Although things like "the cpu cache
size is zero" are, technically speaking, probably correct. :)
There are three different problems here:
1) porting prep from arch=ppc to arch=powerpc so you can build it on an arch
that also supports make headers_install.
2) PowerPC uses a device tree supplied by the hardware to identify the
available hardware, even for stuff living on PCI busses which it could
theoretically probe for but doesn't.
3) The PPC firmware qemu comes with ("Open Hackware") sucks rocks, is hard to
modify, isn't quite being maintained. As mentioned above, the device tree it
passes in (including "prep residual data" from which more nodes in the device
tree can be constructed, and here my understanding goes all fuzzy) does not
make for a happy Linux kernel.
Proposed solutions to all this involve various combinations of creating a
target platform aimed directly at qemu and not pretending to be prep at all
(so it doesn't have to parse residual data), creating our own boot rom image
out of some of the wrapper code the linux kernel's already got and feeding
that to qemu instead of using open hackware at all, hard wiring a device tree
into the kernel and not looking at the one open hackware passes in...)
I'd be following this more closely if compiling a device tree didn't currently
require an external utility (dtc or some such) that doesn't come with the
Linux kernel. No other target platform I've built kernels for requires such
an environmental dependency. (This is a problem both for hardwiring the
device tree into the kernel and for building a new boot rom from the linux
kernel's ppc boot wrapper that would contain such a device tree to feed to
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
More information about the Linuxppc-dev