Standardize on run-time board ID variables
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest1 of 2 patches 0 repliesNew
1 of 2 patches is in this archive. The cover letter announces 2.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 2/2 | am335x_evm: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support | +0 | 1 reply |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH 0/2] Standardize on run-time board ID variables
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_CONFIGto the README which says when set we haveboard_nameandboard_revset at run-time. Then for am335x[1]With
CONFIG_ENV_VARS_UBOOT_CONFIGset, 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}.dtbQuoted 6 lines
Now,
CONFIG_ENV_VARS_UBOOT_CONFIGsets $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_CONFIGset $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 8 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 5 lines
Quoted 3 lines
(This general discussion might usefully happen on the cross-distro mailing list too?)
Yes. Where? :)
cross-distro at lists.linaro.org