OpenRD: relocate environment to 640kB
PATCH 1/1 OpenRD: relocate environment to 640kB
U-Boot has become slightly larger than where the environment sector was previously located. Saving the environment would brick the device.
Relocate the environment to where it is with the stock (i.e. Marvell USP) U-Boot version. That should give plenty of room for U-Boot to grow, including local customisations.
This obviously breaks compatibility with previous mainline versions of U-Boot. Users will need to back up the environment before an update and restore it afterwards, or manually copy it to the new address before the update.
--- include/configs/openrd.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
include/configs/openrd.h +2 -2
@@ -90,8 +90,8 @@* it has to be rounded to sector size */ #define CONFIG_ENV_SIZE 0x20000/* 128k */ -#define CONFIG_ENV_ADDR 0x60000 -#define CONFIG_ENV_OFFSET 0x60000/* env starts here */ +#define CONFIG_ENV_ADDR 0xa0000 +#define CONFIG_ENV_OFFSET 0xa0000/* env starts here */ /* * Default environment variables
Signature · 1 line
1.8.2.1
PATCH 1/1 OpenRD: relocate environment to 640kB
Hi Sascha,
Quoted 22 lines · Sascha Silbe
U-Boot has become slightly larger than where the environment sector was previously located. Saving the environment would brick the device.
Relocate the environment to where it is with the stock (i.e. Marvell USP) U-Boot version. That should give plenty of room for U-Boot to grow, including local customisations.
This obviously breaks compatibility with previous mainline versions of U-Boot. Users will need to back up the environment before an update and restore it afterwards, or manually copy it to the new address before the update.
Signed-off-by Sascha Silbe <[email protected]>--- include/configs/openrd.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)include/configs/openrd.h +0
-0
include/configs/openrd.h line 97
Quoted 10 lines
include/configs/openrd.h +2
-2@@ -90,8 +90,8 @@* it has to be rounded to sector size */ #define CONFIG_ENV_SIZE 0x20000/* 128k */ -#define CONFIG_ENV_ADDR 0x60000 -#define CONFIG_ENV_OFFSET 0x60000/* env starts here */ +#define CONFIG_ENV_ADDR 0xa0000 +#define CONFIG_ENV_OFFSET 0xa0000/* env starts here */ /* * Default environment variables
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 OpenRD: relocate environment to 640kB
Quoted 48 lines · Albert ARIBAUD
Hi Sascha,
Quoted 22 lines · Sascha Silbe
U-Boot has become slightly larger than where the environment sector was previously located. Saving the environment would brick the device.
Relocate the environment to where it is with the stock (i.e. Marvell USP) U-Boot version. That should give plenty of room for U-Boot to grow, including local customisations.
This obviously breaks compatibility with previous mainline versions of U-Boot. Users will need to back up the environment before an update and restore it afterwards, or manually copy it to the new address before the update.
Signed-off-by Sascha Silbe <[email protected]>--- include/configs/openrd.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)include/configs/openrd.h +0
-0include/configs/openrd.h line 97
Quoted 10 lines
include/configs/openrd.h +2
-2@@ -90,8 +90,8 @@* it has to be rounded to sector size */ #define CONFIG_ENV_SIZE 0x20000/* 128k */ -#define CONFIG_ENV_ADDR 0x60000 -#define CONFIG_ENV_OFFSET 0x60000/* env starts here */ +#define CONFIG_ENV_ADDR 0xa0000 +#define CONFIG_ENV_OFFSET 0xa0000/* env starts here */ /* * Default environment variables CC ing Tom.This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Quoted 4 lines
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
Amicalement,
Ping.
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 OpenRD: relocate environment to 640kB
Quoted 51 lines · Albert ARIBAUD
Quoted 48 lines · Albert ARIBAUD
Hi Sascha,
Quoted 22 lines · Sascha Silbe
U-Boot has become slightly larger than where the environment sector was previously located. Saving the environment would brick the device.
Relocate the environment to where it is with the stock (i.e. Marvell USP) U-Boot version. That should give plenty of room for U-Boot to grow, including local customisations.
This obviously breaks compatibility with previous mainline versions of U-Boot. Users will need to back up the environment before an update and restore it afterwards, or manually copy it to the new address before the update.
Signed-off-by Sascha Silbe <[email protected]>--- include/configs/openrd.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)include/configs/openrd.h +0
-0include/configs/openrd.h line 97
Quoted 10 lines
include/configs/openrd.h +2
-2@@ -90,8 +90,8 @@* it has to be rounded to sector size */ #define CONFIG_ENV_SIZE 0x20000/* 128k */ -#define CONFIG_ENV_ADDR 0x60000 -#define CONFIG_ENV_OFFSET 0x60000/* env starts here */ +#define CONFIG_ENV_ADDR 0xa0000 +#define CONFIG_ENV_OFFSET 0xa0000/* env starts here */ /* * Default environment variables CC ing Tom.This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Quoted 6 lines
Quoted 4 lines
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
Amicalement,
Ping.
Oh right, agree your idea here.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130622/9653d35d/attachment.pgp>
PATCH 1/1 OpenRD: relocate environment to 640kB
In reply to Albert ARIBAUDHello Albert, hello Tom,
Albert ARIBAUD <[email protected]> writes:
[Move environment to account for increase in U-Boot size]
Quoted 11 lines
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
Where are the U-Boot Release Notes located? Who is responsible for editing them?
Sascha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130625/0dfd227e/attachment.pgp>
PATCH 1/1 OpenRD: relocate environment to 640kB
Hi Sascha,
Quoted 13 lines · Sascha Silbe
Hello Albert, hello Tom,
Albert ARIBAUD <[email protected]> writes:
[Move environment to account for increase in U-Boot size]
Quoted 8 lines
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Quoted 7 lines
Quoted 3 lines
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
Quoted 4 lines
Where are the U-Boot Release Notes located? Who is responsible for editing them?
Sascha
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 OpenRD: relocate environment to 640kB
Quoted 22 lines · Albert ARIBAUD
Hi Sascha,
Quoted 17 lines · Sascha Silbe
Hello Albert, hello Tom,
Albert ARIBAUD <[email protected]> writes:
[Move environment to account for increase in U-Boot size]
Quoted 11 lines
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
Quoted 6 lines
Quoted 3 lines
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
I imagine that adding -ffunction-sections/-fdata-sections/--gc-sections is what brought the size back down again. We've been adding a lot of kinda optional code, and to avoid having to ifdef the hell out of everything, we've been relying on growth not being a big problem or just ignoring it.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130711/b57f82ef/attachment.pgp>
PATCH 1/1 OpenRD: relocate environment to 640kB
Hi Tom,
Quoted 27 lines · Tom Rini
Quoted 26 lines · Albert ARIBAUD
Hi Sascha,
Quoted 20 lines · Sascha Silbe
Hello Albert, hello Tom,
Albert ARIBAUD <[email protected]> writes:
[Move environment to account for increase in U-Boot size]
Quoted 11 lines
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
Quoted 8 lines
Quoted 2 lines
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
I imagine that adding -ffunction-sections/-fdata-sections/--gc-sections is what brought the size back down again. We've been adding a lot of kinda optional code, and to avoid having to ifdef the hell out of everything, we've been relying on growth not being a big problem or just ignoring it.
... Which in the end can bite back, see anonymous string issue. Are we heading back to carefully selecting which files we build rather than building then dropping?
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 OpenRD: relocate environment to 640kB
Quoted 40 lines · Albert ARIBAUD
Hi Tom,
Quoted 27 lines · Tom Rini
Quoted 26 lines · Albert ARIBAUD
Hi Sascha,
Quoted 20 lines · Sascha Silbe
Hello Albert, hello Tom,
Albert ARIBAUD <[email protected]> writes:
[Move environment to account for increase in U-Boot size]
Quoted 11 lines
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
Quoted 8 lines
Quoted 2 lines
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
I imagine that adding -ffunction-sections/-fdata-sections/--gc-sections is what brought the size back down again. We've been adding a lot of kinda optional code, and to avoid having to ifdef the hell out of everything, we've been relying on growth not being a big problem or just ignoring it.
Quoted 3 lines
... Which in the end can bite back, see anonymous string issue. Are we heading back to carefully selecting which files we build rather than building then dropping?
It depends on what we can get from the tools we have, cleanly. I've seen, for example, patches to kill all output from SPL, as that was required to get the required big features into a size constrained SPL. But I don't think it was clean enough for mainline. On the other hand, we've got some large files, and if splitting them up for logical uses also gets us working around string issues, good for us.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130711/05057f8d/attachment.pgp>
PATCH 1/1 OpenRD: relocate environment to 640kB
In reply to Albert ARIBAUDQuoted 5 lines · Albert ARIBAUD
Quoted 3 lines
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
I had the same questions and tried a few buildman runs, but didn't get a clear picture. The size was going up and down for various slices of commits.
With v2013.07-rc3, we are now at 376344B (? 96% of 384KiB) for openrd_ultimate when built on Debian Wheezy using gcc-4.7-arm-linux-gnueabi from Emdebian.
Is there an equivalent to CONFIG_SPL_MAX_SIZE for the "regular" U-Boot? Detecting the overlap at build time would prevent bricking the device using saveenv at run time. As an additional benefit, commits that push the size beyond the limit would also show up in buildman reports as build failures.
Sascha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130715/6eb39e33/attachment.pgp>
PATCH 1/1 OpenRD: relocate environment to 640kB
Hi Sascha,
Quoted 8 lines · Sascha Silbe
Quoted 5 lines · Albert ARIBAUD
Quoted 3 lines
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
Quoted 7 lines
I had the same questions and tried a few buildman runs, but didn't get a clear picture. The size was going up and down for various slices of commits.
With v2013.07-rc3, we are now at 376344B (? 96% of 384KiB) for
openrd_ultimatewhen built on Debian Wheezy using gcc-4.7-arm-linux-gnueabi from Emdebian.
Thanks for the info.
Quoted 5 lines
Is there an equivalent to
CONFIG_SPL_MAX_SIZEfor the "regular" U-Boot? Detecting the overlap at build time would prevent bricking the device using saveenv at run time. As an additional benefit, commits that push the size beyond the limit would also show up in buildman reports as build failures.
I don't know of a feature like CONFIG_SPL_MAX_SIZE for regular U-Boot. You could 'port it over' as something like CONFIG_MAX_IMAGE_SIZE for U-Boot.
Somehow I gather that an approach like the one I sketched out in
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/165510
could bring benefits like making CONFIG_SPL_MAX_SIZE a feature of a "constraints" component which could be built as well in U-Boot as in SPL; but that's at the very early RFC stage anyway -- actually, it drew no reaction at all so far, leading me to think it's not that useful.
Quoted 1 line
Sascha
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 OpenRD: relocate environment to 640kB
In reply to Sascha SilbeQuoted 16 lines · Sascha Silbe
Quoted 5 lines · Albert ARIBAUD
Quoted 3 lines
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
I had the same questions and tried a few buildman runs, but didn't get a clear picture. The size was going up and down for various slices of commits.
With v2013.07-rc3, we are now at 376344B (??? 96% of 384KiB) for
openrd_ultimatewhen built on Debian Wheezy using gcc-4.7-arm-linux-gnueabi from Emdebian.
Quoted 5 lines
Is there an equivalent to
CONFIG_SPL_MAX_SIZEfor the "regular" U-Boot? Detecting the overlap at build time would prevent bricking the device using saveenv at run time. As an additional benefit, commits that push the size beyond the limit would also show up in buildman reports as build failures.
Yes, you can try using CONFIG_BOARD_SIZE_LIMIT, which is missing from the README, but does have a few examples (git grep around). A patch to document it, and then a patch to enable for openrd would be much appreciated. Thanks!
Quoted 9 lines
Sascha
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130715/0631d2de/attachment.pgp>
PATCH 1/1 OpenRD: relocate environment to 640kB
Hi Sascha,
Quoted 23 lines · Tom Rini
Quoted 16 lines · Sascha Silbe
Quoted 5 lines · Albert ARIBAUD
Quoted 3 lines
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
I had the same questions and tried a few buildman runs, but didn't get a clear picture. The size was going up and down for various slices of commits.
With v2013.07-rc3, we are now at 376344B (??? 96% of 384KiB) for
openrd_ultimatewhen built on Debian Wheezy using gcc-4.7-arm-linux-gnueabi from Emdebian.Quoted 5 lines
Is there an equivalent to
CONFIG_SPL_MAX_SIZEfor the "regular" U-Boot? Detecting the overlap at build time would prevent bricking the device using saveenv at run time. As an additional benefit, commits that push the size beyond the limit would also show up in buildman reports as build failures.
Quoted 4 lines
Yes, you can try using
CONFIG_BOARD_SIZE_LIMIT, which is missing from the README, but does have a few examples (git grep around). A patch to document it, and then a patch to enable for openrd would be much appreciated. Thanks!
Sascha, does this mean the env relocate patch here is dropped in favor of a CONFIG_BOARD_SIZE_LIMIT check at build time?
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 OpenRD: relocate environment to 640kB
Hi Albert,
Quoted 6 lines · Albert ARIBAUD
Quoted 5 lines · Tom Rini
Quoted 3 lines · Sascha Silbe
With v2013.07-rc3, we are now at 376344B (~ 96% of 384KiB) for
openrd_ultimatewhen built on Debian Wheezy using gcc-4.7-arm-linux-gnueabi from Emdebian.
[...]
Quoted 7 lines
Quoted 4 lines
Yes, you can try using
CONFIG_BOARD_SIZE_LIMIT, which is missing from the README, but does have a few examples (git grep around). A patch to document it, and then a patch to enable for openrd would be much appreciated. Thanks!Sascha, does this mean the env relocate patch here is dropped in favor of a
CONFIG_BOARD_SIZE_LIMITcheck at build time?
Given that we're already very close to the limit, we'll likely need the environment relocation patch sooner or later anyway. I'd prefer it to go in now as part of the regular release cycle, rather than as a hot-fix whenever it finally spills over. That also reduces the risk of builds failing only with particular toolchain versions.
Sascha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130811/09029416/attachment.pgp>
cover openrd: Check U-Boot size at build time
In reply to Tom RiniQuoted 4 lines · Tom Rini
Yes, you can try using
CONFIG_BOARD_SIZE_LIMIT, which is missing from the README, but does have a few examples (git grep around). A patch to document it, and then a patch to enable for openrd would be much appreciated. Thanks!
Thanks for the pointer. Here we go.
Sascha Silbe (3):
README: document CONFIG_BOARD_SIZE_LIMIT
Makefile: check native boot image sizes against
CONFIG_BOARD_SIZE_LIMIT
openrd: fail build if U-Boot would overlap with environment in flash
Makefile | 3 +++ README | 5 +++++ include/configs/openrd.h | 5 +++++ 3 files changed, 13 insertions(+)
Signature · 1 line
1.8.3.2
PATCH 1/3 README: document CONFIG_BOARD_SIZE_LIMIT
CONFIG_BOARD_SIZE_LIMIT was introduced by f3a14d37 [Makefile: allow boards to check file size limits] and is in use by several boards, but never got documented.
--- README | 5 +++++ 1 file changed, 5 insertions(+)
README +5 -0
@@ -3843,6 +3843,11 @@ use the "saveenv" command to store a valid environment. later, once stdio is running and output goes to the LCD, if present. +- CONFIG_BOARD_SIZE_LIMIT: + Maximum size of the U-Boot image. When defined, the + build system checks that the actual size does not + exceed it. + Low Level (hardware related) configuration options: ---------------------------------------------------
Signature · 1 line
1.8.3.2
PATCH 1/3 README: document CONFIG_BOARD_SIZE_LIMIT
Quoted 8 lines · On Sun, 11 Aug 2013 16:40:43 +0200 Sascha Silbe <[email protected]> wrote:
CONFIG_BOARD_SIZE_LIMITwas introduced byf3a14d37[Makefile: allow boards to check file size limits] and is in use by several boards, but never got documented.Signed-off-by Sascha Silbe <[email protected]>--- README | 5 +++++ 1 file changed, 5 insertions(+)
applied to u-boot-staging/agust at denx.de. thanks!
Anatolij
PATCH 2/3 Makefile: check native boot image sizes against CONFIG_BOARD_SIZE_LIMIT
In reply to Sascha SilbeThe purpose of CONFIG_BOARD_SIZE_LIMIT is to make sure that U-Boot fits into the space reserved for it in some permanent storage. This includes any overhead incurred by native boot image formats, so check the final image against the size limit, too.
--- Makefile | 3 +++ 1 file changed, 3 insertions(+)
Makefile +3 -0
@@ -459,15 +459,18 @@ $(obj)u-boot.img: $(obj)u-boot.bin $(obj)u-boot.imx: $(obj)u-boot.bin depend $(MAKE) -C $(SRCTREE)/arch/arm/imx-common $(OBJTREE)/u-boot.imx + $(BOARD_SIZE_CHECK) $(obj)u-boot.kwb: $(obj)u-boot.bin $(obj)tools/mkimage -n $(CONFIG_SYS_KWD_CONFIG) -T kwbimage \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) -d $< $@ + $(BOARD_SIZE_CHECK) $(obj)u-boot.pbl: $(obj)u-boot.bin $(obj)tools/mkimage -n $(CONFIG_PBLRCW_CONFIG) \ -R $(CONFIG_PBLPBI_CONFIG) -T pblimage \ -d $< $@ + $(BOARD_SIZE_CHECK) $(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)tools/ubsha1 $(obj)u-boot.bin
Signature · 1 line
1.8.3.2
PATCH 2/3 Makefile: check native boot image sizes against CONFIG_BOARD_SIZE_LIMIT
Quoted 9 lines · On Sun, 11 Aug 2013 16:40:44 +0200 Sascha Silbe <[email protected]> wrote:
The purpose of
CONFIG_BOARD_SIZE_LIMITis to make sure that U-Boot fits into the space reserved for it in some permanent storage. This includes any overhead incurred by native boot image formats, so check the final image against the size limit, too.Signed-off-by Sascha Silbe <[email protected]>--- Makefile | 3 +++ 1 file changed, 3 insertions(+)
this patch doesn't apply any more.
Anatolij
PATCH 3/3 openrd: fail build if U-Boot would overlap with environment in flash
In reply to Sascha SilbeSet CONFIG_BOARD_SIZE_LIMIT so we'll notice at build time if U-Boot has grown so large that it would overlap with the environment area in flash, rather than bricking the device at run-time on first saveenv.
--- include/configs/openrd.h | 5 +++++ 1 file changed, 5 insertions(+)
include/configs/openrd.h +5 -0
@@ -76,6 +76,11 @@#define CONFIG_ENV_SIZE 0x20000/* 128k */ #define CONFIG_ENV_ADDR 0x60000#define CONFIG_ENV_OFFSET 0x60000/* env starts here */ +/* +* Environment is right behind U-Boot in flash. Make sure U-Boot +* doesn't grow into the environment area. +*/ +#define CONFIG_BOARD_SIZE_LIMIT CONFIG_ENV_OFFSET/* * Default environment variables
Signature · 1 line
1.8.3.2
PATCH 3/3 openrd: fail build if U-Boot would overlap with environment in flash
Quoted 8 lines · On Sun, 11 Aug 2013 16:40:45 +0200 Sascha Silbe <[email protected]> wrote:
Set
CONFIG_BOARD_SIZE_LIMITso we'll notice at build time if U-Boot has grown so large that it would overlap with the environment area in flash, rather than bricking the device at run-time on first saveenv.Signed-off-by Sascha Silbe <[email protected]>--- include/configs/openrd.h | 5 +++++ 1 file changed, 5 insertions(+)
applied to u-boot-staging/agust at denx.de. thanks!
Anatolij