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

Grant Likely
2010-08-10T21:09:46Z

On Tue, Aug 10, 2010 at 3:03 PM, John Rigby <john.rigby@linaro.org> wrote:
> Kumar, Grant:
>
> On Tue, Aug 10, 2010 at 1:39 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Thu, Aug 5, 2010 at 5:36 PM, John Rigby <jcrigby@gmail.com> wrote:
>>> On Thu, Aug 5, 2010 at 5:26 PM, Kumar Gala <galak@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.