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

[Stefano Babic]

On 18/07/2016 15:28, Fabio Estevam wrote:
> Hi Stefano,
> 
> 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>
> 
> Any comments about this one? Could it be applied?


No, it is ok, I will apply it.

Regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================