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

[Tom Rini <trini@ti.com>]

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

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

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

> 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.  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.  Also
not hard-coding in the path makes it easier for whichever distro to fill
in that logic.

> (This general discussion might usefully happen on the cross-distro
> mailing list too?)

Yes.  Where? :)

-- 
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/9d0f0cd1/attachment.pgp>