[U-Boot] Merging device trees at runtime for module-based systems

[David Gibson]

On Fri, Oct 26, 2012 at 09:24:11AM +0200, Daniel Mack wrote:
> On 26.10.2012 02:53, David Gibson wrote:
> > On Thu, Oct 25, 2012 at 10:46:32PM +0200, Wolfgang Denk wrote:
> >> Dear Daniel,
> >>
> >> In message <50893633.6070408 at gmail.com> you wrote:
> >>>
> >>> Overwrites must be addressed in the first place. The most common example
> >>> is that a more generic part (the module tree) registers all details
> >>> about a peripheral up-front but then sets its status to 'disabled'. That
> >>> way, the more specific part (the base board tree) can overwrite this
> >>> property to 'okay' at wish to enable it and not care for the pre-defined
> >>> details. This is also how we do things in our device-trees.
> >>
> >> Agreed.
> >>
> >>>> I definitely can see the benefit of such a feature and would be happy
> >>>> if you could go forward and implement it.
> >>>
> >>> Ok then. I guess this should be something that can eventually be merged
> >>> back into libfdt?
> >>
> >> I can't speak for the FDT custodian, but I think this makes a lot of
> >> sense.
> > 
> > As a rule I'm happy to see more functionality for libfdt.  I've only
> > seen bits and pieces of this thread, though, so I'd need to see a
> > summary of what exactly is being proposed.
> 
> That's strange, as I copied you from the very first posting. Anyway,
> here's the archive:

Oh I probably got them somewhere in my mail.  But it's only recently
that I really noticed - I get a fair bit of mail.

>   http://lists.denx.de/pipermail/u-boot/2012-October/138227.html
> 
> I would especially like to know where such a new functionality should
> live, which data types it should operate on and what would be an
> appropriate name for it.

So.. the first thought I have reading the original mail in the thread
is that it's arguable that you really want a more heavyweight firmware
for this setup, that actively maintains a live device tree as OF does,
rather than u-boot which is pretty oriented towards a close-to-static
device setup.  That's just a thought though, I'm not saying that at
least some of this functionality doesn't belong in libfdt.

So, my thought would be that stuff for manipulating big chunks of tree
should go in a new .c file inside the libfdt tree.  We already have
del_node and nop_node of course, which can remove whole subtrees.  I
guess the big extra function you'd want would be something like:

fdt_graft(void *fdt, int offset, void *subtree);

Which would graft the tree blob give by subtree into the "master" tree
(fdt) at node 'offset'.  Actually that might need to take a name for
the top-level of the subtree to take in the new tree too.

Things get trickier when you consider what might need to be tweaked in
the subtree to make it fit into the master tree.  If it requires
widespread alterations through the subtree that's going to get really
ugly and I think you would be better off with a firmware with a fuller
handling of a "live" device tree.  But I think that can probably be
avoided with proper design of the bindings.

To get that to work you'll need to make sure you use some sort of
local addressing within the subtree.  Then it should only be necessary
to insert/alter a "ranges" property at the top level of the subtree
(or possibly its parent) to map that correctly into the global address
space.  Likewise interrupts within the subtree probably shouldn't
address an external interrupt controller but rather the root of the
tree.  You can then insert an "interrupt-map" property which will
wire those into the global interrupt tree.

-- 
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