summaryrefslogtreecommitdiff
path: root/post
diff options
context:
space:
mode:
authorStephen Warren <swarren@nvidia.com>2016-08-08 19:56:35 (GMT)
committerTom Warren <twarren@nvidia.com>2016-08-15 17:26:14 (GMT)
commit06264a79b4ed8155e8746dba10b707d588ca6e9c (patch)
treed2dd2d4490b7b5eca6a91ee0082f346560638865 /post
parent9889862545a0de2e6cf0fdf6171412cafc46c218 (diff)
downloadu-boot-fsl-qoriq-06264a79b4ed8155e8746dba10b707d588ca6e9c.tar.xz
ARM: tegra: fix trimslice environment location
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> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
Diffstat (limited to 'post')
0 files changed, 0 insertions, 0 deletions