[U-Boot] [PATCH 1/4] ARM: fix u-boot.lds for -ffunction-sections/-fdata-sections
From: Stephen Warren swarren@nvidia.com
When -ffunction-sections or -fdata-section are used, symbols are placed into sections such as .data.eserial1_device and .bss.serial_current. Update the linker script to explicitly include these. Without this change (at least with my gcc-4.5.3 built using crosstool-ng), I see that the sections do end up being included, but __bss_end__ gets set to the same value as __bss_start.
Signed-off-by: Stephen Warren swarren@nvidia.com --- This series fixes an SPL size overflow problem on Tegra. Tom Warren is out on vacation until Oct 25th, so he certainly won't be able to review this. Perhaps it could be applied directly to the ARM tree if enough Tegra people ack the series?
Note that this series is not enough to make Tegra support work; either you must hack ./arch/arm/cpu/arm720t/tegra-common/spl.c to call serial_initialize() right before serial_init() in preloader_console_init() or wait for Allen Martin to rework Tegra's SPL support using the common SPL code.
arch/arm/cpu/u-boot.lds | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds index e49ca0c..ae04a6e 100644 --- a/arch/arm/cpu/u-boot.lds +++ b/arch/arm/cpu/u-boot.lds @@ -35,7 +35,7 @@ SECTIONS { __image_copy_start = .; CPUDIR/start.o (.text) - *(.text) + *(.text*) }
. = ALIGN(4); @@ -43,14 +43,14 @@ SECTIONS
. = ALIGN(4); .data : { - *(.data) + *(.data*) }
. = ALIGN(4);
. = .; __u_boot_cmd_start = .; - .u_boot_cmd : { *(.u_boot_cmd) } + .u_boot_cmd : { *(.u_boot_cmd*) } __u_boot_cmd_end = .;
. = ALIGN(4); @@ -65,7 +65,7 @@ SECTIONS
.dynsym : { __dynsym_start = .; - *(.dynsym) + *(.dynsym*) }
_end = .; @@ -81,7 +81,7 @@ SECTIONS
.bss __rel_dyn_start (OVERLAY) : { __bss_start = .; - *(.bss) + *(.bss*) . = ALIGN(4); __bss_end__ = .; }
From: Stephen Warren swarren@nvidia.com
The rules to generate u-boot-{no,}dtb-tegra.bin were almost identical. Combine them into a single paremeterized rule. This will allow the next patch to edit a single rule, rather than being cut/paste twice.
Signed-off-by: Stephen Warren swarren@nvidia.com --- Makefile | 15 ++++++++------- 1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile index ab34fa7..425adf4 100644 --- a/Makefile +++ b/Makefile @@ -514,17 +514,18 @@ $(obj)u-boot.spr: $(obj)u-boot.img $(obj)spl/u-boot-spl.bin
ifeq ($(SOC),tegra20) ifeq ($(CONFIG_OF_SEPARATE),y) -$(obj)u-boot-dtb-tegra.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(obj)u-boot.dtb - $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SYS_TEXT_BASE) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin - cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin $(obj)u-boot.dtb > $@ - rm $(obj)spl/u-boot-spl-pad.bin +nodtb=dtb +dtbfile=$(obj)u-boot.dtb else -$(obj)u-boot-nodtb-tegra.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin +nodtb=nodtb +dtbfile= +endif + +$(obj)u-boot-$(nodtb)-tegra.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(dtbfile) $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SYS_TEXT_BASE) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin - cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $@ + cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin $(dtbfile) > $@ rm $(obj)spl/u-boot-spl-pad.bin endif -endif
ifeq ($(CONFIG_SANDBOX),y) GEN_UBOOT = \
Hi Stephen,
On Tue, Oct 16, 2012 at 2:50 PM, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
The rules to generate u-boot-{no,}dtb-tegra.bin were almost identical. Combine them into a single paremeterized rule. This will allow the next patch to edit a single rule, rather than being cut/paste twice.
Signed-off-by: Stephen Warren swarren@nvidia.com
Acked-by: Simon Glass sjg@chromium.org
Makefile | 15 ++++++++------- 1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile index ab34fa7..425adf4 100644 --- a/Makefile +++ b/Makefile @@ -514,17 +514,18 @@ $(obj)u-boot.spr: $(obj)u-boot.img $(obj)spl/u-boot-spl.bin
ifeq ($(SOC),tegra20) ifeq ($(CONFIG_OF_SEPARATE),y) -$(obj)u-boot-dtb-tegra.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(obj)u-boot.dtb
$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SYS_TEXT_BASE) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bincat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin $(obj)u-boot.dtb > $@rm $(obj)spl/u-boot-spl-pad.bin+nodtb=dtb +dtbfile=$(obj)u-boot.dtb else -$(obj)u-boot-nodtb-tegra.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin +nodtb=nodtb +dtbfile=
You could omit this line if you like.
+endif
+$(obj)u-boot-$(nodtb)-tegra.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(dtbfile)
If you like, you could have a continuation on this line as it is a bit long.
$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SYS_TEXT_BASE) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin > $@
cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin $(dtbfile) > $@ rm $(obj)spl/u-boot-spl-pad.binendif -endif
ifeq ($(CONFIG_SANDBOX),y) GEN_UBOOT = \ -- 1.7.0.4
Regards, Simon
From: Stephen Warren swarren@nvidia.com
If the SPL extends beyond CONFIG_SYS_TEXT_BASE, then it will likely corrupt the main U-Boot binary during execution, causing the main U-Boot binary to fail. Check for this situation during the build to avoid extremely annoying and hard-to-find bugs. Note that checking the size of u-boot-spl.bin is not enough, since BSS size doesn't affect the size of u-boot-spl.bin.
Signed-off-by: Stephen Warren swarren@nvidia.com --- Makefile | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile index 425adf4..2c2d8b6 100644 --- a/Makefile +++ b/Makefile @@ -522,6 +522,11 @@ dtbfile= endif
$(obj)u-boot-$(nodtb)-tegra.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(dtbfile) + ebss=`${CROSS_COMPILE}objdump -t spl/u-boot-spl|awk '/__bss_end__/ {print "0x"$$1}'` ; \ + if [ $$(($$ebss)) -gt $$(($(CONFIG_SYS_TEXT_BASE))) ]; then \ + echo ERROR: SPL BSS ends beyond CONFIG_SYS_TEXT_BASE > /dev/stderr; \ + exit 1; \ + fi $(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SYS_TEXT_BASE) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin $(dtbfile) > $@ rm $(obj)spl/u-boot-spl-pad.bin
Hi Stephen,
On Tue, Oct 16, 2012 at 2:50 PM, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
If the SPL extends beyond CONFIG_SYS_TEXT_BASE, then it will likely corrupt the main U-Boot binary during execution, causing the main U-Boot binary to fail. Check for this situation during the build to avoid extremely annoying and hard-to-find bugs. Note that checking the size of u-boot-spl.bin is not enough, since BSS size doesn't affect the size of u-boot-spl.bin.
Signed-off-by: Stephen Warren swarren@nvidia.com
Makefile | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile index 425adf4..2c2d8b6 100644 --- a/Makefile +++ b/Makefile @@ -522,6 +522,11 @@ dtbfile= endif
$(obj)u-boot-$(nodtb)-tegra.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(dtbfile)
ebss=`${CROSS_COMPILE}objdump -t spl/u-boot-spl|awk '/__bss_end__/ {print "0x"$$1}'` ; \if [ $$(($$ebss)) -gt $$(($(CONFIG_SYS_TEXT_BASE))) ]; then \echo ERROR: SPL BSS ends beyond CONFIG_SYS_TEXT_BASE > /dev/stderr; \exit 1; \fi
Just wanted to check that this works ok for hex values?
$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(CONFIG_SYS_TEXT_BASE) -O binary $(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin $(dtbfile) > $@ rm $(obj)spl/u-boot-spl-pad.bin-- 1.7.0.4
Regards, Simon
On 10/17/2012 06:03 PM, Simon Glass wrote:
Hi Stephen,
On Tue, Oct 16, 2012 at 2:50 PM, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
If the SPL extends beyond CONFIG_SYS_TEXT_BASE, then it will likely corrupt the main U-Boot binary during execution, causing the main U-Boot binary to fail. Check for this situation during the build to avoid extremely annoying and hard-to-find bugs. Note that checking the size of u-boot-spl.bin is not enough, since BSS size doesn't affect the size of u-boot-spl.bin.
diff --git a/Makefile b/Makefile
$(obj)u-boot-$(nodtb)-tegra.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin $(dtbfile)
ebss=`${CROSS_COMPILE}objdump -t spl/u-boot-spl|awk '/__bss_end__/ {print "0x"$$1}'` ; \if [ $$(($$ebss)) -gt $$(($(CONFIG_SYS_TEXT_BASE))) ]; then \echo ERROR: SPL BSS ends beyond CONFIG_SYS_TEXT_BASE > /dev/stderr; \exit 1; \fiJust wanted to check that this works ok for hex values?
Yes, the reason I used $(( )) around the value is because it was hex, so I needed to convert it to an integer for -gt.
On Tue, Oct 16, 2012 at 03:50:08PM -0600, Stephen Warren wrote:
From: Stephen Warren swarren@nvidia.com
If the SPL extends beyond CONFIG_SYS_TEXT_BASE, then it will likely corrupt the main U-Boot binary during execution, causing the main U-Boot binary to fail. Check for this situation during the build to avoid extremely annoying and hard-to-find bugs. Note that checking the size of u-boot-spl.bin is not enough, since BSS size doesn't affect the size of u-boot-spl.bin.
Signed-off-by: Stephen Warren swarren@nvidia.com
Can't you do this in the linker script like we do for other SPL size constraints? Or am I just mis-reading how this is unique and that link-time check can't be used? Thanks!
On 10/18/2012 10:27 AM, Tom Rini wrote:
On Tue, Oct 16, 2012 at 03:50:08PM -0600, Stephen Warren wrote:
From: Stephen Warren swarren@nvidia.com
If the SPL extends beyond CONFIG_SYS_TEXT_BASE, then it will likely corrupt the main U-Boot binary during execution, causing the main U-Boot binary to fail. Check for this situation during the build to avoid extremely annoying and hard-to-find bugs. Note that checking the size of u-boot-spl.bin is not enough, since BSS size doesn't affect the size of u-boot-spl.bin.
Signed-off-by: Stephen Warren swarren@nvidia.com
Can't you do this in the linker script like we do for other SPL size constraints? Or am I just mis-reading how this is unique and that link-time check can't be used? Thanks!
Ah, there aren't any such checks in the linker script I looked at, so I wasn't aware of this capability. I found the following in a different linker script:
ASSERT(__bss_end__ <= 0xfff01000, "NAND bootstrap too big");
I agree using that technique would make sense; I'll try it out.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/18/12 13:45, Stephen Warren wrote:
On 10/18/2012 10:27 AM, Tom Rini wrote:
On Tue, Oct 16, 2012 at 03:50:08PM -0600, Stephen Warren wrote:
From: Stephen Warren swarren@nvidia.com
If the SPL extends beyond CONFIG_SYS_TEXT_BASE, then it will likely corrupt the main U-Boot binary during execution, causing the main U-Boot binary to fail. Check for this situation during the build to avoid extremely annoying and hard-to-find bugs. Note that checking the size of u-boot-spl.bin is not enough, since BSS size doesn't affect the size of u-boot-spl.bin.
Signed-off-by: Stephen Warren swarren@nvidia.com
Can't you do this in the linker script like we do for other SPL size constraints? Or am I just mis-reading how this is unique and that link-time check can't be used? Thanks!
Ah, there aren't any such checks in the linker script I looked at, so I wasn't aware of this capability. I found the following in a different linker script:
ASSERT(__bss_end__ <= 0xfff01000, "NAND bootstrap too big");
I agree using that technique would make sense; I'll try it out.
There's a few different ones, sadly. grep around on CONFIG_SPL_MAX_SIZE.
- -- Tom
From: Stephen Warren swarren@nvidia.com
The SPL has grown. Increase CONFIG_SYS_TEXT_BASE so SPL's BSS does not overlap the main U-Boot.
Signed-off-by: Stephen Warren swarren@nvidia.com --- include/configs/tegra20-common.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h index dc7444d..ced278d 100644 --- a/include/configs/tegra20-common.h +++ b/include/configs/tegra20-common.h @@ -168,7 +168,7 @@ #define PHYS_SDRAM_1 NV_PA_SDRC_CS0 #define PHYS_SDRAM_1_SIZE 0x20000000 /* 512M */
-#define CONFIG_SYS_TEXT_BASE 0x0010c000 +#define CONFIG_SYS_TEXT_BASE 0x0010d000 #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
#define CONFIG_SYS_INIT_RAM_ADDR CONFIG_STACKBASE
Am Dienstag, den 16.10.2012, 15:50 -0600 schrieb Stephen Warren:
From: Stephen Warren swarren@nvidia.com
The SPL has grown. Increase CONFIG_SYS_TEXT_BASE so SPL's BSS does not overlap the main U-Boot.
Is there any specific reason why the SPL is now bigger than before? Or is this just because of the general U-Boot rework (like serial multi anywhere)? And by how much has it grown? This is really more out of curiosity rather than any real objection.
Aside from this I think the general idea is reasonable, as we are not shipping a particularly slim U-Boot on any Tegra platform, nor do we have to hit a hard size limit, so for the series:
Acked-by: Lucas Stach dev@lynxeye.de
Signed-off-by: Stephen Warren swarren@nvidia.com
include/configs/tegra20-common.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h index dc7444d..ced278d 100644 --- a/include/configs/tegra20-common.h +++ b/include/configs/tegra20-common.h @@ -168,7 +168,7 @@ #define PHYS_SDRAM_1 NV_PA_SDRC_CS0 #define PHYS_SDRAM_1_SIZE 0x20000000 /* 512M */
-#define CONFIG_SYS_TEXT_BASE 0x0010c000 +#define CONFIG_SYS_TEXT_BASE 0x0010d000 #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
#define CONFIG_SYS_INIT_RAM_ADDR CONFIG_STACKBASE
On 10/16/2012 04:09 PM, Lucas Stach wrote:
Am Dienstag, den 16.10.2012, 15:50 -0600 schrieb Stephen Warren:
From: Stephen Warren swarren@nvidia.com
The SPL has grown. Increase CONFIG_SYS_TEXT_BASE so SPL's BSS does not overlap the main U-Boot.
Is there any specific reason why the SPL is now bigger than before? Or is this just because of the general U-Boot rework (like serial multi anywhere)? And by how much has it grown? This is really more out of curiosity rather than any real objection.
Looking at this more, I built commit cca6076 "tegra20: Remove armv4t build flags" which was the last patch in the series that enabled SPL on Tegra, and it overflows even there:
Configuring for ventana board... text data bss dec hex filename 226085 4384 274228 504697 7b379 ./u-boot 13857 153 4516 18526 485e ./spl/u-boot-spl
u-boot/master currently has:
Configuring for ventana board... text data bss dec hex filename 233579 4432 274368 512379 7d17b ./u-boot 14382 201 4520 19103 4a9f ./spl/u-boot-spl
So, there is slight growth, but mainly I think we've just been getting lucky.
Also, the overflow might possibly only have been exposed by the recent serial rework; when I found the problem the serial rework caused on Tegra, Allen mentioned that the missing BSS clearing hadn't been a problem before since no global variables were used, but the serial rework caused some to be.
Hi Stephen.
On Tue, Oct 16, 2012 at 3:43 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 10/16/2012 04:09 PM, Lucas Stach wrote:
Am Dienstag, den 16.10.2012, 15:50 -0600 schrieb Stephen Warren:
From: Stephen Warren swarren@nvidia.com
The SPL has grown. Increase CONFIG_SYS_TEXT_BASE so SPL's BSS does not overlap the main U-Boot.
Is there any specific reason why the SPL is now bigger than before? Or is this just because of the general U-Boot rework (like serial multi anywhere)? And by how much has it grown? This is really more out of curiosity rather than any real objection.
Looking at this more, I built commit cca6076 "tegra20: Remove armv4t build flags" which was the last patch in the series that enabled SPL on Tegra, and it overflows even there:
Configuring for ventana board... text data bss dec hex filename 226085 4384 274228 504697 7b379 ./u-boot 13857 153 4516 18526 485e ./spl/u-boot-spl
u-boot/master currently has:
Configuring for ventana board... text data bss dec hex filename 233579 4432 274368 512379 7d17b ./u-boot 14382 201 4520 19103 4a9f ./spl/u-boot-spl
So, there is slight growth, but mainly I think we've just been getting lucky.
Also, the overflow might possibly only have been exposed by the recent serial rework; when I found the problem the serial rework caused on Tegra, Allen mentioned that the missing BSS clearing hadn't been a problem before since no global variables were used, but the serial rework caused some to be.
To ask the opposite question, is it worth increasing by a whole 16KB so that the base address of U-Boot is a more aligned number?
Regards, Simon
On 10/17/2012 06:05 PM, Simon Glass wrote:
Hi Stephen.
On Tue, Oct 16, 2012 at 3:43 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 10/16/2012 04:09 PM, Lucas Stach wrote:
Am Dienstag, den 16.10.2012, 15:50 -0600 schrieb Stephen Warren:
From: Stephen Warren swarren@nvidia.com
The SPL has grown. Increase CONFIG_SYS_TEXT_BASE so SPL's BSS does not overlap the main U-Boot.
Is there any specific reason why the SPL is now bigger than before? Or is this just because of the general U-Boot rework (like serial multi anywhere)? And by how much has it grown? This is really more out of curiosity rather than any real objection.
Looking at this more, I built commit cca6076 "tegra20: Remove armv4t build flags" which was the last patch in the series that enabled SPL on Tegra, and it overflows even there:
Configuring for ventana board... text data bss dec hex filename 226085 4384 274228 504697 7b379 ./u-boot 13857 153 4516 18526 485e ./spl/u-boot-spl
u-boot/master currently has:
Configuring for ventana board... text data bss dec hex filename 233579 4432 274368 512379 7d17b ./u-boot 14382 201 4520 19103 4a9f ./spl/u-boot-spl
So, there is slight growth, but mainly I think we've just been getting lucky.
Also, the overflow might possibly only have been exposed by the recent serial rework; when I found the problem the serial rework caused on Tegra, Allen mentioned that the missing BSS clearing hadn't been a problem before since no global variables were used, but the serial rework caused some to be.
To ask the opposite question, is it worth increasing by a whole 16KB so that the base address of U-Boot is a more aligned number?
That would bloat the binary by about 12KB more than it needs to be. I don't believe there's any particular need for the main U-Boot to be built for any particular address, and we can just continue to bump up this value as/when the SPL grows.
On Wed, Oct 17, 2012 at 09:20:31PM -0600, Stephen Warren wrote:
On 10/17/2012 06:05 PM, Simon Glass wrote:
Hi Stephen.
On Tue, Oct 16, 2012 at 3:43 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 10/16/2012 04:09 PM, Lucas Stach wrote:
Am Dienstag, den 16.10.2012, 15:50 -0600 schrieb Stephen Warren:
From: Stephen Warren swarren@nvidia.com
The SPL has grown. Increase CONFIG_SYS_TEXT_BASE so SPL's BSS does not overlap the main U-Boot.
Is there any specific reason why the SPL is now bigger than before? Or is this just because of the general U-Boot rework (like serial multi anywhere)? And by how much has it grown? This is really more out of curiosity rather than any real objection.
Looking at this more, I built commit cca6076 "tegra20: Remove armv4t build flags" which was the last patch in the series that enabled SPL on Tegra, and it overflows even there:
Configuring for ventana board... text data bss dec hex filename 226085 4384 274228 504697 7b379 ./u-boot 13857 153 4516 18526 485e ./spl/u-boot-spl
u-boot/master currently has:
Configuring for ventana board... text data bss dec hex filename 233579 4432 274368 512379 7d17b ./u-boot 14382 201 4520 19103 4a9f ./spl/u-boot-spl
So, there is slight growth, but mainly I think we've just been getting lucky.
Also, the overflow might possibly only have been exposed by the recent serial rework; when I found the problem the serial rework caused on Tegra, Allen mentioned that the missing BSS clearing hadn't been a problem before since no global variables were used, but the serial rework caused some to be.
To ask the opposite question, is it worth increasing by a whole 16KB so that the base address of U-Boot is a more aligned number?
That would bloat the binary by about 12KB more than it needs to be. I don't believe there's any particular need for the main U-Boot to be built for any particular address, and we can just continue to bump up this value as/when the SPL grows.
Well, lets stop and think for a minute more. Are we likely to add new features to SPL on Tegra (direct OS booting, support in one binary for both SPL-from-flash and SPL-from-something-else) ? If so, lets increase this to a reasonable maximum now rather than keep bumping and breaking. On TI parts for example, we are limited by our SRAM size and set that (minus a bit for stack) as how big we allow SPL to be so that we don't have to tweak this value based on toolchain or feature changes (ELDK 4.2 vs current Linaro for example, can be a noticable size difference).
On 10/18/2012 10:31 AM, Tom Rini wrote:
On Wed, Oct 17, 2012 at 09:20:31PM -0600, Stephen Warren wrote:
On 10/17/2012 06:05 PM, Simon Glass wrote:
On Tue, Oct 16, 2012 at 3:43 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 10/16/2012 04:09 PM, Lucas Stach wrote:
...
To ask the opposite question, is it worth increasing by a whole 16KB so that the base address of U-Boot is a more aligned number?
That would bloat the binary by about 12KB more than it needs to be. I don't believe there's any particular need for the main U-Boot to be built for any particular address, and we can just continue to bump up this value as/when the SPL grows.
Well, lets stop and think for a minute more. Are we likely to add new features to SPL on Tegra (direct OS booting, support in one binary for both SPL-from-flash and SPL-from-something-else) ?
I don't think so. The only purpose of the SPL on Tegra is to run from SDRAM on the AVP CPU, set up clocks for the main Cortex-A9 core, and to cause the A9 to start executing the concatenated main U-Boot image. The SPL always runs from SDRAM.
(As background, the boot ROM sets up SDRAM on Tegra, and copies the concatenated SPL+U-Boot binaries into SDRAM from whatever boot device, so the typical reasons for using SPL don't exist on Tegra).
Allen Martin was thinking about getting the SPL to run from IRAM rather than SDRAM, and I think only execute on the AVP CPU (e.g. for use as a slimmed-down flashing tool downloaded via the boot ROM's USB recovery mechanism). However, I think that would end up being an entirely separate SPL build (since we'd need both, not cut over), so the size requirements would not impact in any way the SPL-in-SDRAM that we have today.
Hi Stephen,
On Tue, Oct 16, 2012 at 2:50 PM, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
When -ffunction-sections or -fdata-section are used, symbols are placed into sections such as .data.eserial1_device and .bss.serial_current. Update the linker script to explicitly include these. Without this change (at least with my gcc-4.5.3 built using crosstool-ng), I see that the sections do end up being included, but __bss_end__ gets set to the same value as __bss_start.
Signed-off-by: Stephen Warren swarren@nvidia.com
This series fixes an SPL size overflow problem on Tegra. Tom Warren is out on vacation until Oct 25th, so he certainly won't be able to review this. Perhaps it could be applied directly to the ARM tree if enough Tegra people ack the series?
Note that this series is not enough to make Tegra support work; either you must hack ./arch/arm/cpu/arm720t/tegra-common/spl.c to call serial_initialize() right before serial_init() in preloader_console_init() or wait for Allen Martin to rework Tegra's SPL support using the common SPL code.
Are you going to submit a patch to enable function-sections, or is that a separate discussion?
arch/arm/cpu/u-boot.lds | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds index e49ca0c..ae04a6e 100644 --- a/arch/arm/cpu/u-boot.lds +++ b/arch/arm/cpu/u-boot.lds @@ -35,7 +35,7 @@ SECTIONS { __image_copy_start = .; CPUDIR/start.o (.text)
*(.text)
*(.text*) } . = ALIGN(4);@@ -43,14 +43,14 @@ SECTIONS
. = ALIGN(4); .data : {
*(.data)
*(.data*) } . = ALIGN(4); . = .; __u_boot_cmd_start = .;
.u_boot_cmd : { *(.u_boot_cmd) }
.u_boot_cmd : { *(.u_boot_cmd*) }
I don't think this line is needed?
__u_boot_cmd_end = .; . = ALIGN(4);@@ -65,7 +65,7 @@ SECTIONS
.dynsym : { __dynsym_start = .;
*(.dynsym)
*(.dynsym*)
Nor this one?
} _end = .;@@ -81,7 +81,7 @@ SECTIONS
.bss __rel_dyn_start (OVERLAY) : { __bss_start = .;
*(.bss)
*(.bss*) . = ALIGN(4); __bss_end__ = .; }-- 1.7.0.4
Regards, Simon
On 10/17/2012 05:58 PM, Simon Glass wrote:
Hi Stephen,
On Tue, Oct 16, 2012 at 2:50 PM, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
When -ffunction-sections or -fdata-section are used, symbols are placed into sections such as .data.eserial1_device and .bss.serial_current. Update the linker script to explicitly include these. Without this change (at least with my gcc-4.5.3 built using crosstool-ng), I see that the sections do end up being included, but __bss_end__ gets set to the same value as __bss_start.
Signed-off-by: Stephen Warren swarren@nvidia.com
This series fixes an SPL size overflow problem on Tegra. Tom Warren is out on vacation until Oct 25th, so he certainly won't be able to review this. Perhaps it could be applied directly to the ARM tree if enough Tegra people ack the series?
Note that this series is not enough to make Tegra support work; either you must hack ./arch/arm/cpu/arm720t/tegra-common/spl.c to call serial_initialize() right before serial_init() in preloader_console_init() or wait for Allen Martin to rework Tegra's SPL support using the common SPL code.
Are you going to submit a patch to enable function-sections, or is that a separate discussion?
For the SPL on Tegra, those flags were already on; this patch fixes a bug rather than prepares for new functionality.
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
.u_boot_cmd : { *(.u_boot_cmd) }
.u_boot_cmd : { *(.u_boot_cmd*) }I don't think this line is needed?
...
*(.dynsym)
*(.dynsym*)Nor this one?
Possibly. I changed all the section names to be future-proof. Perhaps a more targeted patch is warranted.
Hi Stephen,
On Wed, 17 Oct 2012 21:17:45 -0600, Stephen Warren swarren@wwwdotorg.org wrote:
On 10/17/2012 05:58 PM, Simon Glass wrote:
Hi Stephen,
On Tue, Oct 16, 2012 at 2:50 PM, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
When -ffunction-sections or -fdata-section are used, symbols are placed into sections such as .data.eserial1_device and .bss.serial_current. Update the linker script to explicitly include these. Without this change (at least with my gcc-4.5.3 built using crosstool-ng), I see that the sections do end up being included, but __bss_end__ gets set to the same value as __bss_start.
Signed-off-by: Stephen Warren swarren@nvidia.com
This series fixes an SPL size overflow problem on Tegra. Tom Warren is out on vacation until Oct 25th, so he certainly won't be able to review this. Perhaps it could be applied directly to the ARM tree if enough Tegra people ack the series?
Note that this series is not enough to make Tegra support work; either you must hack ./arch/arm/cpu/arm720t/tegra-common/spl.c to call serial_initialize() right before serial_init() in preloader_console_init() or wait for Allen Martin to rework Tegra's SPL support using the common SPL code.
Are you going to submit a patch to enable function-sections, or is that a separate discussion?
For the SPL on Tegra, those flags were already on; this patch fixes a bug rather than prepares for new functionality.
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
.u_boot_cmd : { *(.u_boot_cmd) }
.u_boot_cmd : { *(.u_boot_cmd*) }I don't think this line is needed?
...
*(.dynsym)
*(.dynsym*)Nor this one?
Possibly. I changed all the section names to be future-proof. Perhaps a more targeted patch is warranted.
Has this been (at least build-)tested on all boards which have -ffunction-sections or -fdata-sections?
Amicalement,
On 10/18/2012 02:36 PM, Albert ARIBAUD wrote:
Hi Stephen,
On Wed, 17 Oct 2012 21:17:45 -0600, Stephen Warren swarren@wwwdotorg.org wrote:
On 10/17/2012 05:58 PM, Simon Glass wrote:
Hi Stephen,
On Tue, Oct 16, 2012 at 2:50 PM, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
When -ffunction-sections or -fdata-section are used, symbols are placed into sections such as .data.eserial1_device and .bss.serial_current. Update the linker script to explicitly include these. Without this change (at least with my gcc-4.5.3 built using crosstool-ng), I see that the sections do end up being included, but __bss_end__ gets set to the same value as __bss_start.
Signed-off-by: Stephen Warren swarren@nvidia.com
This series fixes an SPL size overflow problem on Tegra. Tom Warren is out on vacation until Oct 25th, so he certainly won't be able to review this. Perhaps it could be applied directly to the ARM tree if enough Tegra people ack the series?
Note that this series is not enough to make Tegra support work; either you must hack ./arch/arm/cpu/arm720t/tegra-common/spl.c to call serial_initialize() right before serial_init() in preloader_console_init() or wait for Allen Martin to rework Tegra's SPL support using the common SPL code.
Are you going to submit a patch to enable function-sections, or is that a separate discussion?
For the SPL on Tegra, those flags were already on; this patch fixes a bug rather than prepares for new functionality.
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
.u_boot_cmd : { *(.u_boot_cmd) }
.u_boot_cmd : { *(.u_boot_cmd*) }I don't think this line is needed?
...
*(.dynsym)
*(.dynsym*)Nor this one?
Possibly. I changed all the section names to be future-proof. Perhaps a more targeted patch is warranted.
Has this been (at least build-)tested on all boards which have -ffunction-sections or -fdata-sections?
Yes; those flags both appear to be turned on when building the SPL for Tegra (although strangely, not when building the main U-Boot):
xxx-gcc -M -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -ffunction-sections -fdata-sections -DCONFIG_SYS_TEXT_BASE=0x0010c000 -DCONFIG_SPL_TEXT_BASE=0x00108000 -DCONFIG_SPL_BUILD -I/home/swarren/shared/git_wa/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem xxx -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -march=armv4 -mtune=arm7tdmi -MQ xxx/spl/arch/arm/cpu/arm720t/interrupts.o interrupts.c > xxx/spl/arch/arm/cpu/arm720t/.depend.interrupts
On 10/18/2012 02:58 PM, Stephen Warren wrote:
On 10/18/2012 02:36 PM, Albert ARIBAUD wrote:
Hi Stephen,
On Wed, 17 Oct 2012 21:17:45 -0600, Stephen Warren swarren@wwwdotorg.org wrote:
On 10/17/2012 05:58 PM, Simon Glass wrote:
Hi Stephen,
On Tue, Oct 16, 2012 at 2:50 PM, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
When -ffunction-sections or -fdata-section are used, symbols are placed into sections such as .data.eserial1_device and .bss.serial_current. Update the linker script to explicitly include these. Without this change (at least with my gcc-4.5.3 built using crosstool-ng), I see that the sections do end up being included, but __bss_end__ gets set to the same value as __bss_start.
Signed-off-by: Stephen Warren swarren@nvidia.com
This series fixes an SPL size overflow problem on Tegra. Tom Warren is out on vacation until Oct 25th, so he certainly won't be able to review this. Perhaps it could be applied directly to the ARM tree if enough Tegra people ack the series?
Note that this series is not enough to make Tegra support work; either you must hack ./arch/arm/cpu/arm720t/tegra-common/spl.c to call serial_initialize() right before serial_init() in preloader_console_init() or wait for Allen Martin to rework Tegra's SPL support using the common SPL code.
Are you going to submit a patch to enable function-sections, or is that a separate discussion?
For the SPL on Tegra, those flags were already on; this patch fixes a bug rather than prepares for new functionality.
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
.u_boot_cmd : { *(.u_boot_cmd) }
.u_boot_cmd : { *(.u_boot_cmd*) }I don't think this line is needed?
...
*(.dynsym)
*(.dynsym*)Nor this one?
Possibly. I changed all the section names to be future-proof. Perhaps a more targeted patch is warranted.
Has this been (at least build-)tested on all boards which have -ffunction-sections or -fdata-sections?
Yes; those flags both appear to be turned on when building the SPL for Tegra (although strangely, not when building the main U-Boot):
xxx-gcc -M -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -ffunction-sections -fdata-sections -DCONFIG_SYS_TEXT_BASE=0x0010c000 -DCONFIG_SPL_TEXT_BASE=0x00108000 -DCONFIG_SPL_BUILD -I/home/swarren/shared/git_wa/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem xxx -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -march=armv4 -mtune=arm7tdmi -MQ xxx/spl/arch/arm/cpu/arm720t/interrupts.o interrupts.c > xxx/spl/arch/arm/cpu/arm720t/.depend.interrupts
I tried to test this more widely. I found that only arch/arm/cpu/ixp/config.mk enables this on ARM, with the comment:
# -fdata-sections triggers "section .bss overlaps section .rel.dyn" linker error PLATFORM_RELFLAGS += -ffunction-sections LDFLAGS_u-boot += --gc-sections
Indeed, if I edit arch/arm/cpu/armv7/config.mk to enable both -ffunction-sections -fdata-sections, I do see that same section overlap error building for Tegra.
Then, if I apply the .lds patch we're discussing, Tegra builds (and runs) OK with those linker flags enabled. So, this patch seems to fix two issues not just one - bonus:-)
Hi Stephen,
On Thu, 18 Oct 2012 15:17:52 -0600, Stephen Warren swarren@wwwdotorg.org wrote:
On 10/18/2012 02:58 PM, Stephen Warren wrote:
On 10/18/2012 02:36 PM, Albert ARIBAUD wrote:
Hi Stephen,
On Wed, 17 Oct 2012 21:17:45 -0600, Stephen Warren swarren@wwwdotorg.org wrote:
On 10/17/2012 05:58 PM, Simon Glass wrote:
Hi Stephen,
On Tue, Oct 16, 2012 at 2:50 PM, Stephen Warren swarren@wwwdotorg.org wrote:
From: Stephen Warren swarren@nvidia.com
When -ffunction-sections or -fdata-section are used, symbols are placed into sections such as .data.eserial1_device and .bss.serial_current. Update the linker script to explicitly include these. Without this change (at least with my gcc-4.5.3 built using crosstool-ng), I see that the sections do end up being included, but __bss_end__ gets set to the same value as __bss_start.
Signed-off-by: Stephen Warren swarren@nvidia.com
This series fixes an SPL size overflow problem on Tegra. Tom Warren is out on vacation until Oct 25th, so he certainly won't be able to review this. Perhaps it could be applied directly to the ARM tree if enough Tegra people ack the series?
Note that this series is not enough to make Tegra support work; either you must hack ./arch/arm/cpu/arm720t/tegra-common/spl.c to call serial_initialize() right before serial_init() in preloader_console_init() or wait for Allen Martin to rework Tegra's SPL support using the common SPL code.
Are you going to submit a patch to enable function-sections, or is that a separate discussion?
For the SPL on Tegra, those flags were already on; this patch fixes a bug rather than prepares for new functionality.
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
.u_boot_cmd : { *(.u_boot_cmd) }
.u_boot_cmd : { *(.u_boot_cmd*) }I don't think this line is needed?
...
*(.dynsym)
*(.dynsym*)Nor this one?
Possibly. I changed all the section names to be future-proof. Perhaps a more targeted patch is warranted.
Has this been (at least build-)tested on all boards which have -ffunction-sections or -fdata-sections?
Yes; those flags both appear to be turned on when building the SPL for Tegra (although strangely, not when building the main U-Boot):
xxx-gcc -M -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -ffunction-sections -fdata-sections -DCONFIG_SYS_TEXT_BASE=0x0010c000 -DCONFIG_SPL_TEXT_BASE=0x00108000 -DCONFIG_SPL_BUILD -I/home/swarren/shared/git_wa/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem xxx -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -march=armv4 -mtune=arm7tdmi -MQ xxx/spl/arch/arm/cpu/arm720t/interrupts.o interrupts.c > xxx/spl/arch/arm/cpu/arm720t/.depend.interrupts
I tried to test this more widely. I found that only arch/arm/cpu/ixp/config.mk enables this on ARM, with the comment:
# -fdata-sections triggers "section .bss overlaps section .rel.dyn" linker error PLATFORM_RELFLAGS += -ffunction-sections LDFLAGS_u-boot += --gc-sections
Indeed, if I edit arch/arm/cpu/armv7/config.mk to enable both -ffunction-sections -fdata-sections, I do see that same section overlap error building for Tegra.
Then, if I apply the .lds patch we're discussing, Tegra builds (and runs) OK with those linker flags enabled. So, this patch seems to fix two issues not just one - bonus:-)
Unless someone opposes, I will pick this one in u-boot-arm/master later today, as I will be doing some .lds merging on ARM (and then some start.S merging). Once this is done, the Tegra tree (Tom already Cc:) should merge u-boot-arm/master to get this first commit in, then apply commits 2 to 5.
Amicalement,
participants (5)
-
Albert ARIBAUD -
Lucas Stach -
Simon Glass -
Stephen Warren -
Tom Rini