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