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

[Grant Likely]

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:
>>
>> On Aug 5, 2010, at 5:14 PM, John Rigby wrote:
>>
>>> Add fdt_fixup_memory_banks and reimplement fdt_fixup_memory
>>> to use it.
>>>
>>> Signed-off-by: John Rigby <john.rigby at linaro.org>
>>> ---
>>> common/fdt_support.c  |   86 ++++++++++++++++++++++++++-----------------------
>>> include/fdt_support.h |    1 +
>>> 2 files changed, 47 insertions(+), 40 deletions(-)
>>
>> John,
>>
>> Do you have any sense of how far you intend to go w/device tree's on ARM?
>>
>> I ask because I've been thinking we actually need to have "live tree" structure representation in u-boot (much like the kernel) to allow us to do some of the manipulations we are doing more and more of.
>>
>> 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.

>> Wondering how far you envision ARM going w/device tree and u-boot doing node creations and fix ups.
>
> Right now I'm only looking a basic support.  I know there are those
> who believe that u-boot actually does more manipulation than it
> should.  I'll let Grant speak up if he wants to:).

:-)

I still stand on my point that hard coding device tree manipulations
is asking for trouble.  IMNSHO, firmware should really be restricted
to very well defined things in the device tree.  I've been thinking
about this a lot, and I'm going to write a "Recommended Practice"
document for dealing with the .dtb at the firmware level.  At the
moment, I think firmware should be restricted to only touching the
/chosen node, the /memory node, and updating well defined things like
mac address, but only when the Ethernet node is dereferenced from an
/aliases name instead of full path.

I *might* be able to be convinced that firmware should be allowed to
modify other properties, but only if it isn't hard coded into the
firmware (ie, by using a boot script or other method that can be
changed without upgrading firmware).  As we've discovered in the past,
it is very easy to get into a situation where firmware must be
upgraded to deal with a change in the device tree data. (ie. soc node
name cannot be changed from "soc5200" to "soc" on the lite5200 because
older versions of U-Boot do a pathname lookup)  This risk can be
mitigated if there are some well defined rules about what firmware is
and is not allowed to modify in the tree.

g.