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

2016-07-19 Thread Stefano Babic
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

2016-07-18 Thread Fabio Estevam
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?

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

2016-07-14 Thread Fabio Estevam
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 

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

2016-07-11 Thread Otavio Salvador
On Mon, Jul 11, 2016 at 3:51 AM, Alexey Brodkin
 wrote:
> 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

2016-07-11 Thread Alexey Brodkin
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

2016-07-09 Thread Otavio Salvador
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?

-- 
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

2016-07-09 Thread 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. 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 
---
 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