[U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img

[Alexey Brodkin <Alexey.Brodkin@synopsys.com>]

Hi Otavio,

On Sat, 2016-07-09 at 10:02 -0300, Otavio Salvador wrote:
> On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkin
> <Alexey.Brodkin@synopsys.com> wrote:
> > 
> > Recently I started to notice that u-boot.img built for Wandboard
> > by some toolchains becomes so large that it basically overlaps with
> > U-Boot environment area on SD-card.
> > 
> > According to
> > http://wiki.wandboard.org/index.php/Boot-process#sdcard_boot_data_layout
> > Wandboard's SD-card layout is as follows:
> > ------------------------------>8---------------------------
> > ==========================================================
> > 1. 0x00000000???????????Reserved For MBR
> > 2. 0x00000200???512?????Secondary Image Table (optional)
> > 3. 0x00000400???1024????uBoot Image (Starting From IVT)
> > 4. 0x00060000???393216??start of uboot env (size:8k)
> > 5. 0x00062000???????????end of uboot env
> > 6. 0x00100000???1048576 Linux kernel start
> > 7. 0x0076AC00???7777280 start of partition 1
> > ------------------------------>8---------------------------
> > 
> > So for U-Boot we have 383kB (392192 bytes).
> > 
> > But in up to date U-Boot for Wandboard we build separately
> > ?a) SPL
> > ?b) u-boot.img
> > 
> > which gives us a bit more detailed SD-card layout:
> > ------------------------------>8---------------------------
> > ==========================================================
> > 1. 0x00000000???????????Reserved For MBR
> > 2. 0x00000200???512?????Secondary Image Table (optional)
> > 3. 0x00000400???1024????SPL
> > 4. 0x00011400???70656???u-boot.img
> > 5. 0x00060000???393216??start of uboot env (size:8k)
> > 6. 0x00062000???????????end of uboot env
> > ...
> > ------------------------------>8---------------------------
> > 
> > From that layout we may calculate amount of space reserved for
> > u-boot.img. It's just 315kb (322560 bytes).
> > 
> > Now if I build U-Boot with Sourcery CodeBench ARM 2014.05 produced
> > u-boot.img is already more than we expected
> > (323840 bytes instead of "< 322560"):
> > ------------------------------>8---------------------------
> > ls -la u-boot.img
> > -rw-rw-r-- 1 user user 323840 Jul??5 07:38 u-boot.img
> > ------------------------------>8---------------------------
> > 
> > Funny enough if I rebuild U-Boot with ARM toolchain available in
> > my Fedora 23 distro u-boot.img becomes a little bit smaller:
> > ------------------------------>8---------------------------
> > ls -la u-boot.img
> > -rw-rw-r-- 1 user user 322216 Jul??5 07:39 u-boot.img
> > ------------------------------>8---------------------------
> > 
> > What's worse this problem might not affect people most of the time
> > because what happens people would just copy u-boot.img on SD-card and
> > live in happiness with it... well until somebody attempts to save
> > environment in U-Boot with "saveenv" command which will simply
> > overwrite the very end of u-boot.img.
> > That will lead to unusable SD-card until user dd u-boot.img on
> > SD-card again.
> > 
> > I may foresee this issue in the future to become more visible once we
> > add more features in U-Boot for Wandboard or just existing code base
> > becomes bulkier and people will consistently get larger u-boot.img
> > files produced.
> > 
> > IMHO there's an obvious solution for all that - just move U-Boot's env
> > to the very end of the gap between U-Boot and the first real partition
> > on the SD-card. This patch will follow
> > 8fb9eea5653796 ("mx6sabre_common: Fix U-Boot corruption after 'saveenv'").
> > So env is still not in the very end of the gap (obviously 256kb is way
> > too much for U-Boot's env) but at least we have now the same
> > partitioning for i.MX6 boards.
> > 
> > Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > Cc: Otavio Salvador <otavio@ossystems.com.br>
> > Cc: Peter Robinson <pbrobinson@gmail.com>
> > Cc: Tom Rini <trini@konsulko.com>
> > Cc: Peter Korsgaard <peter@korsgaard.com>
> > Cc: Wolfgang Denk <wd@denx.de>
>
> Couldn't this be done on the common header?

It could be done but that's not so straight-forward.
See not all boards that use?"mx6_common.h" store U-Boot's environment
on SD card. There're ones that put env in SPI flash ("cm_fx6", "aristainetos"
etc). Moreover some "include/configs/XXX.h" files put "mx6_common.h" in
the very beginning some in the middle, some in the very end. I.e. we cannot rely
on "#ifdef CONFIG_ENV_IS_IN_MMC" - it might be defined later easily.

That means if we move CONFIG_ENV_OFFSET in "mx6_common.h" we'll need to wrap
CONFIG_ENV_OFFSET on some boards with #undef to allow them to override ENV_OFFSET.

IMHO better solution would be as Tom suggested to move all ENV related things in
Kconfig and there we'll be able to handle it more gracefully.

-Alexey