[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

[Stephen Warren <swarren@wwwdotorg.org>]

On 10/24/2012 11:28 AM, Tom Rini wrote:
> Hey all,
> 
> I've been thinking about one of the problems we need to solve over in TI
> AM335x land and that is given that we support a number of different
> boards with a single binary (and we have an i2c eeprom that tells us
> what board and revision we are on), the user needs to be able to easily
> determine what board we are on so they know what dtb file to load so
> they can boot.  To this end I've added
> CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG to the README which says when set
> we have board_name and board_rev set at run-time.  Then for am335x[1]

With CONFIG_ENV_VARS_UBOOT_CONFIG set, there's a environment variable
named $board that indicates which board U-Boot is running on (and other
related variables). The idea is that the user can:

fsload ${devtype} ${devnum}:${rootpart} ${fdt_addr_r}  \
    /boot/${soc}-${board}.dtb

Now, CONFIG_ENV_VARS_UBOOT_CONFIG sets $board at compile-time, since the
config variable was created in the context on a U-Boot that runs on a
single board. However, I see no reason why we can't maintain the
user-visible results of this config option even in other cases, so that
everything is consistent to the user

To that end, can we make CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG set $board
instead of $board_name?

Adding $board_rev sounds like a very good idea; the filename in the
above command could be modified to:

${soc}-${board}${boardrev}.dtb

Or, do you think it'd be better for boot.scr to always reference
$fdtfile, and so modify Tegra's default environment to derive $fdtfile
from $soc, $board, $boardrev?

(This general discussion might usefully happen on the cross-distro
mailing list too?)

> set that and CONFIG_BOARD_LATE_INIT which will set the variables and add a
> command, findfdt to compare and set fdtfile correctly.  Further
> distro-specific logic can then augment this to figure out what
> filesystem / partition to read from.
> 
> [1]: Yes, this will need re-working after merging Peter K's patches to
> allow for non-TI boards.