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

[Stephen Warren]

On 10/24/2012 12:41 PM, Tom Rini wrote:
> On Wed, Oct 24, 2012 at 11:50:38AM -0600, Stephen Warren wrote:
>> 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
> 
> This works assuming that board maps to the device tree name.  A bit
> more below...

True. I've made sure of that for Tegra.

>> To that end, can we make CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG set
>> $board instead of $board_name?
> 
> I had talked with Joe about this on IRC briefly and he seemed to
> be against overwriting "board"

Why is that? Perhaps alternatively, CONFIG_ENV_VARS_UBOOT_CONFIG
should set both board and a default value for 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
> 
> Indeed, I know we'll need to do this in the future for one of the
> boards in this family.
> 
>> 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?
> 
> Or uEnv.txt, but yes, fdtfile seems to be the standard variable
> name for the device tree to use.

Ah, I do see quite a few U-Boot config headers defining that.

> Doing something to derive this also means that custom development
> can be a bit easier too since you can just set fdtfile directly and
> work out the logic for auto-detection later.

Hmm. So I can't really put the following into Tegra's default environment:

"fdtfile=${soc}-${board}${boardrev}.dtb"

... since that would require any use of "${fdtfile}" in a command to
first expand fdtfile itself, then expand it a second time to pick up
the actual soc/board/... values, and that's not how the shell works.

That implies that e.g. Tegra's scriptboot (seed BOOTCMDS_COMMON in
include/configs/tegra-common-post.h) would need to do something like:

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

... before executing the loaded boot.scr. But then, how would it know
whether to do that, or whether the user wanted to override the fdtfile
value?

In theory, I could do the following in Tegra's default environment:

"fdtfile=" CONFIG_SYS_SOC "-" CONFIG_SYS_BOARD" ".dtb"

But then that wouldn't allow for the fdtfile value to vary at run-time
based on $boardrev.

> Also not hard-coding in the path makes it easier for whichever
> distro to fill in that logic.

By the path, do you mean "/boot", or the way the filename is
construced? "/boot" in my fsload example above was a quote from the
boot.scr I use, not something U-Boot provides, so I'd expect distros
could customize it to their needs. If you mean the filename - I'd
certainly advocate enforcing that U-Boot and the kernel board names
and DT filenames be in sync.

> 
>> (This general discussion might usefully happen on the
>> cross-distro mailing list too?)
> 
> Yes.  Where? :)

cross-distro at lists.linaro.org