Hi Stephen,
On Mon, Oct 29, 2012 at 1:13 PM, Tom Rini <tr...@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 <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.
>
> Works for me.
Same here.
-Joe
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
