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

[Tom Rini]

On Mon, Oct 29, 2012 at 09:15:41AM -0600, Stephen Warren wrote:
> On 10/26/2012 01:45 AM, Joe Hershberger wrote:
> > 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.
> 
> 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.

Works for me.

-- 
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/20121029/973a362f/attachment.pgp>