Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: David Gibson <david <at> gibson.dropbear.id.au>
Subject: Re: Could the DTS experts look at this?
Newsgroups: gmane.linux.ports.ppc64.devel
Date: Tuesday 12th February 2008 23:17:02 UTC (over 8 years ago)
On Tue, Feb 12, 2008 at 12:51:06PM -0600, Scott Wood wrote:
> On Tue, Feb 12, 2008 at 11:36:33AM +1100, David Gibson wrote:
> > On Tue, Feb 12, 2008 at 01:21:44AM +0100, Arnd Bergmann wrote:
> > > On Tuesday 12 February 2008, David Gibson wrote:
> > > > Or to expand.  It's relatively easy now to just include multiple
nodes
> > > > in the tree and either delete or nop some of them out conditionally
> > > > using libfdt.  But the conditional logic should be in the
manipulating
> > > > agent (u-boot or bootwrapper or whatever), there's no way we're
going
> > > > to require a conditional expression parser to interpret the device
> > > > tree blob itself.
> > > 
> > > How about making the logic to nop out nodes a little more generic
> > > without changes to the binary format?
> > > E.g. you could have a "linux,conditional-node" property in the device
> > > tree whose value is compared to a HW configuration specific string.
> > > In Sean's example, you can have linux,conditional-node="Rev.A" in
> > > some nodes and linux,conditional-node="Rev.B" in others, then
> > > knock out all devices that have a non-matching linux,conditional-node
> > > property, and finally remove the properties themselves before
starting
> > > the kernel.
> > 
> > Well, that's basically a u-boot issue.  If they want to do their input
> > trees that way, and have helper functions that deal with it...
> 
> The actual mechanism that we originially discussed, which Timur later
> morphed into conditions-on-nodes, was to have a separate hwoptions node,
> under which would be described various hwoptions (jumpers and such) whose
> state could be either detected by u-boot or set by environment variable. 
> Each hwoption setting would contain a device tree fragment to be merged
into
> the main device tree.

I'm not sure I'm entirely happy about storing the fragments under a
special node - but certainly u-boot could do that if it wants.  What
would certainly be ok is to store various fragments as separate blobs
and fold them together as necessary.  Which reminds me, I meant to
implement a "graft" function in libfdt.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
 
CD: 3ms