[PATCH] spl: Ensure final section before BSS is non-empty

[PATCH] spl: Ensure final section before BSS is non-empty

[Tom Rini]

As part of ensuring that we make a binary image to append our device
tree to and that it will have an 8 byte alignment, one problem was
overlooked. That problem is what happens when we have a section that
only contains ALIGN statements and linker references, but nothing else.
What happens in this case is that we will have a section in the
resulting ELF that has is of the NOBITS type. This in turn means that
when we use objcopy to turn the ELF in to a binary for further
processing, it won't copy anything. This then becomes a problem when we
do not have a separate BSS and instead append a "padding" file to act as
the BSS, and then append our device tree to that. The solution here is
to ensure that the final section in our SPL image is something that will
always exist with contents, in this case __u_boot_list.

Fixes: 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts")
Fixes: f150843499b3 ("riscv: Update linker scripts to ensure appended device tree is aligned")
Reported-by: Brian Sune <briansune@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Ilias, if there's anyone else you can get to look at this which
understands linker scripts better please do. I think I finally see *how*
things go wrong in some cases but I'm less confident in my explanation
above. Thanks.

Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
---
 arch/arm/cpu/armv8/u-boot-spl.lds           | 12 ++++++------
 arch/arm/cpu/u-boot-spl.lds                 | 10 +++++-----
 arch/arm/mach-aspeed/ast2600/u-boot-spl.lds | 10 +++++-----
 arch/riscv/cpu/u-boot-spl.lds               | 11 +++++------
 4 files changed, 21 insertions(+), 22 deletions(-)

diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds b/arch/arm/cpu/armv8/u-boot-spl.lds
index b732133ce76d..29252d870f91 100644
--- a/arch/arm/cpu/armv8/u-boot-spl.lds
+++ b/arch/arm/cpu/armv8/u-boot-spl.lds
@@ -49,12 +49,6 @@ SECTIONS
 	} >.sram
 #endif
 
-	__u_boot_list : {
-		. = ALIGN(8);
-		KEEP(*(SORT(__u_boot_list*)));
-		. = ALIGN(8);
-	} >.sram
-
 	.binman_sym_table : {
 		. = ALIGN(8);
 		__binman_sym_start = .;
@@ -63,6 +57,12 @@ SECTIONS
 		. = ALIGN(8);
 	} > .sram
 
+	__u_boot_list : {
+		. = ALIGN(8);
+		KEEP(*(SORT(__u_boot_list*)));
+		. = ALIGN(8);
+	} >.sram
+
 	__image_copy_end = .;
 	_end = .;
 	_image_binary_end = .;
diff --git a/arch/arm/cpu/u-boot-spl.lds b/arch/arm/cpu/u-boot-spl.lds
index c578c3ebf821..5f807323f856 100644
--- a/arch/arm/cpu/u-boot-spl.lds
+++ b/arch/arm/cpu/u-boot-spl.lds
@@ -31,16 +31,16 @@ SECTIONS
 		*(.data*)
 	}
 
-	. = ALIGN(4);
-	__u_boot_list : {
-		KEEP(*(SORT(__u_boot_list*)));
-	}
-
 	. = ALIGN(4);
 	.binman_sym_table : {
 		__binman_sym_start = .;
 		KEEP(*(SORT(.binman_sym*)));
 		__binman_sym_end = .;
+	}
+
+	. = ALIGN(4);
+	__u_boot_list : {
+		KEEP(*(SORT(__u_boot_list*)));
 		. = ALIGN(8);
 	}
 
diff --git a/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds b/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds
index 303ace2f61ca..260a0a79dd0a 100644
--- a/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds
+++ b/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds
@@ -39,16 +39,16 @@ SECTIONS
 		*(.data*)
 	} > .nor
 
-	. = ALIGN(4);
-	__u_boot_list : {
-		KEEP(*(SORT(__u_boot_list*)));
-	} > .nor
-
 	. = ALIGN(4);
 	.binman_sym_table : {
 		__binman_sym_start = .;
 		KEEP(*(SORT(.binman_sym*)));
 		__binman_sym_end = .;
+	} > .nor
+
+	. = ALIGN(4);
+	__u_boot_list : {
+		KEEP(*(SORT(__u_boot_list*)));
 		. = ALIGN(8);
 	} > .nor
 
diff --git a/arch/riscv/cpu/u-boot-spl.lds b/arch/riscv/cpu/u-boot-spl.lds
index 35de28db8f3a..5a65e6653f25 100644
--- a/arch/riscv/cpu/u-boot-spl.lds
+++ b/arch/riscv/cpu/u-boot-spl.lds
@@ -31,18 +31,17 @@ SECTIONS
 	.data : {
 		*(.data*)
 	} > .spl_mem
-	. = ALIGN(4);
-
-	__u_boot_list : {
-		KEEP(*(SORT(__u_boot_list*)));
-	} > .spl_mem
 
 	. = ALIGN(4);
-
 	.binman_sym_table : {
 		__binman_sym_start = .;
 		KEEP(*(SORT(.binman_sym*)));
 		__binman_sym_end = .;
+	} > .spl_mem
+
+	. = ALIGN(4);
+	__u_boot_list : {
+		KEEP(*(SORT(__u_boot_list*)));
 		. = ALIGN(8);
 	} > .spl_mem
 
-- 
2.43.0

Re: [PATCH] spl: Ensure final section before BSS is non-empty

[Sune Brian]

On Sat, Jan 31, 2026 at 2:36 AM Tom Rini <trini@konsulko.com> wrote:
>
> As part of ensuring that we make a binary image to append our device
> tree to and that it will have an 8 byte alignment, one problem was
> overlooked. That problem is what happens when we have a section that
> only contains ALIGN statements and linker references, but nothing else.
> What happens in this case is that we will have a section in the
> resulting ELF that has is of the NOBITS type. This in turn means that
> when we use objcopy to turn the ELF in to a binary for further
> processing, it won't copy anything. This then becomes a problem when we
> do not have a separate BSS and instead append a "padding" file to act as
> the BSS, and then append our device tree to that. The solution here is
> to ensure that the final section in our SPL image is something that will
> always exist with contents, in this case __u_boot_list.
>
> Fixes: 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts")
> Fixes: f150843499b3 ("riscv: Update linker scripts to ensure appended device tree is aligned")
> Reported-by: Brian Sune <briansune@gmail.com>
> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
> Ilias, if there's anyone else you can get to look at this which
> understands linker scripts better please do. I think I finally see *how*
> things go wrong in some cases but I'm less confident in my explanation
> above. Thanks.
>
> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> ---
>  arch/arm/cpu/armv8/u-boot-spl.lds           | 12 ++++++------
>  arch/arm/cpu/u-boot-spl.lds                 | 10 +++++-----
>  arch/arm/mach-aspeed/ast2600/u-boot-spl.lds | 10 +++++-----
>  arch/riscv/cpu/u-boot-spl.lds               | 11 +++++------
>  4 files changed, 21 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds b/arch/arm/cpu/armv8/u-boot-spl.lds
> index b732133ce76d..29252d870f91 100644
> --- a/arch/arm/cpu/armv8/u-boot-spl.lds
> +++ b/arch/arm/cpu/armv8/u-boot-spl.lds
> @@ -49,12 +49,6 @@ SECTIONS
>         } >.sram
>  #endif
>
> -       __u_boot_list : {
> -               . = ALIGN(8);
> -               KEEP(*(SORT(__u_boot_list*)));
> -               . = ALIGN(8);
> -       } >.sram
> -
>         .binman_sym_table : {
>                 . = ALIGN(8);
>                 __binman_sym_start = .;
> @@ -63,6 +57,12 @@ SECTIONS
>                 . = ALIGN(8);
>         } > .sram
>
> +       __u_boot_list : {
> +               . = ALIGN(8);
> +               KEEP(*(SORT(__u_boot_list*)));
> +               . = ALIGN(8);
> +       } >.sram
> +
>         __image_copy_end = .;
>         _end = .;
>         _image_binary_end = .;
> diff --git a/arch/arm/cpu/u-boot-spl.lds b/arch/arm/cpu/u-boot-spl.lds
> index c578c3ebf821..5f807323f856 100644
> --- a/arch/arm/cpu/u-boot-spl.lds
> +++ b/arch/arm/cpu/u-boot-spl.lds
> @@ -31,16 +31,16 @@ SECTIONS
>                 *(.data*)
>         }
>
> -       . = ALIGN(4);
> -       __u_boot_list : {
> -               KEEP(*(SORT(__u_boot_list*)));
> -       }
> -
>         . = ALIGN(4);
>         .binman_sym_table : {
>                 __binman_sym_start = .;
>                 KEEP(*(SORT(.binman_sym*)));
>                 __binman_sym_end = .;
> +       }
> +
> +       . = ALIGN(4);
> +       __u_boot_list : {
> +               KEEP(*(SORT(__u_boot_list*)));
>                 . = ALIGN(8);
>         }

For ARM v7 on SoCFPGA GEN5 Cyclone V boards:
AC550
AC501

Tested-by: Brian Sune <briansune@gmail.com>

>
> diff --git a/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds b/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds
> index 303ace2f61ca..260a0a79dd0a 100644
> --- a/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds
> +++ b/arch/arm/mach-aspeed/ast2600/u-boot-spl.lds
> @@ -39,16 +39,16 @@ SECTIONS
>                 *(.data*)
>         } > .nor
>
> -       . = ALIGN(4);
> -       __u_boot_list : {
> -               KEEP(*(SORT(__u_boot_list*)));
> -       } > .nor
> -
>         . = ALIGN(4);
>         .binman_sym_table : {
>                 __binman_sym_start = .;
>                 KEEP(*(SORT(.binman_sym*)));
>                 __binman_sym_end = .;
> +       } > .nor
> +
> +       . = ALIGN(4);
> +       __u_boot_list : {
> +               KEEP(*(SORT(__u_boot_list*)));
>                 . = ALIGN(8);
>         } > .nor
>
> diff --git a/arch/riscv/cpu/u-boot-spl.lds b/arch/riscv/cpu/u-boot-spl.lds
> index 35de28db8f3a..5a65e6653f25 100644
> --- a/arch/riscv/cpu/u-boot-spl.lds
> +++ b/arch/riscv/cpu/u-boot-spl.lds
> @@ -31,18 +31,17 @@ SECTIONS
>         .data : {
>                 *(.data*)
>         } > .spl_mem
> -       . = ALIGN(4);
> -
> -       __u_boot_list : {
> -               KEEP(*(SORT(__u_boot_list*)));
> -       } > .spl_mem
>
>         . = ALIGN(4);
> -
>         .binman_sym_table : {
>                 __binman_sym_start = .;
>                 KEEP(*(SORT(.binman_sym*)));
>                 __binman_sym_end = .;
> +       } > .spl_mem
> +
> +       . = ALIGN(4);
> +       __u_boot_list : {
> +               KEEP(*(SORT(__u_boot_list*)));
>                 . = ALIGN(8);
>         } > .spl_mem
>
> --
> 2.43.0
>

[PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS

[Tom Rini]

Historically, when we have an appended device tree and also our
resulting binary will contain the BSS section, we have ensured that
everything will be where it's expected to be by declaring that the BSS
is overlayed with a symbol matches the end of the port of the ELF binary
that is objcopy'd to the binary we concatenate with. This in turn means
that the logic to generate a "pad" file, which is the size found in the
__bss_size symbol, will be correct and then we can concatenate the
device tree and it will begin at __bss_size at run time.

With commit 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts")
we removed this overlay as part of trying to ensure that we met both the
requirements of the device tree to be 8 byte aligned as well as that our
logic to generate the -pad file would match what ended up in the
resulting binary. While it was correct to remove an unused section it
did not solve ultimately solve the problem for all cases.

To really fix the problem, we need to do two things. First, our final
section prior to _image_binary_end must be 8 byte aligned (for the case
of having a separate BSS and so our appended DTB exists at this
location). This cannot be '.binman_sym_table' as it may be empty, and in
turn the ELF type would be NOBITS and so not copied with objcopy. The
__u_boot_list section will never be empty, so it is our final section,
and ends with a '. = ALIGN(8)' statement. Second, as this is the end of
our copied data it is safe to declare that the BSS starts here, so use
the OVERLAY keyword to place the BSS here.

Fixes: 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts")
Reported-by: Brian Sune <briansune@gmail.com>
Reported-by: Phil Phil Sutter <phil@nwl.cc>
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Marek Vasut <marek.vasut+renesas@mailbox.org>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Nathan Barrett-Morrison <nathan.morrison@timesys.com>
Cc: Greg Malysa <malysagreg@gmail.com>
Cc: Ian Roberts <ian.roberts@timesys.com>
Cc: Vasileios Bimpikas <vasileios.bimpikas@analog.com>
Cc: Utsav Agarwal <utsav.agarwal@analog.com>
Cc: Arturs Artamonovs <arturs.artamonovs@analog.com>
Cc: adsp-linux@analog.com

So, first, with the exception of:
axm brppt2 imx28_btt3 imx28_xea mk808 taurus work_92105
all platforms using arch/arm/cpu/u-boot-spl.lds do NOT enable
CONFIG_SPL_SEPARATE_BSS. And of those, only brppt2 enables SPL_OF_REAL.
As an aside, I'm thinking that there is room for a clean-up / merger of
arch/arm/cpu/u-boot-spl.lds and arch/arm/mach-omap2/u-boot-spl.lds
(*widely* used outside of mach-omap2). But for this patch, that one case
is handled correctly, with the first change I explained. All other 32bit
platforms are handled with the second.

Which means second, 64bit ARM platforms. With the exception of:
socfpga_agilex7m socfpga_n5x_atf socfpga_n5x_vab socfpga_stratix10_atf
all ARM64 SPL_FRAMEWORK using platforms use the
arch/arm/cpu/armv8/u-boot-spl.lds explicitly. These other ones set
CONFIG_SPL_LDSCRIPT to a non-existant file and then fall back to using
arch/arm/cpu/armv8/u-boot-spl.lds. There are only 4 platforms which
don't use a separate BSS section and so could trip up the above as well:
r8a779g0_whitehawk r8a779g3_sparrowhawk sc598-som-ezkit-spl sc598-som-ezlite-spl
I have inspected the Renesas platforms manually, and I'm a little unsure
how this case works on the two sc598 platforms.
---
 arch/arm/cpu/armv8/u-boot-spl.lds | 15 ++++++++-------
 arch/arm/cpu/u-boot-spl.lds       | 12 ++++++------
 2 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds b/arch/arm/cpu/armv8/u-boot-spl.lds
index b732133ce76d..39020a1fddde 100644
--- a/arch/arm/cpu/armv8/u-boot-spl.lds
+++ b/arch/arm/cpu/armv8/u-boot-spl.lds
@@ -49,12 +49,6 @@ SECTIONS
 	} >.sram
 #endif
 
-	__u_boot_list : {
-		. = ALIGN(8);
-		KEEP(*(SORT(__u_boot_list*)));
-		. = ALIGN(8);
-	} >.sram
-
 	.binman_sym_table : {
 		. = ALIGN(8);
 		__binman_sym_start = .;
@@ -63,6 +57,12 @@ SECTIONS
 		. = ALIGN(8);
 	} > .sram
 
+	__u_boot_list : {
+		. = ALIGN(8);
+		KEEP(*(SORT(__u_boot_list*)));
+		. = ALIGN(8);
+	} >.sram
+
 	__image_copy_end = .;
 	_end = .;
 	_image_binary_end = .;
@@ -75,7 +75,7 @@ SECTIONS
 		__bss_end = .;
 	} >.sdram
 #else
-	.bss (NOLOAD) : {
+	.bss _image_binary_end (OVERLAY) : {
 		__bss_start = .;
 		*(.bss*)
 		 . = ALIGN(8);
@@ -99,5 +99,6 @@ SECTIONS
 
 ASSERT(_image_binary_end % 8 == 0, \
        "_image_binary_end must be 8-byte aligned for device tree");
+
 ASSERT(ADDR(.bss) % 8 == 0, \
        ".bss must be 8-byte aligned");
diff --git a/arch/arm/cpu/u-boot-spl.lds b/arch/arm/cpu/u-boot-spl.lds
index c578c3ebf821..97083319d39d 100644
--- a/arch/arm/cpu/u-boot-spl.lds
+++ b/arch/arm/cpu/u-boot-spl.lds
@@ -31,16 +31,16 @@ SECTIONS
 		*(.data*)
 	}
 
-	. = ALIGN(4);
-	__u_boot_list : {
-		KEEP(*(SORT(__u_boot_list*)));
-	}
-
 	. = ALIGN(4);
 	.binman_sym_table : {
 		__binman_sym_start = .;
 		KEEP(*(SORT(.binman_sym*)));
 		__binman_sym_end = .;
+	}
+
+	. = ALIGN(4);
+	__u_boot_list : {
+		KEEP(*(SORT(__u_boot_list*)));
 		. = ALIGN(8);
 	}
 
@@ -48,7 +48,7 @@ SECTIONS
 	_image_binary_end = .;
 	_end = .;
 
-	.bss : {
+	.bss _image_binary_end (OVERLAY) : {
 		__bss_start = .;
 		*(.bss*)
 		 . = ALIGN(8);
-- 
2.43.0

Re: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS

[Phil Sutter]

On Thu, Feb 05, 2026 at 05:41:58PM -0600, Tom Rini wrote:
> Historically, when we have an appended device tree and also our
> resulting binary will contain the BSS section, we have ensured that
> everything will be where it's expected to be by declaring that the BSS
> is overlayed with a symbol matches the end of the port of the ELF binary
> that is objcopy'd to the binary we concatenate with. This in turn means
> that the logic to generate a "pad" file, which is the size found in the
> __bss_size symbol, will be correct and then we can concatenate the
> device tree and it will begin at __bss_size at run time.
> 
> With commit 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts")
> we removed this overlay as part of trying to ensure that we met both the
> requirements of the device tree to be 8 byte aligned as well as that our
> logic to generate the -pad file would match what ended up in the
> resulting binary. While it was correct to remove an unused section it
> did not solve ultimately solve the problem for all cases.
> 
> To really fix the problem, we need to do two things. First, our final
> section prior to _image_binary_end must be 8 byte aligned (for the case
> of having a separate BSS and so our appended DTB exists at this
> location). This cannot be '.binman_sym_table' as it may be empty, and in
> turn the ELF type would be NOBITS and so not copied with objcopy. The
> __u_boot_list section will never be empty, so it is our final section,
> and ends with a '. = ALIGN(8)' statement. Second, as this is the end of
> our copied data it is safe to declare that the BSS starts here, so use
> the OVERLAY keyword to place the BSS here.
> 
> Fixes: 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts")
> Reported-by: Brian Sune <briansune@gmail.com>
> Reported-by: Phil Phil Sutter <phil@nwl.cc>
> Signed-off-by: Tom Rini <trini@konsulko.com>

On Synology DS414:

Tested-by: Phil Sutter <phil@nwl.cc>

Thanks, Tom!

Re: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS

[Sune Brian]

On Fri, Feb 6, 2026 at 7:42 AM Tom Rini <trini@konsulko.com> wrote:
>
> Historically, when we have an appended device tree and also our
> resulting binary will contain the BSS section, we have ensured that
> everything will be where it's expected to be by declaring that the BSS
> is overlayed with a symbol matches the end of the port of the ELF binary
> that is objcopy'd to the binary we concatenate with. This in turn means
> that the logic to generate a "pad" file, which is the size found in the
> __bss_size symbol, will be correct and then we can concatenate the
> device tree and it will begin at __bss_size at run time.
>
> With commit 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts")
> we removed this overlay as part of trying to ensure that we met both the
> requirements of the device tree to be 8 byte aligned as well as that our
> logic to generate the -pad file would match what ended up in the
> resulting binary. While it was correct to remove an unused section it
> did not solve ultimately solve the problem for all cases.
>
> To really fix the problem, we need to do two things. First, our final
> section prior to _image_binary_end must be 8 byte aligned (for the case
> of having a separate BSS and so our appended DTB exists at this
> location). This cannot be '.binman_sym_table' as it may be empty, and in
> turn the ELF type would be NOBITS and so not copied with objcopy. The
> __u_boot_list section will never be empty, so it is our final section,
> and ends with a '. = ALIGN(8)' statement. Second, as this is the end of
> our copied data it is safe to declare that the BSS starts here, so use
> the OVERLAY keyword to place the BSS here.
>
> Fixes: 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts")
> Reported-by: Brian Sune <briansune@gmail.com>
> Reported-by: Phil Phil Sutter <phil@nwl.cc>
> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
> Cc: Richard Henderson <richard.henderson@linaro.org>
> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Cc: Marek Vasut <marek.vasut+renesas@mailbox.org>
> Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> Cc: Nathan Barrett-Morrison <nathan.morrison@timesys.com>
> Cc: Greg Malysa <malysagreg@gmail.com>
> Cc: Ian Roberts <ian.roberts@timesys.com>
> Cc: Vasileios Bimpikas <vasileios.bimpikas@analog.com>
> Cc: Utsav Agarwal <utsav.agarwal@analog.com>
> Cc: Arturs Artamonovs <arturs.artamonovs@analog.com>
> Cc: adsp-linux@analog.com
>
> So, first, with the exception of:
> axm brppt2 imx28_btt3 imx28_xea mk808 taurus work_92105
> all platforms using arch/arm/cpu/u-boot-spl.lds do NOT enable
> CONFIG_SPL_SEPARATE_BSS. And of those, only brppt2 enables SPL_OF_REAL.
> As an aside, I'm thinking that there is room for a clean-up / merger of
> arch/arm/cpu/u-boot-spl.lds and arch/arm/mach-omap2/u-boot-spl.lds
> (*widely* used outside of mach-omap2). But for this patch, that one case
> is handled correctly, with the first change I explained. All other 32bit
> platforms are handled with the second.
>
> Which means second, 64bit ARM platforms. With the exception of:
> socfpga_agilex7m socfpga_n5x_atf socfpga_n5x_vab socfpga_stratix10_atf
> all ARM64 SPL_FRAMEWORK using platforms use the
> arch/arm/cpu/armv8/u-boot-spl.lds explicitly. These other ones set
> CONFIG_SPL_LDSCRIPT to a non-existant file and then fall back to using
> arch/arm/cpu/armv8/u-boot-spl.lds. There are only 4 platforms which
> don't use a separate BSS section and so could trip up the above as well:
> r8a779g0_whitehawk r8a779g3_sparrowhawk sc598-som-ezkit-spl sc598-som-ezlite-spl
> I have inspected the Renesas platforms manually, and I'm a little unsure
> how this case works on the two sc598 platforms.
> ---
>  arch/arm/cpu/armv8/u-boot-spl.lds | 15 ++++++++-------
>  arch/arm/cpu/u-boot-spl.lds       | 12 ++++++------
>  2 files changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds b/arch/arm/cpu/armv8/u-boot-spl.lds
> index b732133ce76d..39020a1fddde 100644
> --- a/arch/arm/cpu/armv8/u-boot-spl.lds
> +++ b/arch/arm/cpu/armv8/u-boot-spl.lds
> @@ -49,12 +49,6 @@ SECTIONS
>         } >.sram
>  #endif
>
> -       __u_boot_list : {
> -               . = ALIGN(8);
> -               KEEP(*(SORT(__u_boot_list*)));
> -               . = ALIGN(8);
> -       } >.sram
> -
>         .binman_sym_table : {
>                 . = ALIGN(8);
>                 __binman_sym_start = .;
> @@ -63,6 +57,12 @@ SECTIONS
>                 . = ALIGN(8);
>         } > .sram
>
> +       __u_boot_list : {
> +               . = ALIGN(8);
> +               KEEP(*(SORT(__u_boot_list*)));
> +               . = ALIGN(8);
> +       } >.sram
> +
>         __image_copy_end = .;
>         _end = .;
>         _image_binary_end = .;
> @@ -75,7 +75,7 @@ SECTIONS
>                 __bss_end = .;
>         } >.sdram
>  #else
> -       .bss (NOLOAD) : {
> +       .bss _image_binary_end (OVERLAY) : {
>                 __bss_start = .;
>                 *(.bss*)
>                  . = ALIGN(8);
> @@ -99,5 +99,6 @@ SECTIONS
>
>  ASSERT(_image_binary_end % 8 == 0, \
>         "_image_binary_end must be 8-byte aligned for device tree");
> +
>  ASSERT(ADDR(.bss) % 8 == 0, \
>         ".bss must be 8-byte aligned");


For ARM v7 on SoCFPGA GEN5 no issue under AC501:

Tested-by: Brian Sune <briansune@gmail.com>

Boot Message as follows:

U-Boot SPL 2026.04-rc1-00154-gb5213bbfdcb1-dirty (Feb 06 2026 - 09:11:02 +0800)


U-Boot 2026.04-rc1-00154-gb5213bbfdcb1-dirty (Feb 06 2026 - 09:11:02 +0800)

CPU:   Altera SoCFPGA Platform
FPGA:  Altera Cyclone V, SE/A2 or SX/C2, version 0x0
BOOT:  SD/MMC Internal Transceiver (3.0V)
DRAM:  1 GiB
Core:  29 devices, 15 uclasses, devicetree: separate
MMC:   dwmmc0@ff704000: 0
Loading Environment from MMC... Card did not respond to voltage select! : -110
*** Warning - No block device, using default environment

In:    serial
Out:   serial
Err:   serial
Model: CoreCourse AC501SoC
Net:
Warning: ethernet@ff702000 (eth0) using random MAC address - 36:e3:3d:93:85:a5
eth0: ethernet@ff702000
Hit any key to stop autoboot: 0


> diff --git a/arch/arm/cpu/u-boot-spl.lds b/arch/arm/cpu/u-boot-spl.lds
> index c578c3ebf821..97083319d39d 100644
> --- a/arch/arm/cpu/u-boot-spl.lds
> +++ b/arch/arm/cpu/u-boot-spl.lds
> @@ -31,16 +31,16 @@ SECTIONS
>                 *(.data*)
>         }
>
> -       . = ALIGN(4);
> -       __u_boot_list : {
> -               KEEP(*(SORT(__u_boot_list*)));
> -       }
> -
>         . = ALIGN(4);
>         .binman_sym_table : {
>                 __binman_sym_start = .;
>                 KEEP(*(SORT(.binman_sym*)));
>                 __binman_sym_end = .;
> +       }
> +
> +       . = ALIGN(4);
> +       __u_boot_list : {
> +               KEEP(*(SORT(__u_boot_list*)));
>                 . = ALIGN(8);
>         }
>
> @@ -48,7 +48,7 @@ SECTIONS
>         _image_binary_end = .;
>         _end = .;
>
> -       .bss : {
> +       .bss _image_binary_end (OVERLAY) : {
>                 __bss_start = .;
>                 *(.bss*)
>                  . = ALIGN(8);
> --
> 2.43.0
>

Re: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS

[Marek Vasut]

On 2/6/26 12:41 AM, Tom Rini wrote:
> Historically, when we have an appended device tree and also our
> resulting binary will contain the BSS section, we have ensured that
> everything will be where it's expected to be by declaring that the BSS
> is overlayed with a symbol matches the end of the port

part ?

> of the ELF binary
> that is objcopy'd to the binary we concatenate with. This in turn means
> that the logic to generate a "pad" file, which is the size found in the
> __bss_size symbol, will be correct and then we can concatenate the
> device tree and it will begin at __bss_size at run time.
> 
> With commit 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts")
> we removed this overlay as part of trying to ensure that we met both the
> requirements of the device tree to be 8 byte aligned as well as that our
> logic to generate the -pad file would match what ended up in the
> resulting binary. While it was correct to remove an unused section it
> did not solve ultimately solve the problem for all cases.

solve ultimately solve ... one solve is enough

> To really fix the problem, we need to do two things. First, our final
> section prior to _image_binary_end must be 8 byte aligned (for the case
> of having a separate BSS and so our appended DTB exists at this
> location). This cannot be '.binman_sym_table' as it may be empty, and in
> turn the ELF type would be NOBITS and so not copied with objcopy. The
> __u_boot_list section will never be empty

How can we be sure of that ?

> , so it is our final section,
> and ends with a '. = ALIGN(8)' statement. Second, as this is the end of
> our copied data it is safe to declare that the BSS starts here, so use
> the OVERLAY keyword to place the BSS here.

[...]

> @@ -99,5 +99,6 @@ SECTIONS
>   
>   ASSERT(_image_binary_end % 8 == 0, \
>          "_image_binary_end must be 8-byte aligned for device tree");
> +
>   ASSERT(ADDR(.bss) % 8 == 0, \
>          ".bss must be 8-byte aligned");
Please drop this extra newline ^ .

Re: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2429 bytes --]

On Fri, Feb 06, 2026 at 06:09:49PM +0100, Marek Vasut wrote:
> On 2/6/26 12:41 AM, Tom Rini wrote:
> > Historically, when we have an appended device tree and also our
> > resulting binary will contain the BSS section, we have ensured that
> > everything will be where it's expected to be by declaring that the BSS
> > is overlayed with a symbol matches the end of the port
> 
> part ?
> 
> > of the ELF binary
> > that is objcopy'd to the binary we concatenate with. This in turn means
> > that the logic to generate a "pad" file, which is the size found in the
> > __bss_size symbol, will be correct and then we can concatenate the
> > device tree and it will begin at __bss_size at run time.
> > 
> > With commit 5ffc1dcc26d3 ("arm: Remove rel.dyn from SPL linker scripts")
> > we removed this overlay as part of trying to ensure that we met both the
> > requirements of the device tree to be 8 byte aligned as well as that our
> > logic to generate the -pad file would match what ended up in the
> > resulting binary. While it was correct to remove an unused section it
> > did not solve ultimately solve the problem for all cases.
> 
> solve ultimately solve ... one solve is enough

Yeah, oops.

> > To really fix the problem, we need to do two things. First, our final
> > section prior to _image_binary_end must be 8 byte aligned (for the case
> > of having a separate BSS and so our appended DTB exists at this
> > location). This cannot be '.binman_sym_table' as it may be empty, and in
> > turn the ELF type would be NOBITS and so not copied with objcopy. The
> > __u_boot_list section will never be empty
> 
> How can we be sure of that ?

That __u_boot_list will never be empty? There's too much non-trivial
code using it.

> > , so it is our final section,
> > and ends with a '. = ALIGN(8)' statement. Second, as this is the end of
> > our copied data it is safe to declare that the BSS starts here, so use
> > the OVERLAY keyword to place the BSS here.
> 
> [...]
> 
> > @@ -99,5 +99,6 @@ SECTIONS
> >   ASSERT(_image_binary_end % 8 == 0, \
> >          "_image_binary_end must be 8-byte aligned for device tree");
> > +
> >   ASSERT(ADDR(.bss) % 8 == 0, \
> >          ".bss must be 8-byte aligned");
> Please drop this extra newline ^ .

I'll fix that (and the port->part and solve) when applying, assuming no
feedback from the toolchain gurus.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS

[Greg Malysa]

Hi Tom,

On Thu, Feb 5, 2026 at 6:42 PM Tom Rini <trini@konsulko.com> wrote:
>
> Which means second, 64bit ARM platforms. With the exception of:
> socfpga_agilex7m socfpga_n5x_atf socfpga_n5x_vab socfpga_stratix10_atf
> all ARM64 SPL_FRAMEWORK using platforms use the
> arch/arm/cpu/armv8/u-boot-spl.lds explicitly. These other ones set
> CONFIG_SPL_LDSCRIPT to a non-existant file and then fall back to using
> arch/arm/cpu/armv8/u-boot-spl.lds. There are only 4 platforms which
> don't use a separate BSS section and so could trip up the above as well:
> r8a779g0_whitehawk r8a779g3_sparrowhawk sc598-som-ezkit-spl sc598-som-ezlite-spl
> I have inspected the Renesas platforms manually, and I'm a little unsure
> how this case works on the two sc598 platforms.

Do you recommend using SPL_SEPARATE_BSS on our platform? After power
on, the sc598 has 2 MB of SRAM available starting at 0x20000000 which
we treat as just a single block of memory to use for all of SPL
operation, so we don't have any requirement to do something like a
bare bones DDR initialization before using it as our main memory for
SPL, so it didn't seem necessary to enable. The boot ROM has some
guidelines on where it will place its stack, so we restrict SPL to the
first 192 KB currently but this can easily be expanded. I'm not sure
if I should admit to it, but some decisions on Kconfigs were made 4
years ago as an arbitrary choice during our initial bringup and then
were not reviewed because things were working.

Either way, works for me on the sc598 + ezkit. There's no reason for
it to fail on the ezlite in that case either.

Tested-by: Greg Malysa <malysagreg@gmail.com>

Thanks,
Greg

Re: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]

On Fri, Feb 06, 2026 at 07:02:07PM -0500, Greg Malysa wrote:
> Hi Tom,
> 
> On Thu, Feb 5, 2026 at 6:42 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > Which means second, 64bit ARM platforms. With the exception of:
> > socfpga_agilex7m socfpga_n5x_atf socfpga_n5x_vab socfpga_stratix10_atf
> > all ARM64 SPL_FRAMEWORK using platforms use the
> > arch/arm/cpu/armv8/u-boot-spl.lds explicitly. These other ones set
> > CONFIG_SPL_LDSCRIPT to a non-existant file and then fall back to using
> > arch/arm/cpu/armv8/u-boot-spl.lds. There are only 4 platforms which
> > don't use a separate BSS section and so could trip up the above as well:
> > r8a779g0_whitehawk r8a779g3_sparrowhawk sc598-som-ezkit-spl sc598-som-ezlite-spl
> > I have inspected the Renesas platforms manually, and I'm a little unsure
> > how this case works on the two sc598 platforms.
> 
> Do you recommend using SPL_SEPARATE_BSS on our platform? After power
> on, the sc598 has 2 MB of SRAM available starting at 0x20000000 which
> we treat as just a single block of memory to use for all of SPL
> operation, so we don't have any requirement to do something like a
> bare bones DDR initialization before using it as our main memory for
> SPL, so it didn't seem necessary to enable. The boot ROM has some
> guidelines on where it will place its stack, so we restrict SPL to the
> first 192 KB currently but this can easily be expanded. I'm not sure
> if I should admit to it, but some decisions on Kconfigs were made 4
> years ago as an arbitrary choice during our initial bringup and then
> were not reviewed because things were working.
> 
> Either way, works for me on the sc598 + ezkit. There's no reason for
> it to fail on the ezlite in that case either.

So SPL_SEPARATE_BSS is for when the BSS can be easily put in SDRAM
instead. It's not better or worse than SRAM, it just depends on the
system constraints. I only called these two platforms out because I
don't actually see where the dtb comes from and so couldn't check the
alignment and location matched.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS

[Tom Rini]

On Thu, 05 Feb 2026 17:41:58 -0600, Tom Rini wrote:

> Historically, when we have an appended device tree and also our
> resulting binary will contain the BSS section, we have ensured that
> everything will be where it's expected to be by declaring that the BSS
> is overlayed with a symbol matches the end of the port of the ELF binary
> that is objcopy'd to the binary we concatenate with. This in turn means
> that the logic to generate a "pad" file, which is the size found in the
> __bss_size symbol, will be correct and then we can concatenate the
> device tree and it will begin at __bss_size at run time.
> 
> [...]

Applied to u-boot/master, thanks!

[1/1] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS
      commit: 89965b5eb597d50d052ee79b531f17495cff6f29
-- 
Tom