Files
u-boot-tk1-som/include
Alexey Brodkin 67ff9e11f3 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---------------------------
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Acked-by: Fabio Estevam <fabio.estevam@nxp.com>

==========================================================
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
8fb9eea565 ("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>
2016-07-19 19:52:12 +02:00
..
2016-06-19 17:05:55 -06:00
2016-06-12 23:49:38 +02:00
2016-06-09 13:53:06 -04:00
2016-04-01 17:18:12 -04:00
2016-05-02 18:37:09 -04:00
2016-04-01 17:18:11 -04:00
2016-03-22 12:16:13 -04:00
2016-01-12 10:19:09 -07:00
2016-03-24 09:47:43 +01:00
2016-05-25 17:52:39 +02:00
2016-05-25 17:52:39 +02:00
2015-05-05 20:58:20 -06:00
2015-06-10 19:26:54 -06:00
2016-01-20 19:06:23 -07:00
2015-11-19 20:27:50 -07:00
2014-06-21 10:06:58 -06:00
2016-02-23 16:14:45 +05:30
2016-01-19 08:31:21 -05:00
2015-04-10 14:23:23 +02:00
2016-05-27 10:23:09 -06:00
2016-06-06 13:39:15 -04:00
2016-05-03 17:52:11 -05:00
2016-01-28 12:22:19 -06:00
2016-03-14 15:34:50 -06:00
2016-03-14 15:34:50 -06:00
2016-01-27 15:55:54 +01:00
2016-01-19 08:31:21 -05:00
2016-06-28 12:08:53 -07:00
2015-08-25 22:53:57 -05:00
2015-07-22 08:57:54 +02:00
2016-06-06 13:39:13 -04:00
2014-12-11 13:18:43 -07:00
2016-06-10 13:44:58 -07:00
2014-05-28 10:58:19 +09:00
2016-06-19 17:05:55 -06:00
2016-06-19 17:05:55 -06:00
2016-03-08 15:01:47 -05:00
2015-09-02 15:26:12 +02:00
2016-06-20 05:14:46 -04:00
2016-01-20 10:19:40 -05:00
2015-11-12 08:26:58 +08:00
2015-01-06 10:10:04 +02:00
2016-05-27 10:01:10 -04:00
2015-06-04 03:34:47 -06:00
2016-01-21 20:42:36 -07:00
2016-02-05 12:47:21 +08:00
2015-01-05 12:08:55 -05:00
2016-03-15 15:19:23 -04:00
2016-01-21 20:42:36 -07:00
2016-01-21 20:42:34 -07:00
2015-07-21 17:39:27 -06:00
2015-07-21 17:39:28 -06:00
2016-06-19 17:05:55 -06:00
2016-03-14 15:34:50 -06:00
2016-05-17 09:54:43 -06:00
2015-11-05 08:24:42 +01:00
2016-05-26 20:48:31 -06:00
2015-07-26 12:11:33 +02:00
2016-02-26 08:53:10 -07:00
2016-05-17 09:54:43 -06:00
2016-05-02 18:37:09 -04:00
2016-05-25 13:25:18 +09:00
2016-01-25 10:39:47 -05:00
2015-01-21 10:25:53 +01:00