wandboard: move environment partition farther from u-boot.img
PATCH 1/1 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. 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 follow8fb9eea5653796 ("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.
--- include/configs/wandboard.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/wandboard.h +1 -1
@@ -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 * */
Signature · 1 line
2.5.5
PATCH 1/1 wandboard: move environment partition farther from u-boot.img
Quoted 75 lines · Alexey Brodkin
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 env6.
0x001000001048576 Linux kernel start
7.0x0076AC007777280 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.imgwhich 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.
Quoted 7 lines
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?
Signature · 3 lines
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
PATCH 1/1 wandboard: move environment partition farther from u-boot.img
Hi Otavio,
Quoted 78 lines · Otavio Salvador
Quoted 76 lines · Alexey Brodkin
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.imgwhich 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.
Quoted 9 lines
Quoted 7 lines
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.
-Alexey
PATCH 1/1 wandboard: move environment partition farther from u-boot.img
Quoted 96 lines · Alexey Brodkin
Quoted 78 lines · Otavio Salvador
Quoted 76 lines · Alexey Brodkin
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 env6.
0x001000001048576 Linux kernel start
7.0x0076AC007777280 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.imgwhich 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.Quoted 9 lines
Quoted 7 lines
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 "#ifdefCONFIG_ENV_IS_IN_MMC" - it might be defined later easily.
Quoted 5 lines
That means if we move
CONFIG_ENV_OFFSETin "mx6_common.h" we'll need to wrapCONFIG_ENV_OFFSETon some boards with #undef to allow them to overrideENV_OFFSET.IMHO better solution would be as Tom suggested to move all ENV related things in
Kconfigand there we'll be able to handle it more gracefully.
Great; I agree.
Please see if you find time to move those options for Kconfig so we fix this globally :-)
Signature · 3 lines
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
PATCH 1/1 wandboard: move environment partition farther from u-boot.img
In reply to Alexey BrodkinQuoted 75 lines · Alexey Brodkin
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 env6.
0x001000001048576 Linux kernel start
7.0x0076AC007777280 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.imgwhich 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.
Quoted 7 lines
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]>
PATCH 1/1 wandboard: move environment partition farther from u-boot.img
In reply to Alexey BrodkinHi Stefano,
Quoted 75 lines · Alexey Brodkin
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 env6.
0x001000001048576 Linux kernel start
7.0x0076AC007777280 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.imgwhich 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.
Quoted 7 lines
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]>
Any comments about this one? Could it be applied?
Just noticed this issue here.
Thanks
PATCH 1/1 wandboard: move environment partition farther from u-boot.img
Quoted 79 lines · Fabio Estevam
Hi Stefano,
Quoted 75 lines · Alexey Brodkin
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 env6.
0x001000001048576 Linux kernel start
7.0x0076AC007777280 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.imgwhich 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.
Quoted 9 lines
Quoted 7 lines
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]>Any comments about this one? Could it be applied?
No, it is ok, I will apply it.
Regards,
Stefano
Signature · 5 lines
===================================================================== 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 =====================================================================