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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
