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

[Joe Hershberger]

Hi Tom,

On Wed, Oct 24, 2012 at 2:32 PM, Tom Rini <trini at ti.com> wrote:
> 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?

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.

> [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
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>