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

Dan Malek ppc6dev at digitaldans.com
Tue Aug 10 23:17:18 CEST 2010


On Aug 10, 2010, at 1:26 PM, Grant Likely wrote:

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

Hi Grant.  Yeah, it's me, the "special" case :-)

> ....... but I
> gather from your comment that even that causes problems in your
> use-case.

The /chosen hasn't really caused any trouble.

>   (or is it the /memory node that is the issue?)

Yep, /memory is the big problem.

> ....  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 use the /memory to define the start/size of the various partitions,
which of course only one starts at the base address and none of
them represent the entire memory space.  Updating this as we
do today is bad, but then I can think of other complex ways it
could be useful. :-)  Like... specify a percentage in the node
property and have the firmware update base/size according to
previous device tree requests.  But, not today.

A little off topic, but since we tend to discuss device trees here.
I think Hollis has discussed our use of an "enabled" property,
which has become useful.  It's becoming evident that it's valuable
to define the entire device tree, but then have a property for the
device that specified whether it's enabled for use in a particular
partition.  Today, we take a device tree, make copies for each
partition, and modify "enabled" accordingly.  I guess it could be
extended to include partition information in the property, and
we could then perhaps use a single tree for all partitions.  The
kernel or device drivers then test this to determine if this instance
should be using this device.  Anyway, just information I'd thought
I'd pass along that is still brewing.  I don't know if this has any
value to boot firmware, maybe yet another way to control device
tree updates.

Thanks.

	-- Dan



More information about the U-Boot mailing list