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? :)