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

[Grant Likely]

On Tue, Aug 10, 2010 at 2:17 PM, Dan Malek <ppc6dev at digitaldans.com> wrote:
>
> On Aug 10, 2010, at 12:39 PM, Grant Likely wrote:
>
>> .....  At the
>> moment, I think firmware should be restricted to only touching the
>> /chosen node, the /memory node,
>
> I don't even want it updating these, except maybe for the processor
> clock speeds.

Hi Dan!  I'm glad you're reading as you're one of the use-cases I was
thinking about.  :-)

> I'm trying to use device trees as a mechanism for providing resource
> allocation information in a partitioned, multi-core system.  In this
> case, I don't want the boot firmware making updates to the device
> tree.

Yes, it is really problematic when boot firmware unconditionally makes
device tree changes for this exact reason.  However, it is also true
that there is certain information that firmware really needs to hand
off to the kernel, such as the boot parameters string.  Traditionally,
the chosen node has been the expected place to put that data, but I
gather from your comment that even that causes problems in your
use-case.  (or is it the /memory node that is the issue?)  Can you
give a concrete example so I understand the issue?  The /memory node
update was implemented to match the historical behaviour of u-boot
setting the memory size in the board_info structure, but perhaps that
shouldn't be unconditional.

> I understand in many cases it's quite convenient to have the boot
> firmware update the device tree prior to invoking the OS, but this
> is one time when it's not appreciated.  I'm currently experimenting
> with two models, one using environment variables and another
> using some kind of device tree tagging (i.e. don't update value if
> it's not equal to some unique key).  Neither method has proven
> to be better in all cases.

Cheers,
g.