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. >> 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. Ah, I do see quite a few U-Boot config headers defining that. > 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. Hmm. So I can't really put the following into Tegra's default environment: "fdtfile=${soc}-${board}${boardrev}.dtb" ... since that would require any use of "${fdtfile}" in a command to first expand fdtfile itself, then expand it a second time to pick up the actual soc/board/... values, and that's not how the shell works. That implies that e.g. Tegra's scriptboot (seed BOOTCMDS_COMMON in include/configs/tegra-common-post.h) would need to do something like: setenv fdtfile ${soc}-${board}${boardrev}.dtb ... before executing the loaded boot.scr. But then, how would it know whether to do that, or whether the user wanted to override the fdtfile value? In theory, I could do the following in Tegra's default environment: "fdtfile=" CONFIG_SYS_SOC "-" CONFIG_SYS_BOARD" ".dtb" But then that wouldn't allow for the fdtfile value to vary at run-time based on $boardrev. > Also not hard-coding in the path makes it easier for whichever > distro to fill in that logic. By the path, do you mean "/boot", or the way the filename is construced? "/boot" in my fsload example above was a quote from the boot.scr I use, not something U-Boot provides, so I'd expect distros could customize it to their needs. If you mean the filename - I'd certainly advocate enforcing that U-Boot and the kernel board names and DT filenames be in sync. > >> (This general discussion might usefully happen on the >> cross-distro mailing list too?) > > Yes. Where? :) cross-dis...@lists.linaro.org _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot