On Mon, Jul 11, 2016 at 3:51 AM, Alexey Brodkin <[email protected]> wrote: > On Sat, 2016-07-09 at 10:02 -0300, Otavio Salvador wrote: >> On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkin >> <[email protected]> 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 <[email protected]> >> > Cc: Fabio Estevam <[email protected]> >> > Cc: Otavio Salvador <[email protected]> >> > Cc: Peter Robinson <[email protected]> >> > Cc: Tom Rini <[email protected]> >> > Cc: Peter Korsgaard <[email protected]> >> > Cc: Wolfgang Denk <[email protected]> >> >> 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 <[email protected]> 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
