[U-Boot] [PATCH] distro: Disable iso partition format for SPL
When building an SPL binary, chances are quite slim that we need an iso partition label. However, there were reports of us exceeding our SPL memory limit with iso enabled.
So for now, let's disable the ISO partition format code when in the SPL build.
Reported-by: Heiko Schocher hs@denx.de Signed-off-by: Alexander Graf agraf@suse.de --- include/config_distro_defaults.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/config_distro_defaults.h b/include/config_distro_defaults.h index 5cc2af8..6a72f02 100644 --- a/include/config_distro_defaults.h +++ b/include/config_distro_defaults.h @@ -62,9 +62,12 @@ #define CONFIG_MENU #define CONFIG_DOS_PARTITION #define CONFIG_EFI_PARTITION -#define CONFIG_ISO_PARTITION #define CONFIG_SUPPORT_RAW_INITRD #define CONFIG_SYS_HUSH_PARSER #define CONFIG_ENV_VARS_UBOOT_CONFIG
+#ifndef CONFIG_SPL_BUILD +#define CONFIG_ISO_PARTITION +#endif + #endif /* _CONFIG_CMD_DISTRO_DEFAULTS_H */
Hello Alexander,
Am 25.04.2016 um 14:55 schrieb Alexander Graf:
When building an SPL binary, chances are quite slim that we need an iso partition label. However, there were reports of us exceeding our SPL memory limit with iso enabled.
So for now, let's disable the ISO partition format code when in the SPL build.
Reported-by: Heiko Schocher hs@denx.de Signed-off-by: Alexander Graf agraf@suse.de
include/config_distro_defaults.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
Thanks for the fix!
Acked-by: Heiko Schocher hs@denx.de
bye, Heiko
diff --git a/include/config_distro_defaults.h b/include/config_distro_defaults.h index 5cc2af8..6a72f02 100644 --- a/include/config_distro_defaults.h +++ b/include/config_distro_defaults.h @@ -62,9 +62,12 @@ #define CONFIG_MENU #define CONFIG_DOS_PARTITION #define CONFIG_EFI_PARTITION -#define CONFIG_ISO_PARTITION #define CONFIG_SUPPORT_RAW_INITRD #define CONFIG_SYS_HUSH_PARSER #define CONFIG_ENV_VARS_UBOOT_CONFIG
+#ifndef CONFIG_SPL_BUILD +#define CONFIG_ISO_PARTITION +#endif
- #endif /* _CONFIG_CMD_DISTRO_DEFAULTS_H */
On 04/25/2016 05:03 PM, Heiko Schocher wrote:
Hello Alexander,
Am 25.04.2016 um 14:55 schrieb Alexander Graf:
When building an SPL binary, chances are quite slim that we need an iso partition label. However, there were reports of us exceeding our SPL memory limit with iso enabled.
So for now, let's disable the ISO partition format code when in the SPL build.
Reported-by: Heiko Schocher hs@denx.de Signed-off-by: Alexander Graf agraf@suse.de
include/config_distro_defaults.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
Thanks for the fix!
Acked-by: Heiko Schocher hs@denx.de
Did you test and verify that this fixes the issue for you? My local compile was still too big, but I guess that's a toolchain difference thing :)
Alex
Hello Alexander,
Am 25.04.2016 um 17:04 schrieb Alexander Graf:
On 04/25/2016 05:03 PM, Heiko Schocher wrote:
Hello Alexander,
Am 25.04.2016 um 14:55 schrieb Alexander Graf:
When building an SPL binary, chances are quite slim that we need an iso partition label. However, there were reports of us exceeding our SPL memory limit with iso enabled.
So for now, let's disable the ISO partition format code when in the SPL build.
Reported-by: Heiko Schocher hs@denx.de Signed-off-by: Alexander Graf agraf@suse.de
include/config_distro_defaults.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
Thanks for the fix!
Acked-by: Heiko Schocher hs@denx.de
Did you test and verify that this fixes the issue for you? My local compile was still too big, but I guess that's a toolchain difference thing :)
I tested this patch for an am335x port, I soon post to mainline. With this patch, it compiled again clean for me.
Just tried the "igep0030_nand_defconfig" ... yes, it fails also with this patch:
without your patch: arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 1176 bytes
with it: arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 272 bytes
So, your patch saves some bytes, but this fix seems valid for me, so I acked it ... But it seems, there are more issues with this board ...
Ah, Tom already posted another fix, see: http://patchwork.ozlabs.org/patch/614516/
bye, Heiko
On Mon, Apr 25, 2016 at 05:18:38PM +0200, Heiko Schocher wrote:
Hello Alexander,
Am 25.04.2016 um 17:04 schrieb Alexander Graf:
On 04/25/2016 05:03 PM, Heiko Schocher wrote:
Hello Alexander,
Am 25.04.2016 um 14:55 schrieb Alexander Graf:
When building an SPL binary, chances are quite slim that we need an iso partition label. However, there were reports of us exceeding our SPL memory limit with iso enabled.
So for now, let's disable the ISO partition format code when in the SPL build.
Reported-by: Heiko Schocher hs@denx.de Signed-off-by: Alexander Graf agraf@suse.de
include/config_distro_defaults.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
Thanks for the fix!
Acked-by: Heiko Schocher hs@denx.de
Did you test and verify that this fixes the issue for you? My local compile was still too big, but I guess that's a toolchain difference thing :)
I tested this patch for an am335x port, I soon post to mainline. With this patch, it compiled again clean for me.
Just tried the "igep0030_nand_defconfig" ... yes, it fails also with this patch:
without your patch: arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 1176 bytes
with it: arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 272 bytes
So, your patch saves some bytes, but this fix seems valid for me, so I acked it ... But it seems, there are more issues with this board ...
Ah, Tom already posted another fix, see: http://patchwork.ozlabs.org/patch/614516/
The root problem is that we have a few boards that are once again close to the size limit, depending on toolchain. I'm slightly surprised that you aren't also telling me duovero is broken (that overflows for me depending on toolchaind and I've already asked the maintainer to look into trimming things). We may, in the end, have to take some not-nice patches for this release and see about maybe saying that OMAP3 also needs to use DDR for SPL stack, once set (and saying that ~4KiB space should be enough for stack space prior to DDR init).
participants (3)
-
Alexander Graf -
Heiko Schocher -
Tom Rini