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

[Stephen Warren <swarren@wwwdotorg.org>]

On 10/26/2012 01:45 AM, Joe Hershberger wrote:
> Hi Tom,
> 
> On Wed, Oct 24, 2012 at 2:32 PM, Tom Rini <trini@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.

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.