pico-imx7d: Increase the CONFIG_ENV_OFFSET size

U-Boot binary has grown in such a way that it goes beyond the reserved area for the environment variables.

Running "saveenv" causes U-Boot to hang because of this overlap.

Fix this problem by increasing the CONFIG_ENV_OFFSET size.

Also, in order to prevent this same problem in the future, use CONFIG_BOARD_SIZE_LIMIT, which will detect the overlap in build-time.

CONFIG_BOARD_SIZE_LIMIT does not accept math expressions, so declare CONFIG_ENV_OFFSET with its direct value instead.

Signed-off-by Fabio Estevam <[email protected]>

U-Boot binary has grown in such a way that it goes beyond the reserved area for the environment variables.

Running "saveenv" causes U-Boot to hang because of this overlap.

Fix this problem by increasing the CONFIG_ENV_OFFSET size.

Also, in order to prevent this same problem in the future, use CONFIG_BOARD_SIZE_LIMIT, which will detect the overlap in build-time.

CONFIG_BOARD_SIZE_LIMIT does not accept math expressions, so declare CONFIG_ENV_OFFSET with its direct value instead.

+ * CONFIG_BOARD_SIZE_LIMIT = CONFIG_ENV_OFFSET - u-boot.img offset
+ * CONFIG_BOARD_SIZE_LIMIT = 768k - 69k = 699k = 715776
+ *
+ * Currently CONFIG_BOARD_SIZE_LIMIT does not handle expressions, so
+ * write the direct value here
+ */
+#define CONFIG_BOARD_SIZE_LIMIT 715776

This is IMHO the wrong approach. Why not fix this problem?

Can you please try somthing like this (only minimally tested):

Quoted 2 lines

Can you please try somthing like this (only minimally tested):

I tried it, thanks, but unfortunately It does not work for me.

Here is the complete patch I used, which consists of your proposal plus my changes:
http://dark-code.bulix.org/nhg8l0-515675

Then when I build the pico-imx7d_defconfig target I get the following error:

/bin/sh: 1: printf: CONFIG_ENV_OFFSET - (69 * 1024): expected numeric value

Can you live with something like this:

#define CONFIG_ENV_OFFSET (768 * 1024)
#define CONFIG_BOARD_SIZE_LIMIT ((768 * 1024) - (69 * 1024))

[or maybe even ((768 - 69) * 1024) ?]

Quoted 4 lines · Wolfgang Denk

Can you live with something like this:

#define CONFIG_ENV_OFFSET (768 * 1024)
#define CONFIG_BOARD_SIZE_LIMIT ((768 * 1024) - (69 * 1024))

It does not work:

/bin/sh: 1: printf: ((768 * 1024) - (69 * 1024)): expected numeric value u-boot-nodtb.bin exceeds file size limit:
limit: 0 bytes
actual: 482968 bytes
excess: 482968 bytes

Quoted 1 line

[or maybe even ((768 - 69) * 1024) ?]

/bin/sh: 1: printf: ((768 - 69) * 1024): expected numeric value u-boot-nodtb.bin exceeds file size limit:
limit: 0 bytes
actual: 482968 bytes
excess: 482968 bytes
Makefile:1040: recipe for target 'u-boot-nodtb.bin' failed

Can we please go with the solution I sent, which is ugly but at least allows the board to boot?

Agreed. It is better Wolfgang to send a tested solution before we change it one more time.

This fix should go in as the board is broken without it.

Quoted 4 lines · Wolfgang Denk

Can you live with something like this:

#define CONFIG_ENV_OFFSET (768 * 1024)
#define CONFIG_BOARD_SIZE_LIMIT ((768 * 1024) - (69 * 1024))

It does not work:

/bin/sh: 1: printf: ((768 * 1024) - (69 * 1024)): expected numeric value u-boot-nodtb.bin exceeds file size limit:
limit: 0 bytes
actual: 482968 bytes
excess: 482968 bytes

Is there any chance you mis-applied my patch?

Ok, so I started again.

The reason for the failure is because there is an extra CONFIG_BOARD_SIZE_LIMIT check inside the main Makefile.

Your patch only covers arch/arm/mach-imx/Makefile.

Then I am able to successfully build it.

It seems we need to avoid the double CONFIG_BOARD_SIZE_LIMIT check.

IMO there is nothing architecture specific about this check, so we should probably patch the top level Makefile and remove the test in arch/arm/mach-imx/Makefile ?

1. The imx check has been introduced by:

commit 43e6f94cbcaf193aeedcf86e85a3ff4c79f66773

Author: Marcel Ziswiler <[email protected]>
Date:   Fri Nov 9 15:31:17 2018 +0100

imx: mkimage: add size check to the u-boot.imx make target

The make macro to check if the binary exceeds the board size limit is taken straight from the root Makefile.

Without this and e.g. enabled EFI Vybrid fails booting as the regular size limit check does not take the final u-boot.imx binary size into account which is bigger due to alignment as well as IMX header stuff.

2. For testing purpose, I removed the imx check and patched the main Makefile, but still got error:
u-boot-nodtb.bin exceeds file size limit:
limit: 0 bytes
actual: 482968 bytes
excess: 482968 bytes

How should we proceed?

OK, so this is an additional (second) test run for a special configuration, but the code to perform the test has just been duplicated from the top level makefile (which is not a nice thing).

I think we should tun this code either into a Makefile function that is defined only once and can then be used elsewhere as well, or turn it into an external script unter scripts/

What do you think?

If I know how to repeat your exact test, I can try to fix that.

So far, the use of CONFIG_BOARD_SIZE_LIMIT would only work with plain numeric constants. Extend it to allow for expressions, so one can for example use

        #define CONFIG_BOARD_SIZE_LIMIT (768 << 10)

in the board configuration.

Signed-off-by Wolfgang Denk <[email protected]>

Cc Fabio Estevam <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Vanessa Maegima <[email protected]>

Cc Otavio Salvador <[email protected]>

Cc John Weber <[email protected]>

Cc Stefan Roese <[email protected]>

So far, the use of CONFIG_BOARD_SIZE_LIMIT would only work with plain numeric constants. Extend it to allow for expressions, so one can for example use

        #define CONFIG_BOARD_SIZE_LIMIT (768 << 10)

in the board configuration.

Signed-off-by Wolfgang Denk <[email protected]>

Still not working for me. I do see a warning now:

LD spl/u-boot-spl
/bin/sh: 1: arithmetic expression: expecting primary: ""((768 - 69) * 1024)""
COPY u-boot.bin
MKIMAGE u-boot.img
OBJCOPY spl/u-boot-spl-nodtb.bin
COPY spl/u-boot-spl.bin
CFGS spl/u-boot-spl.cfgout
MKIMAGE SPL
CFGCHK u-boot.cfg

It does allow the build to proceed, but it is not really detecting the overlap anymore.

For example: let's force the overlap by setting a very small CONFIG_BOARD_SIZE_LIMIT of only 1K:

#define CONFIG_ENV_OFFSET (768 * 1024)
#define CONFIG_BOARD_SIZE_LIMIT (1 * 1024)

/bin/sh: 1: arithmetic expression: expecting primary: ""(1 * 1024)""

It still allowed a successful build, but it should have thrown an error about the overlap.

Please try it on the shell:

-> echo $(( ((768 - 69) * 1024) ))
715776
-> echo $(( (1 * 1024) ))
1024

It does for me, if I set the limit low:

OBJCOPY spl/u-boot-spl-nodtb.bin
COPY spl/u-boot-spl.bin
CFGS spl/u-boot-spl.cfgout
MKIMAGE SPL
OBJCOPY u-boot.srec
OBJCOPY u-boot-nodtb.bin
u-boot-nodtb.bin exceeds file size limit:
limit: 1024 bytes
actual: 480172 bytes
excess: 479148 bytes
make: *** [Makefile:1071: u-boot-nodtb.bin] Error 1

Previously I tested on a machine running Ubuntu 16.04 and today I also tested on another machine running Ubuntu 18.04.

The results are the same on both machines:

1. I get a "expecting primary" warning:

OBJCOPY u-boot-nodtb.bin
/bin/sh: 1: arithmetic expression: expecting primary: ""(1 * 1024)""

This makes really no sense to me. Can you please send me (off list) a git diff of the tree that is not building for you against the nearest mainline commit?

And please also the output of /"bin/sh --version".

$ /bin/sh --version
/bin/sh: 0: Illegal option --

In my system /bin/sh points to bash:

$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4 mai  2  2018 /bin/sh -> dash

Fabio wrote...

$ /bin/sh --version
/bin/sh: 0: Illegal option --

In my system /bin/sh points to bash:

$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4 mai  2  2018 /bin/sh -> dash

Just to pick up on the obvious… /bin/sh is showing as linked to dash not bash!

Using (( … )) for arithmetic expansion is a bashism [1]

Quoted 6 lines · Andy Pont

Fabio wrote...

$ /bin/sh --version
/bin/sh: 0: Illegal option --

Quoted 5 lines

In my system /bin/sh points to bash:

$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4 mai  2  2018 /bin/sh -> dash

Just to pick up on the obvious… /bin/sh is showing as linked to dash not bash!

Yes, I meant bash.

Hi Wolfgang,

Quoted 3 lines · Wolfgang Denk

This makes really no sense to me. Can you please send me (off list) a git diff of the tree that is not building for you against the nearest mainline commit?

I am running top of tree mainline U-Boot + your patch from this thread, plus:

include/configs/pico-imx7d.h +0 -0

 #define CONFIG_SYS_FSL_USDHC_NUM               2
 
 #define CONFIG_SYS_MMC_ENV_DEV                 0

It does build fine, but as I have intentionally forced a small CONFIG_BOARD_SIZE_LIMIT I wanted it to fail, but it does not fail as shown below:

OBJCOPY u-boot-nodtb.bin
/bin/sh: 1: arithmetic expression: expecting primary: ""(1 * 1024)""
SYM u-boot.sym
COPY u-boot.bin
MKIMAGE u-boot.img
===================== WARNING ======================
This board does not use CONFIG_DM_MMC. Please update
the board to use CONFIG_DM_MMC before the v2019.04 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_USB. Please update
the board to use CONFIG_DM_USB before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info.
====================================================
CFGCHK u-boot.cfg

As you can see there are two issues:

1. The warnin: /bin/sh: 1: arithmetic expression: expecting primary:
""(1 * 1024)""

2. It should have not built in this case. It should have detected the overlap and signalized the error

Quoted 1 line

And please also the output of /"bin/sh --version".

$ /bin/sh --version
/bin/sh: 0: Illegal option --

In my system /bin/sh points to bash:

$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4 mai  2  2018 /bin/sh -> dash

/bin/bash --version
GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

I am able to reproduce this problem with a standalone script:

$ cat random.sh
#!/bin/bash
echo $(($RANDOM % 10))
$ ./random.sh
3

Worked fine with bash.

Now if I force it to dash:

$ cat random.sh
#!/bin/dash
echo $(($RANDOM % 10))
$ ./random.sh
./random.sh: 2: ./random.sh: arithmetic expression: expecting primary: " % 10"

Which is the same warning I get in U-Boot.
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

If you take a look at how CONFIG_BOARD_SIZE_LIMIT is used

        ifneq ($(CONFIG_BOARD_SIZE_LIMIT),)
        BOARD_SIZE_CHECK = \
                @actual=`wc -c $@ | awk '{print $$1}'`; \
                limit=`printf "%d" $(CONFIG_BOARD_SIZE_LIMIT)`; \
                if test $$actual -gt $$limit; then \
                        echo "$@ exceeds file size limit:" >&2 ; \
                        echo "  limit:  $$limit bytes" >&2 ; \
                        echo "  actual: $$actual bytes" >&2 ; \
                        echo "  excess: $$((actual - limit)) bytes" >&2; \
                        exit 1; \
                fi
        else
        BOARD_SIZE_CHECK =
        endif

you will notice that there’s no arithmetic expansion on it prior to it being passed int a 'if -gt’ compare.

'git grep’ also shows that no other board is requesting an arithmetic expansion on this (i.e. everyone else just uses a constant).

Note that the C-preprocessor will not do arithmetic for you... So you’ll either have to change the Makefile or define this as an actual constant number.

I am running top of tree mainline U-Boot + your patch from this thread, plus:

include/configs/pico-imx7d.h +2 -1

@@ -134,7 +134,8 @@
 /* FLASH and environment organization */
 #define CONFIG_ENV_SIZE                        SZ_8K
 
-#define CONFIG_ENV_OFFSET                      (8 * SZ_64K)
+#define CONFIG_ENV_OFFSET              (768 * 1024)
+#define CONFIG_BOARD_SIZE_LIMIT                (1 * 1024)
 #define CONFIG_SYS_FSL_USDHC_NUM               2
 
 #define CONFIG_SYS_MMC_ENV_DEV                 0

It does build fine, but as I have intentionally forced a small CONFIG_BOARD_SIZE_LIMIT I wanted it to fail, but it does not fail as shown below:

OBJCOPY u-boot-nodtb.bin
/bin/sh: 1: arithmetic expression: expecting primary: ""(1 * 1024)""

Quoted 2 lines

/bin/sh: 1: arithmetic expression: expecting primary: ""(1 * 1024)""

SHELL = /bin/bash"

And by forcing the SHELL variable to bash, then your patch works fine here:

This should also work - replace the line

        @(echo $$(($(CONFIG_BOARD_SIZE_LIMIT))); wc -c $@ ) | \

by

        @(awk "END { print $$(echo $(CONFIG_BOARD_SIZE_LIMIT)) }" /dev/null; wc -c $@ ) | \

Can you please try this out?

I replaced it on the main Makefile and also in the imx one and it works as expected now.

When you send the v2, you can add:

Tested-by Fabio Estevam <[email protected]>

So far, the use of CONFIG_BOARD_SIZE_LIMIT would only work with plain numeric constants. Extend it to allow for expressions, so one can for example use

	#define CONFIG_BOARD_SIZE_LIMIT	(768 << 10)

in the board configuration.

Signed-off-by Wolfgang Denk <[email protected]>

Tested-by Fabio Estevam <[email protected]>

Cc Fabio Estevam <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Vanessa Maegima <[email protected]>

Cc Otavio Salvador <[email protected]>

Cc John Weber <[email protected]>

Cc Stefan Roese <[email protected]>

---
v2: replace bashism for evaluating expressions in CONFIG_BOARD_SIZE_LIMIT
by another call to awk.

Note 1: As gawk lacks an eval function and we don't want to rely on
bash being used as shell, we use another call to awk to evaluate the expression. This has the disadvantage that we cannot use expressions like "<<" which awk does not understand. OK, one could replace awk by something better...

Note 2: This patch focusses on enabling this new feature. It does
not addres another issue that should be solved in a later
commit: the duplication of the same code in Makefile and arch/arm/mach-imx/Makefile

---
 Makefile                   | 17 ++++++++---------
 arch/arm/mach-imx/Makefile | 17 ++++++++---------
 2 files changed, 16 insertions(+), 18 deletions(-)

Makefile +0 -0

index 0d11ff9797..87eb0fd2b1 100644
@@ -774,15 +774,14 @@ LDPPFLAGS += \
 
 ifneq ($(CONFIG_BOARD_SIZE_LIMIT),)
 BOARD_SIZE_CHECK = \

Quoted 45 lines · Wolfgang Denk

So far, the use of CONFIG_BOARD_SIZE_LIMIT would only work with plain numeric constants. Extend it to allow for expressions, so one can for example use

      #define CONFIG_BOARD_SIZE_LIMIT (768 << 10)

in the board configuration.

Signed-off-by Wolfgang Denk <[email protected]>

Tested-by Fabio Estevam <[email protected]>

Cc Fabio Estevam <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Vanessa Maegima <[email protected]>

Cc Otavio Salvador <[email protected]>

Cc John Weber <[email protected]>

Cc Stefan Roese <[email protected]>

---
v2: replace bashism for evaluating expressions in CONFIG_BOARD_SIZE_LIMIT
by another call to awk.

Note 1: As gawk lacks an eval function and we don't want to rely on
bash being used as shell, we use another call to awk to evaluate the expression. This has the disadvantage that we cannot use expressions like "<<" which awk does not understand. OK, one could replace awk by something better...

Note 2: This patch focusses on enabling this new feature. It does
not addres another issue that should be solved in a later
commit: the duplication of the same code in Makefile and arch/arm/mach-imx/Makefile

---
 Makefile                   | 17 ++++++++---------
 arch/arm/mach-imx/Makefile | 17 ++++++++---------
 2 files changed, 16 insertions(+), 18 deletions(-)

Makefile +0 -0

index 0d11ff9797..87eb0fd2b1 100644
@@ -774,15 +774,14 @@ LDPPFLAGS += \
 
 ifneq ($(CONFIG_BOARD_SIZE_LIMIT),)
 BOARD_SIZE_CHECK = \

Makefile LDPPFLAGS += \ · line 777

Quoted 10 lines

Makefile +1 -9

-     @actual=`wc -c $@ | awk '{print $$1}'`; \
-     limit=`printf "%d" $(CONFIG_BOARD_SIZE_LIMIT)`; \
-     if test $$actual -gt $$limit; then \
-             echo "$@ exceeds file size limit:" >&2 ; \
-             echo "  limit:  $$limit bytes" >&2 ; \
-             echo "  actual: $$actual bytes" >&2 ; \
-             echo "  excess: $$((actual - limit)) bytes" >&2; \
-             exit 1; \
-     fi
+     @(awk "END{print $$(echo $(CONFIG_BOARD_SIZE_LIMIT))}" /dev/null; wc -c $@ ) | \

So this fails with awk being provided by mawk, not gawk:

$ mawk "END{print $(echo 0xE0000)}" /dev/null;
0
$ gawk "END{print $(echo 0xE0000)}" /dev/null;
917504

And then things fail as mawk doesn't like hex.

Now, at the end of the day, I'm now not sure I agree with this patch in concept. When CONFIG_BOARD_SIZE_LIMIT is moved to Kconfig it will be taking I would assume a hex input and so we don't have to worry about << at all.

Tom,

Quoted 65 lines · Tom Rini

Quoted 45 lines · Wolfgang Denk

So far, the use of CONFIG_BOARD_SIZE_LIMIT would only work with plain numeric constants. Extend it to allow for expressions, so one can for example use

      #define CONFIG_BOARD_SIZE_LIMIT (768 << 10)

in the board configuration.

Signed-off-by Wolfgang Denk <[email protected]>

Tested-by Fabio Estevam <[email protected]>

Cc Fabio Estevam <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Vanessa Maegima <[email protected]>

Cc Otavio Salvador <[email protected]>

Cc John Weber <[email protected]>

Cc Stefan Roese <[email protected]>

---
v2: replace bashism for evaluating expressions in CONFIG_BOARD_SIZE_LIMIT
by another call to awk.

Note 1: As gawk lacks an eval function and we don't want to rely on
bash being used as shell, we use another call to awk to evaluate the expression. This has the disadvantage that we cannot use expressions like "<<" which awk does not understand. OK, one could replace awk by something better...

Note 2: This patch focusses on enabling this new feature. It does
not addres another issue that should be solved in a later
commit: the duplication of the same code in Makefile and arch/arm/mach-imx/Makefile

---
 Makefile                   | 17 ++++++++---------
 arch/arm/mach-imx/Makefile | 17 ++++++++---------
 2 files changed, 16 insertions(+), 18 deletions(-)

Makefile +0 -0

index 0d11ff9797..87eb0fd2b1 100644
@@ -774,15 +774,14 @@ LDPPFLAGS += \
 
 ifneq ($(CONFIG_BOARD_SIZE_LIMIT),)
 BOARD_SIZE_CHECK = \

Makefile LDPPFLAGS += \ · line 777

Quoted 10 lines

Makefile +1 -9

-     @actual=`wc -c $@ | awk '{print $$1}'`; \
-     limit=`printf "%d" $(CONFIG_BOARD_SIZE_LIMIT)`; \
-     if test $$actual -gt $$limit; then \
-             echo "$@ exceeds file size limit:" >&2 ; \
-             echo "  limit:  $$limit bytes" >&2 ; \
-             echo "  actual: $$actual bytes" >&2 ; \
-             echo "  excess: $$((actual - limit)) bytes" >&2; \
-             exit 1; \
-     fi
+     @(awk "END{print $$(echo $(CONFIG_BOARD_SIZE_LIMIT))}" /dev/null; wc -c $@ ) | \

So this fails with awk being provided by mawk, not gawk:

$ mawk "END{print $(echo 0xE0000)}" /dev/null;
0
$ gawk "END{print $(echo 0xE0000)}" /dev/null;
917504

Quoted 6 lines

And then things fail as mawk doesn't like hex.

Now, at the end of the day, I'm now not sure I agree with this patch in concept. When CONFIG_BOARD_SIZE_LIMIT is moved to Kconfig it will be taking I would assume a hex input and so we don't have to worry about << at all.

Sorry to warm up an old thread, but I have some slightly new input on this.

I can understand you disliking the concept of this patch regarding U-Boot proper size check (if CONFIG_BOARD_SIZE_LIMIT moves to Kconfig).

However, I think for SPL this is different: SPL often starts with one single small SRAM shared for code + data. In this case, the size available for the SPL binary often can be calculated like this:

CONFIG_SPL_MAX_SIZE = SRAM_SIZE - SYS_MALLOC_F_LEN - GENERATED_GBL_DATA_SIZE - STACKSIZE;

Being like that, it cannot just be moved to Kconfig and by definition is not a hardcoded single hex number but changes depending on other options.

I see two ways out here:
a) continue the way of this patch until it works for all shells/awks or
b) implement SPL binary size check using 4 constants instead of 1 (see above)

I'm willing to code this through, as I am hitting this limit on socfpga, so I could need a decision ;-)

OK, so a few thoughts here.
- What's the portable way to do hex-based math? If we really need it?

Quoted 2 lines · Tom Rini

OK, so a few thoughts here.
- What's the portable way to do hex-based math? If we really need it?

Use printf(3) to convert to/from hex, and standard shell arithmetic with $(( )).

Looks horrible, but something like:

v=$(( $( printf "%d\n" 0xa0 ) + $( printf "%d\n" 0x10 ) )) printf "v = %d (%x)\n" $v $v

... maybe arranged into some sh helper functions.

Martin
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Quoted 11 lines · Martin Husemann

Quoted 2 lines · Tom Rini

OK, so a few thoughts here.
- What's the portable way to do hex-based math? If we really need it?

Use printf(3) to convert to/from hex, and standard shell arithmetic with $(( )).

Quoted 4 lines

Looks horrible, but something like:

v=$(( $( printf "%d\n" 0xa0 ) + $( printf "%d\n" 0x10 ) )) printf "v = %d (%x)\n" $v $v

Can we just assume that awk is available? After all, AWK is defined in the top-level Makefile...

Quoted 11 lines · Martin Husemann

Quoted 2 lines · Tom Rini

OK, so a few thoughts here.
- What's the portable way to do hex-based math? If we really need it?

Use printf(3) to convert to/from hex, and standard shell arithmetic with $(( )).

Quoted 4 lines

Looks horrible, but something like:

v=$(( $( printf "%d\n" 0xa0 ) + $( printf "%d\n" 0x10 ) )) printf "v = %d (%x)\n" $v $v

Can we just assume that awk is available? After all, AWK is defined in the top-level Makefile...

Quoted 2 lines · Tom Rini

OK, so a few thoughts here.
- What's the portable way to do hex-based math? If we really need it?

Use printf(3) to convert to/from hex, and standard shell arithmetic with $(( )).

Looks horrible, but something like:

v=$(( $( printf "%d\n" 0xa0 ) + $( printf "%d\n" 0x10 ) )) printf "v = %d (%x)\n" $v $v

... maybe arranged into some sh helper functions.

U-Boot binary has grown in such a way that it goes beyond the reserved area for the environment variables.

Running "saveenv" causes U-Boot to hang because of this overlap.

Fix this problem by increasing the CONFIG_ENV_OFFSET size.

Also, in order to prevent this same problem in the future, use CONFIG_BOARD_SIZE_LIMIT, which will detect the overlap in build-time.

CONFIG_BOARD_SIZE_LIMIT does not accept math expressions, so declare CONFIG_ENV_OFFSET with its direct value instead.

Signed-off-by Fabio Estevam <[email protected]>

---
Changes since v3:
- Take the 69k u-boot.img offset into account when calculating CONFIG_BOARD_SIZE_LIMIT (Wolfgang)

Hi Stefano,

Quoted 11 lines · Fabio Estevam

U-Boot binary has grown in such a way that it goes beyond the reserved area for the environment variables.

Running "saveenv" causes U-Boot to hang because of this overlap.

Fix this problem by increasing the CONFIG_ENV_OFFSET size.

Also, in order to prevent this same problem in the future, use CONFIG_BOARD_SIZE_LIMIT, which will detect the overlap in build-time.

Quoted 8 lines

CONFIG_BOARD_SIZE_LIMIT does not accept math expressions, so declare CONFIG_ENV_OFFSET with its direct value instead.

Signed-off-by Fabio Estevam <[email protected]>

---
Changes since v3:
- Take the 69k u-boot.img offset into account when calculating CONFIG_BOARD_SIZE_LIMIT (Wolfgang)

Could you please consider applying this version?

Wolfgang's patch causes breakage on some systems as reported by Tom and I would prefer we fix the critical problem soon independently of Wolgang's fix.

Yes, I agree with you - we could have a follow up patch when Wolfgang's patch will be merged.