[U-Boot] [PATCH V2 3/4] env_mmc: allow negative CONFIG_ENV_OFFSET

[Peter Korsgaard]

>>>>> "S" == Stephen Warren <swarren at wwwdotorg.org> writes:

 S> From: Stephen Warren <swarren at nvidia.com>
 S> A negative value of CONFIG_ENV_OFFSET is treated as a backwards offset
 S> from the end of the eMMC device/partition, rather than a forwards offset
 S> from the start.

 S> This is useful when a single board may be stuffed with different eMMC
 S> devices, each of which has a different capacity, and you always want the
 S> environment to be stored at the very end of the device (or eMMC boot
 S> partition for example).

 S> One example of this case is NVIDIA's Ventana reference board.

 S> Signed-off-by: Stephen Warren <swarren at nvidia.com>
 S> ---
 S> v2: Also update README to describe the change.
 S> ---
 S>  README           |   11 +++++++++++
 S>  common/env_mmc.c |   12 ++++++++++--
 S>  2 files changed, 21 insertions(+), 2 deletions(-)

 S> diff --git a/README b/README
 S> index b9936ca..4335730 100644
 S> --- a/README
 S> +++ b/README
 S> @@ -3627,6 +3627,14 @@ but it can not erase, write this NOR flash by SRIO or PCIE interface.
 S>  	  These two #defines specify the offset and size of the environment
 S>  	  area within the specified MMC device.
 
 S> +	  If offset is positive (the usual case), it is treated as relative to
 S> +	  the start of the MMC partition. If offset is negative, it is treated
 S> +	  as relative to the end of the MMC partition. This can be useful if
 S> +	  your board may be fitted with different MMC devices, which have
 S> +	  different sizes for the MMC partitions, and you always want the
 S> +	  environment placed at the very end of the partition, to leave the
 S> +	  maximum possible space before it, to store other data.
 S> +
 S>  	  These two values must be aligned to an MMC sector boundary.
 
 S>  	- CONFIG_ENV_OFFSET_REDUND (optional):
 S> @@ -3636,6 +3644,9 @@ but it can not erase, write this NOR flash by SRIO or PCIE interface.
 S>  	  valid backup copy in case the other copy is corrupted, e.g. due
 S>  	  to a power failure during a "saveenv" operation.
 
 S> +	  This value may also be positive or negative; this is handled in the
 S> +	  same way as CONFIG_ENV_OFFSET.
 S> +
 S>  	  This value must also be aligned to an MMC sector boundary.
 
 S>  	- CONFIG_ENV_SIZE_REDUND (optional):
 S> diff --git a/common/env_mmc.c b/common/env_mmc.c
 S> index 9ca098f..5d3a769 100644
 S> --- a/common/env_mmc.c
 S> +++ b/common/env_mmc.c
 S> @@ -53,11 +53,19 @@ DECLARE_GLOBAL_DATA_PTR;
 
 S>  __weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr)
 S>  {
 S> -	*env_addr = CONFIG_ENV_OFFSET;
 S> +	s64 offset;
 S> +
 S> +	offset = CONFIG_ENV_OFFSET;
 S>  #ifdef CONFIG_ENV_OFFSET_REDUND
 S>  	if (copy)
 S> -		*env_addr = CONFIG_ENV_OFFSET_REDUND;
 S> +		offset = CONFIG_ENV_OFFSET_REDUND;
 S>  #endif
 S> +
 S> +	if (offset < 0)
 S> +		offset += mmc->capacity;
 S> +
 S> +	*env_addr = offset;
 S> +

This is quite a mix of data types (u32/s64/u64). Not directly related to
this patch, but it would imho be nicer to let env_mmc work directly with
block numbers instead of bytes, that way stuff would also work with >4GB
MMCs.

-- 
Bye, Peter Korsgaard