The U-boot binary may trip over its actual allocated size in the storage. In such a case, the environment will not be readable anymore (because corrupted when the new image was flashed), and any attempt at using saveenv to reconstruct the environment will result in a corrupted U-boot binary.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com --- arch/arm/dts/sunxi-u-boot.dtsi | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi index 5adfd9bca2ec..b44660e8d37e 100644 --- a/arch/arm/dts/sunxi-u-boot.dtsi +++ b/arch/arm/dts/sunxi-u-boot.dtsi @@ -1,5 +1,13 @@ #include <config.h>
+/* + * This is the maximum size the U-boot binary can be, which is + * basically the start of the environment, minus the (padded) size of + * the SPL), minus the offset at which the generated file is supposed + * to be flashed in the MMC. + */ +#define UBOOT_MAX_SIZE (CONFIG_ENV_OFFSET - CONFIG_SPL_PAD_TO - (8 << 10)) + / { binman { filename = "u-boot-sunxi-with-spl.bin"; @@ -8,6 +16,9 @@ filename = "spl/sunxi-spl.bin"; }; u-boot-img { +#ifdef CONFIG_MMC + size = <UBOOT_MAX_SIZE>; +#endif pos = <CONFIG_SPL_PAD_TO>; }; };