diff mbox

[U-Boot] ARM: tegra: fix trimslice environment location

Message ID 20160808195635.17583-1-swarren@wwwdotorg.org
State Accepted
Commit 06264a79b4ed8155e8746dba10b707d588ca6e9c
Delegated to: Tom Warren
Headers show

Commit Message

Stephen Warren Aug. 8, 2016, 7:56 p.m. UTC 
From: Stephen Warren <swarren@nvidia.com>

Trimslice currently stores its environment at 512KiB into the SPI flash
chip. The U-Boot binary has grown such that the size of the boot image
(which includes the Tegra BCT, padding, and the U-Boot binary) is slightly
larger than 512K now. Consequently, writing the boot image to flash
corrupts the saved environment, and equally, writing to or erasing the
environment will corrupt the bootloader, which in turn will cause the
Tegra boot ROM to enter recovery mode during boot, making it look as if
the system is non-operational. Note that tegra-uboot-flasher writes to
the environment during the flashing process.

Solve this by moving the environment as high as possible in flash. This
will allow the U-Boot binary to roughly double in size before this problem
is hit again, at which point there's nothing we can do anyway since the
binary won't fit into flash.

99% of other Tegra boards store the environment in eMMC and use a negative
value for CONFIG_ENV_OFFSET, which already automatically places the
environment as near the end of boot flash as possible. The 1 remaining
board hard-codes CONFIG_ENV_OFFSET to 2MiB, which allows for plenty more
bloat.

Reported-by: Stephen L Arnold <nerdboy@gentoo.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 include/configs/trimslice.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Simon Glass Aug. 8, 2016, 9:44 p.m. UTC | #1 
On 8 August 2016 at 13:56, Stephen Warren <swarren@wwwdotorg.org> wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Trimslice currently stores its environment at 512KiB into the SPI flash
> chip. The U-Boot binary has grown such that the size of the boot image
> (which includes the Tegra BCT, padding, and the U-Boot binary) is slightly
> larger than 512K now. Consequently, writing the boot image to flash
> corrupts the saved environment, and equally, writing to or erasing the
> environment will corrupt the bootloader, which in turn will cause the
> Tegra boot ROM to enter recovery mode during boot, making it look as if
> the system is non-operational. Note that tegra-uboot-flasher writes to
> the environment during the flashing process.
>
> Solve this by moving the environment as high as possible in flash. This
> will allow the U-Boot binary to roughly double in size before this problem
> is hit again, at which point there's nothing we can do anyway since the
> binary won't fit into flash.
>
> 99% of other Tegra boards store the environment in eMMC and use a negative
> value for CONFIG_ENV_OFFSET, which already automatically places the
> environment as near the end of boot flash as possible. The 1 remaining
> board hard-codes CONFIG_ENV_OFFSET to 2MiB, which allows for plenty more
> bloat.
>
> Reported-by: Stephen L Arnold <nerdboy@gentoo.org>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
>  include/configs/trimslice.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass <sjg@chromium.org>
diff mbox

Patch

diff --git a/include/configs/trimslice.h b/include/configs/trimslice.h
index b761640b8fb8..9d49f6380352 100644
--- a/include/configs/trimslice.h
+++ b/include/configs/trimslice.h
@@ -37,7 +37,8 @@ 
 #define CONFIG_ENV_SPI_MAX_HZ		48000000
 #define CONFIG_ENV_SPI_MODE		SPI_MODE_0
 #define CONFIG_ENV_SECT_SIZE		CONFIG_ENV_SIZE
-#define CONFIG_ENV_OFFSET		(512 * 1024)
+/* 1MiB flash, environment located as high as possible */
+#define CONFIG_ENV_OFFSET		(SZ_1M - CONFIG_ENV_SIZE)
 
 /* USB Host support */
 #define CONFIG_USB_EHCI