[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. 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@synopsys.com Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Otavio Salvador otavio@ossystems.com.br Cc: Peter Robinson pbrobinson@gmail.com Cc: Tom Rini trini@konsulko.com Cc: Peter Korsgaard peter@korsgaard.com Cc: Wolfgang Denk wd@denx.de --- 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 * */
On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkin Alexey.Brodkin@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---------------------------
- 0x00000000 Reserved For MBR
- 0x00000200 512 Secondary Image Table (optional)
- 0x00000400 1024 uBoot Image (Starting From IVT)
- 0x00060000 393216 start of uboot env (size:8k)
- 0x00062000 end of uboot env
- 0x00100000 1048576 Linux kernel start
- 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---------------------------
- 0x00000000 Reserved For MBR
- 0x00000200 512 Secondary Image Table (optional)
- 0x00000400 1024 SPL
- 0x00011400 70656 u-boot.img
- 0x00060000 393216 start of uboot env (size:8k)
- 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@synopsys.com Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Otavio Salvador otavio@ossystems.com.br Cc: Peter Robinson pbrobinson@gmail.com Cc: Tom Rini trini@konsulko.com Cc: Peter Korsgaard peter@korsgaard.com Cc: Wolfgang Denk wd@denx.de
Couldn't this be done on the common header?
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 Alexey.Brodkin@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---------------------------
- 0x00000000 Reserved For MBR
- 0x00000200 512 Secondary Image Table (optional)
- 0x00000400 1024 uBoot Image (Starting From IVT)
- 0x00060000 393216 start of uboot env (size:8k)
- 0x00062000 end of uboot env
- 0x00100000 1048576 Linux kernel start
- 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---------------------------
- 0x00000000 Reserved For MBR
- 0x00000200 512 Secondary Image Table (optional)
- 0x00000400 1024 SPL
- 0x00011400 70656 u-boot.img
- 0x00060000 393216 start of uboot env (size:8k)
- 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@synopsys.com Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Otavio Salvador otavio@ossystems.com.br Cc: Peter Robinson pbrobinson@gmail.com Cc: Tom Rini trini@konsulko.com Cc: Peter Korsgaard peter@korsgaard.com Cc: Wolfgang Denk wd@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.
-Alexey
On Mon, Jul 11, 2016 at 3:51 AM, Alexey Brodkin Alexey.Brodkin@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@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---------------------------
- 0x00000000 Reserved For MBR
- 0x00000200 512 Secondary Image Table (optional)
- 0x00000400 1024 uBoot Image (Starting From IVT)
- 0x00060000 393216 start of uboot env (size:8k)
- 0x00062000 end of uboot env
- 0x00100000 1048576 Linux kernel start
- 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---------------------------
- 0x00000000 Reserved For MBR
- 0x00000200 512 Secondary Image Table (optional)
- 0x00000400 1024 SPL
- 0x00011400 70656 u-boot.img
- 0x00060000 393216 start of uboot env (size:8k)
- 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@synopsys.com Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Otavio Salvador otavio@ossystems.com.br Cc: Peter Robinson pbrobinson@gmail.com Cc: Tom Rini trini@konsulko.com Cc: Peter Korsgaard peter@korsgaard.com Cc: Wolfgang Denk wd@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@ossystems.com.br
Please see if you find time to move those options for Kconfig so we fix this globally :-)
On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkin Alexey.Brodkin@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---------------------------
- 0x00000000 Reserved For MBR
- 0x00000200 512 Secondary Image Table (optional)
- 0x00000400 1024 uBoot Image (Starting From IVT)
- 0x00060000 393216 start of uboot env (size:8k)
- 0x00062000 end of uboot env
- 0x00100000 1048576 Linux kernel start
- 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---------------------------
- 0x00000000 Reserved For MBR
- 0x00000200 512 Secondary Image Table (optional)
- 0x00000400 1024 SPL
- 0x00011400 70656 u-boot.img
- 0x00060000 393216 start of uboot env (size:8k)
- 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@synopsys.com Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Otavio Salvador otavio@ossystems.com.br Cc: Peter Robinson pbrobinson@gmail.com Cc: Tom Rini trini@konsulko.com Cc: Peter Korsgaard peter@korsgaard.com Cc: Wolfgang Denk wd@denx.de
Acked-by: Fabio Estevam fabio.estevam@nxp.com
Hi Stefano,
On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkin Alexey.Brodkin@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---------------------------
- 0x00000000 Reserved For MBR
- 0x00000200 512 Secondary Image Table (optional)
- 0x00000400 1024 uBoot Image (Starting From IVT)
- 0x00060000 393216 start of uboot env (size:8k)
- 0x00062000 end of uboot env
- 0x00100000 1048576 Linux kernel start
- 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---------------------------
- 0x00000000 Reserved For MBR
- 0x00000200 512 Secondary Image Table (optional)
- 0x00000400 1024 SPL
- 0x00011400 70656 u-boot.img
- 0x00060000 393216 start of uboot env (size:8k)
- 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@synopsys.com Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Otavio Salvador otavio@ossystems.com.br Cc: Peter Robinson pbrobinson@gmail.com Cc: Tom Rini trini@konsulko.com Cc: Peter Korsgaard peter@korsgaard.com Cc: Wolfgang Denk wd@denx.de
Any comments about this one? Could it be applied?
Just noticed this issue here.
Thanks
On 18/07/2016 15:28, Fabio Estevam wrote:
Hi Stefano,
On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkin Alexey.Brodkin@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---------------------------
- 0x00000000 Reserved For MBR
- 0x00000200 512 Secondary Image Table (optional)
- 0x00000400 1024 uBoot Image (Starting From IVT)
- 0x00060000 393216 start of uboot env (size:8k)
- 0x00062000 end of uboot env
- 0x00100000 1048576 Linux kernel start
- 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---------------------------
- 0x00000000 Reserved For MBR
- 0x00000200 512 Secondary Image Table (optional)
- 0x00000400 1024 SPL
- 0x00011400 70656 u-boot.img
- 0x00060000 393216 start of uboot env (size:8k)
- 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@synopsys.com Cc: Fabio Estevam fabio.estevam@nxp.com Cc: Otavio Salvador otavio@ossystems.com.br Cc: Peter Robinson pbrobinson@gmail.com Cc: Tom Rini trini@konsulko.com Cc: Peter Korsgaard peter@korsgaard.com Cc: Wolfgang Denk wd@denx.de
Any comments about this one? Could it be applied?
No, it is ok, I will apply it.
Regards, Stefano
participants (4)
-
Alexey Brodkin -
Fabio Estevam -
Otavio Salvador -
Stefano Babic