On 12/06/2010 10:52 PM, Wolfgang Denk wrote: > Dear Deepak Saxena, > > I am not sure this is a good idea. > > So far we have a pretty clear definition of responsibilities. > U-Boot does the low level initialization, including the sizing and > testing of the system memory. U-Boot then passes its results to Linux > in the (modified by U-Boot) device tree. > > Your patch inverts this situation, at least for the memory. > > I agree that there may be situations where you want an easy way to > pass such information. But then let's handle this right. > > If you define that the device tree is the "master" for information > about the memory layout (and potentially other hardware specifics), > then you should be consequent and pass make U-Boot process this > information. We've discussed before that there are a number of cases > where it would be nice if U-Boot itself could be configured usign a > device tree. This appears to be another one. > > What do you think?
Hi Wolfgang, Thanks for the response, I have a few different thoughts on the subject. I am a big fan of having consistent and clear definitions of responsibilities; however, I think the model of having U-Boot handle the creation of memory nodes in the DTB does not scale cleanly to users configuring, deploying, and managing complicated AMP environments. While we could provide a method to provide this information at build time to make U-Boot, this forces a static memory partitioning on the system and does not mesh well with use cases where developers may be testing different system layout options as it would require a rebuild and reflash every time a new configuration is to be tested. In certain environments, a developer may not be permitted to reflash the bootloader on a board shared by others (such as a remote HW lab). The bootm_low and bootm_size variables are an attempt to get around this by overriding what U-Boot knows about the system but I think those also don't scale well when we start dealing with large numbers of cores (32+) with independent OS instances on them for some of the same reasons. I think it is far simpler to have some custom scripts to spit out new DTB files that uBoot is configured to load every time it boots than to have to change a bunch of environment variables on boot. In the multi-node environments, we can't simply tell U-Boot to process the DTB to determine how much memory is in the system as there is one DTB per AMP node. One idea that comes to mind but that I think is not the right way to go due to complexity is to have the concept of nested DTBs that can define multiple operational "machines" and U-Boot knows how to read this and send the right sub-DTB to the right kernel image. I'm new to U-Boot development so would like to hear about the other use cases you mentioned (pointer to email threads are OK) so I can have a better understanding of the overall issues. Thinking about this at a higher level, I think the question is where is the delineation between board bringup/configuration and run time configuration management? Scanning memory and determining how much exists and programming the memory controller is a board-bring up and configuration task that a bootloader has traditionally done. Partitioning for AMP operation is about managing what and how is running on top of the bootloader. How much knowledge should the bootloader have about this? The approach of providing the memory partitioning in the DTB basically removes any of this knowledge from U-Boot, while the other approaches (bootm, build-time configuration) make U-Boot very aware and tied to what might be running above and reduce flexibility to easily change that. Thanks, ~Deepak _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot