Re: [U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img
On 18/07/2016 15:28, Fabio Estevam wrote: > Hi Stefano, > > On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkin >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. 0x Reserved For MBR >> 2. 0x0200 512 Secondary Image Table (optional) >> 3. 0x0400 1024uBoot Image (Starting From IVT) >> 4. 0x0006 393216 start of uboot env (size:8k) >> 5. 0x00062000 end of uboot env >> 6. 0x0010 1048576 Linux kernel start >> 7. 0x0076AC00 280 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. 0x Reserved For MBR >> 2. 0x0200 512 Secondary Image Table (optional) >> 3. 0x0400 1024SPL >> 4. 0x00011400 70656 u-boot.img >> 5. 0x0006 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 >> Cc: Fabio Estevam >> Cc: Otavio Salvador >> Cc: Peter Robinson >> Cc: Tom Rini >> Cc: Peter Korsgaard >> Cc: Wolfgang Denk > > 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: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img
Hi Stefano, On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkinwrote: > 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. 0x Reserved For MBR > 2. 0x0200 512 Secondary Image Table (optional) > 3. 0x0400 1024uBoot Image (Starting From IVT) > 4. 0x0006 393216 start of uboot env (size:8k) > 5. 0x00062000 end of uboot env > 6. 0x0010 1048576 Linux kernel start > 7. 0x0076AC00 280 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. 0x Reserved For MBR > 2. 0x0200 512 Secondary Image Table (optional) > 3. 0x0400 1024SPL > 4. 0x00011400 70656 u-boot.img > 5. 0x0006 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 > Cc: Fabio Estevam > Cc: Otavio Salvador > Cc: Peter Robinson > Cc: Tom Rini > Cc: Peter Korsgaard > Cc: Wolfgang Denk Any comments about this one? Could it be applied? Just noticed this issue here. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img
On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkinwrote: > 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. 0x Reserved For MBR > 2. 0x0200 512 Secondary Image Table (optional) > 3. 0x0400 1024uBoot Image (Starting From IVT) > 4. 0x0006 393216 start of uboot env (size:8k) > 5. 0x00062000 end of uboot env > 6. 0x0010 1048576 Linux kernel start > 7. 0x0076AC00 280 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. 0x Reserved For MBR > 2. 0x0200 512 Secondary Image Table (optional) > 3. 0x0400 1024SPL > 4. 0x00011400 70656 u-boot.img > 5. 0x0006 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 > Cc: Fabio Estevam > Cc: Otavio Salvador > Cc: Peter Robinson > Cc: Tom Rini > Cc: Peter Korsgaard > Cc: Wolfgang Denk Acked-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img
On Mon, Jul 11, 2016 at 3:51 AM, Alexey Brodkinwrote: > On Sat, 2016-07-09 at 10:02 -0300, Otavio Salvador wrote: >> On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkin >> 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. 0x Reserved For MBR >> > 2. 0x0200 512 Secondary Image Table (optional) >> > 3. 0x0400 1024uBoot Image (Starting From IVT) >> > 4. 0x0006 393216 start of uboot env (size:8k) >> > 5. 0x00062000 end of uboot env >> > 6. 0x0010 1048576 Linux kernel start >> > 7. 0x0076AC00 280 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. 0x Reserved For MBR >> > 2. 0x0200 512 Secondary Image Table (optional) >> > 3. 0x0400 1024SPL >> > 4. 0x00011400 70656 u-boot.img >> > 5. 0x0006 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 >> > Cc: Fabio Estevam >> > Cc: Otavio Salvador >> > Cc: Peter Robinson >> > Cc: Tom Rini >> > Cc: Peter Korsgaard >> > Cc: Wolfgang Denk >> >> 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:
Re: [U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img
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 >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. 0x Reserved For MBR > > 2. 0x0200 512 Secondary Image Table (optional) > > 3. 0x0400 1024uBoot Image (Starting From IVT) > > 4. 0x0006 393216 start of uboot env (size:8k) > > 5. 0x00062000 end of uboot env > > 6. 0x0010 1048576 Linux kernel start > > 7. 0x0076AC00 280 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. 0x Reserved For MBR > > 2. 0x0200 512 Secondary Image Table (optional) > > 3. 0x0400 1024SPL > > 4. 0x00011400 70656 u-boot.img > > 5. 0x0006 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 > > Cc: Fabio Estevam > > Cc: Otavio Salvador > > Cc: Peter Robinson > > Cc: Tom Rini > > Cc: Peter Korsgaard > > Cc: Wolfgang Denk > > 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img
On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkinwrote: > 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. 0x Reserved For MBR > 2. 0x0200 512 Secondary Image Table (optional) > 3. 0x0400 1024uBoot Image (Starting From IVT) > 4. 0x0006 393216 start of uboot env (size:8k) > 5. 0x00062000 end of uboot env > 6. 0x0010 1048576 Linux kernel start > 7. 0x0076AC00 280 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. 0x Reserved For MBR > 2. 0x0200 512 Secondary Image Table (optional) > 3. 0x0400 1024SPL > 4. 0x00011400 70656 u-boot.img > 5. 0x0006 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 > Cc: Fabio Estevam > Cc: Otavio Salvador > Cc: Peter Robinson > Cc: Tom Rini > Cc: Peter Korsgaard > Cc: Wolfgang Denk Couldn't this be done on the common header? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img
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. 0x Reserved For MBR 2. 0x0200 512 Secondary Image Table (optional) 3. 0x0400 1024uBoot Image (Starting From IVT) 4. 0x0006 393216 start of uboot env (size:8k) 5. 0x00062000 end of uboot env 6. 0x0010 1048576 Linux kernel start 7. 0x0076AC00 280 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. 0x Reserved For MBR 2. 0x0200 512 Secondary Image Table (optional) 3. 0x0400 1024SPL 4. 0x00011400 70656 u-boot.img 5. 0x0006 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 BrodkinCc: Fabio Estevam Cc: Otavio Salvador Cc: Peter Robinson Cc: Tom Rini Cc: Peter Korsgaard Cc: Wolfgang Denk --- include/configs/wandboard.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index 99f5c0c..928d3d5 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -181,7 +181,7 @@ #define CONFIG_ENV_SIZE(8 * 1024) #define CONFIG_ENV_IS_IN_MMC -#define CONFIG_ENV_OFFSET (6 * 64 * 1024) +#define CONFIG_ENV_OFFSET (768 * 1024) #define CONFIG_SYS_MMC_ENV_DEV 0 #endif/* __CONFIG_H * */ -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot