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. > [snip] >> > 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 > > I hope that a longer term thing would be trying to share more of the > bootcmd related magic between all our parts. How we deal with this on > TI stuff is that in uEnv.txt if we find the file, we load the file into > the environment (so fdtfile=mylocalstuff.dtb will overwrite the default) > and if uenvcmd is set execute that command. > >> >> ... 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. > > It's not an imutable variable, so you could change it, if you do that > early in the process. > >> > 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. > > Agreed all around. fdtfile should be the basename(1) of the file and > let the rest be done elsewhere. And it should be set to the expect > default coming out of the kernel or wherever the master device tree repo > is. > > -- > Tom > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot