[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables
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] set that and CONFIG_BOARD_LATE_INIT which will set the variables and add a command, findfdt to compare and set fdtfile correctly. Further distro-specific logic can then augment this to figure out what filesystem / partition to read from.
[1]: Yes, this will need re-working after merging Peter K's patches to allow for non-TI boards.
This option is intended to be set by boards which will set the board_name and board_rev environment variables. These are to be used when the U-Boot binary can support more than one board type at run-time and the user needs an easy way (for example for scripting to determine what device tree to load) to determine what board they are on.
Signed-off-by: Tom Rini trini@ti.com --- README | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/README b/README index 69da2b8..430fc16 100644 --- a/README +++ b/README @@ -2309,6 +2309,12 @@ CBFS (Coreboot Filesystem) support - CONFIG_SYS_VENDOR - CONFIG_SYS_SOC
+ CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG + + Define this in order to add variables describing certain + run-time determined information about the hardware to the + environment. These will be named board_name, board_rev. + - DataFlash Support: CONFIG_HAS_DATAFLASH
We add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG, CONFIG_BOARD_LATE_INIT to set the variables and then fdtfile and findfdt to make us of this. It is now possible to do 'run findfdt' to have fdtfile be set to the value of the dtb file to load for the board we are running on.
Signed-off-by: Tom Rini trini@ti.com --- arch/arm/cpu/armv7/am33xx/board.c | 20 ++++++++++++++++++++ include/configs/am335x_evm.h | 10 ++++++++++ 2 files changed, 30 insertions(+)
diff --git a/arch/arm/cpu/armv7/am33xx/board.c b/arch/arm/cpu/armv7/am33xx/board.c index 978b184..a138848 100644 --- a/arch/arm/cpu/armv7/am33xx/board.c +++ b/arch/arm/cpu/armv7/am33xx/board.c @@ -223,6 +223,26 @@ int board_init(void) return 0; }
+#ifdef CONFIG_BOARD_LATE_INIT +int board_late_init(void) +{ +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG + char safe_string[HDR_NAME_LEN + 1]; + + /* Now set variables based on the header. */ + strncpy(safe_string, (char *)header.name, sizeof(header.name)); + safe_string[sizeof(header.name)] = 0; + setenv("board_name", safe_string); + + strncpy(safe_string, (char *)header.version, sizeof(header.version)); + safe_string[sizeof(header.version)] = 0; + setenv("board_rev", safe_string); +#endif + + return 0; +} +#endif + #ifdef CONFIG_DRIVER_TI_CPSW static void cpsw_control(int enabled) { diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 339d4bd..3adf548 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -29,6 +29,7 @@ #define CONFIG_SYS_LONGHELP /* undef to save memory */ #define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ #define CONFIG_SYS_PROMPT "U-Boot# " +#define CONFIG_BOARD_LATE_INIT #define CONFIG_SYS_NO_FLASH #define MACH_TYPE_TIAM335EVM 3589 /* Until the next sync */ #define CONFIG_MACH_TYPE MACH_TYPE_TIAM335EVM @@ -46,11 +47,13 @@
/* set to negative value for no autoboot */ #define CONFIG_BOOTDELAY 1 +#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG #define CONFIG_EXTRA_ENV_SETTINGS \ "loadaddr=0x80200000\0" \ "fdtaddr=0x80F80000\0" \ "rdaddr=0x81000000\0" \ "bootfile=/boot/uImage\0" \ + "fdtfile=\0" \ "console=ttyO0,115200n8\0" \ "optargs=\0" \ "mmcdev=0\0" \ @@ -79,6 +82,13 @@ "ramboot=echo Booting from ramdisk ...; " \ "run ramargs; " \ "bootm ${loadaddr}\0" \ + "findfdt="\ + "if test $board_name = A335BONE; then " \ + "setenv fdtfile am335x-bone.dtb; fi; " \ + "if test $board_name = A33515BB; then " \ + "setenv fdtfile am335x-evm.dtb; fi; " \ + "if test $board_name = A335X_SK; then " \ + "setenv fdtfile am335x-evmsk.dtb; fi\0" \
#define CONFIG_BOOTCOMMAND \ "if mmc rescan ${mmcdev}; then " \
On 10/24/2012 11:28 AM, Tom Rini wrote:
We add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG, CONFIG_BOARD_LATE_INIT to set the variables and then fdtfile and findfdt to make us of this. It is now possible to do 'run findfdt' to have fdtfile be set to the value of the dtb file to load for the board we are running on.
diff --git a/arch/arm/cpu/armv7/am33xx/board.c b/arch/arm/cpu/armv7/am33xx/board.c
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
- char safe_string[HDR_NAME_LEN + 1];
- /* Now set variables based on the header. */
- strncpy(safe_string, (char *)header.name, sizeof(header.name));
- safe_string[sizeof(header.name)] = 0;
- setenv("board_name", safe_string);
- strncpy(safe_string, (char *)header.version, sizeof(header.version));
- safe_string[sizeof(header.version)] = 0;
- setenv("board_rev", safe_string);
+#endif
By the way, is there any way to flag these variables as not being saved in the environment by saveenv? With the code above, the values will get over-written every time, so it's not such a big deal; the only issue is that the value needlessly gets saved into flash or uEnv.txt.
But what about a runtime-calculated variable that is only sometimes set? I suppose the answer there is to explicitly clear it if you aren't setting it.
Or what about if the environment gets saved to uEnv.txt on an SD card which gets moved to a compatible but different board or board revision, running an older U-Boot that doesn't have this patch; then, the values stick around even though they're stale.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/24/12 12:21, Stephen Warren wrote:
On 10/24/2012 11:28 AM, Tom Rini wrote:
We add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG, CONFIG_BOARD_LATE_INIT to set the variables and then fdtfile and findfdt to make us of this. It is now possible to do 'run findfdt' to have fdtfile be set to the value of the dtb file to load for the board we are running on.
diff --git a/arch/arm/cpu/armv7/am33xx/board.c b/arch/arm/cpu/armv7/am33xx/board.c
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG + char safe_string[HDR_NAME_LEN + 1]; + + /* Now set variables based on the header. */ + strncpy(safe_string, (char *)header.name, sizeof(header.name)); + safe_string[sizeof(header.name)] = 0; + setenv("board_name", safe_string); + + strncpy(safe_string, (char *)header.version, sizeof(header.version)); + safe_string[sizeof(header.version)] = 0; + setenv("board_rev", safe_string); +#endif
By the way, is there any way to flag these variables as not being saved in the environment by saveenv? With the code above, the values will get over-written every time, so it's not such a big deal; the only issue is that the value needlessly gets saved into flash or uEnv.txt.
But what about a runtime-calculated variable that is only sometimes set? I suppose the answer there is to explicitly clear it if you aren't setting it.
Joe? Am I thinking right that your env work leads us down the path of being able to do this?
Or what about if the environment gets saved to uEnv.txt on an SD card which gets moved to a compatible but different board or board revision, running an older U-Boot that doesn't have this patch; then, the values stick around even though they're stale.
Yes, there's potential problems, but I think we can work around it or live with it. And FYI, uEnv.txt is (more or less) an un-mkimage'd boot.scr file :)
- -- Tom
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
To that end, can we make CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG set $board instead of $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
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?
(This general discussion might usefully happen on the cross-distro mailing list too?)
set that and CONFIG_BOARD_LATE_INIT which will set the variables and add a command, findfdt to compare and set fdtfile correctly. Further distro-specific logic can then augment this to figure out what filesystem / partition to read from.
[1]: Yes, this will need re-working after merging Peter K's patches to allow for non-TI boards.
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? :)
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-distro@lists.linaro.org
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?
[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.
On 10/24/2012 01: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:
...
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.
Ah, so uEnv.txt is some user-managed file along the same lines as boot.scr. I had thought it was the file behind CONFIG_ENV_IS_IN_FAT.
... 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.
Sure. My point was that would end up duplicating the method to construct the value in two places; one in includes/configs/xxx.h for the default, and one in code in U-Boot for the case where we override the default to include some version number. That doesn't seem ideal.
Hi Tom,
On Wed, Oct 24, 2012 at 2:32 PM, Tom Rini trini@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
On 10/26/2012 01:45 AM, Joe Hershberger wrote:
Hi Tom,
On Wed, Oct 24, 2012 at 2:32 PM, Tom Rini trini@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.
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.
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 trini@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.
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.
Hi Stephen,
On Mon, Oct 29, 2012 at 1:13 PM, Tom Rini trini@ti.com wrote:
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 trini@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.
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.
Same here.
-Joe
Hi,
On Wed, Oct 24, 2012 at 12:05 PM, Stephen Warren swarren@wwwdotorg.org 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.
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.
I did create a patch to make environment variables recursive. It is a right pain to have to 'setenv' them to get them to work in this way. However I wasn't really sure how to control it. Can we just move to recursive environment variable evaluation, or would that break things? Perhaps a CONFIG_ option?
Re this discussion, if the board itself can detect its revision then great. If it can't, then presumably the factory process writes the correct fdt to the board during manufacture.
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-distro@lists.linaro.org ______________________________________
Regards, Simon
On Wed, Oct 24, 2012 at 10:28:15AM -0700, Tom Rini wrote:
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] set that and CONFIG_BOARD_LATE_INIT which will set the variables and add a command, findfdt to compare and set fdtfile correctly. Further distro-specific logic can then augment this to figure out what filesystem / partition to read from.
[1]: Yes, this will need re-working after merging Peter K's patches to allow for non-TI boards.
Applied to u-boot/master (with a small change in 2/2 for Stephen's patch), thanks!
participants (4)
-
Joe Hershberger -
Simon Glass -
Stephen Warren -
Tom Rini