Skip to contentSkip to conversation

ARM: fix u-boot.lds for -ffunction-sections/-fdata-sections

PATCH New Stephen Warren 4 participants 15 messages Oct 22, 2012 – Oct 28, 2012

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH v3 1/5 ARM: fix u-boot.lds for -ffunction-sections/-fdata-sections

From: Stephen Warren <[email protected]>

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.

---
v3: No change.
v2: Removed changes from some entries where it wasn't needed.

---
 arch/arm/cpu/u-boot.lds |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)
arch/arm/cpu/u-boot.lds +4 -4
index e49ca0c..9153c3d 100644
@@ -34,8 +34,8 @@ SECTIONS
 	.text :
 	{
 		__image_copy_start = .;
-		CPUDIR/start.o (.text)
-		*(.text)
+		CPUDIR/start.o (.text*)
+		*(.text*)
 	}
 
 	. = ALIGN(4);
@@ -43,7 +43,7 @@ SECTIONS
 
 	. = ALIGN(4);
 	.data : {
-		*(.data)
+		*(.data*)
 	}
 
 	. = ALIGN(4);
@@ -81,7 +81,7 @@ SECTIONS
 
 	.bss __rel_dyn_start (OVERLAY) : {
 		__bss_start = .;
-		*(.bss)
+		*(.bss*)
 		 . = ALIGN(4);
 		__bss_end__ = .;
 	}
Signature · 1 line
1.7.0.4
#1 lore raw

PATCH v3 2/5 ARM: enhance u-boot.lds to detect over-sized SPL

From: Stephen Warren <[email protected]>

Add an ASSERT() to u-boot.lds to detect an SPL that doesn't fit within SPL_TEXT_BASE..SPL_MAX_SIZE.

Different .lds files implement this check in two possible ways:
1) An ASSERT() like this
2) Defining a MEMORY region of size SPL_MAX_SIZE, and re-directing all linker output into that region. Since u-boot.lds is used for both SPL and main U-Boot, this would entail only sometimes defining a MEMORY region, and only sometimes performing that redirection, and hence option (1) was deemed much simpler, and hence implemented.

Note that this causes build failures at least for NVIDIA Tegra Seaboard and Ventana. However, these are legitimate; the SPL doesn't fit within the required space, and this does cause runtime issues.

---
v3: No change.
v2: New patch; replaced checks in Makefile.

---
 arch/arm/cpu/u-boot.lds |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)
arch/arm/cpu/u-boot.lds +4 -0
index 9153c3d..ec2a273 100644
@@ -92,3 +92,7 @@ SECTIONS
 	/DISCARD/ : { *(.interp*) }
 	/DISCARD/ : { *(.gnu*) }
 }
+
+#if defined(CONFIG_SPL_TEXT_BASE) && defined(CONFIG_SPL_MAX_SIZE)
+ASSERT(__bss_end__ < (CONFIG_SPL_TEXT_BASE + CONFIG_SPL_MAX_SIZE), "SPL image too big");
+#endif
Signature · 1 line
1.7.0.4
#2 lore raw

PATCH v3 2/5 ARM: enhance u-boot.lds to detect over-sized SPL

Quoted 13 lines · Stephen Warren

From: Stephen Warren <[email protected]>

Add an ASSERT() to u-boot.lds to detect an SPL that doesn't fit within SPL_TEXT_BASE..SPL_MAX_SIZE.

Different .lds files implement this check in two possible ways:
1) An ASSERT() like this
2) Defining a MEMORY region of size SPL_MAX_SIZE, and re-directing all linker output into that region. Since u-boot.lds is used for both SPL and main U-Boot, this would entail only sometimes defining a MEMORY region, and only sometimes performing that redirection, and hence option (1) was deemed much simpler, and hence implemented.

Quoted 7 lines

Note that this causes build failures at least for NVIDIA Tegra Seaboard and Ventana. However, these are legitimate; the SPL doesn't fit within the required space, and this does cause runtime issues.

This isn't quite what I envisoned at first (see arch/arm/cpu/armv7/omap-common/u-boot-spl.lds) but I think for the generic linker script, this is the least instrusive method.

And since parts 1 and 2 are generic code, I've assigned them to Albert in patchwork. It's his call if he wants to take them or have them all come via the tegra tree.

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/20121022/6f8eca56/attachment.pgp>
#3 lore raw

PATCH v3 2/5 ARM: enhance u-boot.lds to detect over-sized SPL

Quoted 15 lines · Tom Rini
Quoted 13 lines · Stephen Warren

From: Stephen Warren <[email protected]>

Add an ASSERT() to u-boot.lds to detect an SPL that doesn't fit within SPL_TEXT_BASE..SPL_MAX_SIZE.

Different .lds files implement this check in two possible ways:
1) An ASSERT() like this
2) Defining a MEMORY region of size SPL_MAX_SIZE, and re-directing all linker output into that region. Since u-boot.lds is used for both SPL and main U-Boot, this would entail only sometimes defining a MEMORY region, and only sometimes performing that redirection, and hence option (1) was deemed much simpler, and hence implemented.

Quoted 7 lines
Quoted 7 lines

Note that this causes build failures at least for NVIDIA Tegra Seaboard and Ventana. However, these are legitimate; the SPL doesn't fit within the required space, and this does cause runtime issues.

I tested this series on seaboard.

Quoted 19 lines

This isn't quite what I envisoned at first (see arch/arm/cpu/armv7/omap-common/u-boot-spl.lds) but I think for the generic linker script, this is the least instrusive method.

And since parts 1 and 2 are generic code, I've assigned them to Albert in patchwork. It's his call if he wants to take them or have them all come via the tegra tree.

--
Tom

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

#4 lore raw

PATCH v3 3/5 ARM: tegra: derive CONFIG_SPL_MAX_SIZE instead of hard-coding it

In reply to Stephen Warren

From: Stephen Warren <[email protected]>

For Tegra, the SPL and main U-Boot are concatenated together to form a single memory image. Hence, the maximum SPL size is the different in TEXT_BASE for SPL and main U-Boot. Instead of manually calculating SPL_MAX_SIZE based on those two TEXT_BASE, which can lead to errors if one TEXT_BASE is changed without updating SPL_MAX_SIZE, simply perform the calculation automatically.

---
v3: No change.
v2: New patch.

---
 include/configs/tegra20-common.h |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
include/configs/tegra20-common.h +2 -1
index 70c5cfb..c0c93e5 100644
@@ -188,7 +188,8 @@
 #define CONFIG_SPL
 #define CONFIG_SPL_NAND_SIMPLE
 #define CONFIG_SPL_TEXT_BASE		0x00108000
-#define CONFIG_SPL_MAX_SIZE		0x00004000
+#define CONFIG_SPL_MAX_SIZE		(CONFIG_SYS_TEXT_BASE - \
+						CONFIG_SPL_TEXT_BASE)
 #define CONFIG_SYS_SPL_MALLOC_START	0x00090000
 #define CONFIG_SYS_SPL_MALLOC_SIZE	0x00010000
 #define CONFIG_SPL_STACK		0x000ffffc
Signature · 1 line
1.7.0.4
#5 lore raw

PATCH v3 3/5 ARM: tegra: derive CONFIG_SPL_MAX_SIZE instead of hard-coding it

Quoted 9 lines · Stephen Warren

From: Stephen Warren <[email protected]>

For Tegra, the SPL and main U-Boot are concatenated together to form a single memory image. Hence, the maximum SPL size is the different in TEXT_BASE for SPL and main U-Boot. Instead of manually calculating SPL_MAX_SIZE based on those two TEXT_BASE, which can lead to errors if one TEXT_BASE is changed without updating SPL_MAX_SIZE, simply perform the calculation automatically.

Quoted 3 lines

I tested this series on seaboard.

Quoted 24 lines

---
v3: No change.
v2: New patch.

---
 include/configs/tegra20-common.h |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
include/configs/tegra20-common.h +2 -2
index 70c5cfb..c0c93e5 100644
@@ -188,7 +188,8 @@
 #define CONFIG_SPL
 #define CONFIG_SPL_NAND_SIMPLE
 #define CONFIG_SPL_TEXT_BASE           0x00108000
-#define CONFIG_SPL_MAX_SIZE            0x00004000
+#define CONFIG_SPL_MAX_SIZE            (CONFIG_SYS_TEXT_BASE - \
+                                               CONFIG_SPL_TEXT_BASE)
 #define CONFIG_SYS_SPL_MALLOC_START    0x00090000
 #define CONFIG_SYS_SPL_MALLOC_SIZE     0x00010000
 #define CONFIG_SPL_STACK               0x000ffffc
--

1.7.0.4

#6 lore raw

PATCH v3 4/5 ARM: tegra: select between Seaboard/Ventana at compile time

In reply to Stephen Warren

From: Stephen Warren <[email protected]>

Seaboard and Ventana are very similar boards, and so share the seaboard.c board file. The one difference needed so far is detected at run-time by calling machine_is_ventana(). This bloats the Ventana build with code that is never used. Switch to detecting Ventana at compile time to remove bloat. This shaves ~5K off the SPL size on Ventana, and makes the SPL fit within the max size.

---
v3: Combined back-to-back #ifdefs.
v2: New patch to replace modification of CONFIG_SYS_TEXT_BASE.

---
 board/nvidia/seaboard/seaboard.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)
board/nvidia/seaboard/seaboard.c +1 -3
index 4e8a183..ea431e9 100644
@@ -34,7 +34,7 @@
 #endif
 
 /* TODO: Remove this code when the SPI switch is working */
-#ifndef CONFIG_SPI_UART_SWITCH
+#if !defined(CONFIG_SPI_UART_SWITCH) && (CONFIG_MACH_TYPE != MACH_TYPE_VENTANA)
 /*
  * Routine: gpio_config_uart_seaboard
  * Description: Force GPIO_PI3 low on Seaboard so UART4 works.
@@ -48,8 +48,6 @@ static void gpio_config_uart_seaboard(void)
 
 void gpio_early_init_uart(void)
 {
-	if (machine_is_ventana())
-		return;
 	gpio_config_uart_seaboard();
 }
 #endif
Signature · 1 line
1.7.0.4
#7 lore raw

PATCH v3 4/5 ARM: tegra: select between Seaboard/Ventana at compile time

Quoted 10 lines · Stephen Warren

From: Stephen Warren <[email protected]>

Seaboard and Ventana are very similar boards, and so share the seaboard.c board file. The one difference needed so far is detected at run-time by calling machine_is_ventana(). This bloats the Ventana build with code that is never used. Switch to detecting Ventana at compile time to remove bloat. This shaves ~5K off the SPL size on Ventana, and makes the SPL fit within the max size.

I tested this series on seaboard.

Quoted 4 lines

---
v3: Combined back-to-back #ifdefs.
v2: New patch to replace modification of CONFIG_SYS_TEXT_BASE.
---

#8 lore raw

PATCH v3 5/5 ARM: tegra: don't request GPIO from Seaboard's SPL

In reply to Stephen Warren

From: Stephen Warren <[email protected]>

Seaboard has a GPIO that switches an external mux between Tegra's debug UART and SPI flash. This is initialized from the SPL so that SPL debug output can be seen. Simplify the code that does this, and don't actually request the GPIO in the SPL; just program it. This saves ~4.5K from the size of the SPL, mostly BSS due to the large gpio_names[] table that is no longer required. This makes Seaboard's SPL fit within the current max size.

---
v3: No change.
v2: New patch to replace modification of CONFIG_SYS_TEXT_BASE.

---
 board/nvidia/seaboard/seaboard.c |   14 ++++----------
 1 files changed, 4 insertions(+), 10 deletions(-)
board/nvidia/seaboard/seaboard.c +4 -10
index ea431e9..c412c07 100644
@@ -26,6 +26,7 @@
 #include <asm/arch/tegra.h>
 #include <asm/arch/clock.h>
 #include <asm/arch/funcmux.h>
+#include <asm/arch/gpio.h>
 #include <asm/arch/pinmux.h>
 #include <asm/arch-tegra/mmc.h>
 #include <asm/gpio.h>
@@ -35,21 +36,14 @@
 
 /* TODO: Remove this code when the SPI switch is working */
 #if !defined(CONFIG_SPI_UART_SWITCH) && (CONFIG_MACH_TYPE != MACH_TYPE_VENTANA)
-/*
- * Routine: gpio_config_uart_seaboard
- * Description: Force GPIO_PI3 low on Seaboard so UART4 works.
- */
-static void gpio_config_uart_seaboard(void)
+void gpio_early_init_uart(void)
 {
 	/* Enable UART via GPIO_PI3 (port 8, bit 3) so serial console works */
+#ifndef CONFIG_SPL_BUILD
 	gpio_request(GPIO_PI3, NULL);
+#endif
 	gpio_direction_output(GPIO_PI3, 0);
 }
-
-void gpio_early_init_uart(void)
-{
-	gpio_config_uart_seaboard();
-}
 #endif
 
 #ifdef CONFIG_TEGRA_MMC
Signature · 1 line
1.7.0.4
#9 lore raw

PATCH v3 5/5 ARM: tegra: don't request GPIO from Seaboard's SPL

Hi,

Quoted 10 lines · Stephen Warren

From: Stephen Warren <[email protected]>

Seaboard has a GPIO that switches an external mux between Tegra's debug UART and SPI flash. This is initialized from the SPL so that SPL debug output can be seen. Simplify the code that does this, and don't actually request the GPIO in the SPL; just program it. This saves ~4.5K from the size of the SPL, mostly BSS due to the large gpio_names[] table that is no longer required. This makes Seaboard's SPL fit within the current max size.

Quoted 3 lines

I tested this series on seaboard.

Quoted 4 lines

---
v3: No change.
v2: New patch to replace modification of CONFIG_SYS_TEXT_BASE.
---

#10 lore raw

PATCH v3 5/5 ARM: tegra: don't request GPIO from Seaboard's SPL

In reply to Stephen Warren

Hi Stephen,

Quoted 9 lines · Stephen Warren

From: Stephen Warren <[email protected]>

Seaboard has a GPIO that switches an external mux between Tegra's debug UART and SPI flash. This is initialized from the SPL so that SPL debug output can be seen. Simplify the code that does this, and don't actually request the GPIO in the SPL; just program it. This saves ~4.5K from the size of the SPL, mostly BSS due to the large gpio_names[] table that is no longer required. This makes Seaboard's SPL fit within the current max size.

Is it possible to reorder the patch series so that Seaboard (and Ventana?) builds do not break temporarily between patch 2 and this patch?

Amicalement,

Signature · 1 line
Albert.
#11 lore raw

PATCH v3 5/5 ARM: tegra: don't request GPIO from Seaboard's SPL

Quoted 15 lines · Albert ARIBAUD

Hi Stephen,

Quoted 9 lines · Stephen Warren

From: Stephen Warren <[email protected]>

Seaboard has a GPIO that switches an external mux between Tegra's debug UART and SPI flash. This is initialized from the SPL so that SPL debug output can be seen. Simplify the code that does this, and don't actually request the GPIO in the SPL; just program it. This saves ~4.5K from the size of the SPL, mostly BSS due to the large gpio_names[] table that is no longer required. This makes Seaboard's SPL fit within the current max size.

Quoted 3 lines

Is it possible to reorder the patch series so that Seaboard (and Ventana?) builds do not break temporarily between patch 2 and this patch?

It would be possibel, although I'd personally rather call out the issue explicitly with a build break; if the build succeeds, you end up using code that silently causes memory corruption. Of course, this issue has been around for a while, so perhaps hiding it for another couple extra commits wouldn't be a big deal. Plus, the build break proves the assert in the .lds file works:-) But it's not big deal either way; feel free to re-order the commits if you want.

#12 lore raw

PATCH v3 5/5 ARM: tegra: don't request GPIO from Seaboard's SPL

Hi Stephen,

Quoted 20 lines · Stephen Warren
Quoted 15 lines · Albert ARIBAUD

Hi Stephen,

Quoted 9 lines · Stephen Warren

From: Stephen Warren <[email protected]>

Seaboard has a GPIO that switches an external mux between Tegra's debug UART and SPI flash. This is initialized from the SPL so that SPL debug output can be seen. Simplify the code that does this, and don't actually request the GPIO in the SPL; just program it. This saves ~4.5K from the size of the SPL, mostly BSS due to the large gpio_names[] table that is no longer required. This makes Seaboard's SPL fit within the current max size.

Quoted 3 lines

Is it possible to reorder the patch series so that Seaboard (and Ventana?) builds do not break temporarily between patch 2 and this patch?

Quoted 7 lines

It would be possibel, although I'd personally rather call out the issue explicitly with a build break; if the build succeeds, you end up using code that silently causes memory corruption. Of course, this issue has been around for a while, so perhaps hiding it for another couple extra commits wouldn't be a big deal. Plus, the build break proves the assert in the .lds file works:-) But it's not big deal either way; feel free to re-order the commits if you want.

No need: your points are valid.

Amicalement,

Signature · 1 line
Albert.
#13 lore raw

PATCH v3 1/5 ARM: fix u-boot.lds for -ffunction-sections/-fdata-sections

In reply to Stephen Warren
Quoted 11 lines · Stephen Warren

From: Stephen Warren <[email protected]>

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.

I tested this series on seaboard.

Regards,
Simon

#14 lore raw

PATCH v3 1/5 ARM: fix u-boot.lds for -ffunction-sections/-fdata-sections

Hi Simon,

Quoted 13 lines · Simon Glass
Quoted 11 lines · Stephen Warren

From: Stephen Warren <[email protected]>

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.

Quoted 8 lines

I tested this series on seaboard.

Regards,
Simon

Applied (this patch only in the series) to u-boot-arm/master, thanks!

Amicalement,

Signature · 1 line
Albert.