[U-Boot] RFC: Not overriding device-tree memory nodes

[Deepak Saxena]

I am playing with loading of multiple Linux images on individual cores 
on a multi core system (P2020RDB for example) and would like to be able 
to provide the memory information for each node via the DTB as opposed 
to using the bootm_low and bootm_size environment variables. The env 
variables work; however, setting the environment variable for each node 
when we're already using the DTB to partition devices on the system 
seems confusing from the perspective of someone who is trying to 
configure and deploy a complex multi-core environment (8, 16, and more 
cores).

Using the DTB's memory node is easily accomplished by adding some code 
to the ft_board_setup() to check if a valid memory/reg property exists 
(valid meaning that it is within the [bd_memstart, bd_memstart + 
bd_memsize] range) and honoring that. The issue that comes up is what to 
do when there is a valid range in the DTB and the user has also set a 
bootm_range. For example the user is doing some quick testing and wants 
to change the amount of memory for a node or two just for one run via 
the variables instead of re-building the DTB. My thought is to 
prioritize the environment variable over the DTB; however calling 
getenv_bootm_low() returns a valid value even if the user has not set so 
there's no way to tell if the user set it or not. I'd like to do one of 
two following to deal with this:

1) Add a parameter to getenv_bootm_low() that returns whether the 
variable is user set or a default value,
    getenv_bootm_low(&user_set) for example.

2) Just make an assumption in ft_board_setup()  if (bootm_low + 
bootm_size == bd_memstart + bd_memsize),
    the user did not set the value and we should honor what is in the DTB.

I'm leaning with option 2 as it is not intrusive to other callers and 
less confusing in my opinion and I'll likely wrap the code to check for 
an existing memory/reg DTB entry in a new ft_bootm_fixup() function that 
can be used by any existing and future boards that implement 
CONFIG_OF_BOARD_SETUP.

Thoughts?
~Deepak