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