Skip to content

Standardize on run-time board ID variables

Stephen Warren u-boot 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest0 of 2 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 2 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [U-Boot] [PATCH 0/2] Standardize on run-time board ID variables
Quoted 48 lines · Joe Hershberger

Hi Tom,

Quoted 45 lines · Tom Rini
Quoted 43 lines · Stephen Warren
Quoted 29 lines · Tom Rini
Quoted 21 lines · Stephen Warren
Quoted 11 lines · Tom Rini

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

Quoted 6 lines

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

Quoted 2 lines

This works assuming that board maps to the device tree name. A bit more below...

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

Quoted 5 lines
Quoted 2 lines

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.

Quoted 7 lines
Quoted 1 line

Joe?

It think in the use-case that you are talking about (multiple boards, one binary) the board from the build of the binary could still be useful to know in addition to the run-time-determined board name and rev. I think it would also be useful to have the "target" available in the env for the same reason. Tom and I also discussed this on IRC.

OK, so in that case I guess CONFIG_ENV_VARS_UBOOT_CONFIG should set both board and board_name, so that both variables always exist for use by scripts, so scripts don't have to contain endless conditionals. For the multiple-boards-one-binary case, board_name can always be overridden at run-time. If everyone agrees, I can send a patch to add that variable to CONFIG_ENV_VARS_UBOOT_CONFIG.