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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
