[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

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

-- 
Tom

[U-Boot] [PATCH 1/2] README: Document CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG

[Tom Rini]

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

[U-Boot] [PATCH 2/2] am335x_evm: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support

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

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 " \
-- 
1.7.9.5

[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

[Stephen Warren]

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.

[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

[Tom Rini]

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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121024/9d0f0cd1/attachment.pgp>

[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

[Stephen Warren]

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 at lists.linaro.org

[U-Boot] [PATCH 2/2] am335x_evm: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support

[Stephen Warren]

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.

[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121024/1d86685a/attachment.pgp>

[U-Boot] [PATCH 2/2] am335x_evm: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support

[Tom Rini]

-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQiFYXAAoJENk4IS6UOR1WyIMP/iGYC6j001RpBgV3zn3AgAvG
5h+2f9C/LgSrEiuH2FarginkbOqyRR1fn/GYbwK/hK3+UMyPU7bY2m++VJ1RobQ8
j8A4HGHxBh/afrpkly/TtgXjJeK5NPxB7AH0mu0UBsBAFg7b64dVjVc1ZUuwkqBO
zddoFhLOvpUAuBOPiVZLBUREdgGs23pG7HO7yfyEbdUsZv6U09zlY/FQR06JgANu
2AjUZ932oH54448qmXdX2ePdX8zpWeXmsHwEDWX8kgJbGiUSe2oQbBc/u27/g1KS
LiJKfh9YaJV8EYkeF+i/CDwWNI81ykuHsSOem/AsXNhk3/r2Ua54WB3oUXHEZji1
h6J+3wxF1pS/9r5/FzHsKaeR5GCGXDDEDONlDuJb4PB0ZCuDfzGmsAOBxtA/0GiU
U6S3Cxwk7ajmXdtbVpZ+kzIemsqHbJd2wXKR2UDPa7fNqiTDa0XLfvWuwx6PdAmJ
aZoz344padFBdv/qVmF8657pUMaPW8A4YuTFmf1sj2QD3BtA5ATbMKD2Wu5RXbjY
feb/BxbZihfnCSA3RoyDCZC7Bh/OHz9v2lK6aSBQR1Jh+4ozmn6njla5iNVKcLuX
SbRyjJk1kmaAOUcdhDV6py9I+Fs8CmGFynBSCSkY+8nIiCzVl8587z8bcAOp6lHn
Fq0Kcoybbkp2lhyqAUG0
=sttt
-----END PGP SIGNATURE-----

[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

[Stephen Warren]

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.

[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

[Simon Glass]

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 at lists.linaro.org
> ______________________________________

Regards,
Simon

[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

[Joe Hershberger]

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

[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

[Stephen Warren]

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.

[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121029/973a362f/attachment.pgp>

[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

[Joe Hershberger]

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

[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121104/c3fe3b55/attachment.pgp>