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

[Daniel Mack <zonque@gmail.com>]

On 01.11.2012 04:26, David Gibson wrote:
> On Fri, Oct 26, 2012 at 09:24:11AM +0200, Daniel Mack wrote:

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

I called the function fdt_overlay, but I guess the implementation is
similar to what you thought of. I pushed it here, see the topmost 3 commits:

  https://github.com/zonque/dtc/commits/overlay

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

As pointed out on another end of this thread, the use of my simple
implementation is rather limited. I need to think about something more
sophisticated, or abadon the idea alltogether.


Thanks,
Daniel