From: Rob Landley <rob@landley.net>
To: Christoph Hellwig <hch@lst.de>
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>,
Milton Miller <miltonm@bga.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH 1/2] qemu platform, v2
Date: Sat, 22 Sep 2007 14:16:20 -0500 [thread overview]
Message-ID: <200709221416.21580.rob@landley.net> (raw)
In-Reply-To: <20070922095546.GA14185@lst.de>
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
the kernel.)
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
next prev parent reply other threads:[~2007-09-22 19:34 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-21 23:02 [PATCH 0/15] bootwrapper: kexec and external payloads Milton Miller
2007-09-21 23:03 ` [PATCH 1/15] boot: find initrd location from device-tree Milton Miller
2007-09-24 2:58 ` David Gibson
2007-09-24 5:50 ` Rob Landley
2007-09-24 8:02 ` Milton Miller
2007-09-25 3:27 ` David Gibson
2007-09-26 5:49 ` Milton Miller
2007-09-21 23:03 ` [PATCH 2/15] boot: record header bytes in gunzip_start Milton Miller
2007-09-24 2:59 ` David Gibson
2007-09-21 23:03 ` [PATCH 3/15] boot: simplfy gunzip_finish Milton Miller
2007-09-21 23:03 ` [PATCH 4/15] bootwrapper: smp support code Milton Miller
2007-09-21 23:04 ` [PATCH 5/15] bootwrapper: occuppied memory ranges Milton Miller
2007-09-24 3:09 ` David Gibson
2007-09-24 9:33 ` Milton Miller
2007-09-21 23:04 ` [PATCH 6/15] bootwrapper: help for 64 bit cpus Milton Miller
2007-09-24 3:14 ` David Gibson
2007-09-21 23:04 ` [PATCH 7/15] bootwrapper: Add kexec callable zImage wrapper Milton Miller
2007-09-24 3:23 ` David Gibson
2007-09-21 23:05 ` [PATCH 8/15] bootwrapper: convert flatdevtree to version 16 Milton Miller
2007-09-24 3:36 ` David Gibson
2007-09-24 6:54 ` Milton Miller
2007-09-25 3:46 ` David Gibson
2007-09-26 16:19 ` Milton Miller
2007-09-27 2:45 ` David Gibson
2007-09-27 15:44 ` Milton Miller
2007-09-28 2:40 ` David Gibson
2007-09-28 15:16 ` Milton Miller
2007-10-03 5:29 ` David Gibson
2007-09-21 23:05 ` [PATCH 9/15] bootwrapper: rtas support Milton Miller
2007-09-24 3:46 ` David Gibson
2007-09-21 23:05 ` [PATCH 10/15] bootwrapper: add cpio file extraction library Milton Miller
2007-09-21 23:06 ` [PATCH 11/15] bootwrapper: allow vmlinuz to be an external payload Milton Miller
2007-09-21 23:06 ` [PATCH 12/15] bootwrapper: kexec extract vmlinux from initramfs Milton Miller
2007-09-21 23:06 ` [PATCH 13/15] bootwrapper: attach an empty vmlinux Milton Miller
2007-09-24 4:03 ` David Gibson
2007-09-21 23:08 ` [PATCH 14/15] boot: add a hook to start cpus Milton Miller
2007-09-21 23:08 ` [PATCH 15/15] bootwrapper: recheck for command line after fixups Milton Miller
2007-09-21 23:08 ` [PATCH 1/2] qemu platform, v2 Milton Miller
2007-09-22 9:55 ` Christoph Hellwig
2007-09-22 19:16 ` Rob Landley [this message]
2007-09-23 4:27 ` Paul Mackerras
2007-09-23 22:01 ` Rob Landley
2007-09-28 16:53 ` Segher Boessenkool
2007-09-28 20:14 ` Rob Landley
2007-10-01 5:33 ` David Gibson
2007-10-17 20:28 ` Grant Likely
2007-10-17 23:09 ` Rob Landley
2007-10-18 9:59 ` Matt Sealey
2007-10-18 17:19 ` Milton Miller
2007-10-18 17:29 ` Grant Likely
2007-10-19 6:28 ` Rob Landley
2007-09-24 4:00 ` David Gibson
2007-09-24 7:46 ` Christoph Hellwig
2007-09-24 9:48 ` Milton Miller
2007-09-21 23:08 ` [PATCH 2/2] qemu platform rom, v2 Milton Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200709221416.21580.rob@landley.net \
--to=rob@landley.net \
--cc=david@gibson.dropbear.id.au \
--cc=hch@lst.de \
--cc=linuxppc-dev@ozlabs.org \
--cc=miltonm@bga.com \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).