[U-Boot] [RFC 1/3] FDT: Add fixup support of multiple banks of memory

[Grant Likely]

On Tue, Aug 10, 2010 at 3:03 PM, John Rigby <john.rigby at linaro.org> wrote:
> Kumar, Grant:
>
> On Tue, Aug 10, 2010 at 1:39 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
>> On Thu, Aug 5, 2010 at 5:36 PM, John Rigby <jcrigby at gmail.com> wrote:
>>> On Thu, Aug 5, 2010 at 5:26 PM, Kumar Gala <galak at kernel.crashing.org> wrote:
>>>>
>
> ....
>
>>>>
>>>> The problem w/libfdt is that use of 'offsets' to get to nodes can be problematic if the offset changes while manipulating it.  There are ways around thus but a number of functions we do would benefit from a more live tree.
>>
>> This is actually a really good point.  Offsets changing under your
>> feet is just asking for bugs.  I could see this as being a legitimate
>> justification for having a live tree model in libfdt and the ability
>> to transition between the live and flat representations.  I was
>> against this when we chatted on IRC the other day as it sounds like
>> overkill, but this is a legitimate concern.  dtc has a live tree
>> representation that could probably be migrated into libfdt.
>>
>
> I don't think I fully understood Kumar's question when he first sent
> it.  Now I want to understand.  Are these gotcha's and workaround's
> with libfdt documented anywhere?  If not then I would be willing to
> write up something.  But I'll need some pointers to get me started.
> In the longer term how much work do you think it would be to make
> libfdt's internal representation dynamic?  I would be willing spend
> some time on this if the consensus is that it is worth having.

libfdt's implementation is *by design* static so that is can be easily
supported in minimal firmwares.  The live tree would be an additional
model in addition to the flattree routines.  Take a look in the dtc
repo to see how the the device tree compiler uses it.

g.