>>>>> "S" == Stephen Warren <swar...@wwwdotorg.org> writes:

 S> From: Stephen Warren <swar...@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 <swar...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to