From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 29 Oct 2012 11:13:39 -0700 Subject: [U-Boot] [PATCH 0/2] Standardize on run-time board ID variables In-Reply-To: <508E9D9D.4090801@wwwdotorg.org> References: <1351099697-8786-1-git-send-email-trini@ti.com> <50882A6E.8060108@wwwdotorg.org> <20121024184131.GB8148@bill-the-cat> <50883BEC.3040505@wwwdotorg.org> <20121024193210.GC8148@bill-the-cat> <508E9D9D.4090801@wwwdotorg.org> Message-ID: <20121029181339.GF15691@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: