[PATCH 02/10] arm: Update linker scripts to ensure appended device tree is aligned

[Tom Rini]

On Thu, Jan 22, 2026 at 12:08:04AM -0300, Fabio Estevam wrote:
> Hi Tom,
> 
> On Thu, Jan 15, 2026 at 7:28 PM Tom Rini <trini at konsulko.com> wrote:
> >
> > With commit 0535e46d55d7 ("scripts/dtc: Update to upstream version
> > v1.7.2-35-g52f07dcca47c") it is now a fatal error to U-Boot if our
> > device tree is not 8-byte aligned. In commit f613a6e15ef7 ("ARM: OMAP2+:
> > Pad SPL binary to 8-byte alignment before DTB") Beleswar Padhi explains
> > that we must have ALIGN(x) statements inside of a section to ensure that
> > padding is included and not simply that the linker address counter is
> > incremented. To that end, this patch:
> > - Expands some linker sections to be more readable when adding a second
> >   statement to the section.
> > - Aligns the final section before _end (for U-Boot) or
> >   _image_binary_end or __bss_end (for xPL phases) by 8-bytes by adding
> >   '. = ALIGN(8);' to the final section before the symbol.
> > - Ensure that we do have alignment by adding an ASSERT so that when not
> >   aligned we fail to link (and explain why).
> > - Remove now-spurious  '. = ALIGN(x);' statements that were intended to
> >   provide the above alignments.
> >
> > Signed-off-by: Tom Rini <trini at konsulko.com>
> > ---
> > The only part of this I am only mostly rather than fully confident in is
> > having caught all cases of having SPL_SEPARATE_BSS being false. I
> > believe I have as the generic ARM SPL linker script enforces the BSS
> > ending with 8-byte alignment, and the point of the ASSERTs here is to
> > catch the case where the section we're adding the ALIGN to ends up being
> > empty and so that ALIGN would become useless.
> 
> I'm working on bringing up Rockchip RV1103 (ARMv7 SoC, no custom .lds file)
> 
> After this patch is applied, the board does not boot anymore:
> 
> Missing DTB
> spl_early_init() failed: -2
> ### ERROR ### Please RESET the board ###
> 
> If I force "imply SPL_SEPARATE_BSS" in the SoC Kconfig, the board boots again.
> 
> In this case, the build shows some warnings:
> 
>   LD      spl/u-boot-spl
> /usr/bin/arm-linux-gnueabihf-ld: invalid length for memory region .sram
> /usr/bin/arm-linux-gnueabihf-ld: invalid origin for memory region .sdram
> /usr/bin/arm-linux-gnueabihf-ld: invalid length for memory region .sdram
>   OBJCOPY spl/u-boot-spl-nodtb.bin
>   SYM     spl/u-boot-spl.sym
>   CAT     spl/u-boot-spl-dtb.bin
>   COPY    spl/u-boot-spl.bin
>   BINMAN  .binman_stamp
>   OFCHK   .config
> 
> RV1108 is also an ARMv7 without SPL_SEPARATE_BSS, so I believe it is
> also affected by this change.
> 
> What do you suggest?

Where are those memory regions coming from? They aren't specified in
arch/arm/cpu/u-boot-spl.lds

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260122/ebb0528e/attachment.sig>