[U-Boot] [PATCH] Honor /memory/reg node in DTB files

[Deepak Saxena]

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