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 <[email protected]> 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 <[email protected]> > > --- > > 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
signature.asc
Description: PGP signature
