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

[Tom Rini]

On Wed, Oct 24, 2012 at 01:05:16PM -0600, Stephen Warren wrote:
> 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.

Joe?

[snip]
> > 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

I hope that a longer term thing would be trying to share more of the
bootcmd related magic between all our parts.  How we deal with this on
TI stuff is that in uEnv.txt if we find the file, we load the file into
the environment (so fdtfile=mylocalstuff.dtb will overwrite the default)
and if uenvcmd is set execute that command.

> 
> ... 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.

It's not an imutable variable, so you could change it, if you do that
early in the process.

> > 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.

Agreed all around.  fdtfile should be the basename(1) of the file and
let the rest be done elsewhere.  And it should be set to the expect
default coming out of the kernel or wherever the master device tree repo
is.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121024/1d86685a/attachment.pgp>