From patchwork Wed May 22 19:21:10 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Warren X-Patchwork-Id: 245699 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from theia.denx.de (theia.denx.de [85.214.87.163]) by ozlabs.org (Postfix) with ESMTP id 444B12C007E for ; Thu, 23 May 2013 05:22:02 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 8417A4A03A; Wed, 22 May 2013 21:21:50 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at theia.denx.de Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRchewUxT81N; Wed, 22 May 2013 21:21:50 +0200 (CEST) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 9A4A04A040; Wed, 22 May 2013 21:21:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 45F494A029 for ; Wed, 22 May 2013 21:21:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at theia.denx.de Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppzFtSB8CCtk for ; Wed, 22 May 2013 21:21:31 +0200 (CEST) X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 (only DNSBL check requested) Received: from avon.wwwdotorg.org (avon.wwwdotorg.org [70.85.31.133]) by theia.denx.de (Postfix) with ESMTPS id 7BC4B4A025 for ; Wed, 22 May 2013 21:21:22 +0200 (CEST) Received: from severn.wwwdotorg.org (unknown [192.168.65.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by avon.wwwdotorg.org (Postfix) with ESMTPS id 03125644D; Wed, 22 May 2013 13:27:28 -0600 (MDT) Received: from swarren-lx1.nvidia.com (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by severn.wwwdotorg.org (Postfix) with ESMTPSA id B809DE4106; Wed, 22 May 2013 13:21:19 -0600 (MDT) From: Stephen Warren To: u-boot@lists.denx.de, Tom Rini Date: Wed, 22 May 2013 13:21:10 -0600 Message-Id: <1369250471-9851-3-git-send-email-swarren@wwwdotorg.org> X-Mailer: git-send-email 1.7.10.4 In-Reply-To: <1369250471-9851-1-git-send-email-swarren@wwwdotorg.org> References: <1369250471-9851-1-git-send-email-swarren@wwwdotorg.org> X-NVConfidentiality: public X-Virus-Scanned: clamav-milter 0.97.7 at avon.wwwdotorg.org X-Virus-Status: Clean Cc: Stephen Warren , Andy Fleming , Tom Warren Subject: [U-Boot] [PATCH V2 3/4] env_mmc: allow negative CONFIG_ENV_OFFSET X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: u-boot-bounces@lists.denx.de Errors-To: u-boot-bounces@lists.denx.de From: Stephen Warren A negative value of CONFIG_ENV_OFFSET is treated as a backwards offset from the end of the eMMC device/partition, rather than a forwards offset from the start. This is useful when a single board may be stuffed with different eMMC devices, each of which has a different capacity, and you always want the environment to be stored at the very end of the device (or eMMC boot partition for example). One example of this case is NVIDIA's Ventana reference board. Signed-off-by: Stephen Warren --- v2: Also update README to describe the change. --- README | 11 +++++++++++ common/env_mmc.c | 12 ++++++++++-- 2 files changed, 21 insertions(+), 2 deletions(-) diff --git a/README b/README index b9936ca..4335730 100644 --- a/README +++ b/README @@ -3627,6 +3627,14 @@ but it can not erase, write this NOR flash by SRIO or PCIE interface. These two #defines specify the offset and size of the environment area within the specified MMC device. + If offset is positive (the usual case), it is treated as relative to + the start of the MMC partition. If offset is negative, it is treated + as relative to the end of the MMC partition. This can be useful if + your board may be fitted with different MMC devices, which have + different sizes for the MMC partitions, and you always want the + environment placed at the very end of the partition, to leave the + maximum possible space before it, to store other data. + These two values must be aligned to an MMC sector boundary. - CONFIG_ENV_OFFSET_REDUND (optional): @@ -3636,6 +3644,9 @@ but it can not erase, write this NOR flash by SRIO or PCIE interface. valid backup copy in case the other copy is corrupted, e.g. due to a power failure during a "saveenv" operation. + This value may also be positive or negative; this is handled in the + same way as CONFIG_ENV_OFFSET. + This value must also be aligned to an MMC sector boundary. - CONFIG_ENV_SIZE_REDUND (optional): diff --git a/common/env_mmc.c b/common/env_mmc.c index 9ca098f..5d3a769 100644 --- a/common/env_mmc.c +++ b/common/env_mmc.c @@ -53,11 +53,19 @@ DECLARE_GLOBAL_DATA_PTR; __weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr) { - *env_addr = CONFIG_ENV_OFFSET; + s64 offset; + + offset = CONFIG_ENV_OFFSET; #ifdef CONFIG_ENV_OFFSET_REDUND if (copy) - *env_addr = CONFIG_ENV_OFFSET_REDUND; + offset = CONFIG_ENV_OFFSET_REDUND; #endif + + if (offset < 0) + offset += mmc->capacity; + + *env_addr = offset; + return 0; }