From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 24 Oct 2012 11:41:31 -0700 Subject: [U-Boot] [PATCH 0/2] Standardize on run-time board ID variables In-Reply-To: <50882A6E.8060108@wwwdotorg.org> References: <1351099697-8786-1-git-send-email-trini@ti.com> <50882A6E.8060108@wwwdotorg.org> Message-ID: <20121024184131.GB8148@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 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... > 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" > Adding $board_rev sounds like a very good idea; the filename in the > above command could be modified to: > > ${soc}-${board}${boardrev}.dtb Indeed, I know we'll need to do this in the future for one of the boards in this family. > Or, do you think it'd be better for boot.scr to always reference > $fdtfile, and so modify Tegra's default environment to derive $fdtfile > from $soc, $board, $boardrev? Or uEnv.txt, but yes, fdtfile seems to be the standard variable name for the device tree to use. Doing something to derive this also means that custom development can be a bit easier too since you can just set fdtfile directly and work out the logic for auto-detection later. Also not hard-coding in the path makes it easier for whichever distro to fill in that logic. > (This general discussion might usefully happen on the cross-distro > mailing list too?) Yes. Where? :) -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: