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