Standardize on run-time board ID variables

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.

arch/arm/cpu/armv7/am33xx/board.c +2 -0

 
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+	char safe_string[HDR_NAME_LEN + 1];

Quoted 10 lines · Tom Rini

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.

arch/arm/cpu/armv7/am33xx/board.c +1 -0

 
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG +	char 

Quoted 7 lines

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.

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.

Quoted 10 lines · Tom Rini

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

Quoted 21 lines · Stephen Warren

Quoted 11 lines · Tom Rini

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

Quoted 6 lines

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...

Quoted 2 lines

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"

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 3 lines

(This general discussion might usefully happen on the cross-distro mailing list too?)

Yes. Where? :)

Quoted 29 lines · Tom Rini

Quoted 21 lines · Stephen Warren

Quoted 11 lines · Tom Rini

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

Quoted 6 lines

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

Quoted 2 lines

This works assuming that board maps to the device tree name. A bit more below...

True. I've made sure of that for Tegra.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 1 line · Stephen Warren

On 10/24/2012 12:41 PM, Tom Rini wrote:

Quoted 19 lines

Quoted 4 lines

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:

Quoted 1 line

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.

Quoted 7 lines

... 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:

Quoted 4 lines

"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.

Quoted 38 lines · Stephen Warren

Quoted 29 lines · Tom Rini

Quoted 21 lines · Stephen Warren

Quoted 11 lines · Tom Rini

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

Quoted 6 lines

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

Quoted 2 lines

This works assuming that board maps to the device tree name. A bit more below...

True. I've made sure of that for Tegra.

Quoted 3 lines

Quoted 2 lines

To that end, can we make CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG set $board instead of $board_name?

Quoted 5 lines

Quoted 2 lines

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]

Quoted 8 lines

Quoted 3 lines

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"

Quoted 8 lines

... 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.

Quoted 11 lines

... 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.

Quoted 9 lines

Quoted 2 lines

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 at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Hi Tom,

Quoted 45 lines · Tom Rini

Quoted 43 lines · Stephen Warren

Quoted 29 lines · Tom Rini

Quoted 21 lines · Stephen Warren

Quoted 11 lines · Tom Rini

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

Quoted 6 lines

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

Quoted 2 lines

This works assuming that board maps to the device tree name. A bit more below...

True. I've made sure of that for Tegra.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 1 line

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.

Quoted 48 lines · Joe Hershberger

Hi Tom,

Quoted 45 lines · Tom Rini

Quoted 43 lines · Stephen Warren

Quoted 29 lines · Tom Rini

Quoted 21 lines · Stephen Warren

Quoted 11 lines · Tom Rini

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

Quoted 6 lines

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

Quoted 2 lines

This works assuming that board maps to the device tree name. A bit more below...

True. I've made sure of that for Tegra.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 7 lines

Quoted 1 line

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.

Quoted 57 lines · Stephen Warren

Quoted 55 lines · Joe Hershberger

Hi Tom,

Quoted 39 lines · Tom Rini

Quoted 38 lines · Stephen Warren

Quoted 29 lines · Tom Rini

Quoted 21 lines · Stephen Warren

Quoted 11 lines · Tom Rini

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

Quoted 6 lines

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

Quoted 2 lines

This works assuming that board maps to the device tree name. A bit more below...

True. I've made sure of that for Tegra.

Quoted 3 lines

Quoted 2 lines

To that end, can we make CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG set $board instead of $board_name?

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

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.

Quoted 6 lines

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.

Quoted 29 lines · Tom Rini

Quoted 21 lines · Stephen Warren

Quoted 11 lines · Tom Rini

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

Quoted 6 lines

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

Quoted 2 lines

This works assuming that board maps to the device tree name. A bit more below...

True. I've made sure of that for Tegra.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 8 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 1 line

Quoted 4 lines

Quoted 2 lines

(This general discussion might usefully happen on the cross-distro mailing list too?)

Yes. Where? :)

cross-distro at lists.linaro.org
______________________________________

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.