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

[Stephen Warren <swarren@wwwdotorg.org>]

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.