On Tue, Aug 10, 2010 at 2:17 PM, Dan Malek <ppc6...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
