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