[U-Boot] [PATCH v3] warp7: Fix U-Boot corruption after saving the environment
U-Boot binary has grown in such a way that it goes beyond the reserved area for the environment variables.
Running "saveenv" followed by a "reset" causes U-Boot to hang because of this overlap.
Fix this problem by selecting CONFIG_SYS_THUMB_BUILD=y, which generates a smaller u-boot-dtb.imx binary.
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 festevam@gmail.com --- Changes since v2: - Select CONFIG_SYS_THUMB_BUILD=y (Tom)
configs/warp7_defconfig | 1 + include/configs/warp7.h | 13 +++++++++++++ 2 files changed, 14 insertions(+)
diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index 72cdb684a7..781cbe12d7 100644 --- a/configs/warp7_defconfig +++ b/configs/warp7_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_SYS_THUMB_BUILD=y CONFIG_ARCH_MX7=y CONFIG_SYS_TEXT_BASE=0x87800000 CONFIG_TARGET_WARP7=y diff --git a/include/configs/warp7.h b/include/configs/warp7.h index 9a82581c5f..af278c617e 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -125,6 +125,19 @@ #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
+/* + * Environment starts at CONFIG_ENV_OFFSET = 0x80000 = 512k + * + * Detect overlap between U-Boot image and environment area in build-time + * + * CONFIG_BOARD_SIZE_LIMIT = CONFIG_ENV_OFFSET - u-boot.imx offset + * CONFIG_BOARD_SIZE_LIMIT = 512k - 1k = 511k = 523264 + * + * Currently CONFIG_BOARD_SIZE_LIMIT does not handle expressions, so + * write the direct value here + */ +#define CONFIG_BOARD_SIZE_LIMIT 523264 + /* I2C configs */ #define CONFIG_SYS_I2C_MXC #define CONFIG_SYS_I2C_SPEED 100000
On Tue, Dec 03, 2019 at 12:04:46AM -0300, Fabio Estevam wrote:
U-Boot binary has grown in such a way that it goes beyond the reserved area for the environment variables.
Running "saveenv" followed by a "reset" causes U-Boot to hang because of this overlap.
Fix this problem by selecting CONFIG_SYS_THUMB_BUILD=y, which generates a smaller u-boot-dtb.imx binary.
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 festevam@gmail.com
Thanks for the rework. Can you please look at what other i.MX boards are likely fine, or perhaps more clearly if any i.MX5/6 SoCs do have thumb2 related errata that might make it a bad idea to use thumb by default ?
Reviewed-by: Tom Rini trini@konsulko.com
Hi Tom,
On Tue, Dec 3, 2019 at 12:10 AM Tom Rini trini@konsulko.com wrote:
Thanks for the rework. Can you please look at what other i.MX boards are likely fine, or perhaps more clearly if any i.MX5/6 SoCs do have thumb2 related errata that might make it a bad idea to use thumb by default ?
It looks like i.MX51 and i.MX53 have the thumb related erratum: https://www.nxp.com/docs/en/errata/IMX53CE.pdf
i.MX6 series should work fine in thumb without issues and we could try to enable thumb by default for the next cycle.
Reviewed-by: Tom Rini trini@konsulko.com
-- Tom
On Tue, Dec 03, 2019 at 08:56:05AM -0300, Fabio Estevam wrote:
Hi Tom,
On Tue, Dec 3, 2019 at 12:10 AM Tom Rini trini@konsulko.com wrote:
Thanks for the rework. Can you please look at what other i.MX boards are likely fine, or perhaps more clearly if any i.MX5/6 SoCs do have thumb2 related errata that might make it a bad idea to use thumb by default ?
It looks like i.MX51 and i.MX53 have the thumb related erratum: https://www.nxp.com/docs/en/errata/IMX53CE.pdf
i.MX6 series should work fine in thumb without issues and we could try to enable thumb by default for the next cycle.
Thanks!
Hello Fabio,
Am 03.12.2019 um 12:56 schrieb Fabio Estevam:
Hi Tom,
On Tue, Dec 3, 2019 at 12:10 AM Tom Rini trini@konsulko.com wrote:
Thanks for the rework. Can you please look at what other i.MX boards are likely fine, or perhaps more clearly if any i.MX5/6 SoCs do have thumb2 related errata that might make it a bad idea to use thumb by default ?
It looks like i.MX51 and i.MX53 have the thumb related erratum: https://www.nxp.com/docs/en/errata/IMX53CE.pdf
i.MX6 series should work fine in thumb without issues and we could try to enable thumb by default for the next cycle.
I just enabled thumb build [1] for the DM/DTS rework for the imx6 based aristainetos board ... and as I can say, U-Boot works fine on it.
bye, Heiko [1] http://patchwork.ozlabs.org/patch/1202811/
On Tue, Dec 03, 2019 at 06:07:57PM +0100, Heiko Schocher wrote:
Hello Fabio,
Am 03.12.2019 um 12:56 schrieb Fabio Estevam:
Hi Tom,
On Tue, Dec 3, 2019 at 12:10 AM Tom Rini trini@konsulko.com wrote:
Thanks for the rework. Can you please look at what other i.MX boards are likely fine, or perhaps more clearly if any i.MX5/6 SoCs do have thumb2 related errata that might make it a bad idea to use thumb by default ?
It looks like i.MX51 and i.MX53 have the thumb related erratum: https://www.nxp.com/docs/en/errata/IMX53CE.pdf
i.MX6 series should work fine in thumb without issues and we could try to enable thumb by default for the next cycle.
I just enabled thumb build [1] for the DM/DTS rework for the imx6 based aristainetos board ... and as I can say, U-Boot works fine on it.
There's a number of other SoCs using it too :) It really just isn't default due to the problems of early-generation ARMv7 platforms and in turn my not wanting to break them by accident. But with that in mind, a deeper dive in to a few different vendor SoCs should tell us which ones need to default to off and what can be on, and we could get better size defaults all around (but not force, let people decide if thumb2-but-smaller is quicker boot than full-but-larger).
participants (3)
-
Fabio Estevam -
Heiko Schocher -
Tom Rini