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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
