Hi Stephen,
On Mon, Oct 29, 2012 at 1:13 PM, Tom Rini trini@ti.com wrote:
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.
Same here.
-Joe