Hi,
On 19/10/17 15:04, Maxime Ripard wrote:
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.
Merci beaucoup for that v2 series!
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))
Just bikeshedding: Can't we use: (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR << 9) for the last two expressions?
But that's just a nit, so:
Reviewed-by: Andre Przywara andre.przywara@arm.com
Cheers, Andre.
/ { 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>; }; };