[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110103175254.GD2522@angua.secretlab.ca>
Date: Mon, 3 Jan 2011 10:52:54 -0700
From: Grant Likely <grant.likely@...retlab.ca>
To: "H. Peter Anvin" <hpa@...ux.intel.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>, x86@...nel.org,
linux-kernel@...r.kernel.org, sodaville@...utronix.de,
Rob Landley <rob@...dley.net>,
devicetree-discuss@...ts.ozlabs.org
Subject: Re: [sodaville] [PATCH 02/11] x86: Add device tree support
On Mon, Jan 03, 2011 at 08:19:36AM -0800, H. Peter Anvin wrote:
> On 01/03/2011 08:05 AM, H. Peter Anvin wrote:
> > On 12/30/2010 12:58 PM, Grant Likely wrote:
> >>
> >> Right, but in all of those cases a boot wrapper provides the same
> >> functionality with better flexability, such as being able to provided
> >> the dtb image(s) at install time instead of compile time.
> >>
> >
> > Assuming the boot wrapper is written correctly. I have seen a number of
> > cases in which it was not, and it being "already locked into firmware"
> > and not changeable.
> >
> > It's a nice theory. And in theory, theory and practice agree.
> >
>
> By the way, this is the same reason we also allow the initramfs and even
> the command line to be compiled in.
I think we've got an impedance mismatch.
The whole point of the ppc boot wrapper, and the kind of boot wrapper
that I'm talking about here, is that it becomes part of the kernel
image and is *not* part of firmware. ie. an executable wrapper which
carries the kernel as it's payload. I'm wary too of depending of
firmware to get things right because it can be so painful to change.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists