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

[Daniel Mack <zonque@gmail.com>]

Hi Wolfgang,

On 25.10.2012 14:44, Wolfgang Denk wrote:
> In message <5087B919.2010006@gmail.com> you wrote:
>>
>> So let's say we have n versions of the baseboard and m versions of the
>> module, we would much like to only prepare n + m files, instead of n * m
>> by pre-compiling every possible combination (some of which may actually
>> never occur 'in the wild').
> 
> What you are facing is a situation that
> 1) appears to be pretty common, and
> 2) has (AFAICT) not been truely satisfactory solved yet.
> 
>> So my question is: is it possible to do that kind of assembly of a
>> number of files at runtime in U-Boot? I guess all it takes is merging a
>> number of trees together, right? I browsed through the APIs but couldn't
>> yet find an clear approach to that kind of problem. If not, what would
>> it take to add that functionality? I can probably help with the
>> implementation if someone tells me what would be the right way.
> 
> I think it should be possible to overlay several DT images; ideally
> these would be strictly orthogonal, i. e. the newly loaded one would
> only add new properties, but I think it should be also no problem to
> define some latest-wins policy, i. e. in case of already existing
> properties the newly loaded ones would just overwrite the previous
> settings.

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.

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


Thanks,
Daniel