* Re: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS
2026-02-05 23:41 ` [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS Tom Rini
@ 2026-02-06 0:43 ` Phil Sutter
2026-02-06 1:14 ` Sune Brian
` (3 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Phil Sutter @ 2026-02-06 0:43 UTC (permalink / raw)
To: Tom Rini
Cc: u-boot, Brian Sune, Richard Henderson, Ilias Apalodimas,
Marek Vasut, Nobuhiro Iwamatsu, Nathan Barrett-Morrison,
Greg Malysa, Ian Roberts, Vasileios Bimpikas, Utsav Agarwal,
Arturs Artamonovs, adsp-linux
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!
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS
2026-02-05 23:41 ` [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS Tom Rini
2026-02-06 0:43 ` Phil Sutter
@ 2026-02-06 1:14 ` Sune Brian
2026-02-06 17:09 ` Marek Vasut
` (2 subsequent siblings)
4 siblings, 0 replies; 10+ messages in thread
From: Sune Brian @ 2026-02-06 1:14 UTC (permalink / raw)
To: Tom Rini
Cc: u-boot, Phil Phil Sutter, Richard Henderson, Ilias Apalodimas,
Marek Vasut, Nobuhiro Iwamatsu, Nathan Barrett-Morrison,
Greg Malysa, Ian Roberts, Vasileios Bimpikas, Utsav Agarwal,
Arturs Artamonovs, adsp-linux
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
>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS
2026-02-05 23:41 ` [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS Tom Rini
2026-02-06 0:43 ` 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 20:41 ` Tom Rini
4 siblings, 1 reply; 10+ messages in thread
From: Marek Vasut @ 2026-02-06 17:09 UTC (permalink / raw)
To: Tom Rini, u-boot
Cc: Brian Sune, Phil Phil Sutter, Richard Henderson, Ilias Apalodimas,
Marek Vasut, Nobuhiro Iwamatsu, Nathan Barrett-Morrison,
Greg Malysa, Ian Roberts, Vasileios Bimpikas, Utsav Agarwal,
Arturs Artamonovs, adsp-linux
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 ^ .
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS
2026-02-06 17:09 ` Marek Vasut
@ 2026-02-06 18:00 ` Tom Rini
0 siblings, 0 replies; 10+ messages in thread
From: Tom Rini @ 2026-02-06 18:00 UTC (permalink / raw)
To: Marek Vasut
Cc: u-boot, Brian Sune, Phil Phil Sutter, Richard Henderson,
Ilias Apalodimas, Marek Vasut, Nobuhiro Iwamatsu,
Nathan Barrett-Morrison, Greg Malysa, Ian Roberts,
Vasileios Bimpikas, Utsav Agarwal, Arturs Artamonovs, adsp-linux
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS
2026-02-05 23:41 ` [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS Tom Rini
` (2 preceding siblings ...)
2026-02-06 17:09 ` Marek Vasut
@ 2026-02-07 0:02 ` Greg Malysa
2026-02-09 14:30 ` Tom Rini
2026-02-09 20:41 ` Tom Rini
4 siblings, 1 reply; 10+ messages in thread
From: Greg Malysa @ 2026-02-07 0:02 UTC (permalink / raw)
To: Tom Rini
Cc: u-boot, Brian Sune, Phil Phil Sutter, Richard Henderson,
Ilias Apalodimas, Marek Vasut, Nobuhiro Iwamatsu,
Nathan Barrett-Morrison, Ian Roberts, Vasileios Bimpikas,
Utsav Agarwal, Arturs Artamonovs, adsp-linux
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS
2026-02-07 0:02 ` Greg Malysa
@ 2026-02-09 14:30 ` Tom Rini
0 siblings, 0 replies; 10+ messages in thread
From: Tom Rini @ 2026-02-09 14:30 UTC (permalink / raw)
To: Greg Malysa
Cc: u-boot, Brian Sune, Phil Phil Sutter, Richard Henderson,
Ilias Apalodimas, Marek Vasut, Nobuhiro Iwamatsu,
Nathan Barrett-Morrison, Ian Roberts, Vasileios Bimpikas,
Utsav Agarwal, Arturs Artamonovs, adsp-linux
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS
2026-02-05 23:41 ` [PATCH v2] arm: spl: Ensure 8 byte alignment of appended DTB without separate BSS Tom Rini
` (3 preceding siblings ...)
2026-02-07 0:02 ` Greg Malysa
@ 2026-02-09 20:41 ` Tom Rini
4 siblings, 0 replies; 10+ messages in thread
From: Tom Rini @ 2026-02-09 20:41 UTC (permalink / raw)
To: u-boot, Tom Rini
Cc: Brian Sune, Phil Phil Sutter, Richard Henderson, Ilias Apalodimas,
Marek Vasut, Nobuhiro Iwamatsu, Nathan Barrett-Morrison,
Greg Malysa, Ian Roberts, Vasileios Bimpikas, Utsav Agarwal,
Arturs Artamonovs, adsp-linux
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
^ permalink raw reply [flat|nested] 10+ messages in thread