[U-Boot] [RFC/PATCH] Makefile: allow boards to check file size limits
Boards often have a reserved size limit on the flash where they're stored. Sometimes during upgrades or config changes, those limits are exceeded, but no one notices until they try to upgrade and the limit screws things up. Either not enough of U-Boot is written to flash (and so the reboot fails), or too much is written (and so things after it get clobbered).
So allow boards to declare a size limit (in bytes) and have the build system check it while building.
Signed-off-by: Mike Frysinger vapier@gentoo.org --- Makefile | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile index de4ceb9..ca12d78 100644 --- a/Makefile +++ b/Makefile @@ -304,6 +304,21 @@ __LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD)) ######################################################################### #########################################################################
+ifneq ($(CONFIG_BOARD_SIZE_LIMIT),) +BOARD_SIZE_CHECK = \ + @actual=`wc -c $@ | awk '{print $$1}'`; \ + limit=$(CONFIG_BOARD_SIZE_LIMIT); \ + if test $$actual -gt $$limit; then \ + echo "$@ exceeds file size limit:"; \ + echo " limit: $$limit bytes"; \ + echo " actual: $$actual bytes"; \ + echo " excess: $$((actual - limit)) bytes"; \ + exit 1; \ + fi +else +BOARD_SIZE_CHECK = +endif + # Always append ALL so that arch config.mk's can add custom ones ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map $(U_BOOT_NAND) $(U_BOOT_ONENAND)
@@ -317,10 +332,12 @@ $(obj)u-boot.srec: $(obj)u-boot
$(obj)u-boot.bin: $(obj)u-boot $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@ + $(BOARD_SIZE_CHECK)
$(obj)u-boot.ldr: $(obj)u-boot $(CREATE_LDR_ENV) $(LDR) -T $(CONFIG_BFIN_CPU) -c $@ $< $(LDR_FLAGS) + $(BOARD_SIZE_CHECK)
$(obj)u-boot.ldr.hex: $(obj)u-boot.ldr $(OBJCOPY) ${OBJCFLAGS} -O ihex $< $@ -I binary
Dear Mike Frysinger,
In message 1287025103-26681-1-git-send-email-vapier@gentoo.org you wrote:
Boards often have a reserved size limit on the flash where they're stored. Sometimes during upgrades or config changes, those limits are exceeded, but no one notices until they try to upgrade and the limit screws things up. Either not enough of U-Boot is written to flash (and so the reboot fails), or too much is written (and so things after it get clobbered).
So allow boards to declare a size limit (in bytes) and have the build system check it while building.
Signed-off-by: Mike Frysinger vapier@gentoo.org
Makefile | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile index de4ceb9..ca12d78 100644 --- a/Makefile +++ b/Makefile @@ -304,6 +304,21 @@ __LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD)) ######################################################################### #########################################################################
+ifneq ($(CONFIG_BOARD_SIZE_LIMIT),) +BOARD_SIZE_CHECK = \
- @actual=`wc -c $@ | awk '{print $$1}'`; \
How about using
stat -c '%s'
to get the file size in a single command, without need to actually read all the data?
Best regards,
Wolfgang Denk
On Monday, October 18, 2010 16:43:37 Wolfgang Denk wrote:
Mike Frysinger wrote:
+ifneq ($(CONFIG_BOARD_SIZE_LIMIT),) +BOARD_SIZE_CHECK = \
- @actual=`wc -c $@ | awk '{print $$1}'`; \
How about using
stat -c '%s'
to get the file size in a single command, without need to actually read all the data?
because `stat` isnt portable :(. it isnt part of the POSIX standard ... OS X certainly does not support this, and i imagine most *BSD's dont.
`wc -c` on the other hand should work everywhere and is part of POSIX. looking at the `strace` output, the GNU wc doesnt actually read() the file when using just the -c option. seems to use lseek(SEEK_END). -mike
Dear Mike Frysinger,
In message 201010190017.52346.vapier@gentoo.org you wrote:
- @actual=`wc -c $@ | awk '{print $$1}'`; \
How about using
stat -c '%s'
to get the file size in a single command, without need to actually read all the data?
because `stat` isnt portable :(. it isnt part of the POSIX standard ... OSX certainly does not support this, and i imagine most *BSD's dont.
I see (well, at least FreeBSD 8.1 has "stat"; their man page claims it "appeared in NetBSD 1.6 and FreeBSD 4.10).
Best regards,
Wolfgang Denk
On Tuesday, October 19, 2010 01:24:44 Wolfgang Denk wrote:
Mike Frysinger wrote:
- @actual=`wc -c $@ | awk '{print $$1}'`; \
How about using
stat -c '%s'
to get the file size in a single command, without need to actually read all the data?
because `stat` isnt portable :(. it isnt part of the POSIX standard ... OSX certainly does not support this, and i imagine most *BSD's dont.
I see (well, at least FreeBSD 8.1 has "stat"; their man page claims it "appeared in NetBSD 1.6 and FreeBSD 4.10).
yes, but what i was referring to was the command line options. everyone has `stat`, but it's really only the GNU stat that supports the '-c fmt' option using the semantics necessary here. `wc -c` is going to work everywhere, but i would need to figure out what OS i'm on and where `stat` is coming from so i would know how to properly invoke it. -mike
Dear Mike Frysinger,
In message 1287025103-26681-1-git-send-email-vapier@gentoo.org you wrote:
Boards often have a reserved size limit on the flash where they're stored. Sometimes during upgrades or config changes, those limits are exceeded, but no one notices until they try to upgrade and the limit screws things up. Either not enough of U-Boot is written to flash (and so the reboot fails), or too much is written (and so things after it get clobbered).
So allow boards to declare a size limit (in bytes) and have the build system check it while building.
Signed-off-by: Mike Frysinger vapier@gentoo.org
Makefile | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
Hi,
The size of other sections like the bss section also need to be accounted for when doing a size check.
Insufficient space for bss when doing something like a MMC read which requires large buffers causes system hangs for no apparent reason.
Regards, Vaibhav
On Wed, Oct 20, 2010 at 2:59 AM, Wolfgang Denk wd@denx.de wrote:
Dear Mike Frysinger,
In message 1287025103-26681-1-git-send-email-vapier@gentoo.org you wrote:
Boards often have a reserved size limit on the flash where they're
stored.
Sometimes during upgrades or config changes, those limits are exceeded, but no one notices until they try to upgrade and the limit screws things up. Either not enough of U-Boot is written to flash (and so the reboot fails), or too much is written (and so things after it get clobbered).
So allow boards to declare a size limit (in bytes) and have the build system check it while building.
Signed-off-by: Mike Frysinger vapier@gentoo.org
Makefile | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de A memorandum is written not to inform the reader, but to protect the writer. -- Dean Acheson _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Wednesday, October 20, 2010 00:38:08 Vaibhav Bedia wrote:
please do not top post
The size of other sections like the bss section also need to be accounted for when doing a size check.
that really cannot be checked at compile time. it certainly cannot be done easily or with a few lines of shell code.
Insufficient space for bss when doing something like a MMC read which requires large buffers causes system hangs for no apparent reason.
that doesnt make much sense. bss is statically allocated. either it exists, or it doesnt. if bss doesnt work, your system/build is fundamentally screwed. either way, none of this is related to my patch. -mike
On Wed, Oct 20, 2010 at 10:46 AM, Mike Frysinger vapier@gentoo.org wrote:
On Wednesday, October 20, 2010 00:38:08 Vaibhav Bedia wrote:
please do not top post
Sorry about the top posting.
The size of other sections like the bss section also need to be accounted for when doing a size check.
that really cannot be checked at compile time. it certainly cannot be done easily or with a few lines of shell code.
Insufficient space for bss when doing something like a MMC read which requires large buffers causes system hangs for no apparent reason.
that doesnt make much sense. bss is statically allocated. either it exists, or it doesnt. if bss doesnt work, your system/build is fundamentally screwed.
Just displaying the binary size can be misleading IMHO. If the info printed contains the complete memory requirement (stack+heap+bss) then it can potentially save a lot of time during debugging
either way, none of this is related to my patch.
-mike
Dear Vaibhav Bedia,
In message AANLkTinvwZsVZosDgLtGV2LiJhU0QWQoQdfD765z=1SH@mail.gmail.com you wrote:
Just displaying the binary size can be misleading IMHO. If the info printed contains the complete memory requirement (stack+heap+bss) then it can potentially save a lot of time during debugging
Just run "MAKEALL" for your board and you get exactly what you are asking for,
either way, none of this is related to my patch.
-mike
You really need to get your quoting right.
Please read http://www.netmeister.org/news/learn2quote.html
--0016e649837c8d6440049306e906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
And STOP posting HTML!
Best regards,
Wolfgang Denk
participants (3)
-
Mike Frysinger -
Vaibhav Bedia -
Wolfgang Denk