On 10/26/2012 01:45 AM, Joe Hershberger wrote: > Hi Tom, > > On Wed, Oct 24, 2012 at 2:32 PM, Tom Rini <tr...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot