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

[Otavio Salvador]

On Mon, Jul 11, 2016 at 3:51 AM, Alexey Brodkin
<Alexey.Brodkin at synopsys.com> wrote:
> 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 at 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 at synopsys.com>
>> > Cc: Fabio Estevam <fabio.estevam at nxp.com>
>> > Cc: Otavio Salvador <otavio at ossystems.com.br>
>> > Cc: Peter Robinson <pbrobinson at gmail.com>
>> > Cc: Tom Rini <trini at konsulko.com>
>> > Cc: Peter Korsgaard <peter at korsgaard.com>
>> > Cc: Wolfgang Denk <wd at 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.

Great; I agree.

Acked-by: Otavio Salvador <otavio at ossystems.com.br>

Please see if you find time to move those options for Kconfig so we
fix this globally :-)

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750