public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Cc: Brian Sune <briansune@gmail.com>, Phil Phil Sutter <phil@nwl.cc>,
	Richard Henderson <richard.henderson@linaro.org>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Marek Vasut <marek.vasut+renesas@mailbox.org>,
	Nobuhiro Iwamatsu <iwamatsu@nigauri.org>,
	Nathan Barrett-Morrison <nathan.morrison@timesys.com>,
	Greg Malysa <malysagreg@gmail.com>,
	Ian Roberts <ian.roberts@timesys.com>,
	Vasileios Bimpikas <vasileios.bimpikas@analog.com>,
	Utsav Agarwal <utsav.agarwal@analog.com>,
	Arturs Artamonovs <arturs.artamonovs@analog.com>,
	adsp-linux@analog.com
Subject: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS
Date: Thu,  5 Feb 2026 17:41:58 -0600	[thread overview]
Message-ID: <20260205234158.3768337-1-trini@konsulko.com> (raw)
In-Reply-To: <20260130183635.2612933-1-trini@konsulko.com>

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


  parent reply	other threads:[~2026-02-05 23:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-30 18:36 [PATCH] spl: Ensure final section before BSS is non-empty Tom Rini
2026-02-02 17:42 ` Sune Brian
2026-02-05 23:41 ` Tom Rini [this message]
2026-02-06  0:43   ` [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS Phil Sutter
2026-02-06  1:14   ` Sune Brian
2026-02-06 17:09   ` Marek Vasut
2026-02-06 18:00     ` Tom Rini
2026-02-07  0:02   ` Greg Malysa
2026-02-09 14:30     ` Tom Rini
2026-02-09 20:41   ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260205234158.3768337-1-trini@konsulko.com \
    --to=trini@konsulko.com \
    --cc=adsp-linux@analog.com \
    --cc=arturs.artamonovs@analog.com \
    --cc=briansune@gmail.com \
    --cc=ian.roberts@timesys.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=iwamatsu@nigauri.org \
    --cc=malysagreg@gmail.com \
    --cc=marek.vasut+renesas@mailbox.org \
    --cc=nathan.morrison@timesys.com \
    --cc=phil@nwl.cc \
    --cc=richard.henderson@linaro.org \
    --cc=u-boot@lists.denx.de \
    --cc=utsav.agarwal@analog.com \
    --cc=vasileios.bimpikas@analog.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox