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

[Tom Rini <trini@konsulko.com>]

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

On Thu, Feb 05, 2026 at 12:00:34AM +0100, Phil Sutter wrote:
> On Wed, Feb 04, 2026 at 03:50:16PM -0600, Tom Rini wrote:
> > On Wed, Feb 04, 2026 at 10:40:12PM +0100, Phil Sutter wrote:
> > > On Wed, Feb 04, 2026 at 03:31:39PM -0600, Tom Rini wrote:
> > > > On Wed, Feb 04, 2026 at 10:27:11PM +0100, Phil Sutter wrote:
> > > > > On Wed, Feb 04, 2026 at 03:20:10PM -0600, Tom Rini wrote:
> > > > > > On Wed, Feb 04, 2026 at 10:16:12PM +0100, Phil Sutter wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On Thu, Jan 15, 2026 at 04:19:32PM -0600, Tom Rini 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@konsulko.com>
> > > > > > > 
> > > > > > > For unclear reasons, this seems to break boot via xmodem protocol on my
> > > > > > > Synology DS414. I found this commit via 'git bisect'. The symptom is:
> > > > > > > 
> > > > > > > | kwboot version 2026.04-rc1-00098-g6ad0cf8f83db
> > > > > > > | Detected kwbimage v1 with SPI boot signature
> > > > > > > | Patching image boot signature to UART
> > > > > > > | Aligning image header to Xmodem block size
> > > > > > > | Sending boot message. Please reboot the target...\
> > > > > > > | Sending boot image header (67584 bytes)...
> > > > > > > |   0 % [......................................................................]
> > > > > > > |  13 % [......................................................................]
> > > > > > > |  26 % [......................................................................]
> > > > > > > |  39 % [......................................................................]
> > > > > > > |  53 % [......................................................................]
> > > > > > > |  66 % [......................................................................]
> > > > > > > |  79 % [......................................................................]
> > > > > > > |  92 % [......................................                                ]
> > > > > > > | Done
> > > > > > > | Missing DTB
> > > > > > > | spl_init() failed: -2
> > > > > > > | ### ERROR ### Please RESET the board ###
> > > > > > > | 
> > > > > > > | 
> > > > > > > | xmodem: Connection timed out
> > > > > > > 
> > > > > > > Debug printf()s in fdtdec_prepare_fdt() show that fdt_check_header()
> > > > > > > returns -FDT_ERR_BADMAGIC.
> > > > > > > 
> > > > > > > With HEAD at a8d982e1f1726 ("x86: cpu: Fix crash on FTRACE enabled
> > > > > > > builds"), reverting arch/arm/cpu/u-boot-spl.lds like so:
> > > > > > > 
> > > > > > > | @@ -41,14 +41,21 @@ SECTIONS
> > > > > > > |                 __binman_sym_start = .;
> > > > > > > |                 KEEP(*(SORT(.binman_sym*)));
> > > > > > > |                 __binman_sym_end = .;
> > > > > > > | -               . = ALIGN(8);
> > > > > > > |         }
> > > > > > > |  
> > > > > > > | +       . = ALIGN(4); /* critical! */
> > > > > > > |         __image_copy_end = .;
> > > > > > > | +       .rel.dyn : {
> > > > > > > | +               __rel_dyn_start = .;
> > > > > > > | +               *(.rel*)
> > > > > > > | +               __rel_dyn_end = .;
> > > > > > > | +       }
> > > > > > > | +
> > > > > > > | +       . = ALIGN(8);
> > > > > > > |         _image_binary_end = .;
> > > > > > > |         _end = .;
> > > > > > > |  
> > > > > > > | -       .bss : {
> > > > > > > | +       .bss __rel_dyn_start (OVERLAY) : {
> > > > > > > |                 __bss_start = .;
> > > > > > > |                 *(.bss*)
> > > > > > > |                  . = ALIGN(8);
> > > > > > > 
> > > > > > > The SPL image starts up again and continues loading the real uboot
> > > > > > > image. Note that I have no idea what these changes actually do, so I
> > > > > > > need instructions if I should dig further.
> > > > > > 
> > > > > > Does:
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20260130183635.2612933-1-trini@konsulko.com/
> > > > > > fix it?
> > > > > 
> > > > > Sadly not, same result.
> > > > 
> > > > Ugh. What file, specifically, do you send via xmodem? And so that maybe
> > > > I can more easily replicate the failure, are you using the kernel.org
> > > > gcc-14.2.0 toolchain or something else?
> > > 
> > > I am building with a custom-built arm-openadk-linux-uclibceabi-gcc
> > > version 14.3.0. Basically what I run is:
> > > 
> > > MYENV='ARCH=arm CROSS_COMPILE=~/git/openadk-ds414/toolchain_synology-ds414_uclibc-ng_softfp_eabi_arm/usr/bin/arm-openadk-linux-uclibceabi-'
> > > 
> > > make $MYENV clean && \
> > > for f in $(ls u-boot*.kwb 2>/dev/null); do rm $f; done && \
> > > make $MYENV ds414_defconfig && \
> > > make $MYENV -j12 && \
> > > ./tools/kwboot -a -t -p -b u-boot-*spl.kwb /dev/ttyUSB0
> > > 
> > > With current uboot, this should be u-boot-with-spl.kwb image.
> > > 
> > > With said patch reverted (or the above changes applied), I produce a
> > > working u-boot-with-spl.kwb which loads and boots linux from flash. So
> > > my toolchain is at least not totally broken. ;)
> > 
> > Right, so, for background, the following threads might shed some light
> > on things:
> > https://lore.kernel.org/u-boot/CAOMZO5DZNJ+=AP1spWCv7Ar6etf03H=DFVU=mXZcC7QFTGoh_Q@mail.gmail.com/
> > https://lore.kernel.org/u-boot/20260123161907.392211-1-festevam@gmail.com/
> > 
> > And so to that end, can you please do:
> > hexdump -Cv u-boot-with-spl.kwb | grep 'd0 0d fe ed'
> > and let me know what that says? And the first line there should match,
> > content-wise at least (but not quite file offset) spl/u-boot-spl. I was
> > asking about your toolchain because with gcc-14.2.0 from kernel.org:
> > $ hexdump -Cv /tmp/ds414/spl/u-boot-spl | grep 'd0 0d fe ed'
> > 00002ed0  6f f0 12 00 70 47 00 bf  d0 0d fe ed 00 29 05 db  |o...pG.......)..|
> > $ hexdump -Cv /tmp/ds414/u-boot-with-spl.kwb | grep 'd0 0d fe ed'
> > 00001ed0  6f f0 12 00 70 47 00 bf  d0 0d fe ed 00 29 05 db  |o...pG.......)..|
> 
> This is with HEAD at a8d982e1f17 + your "spl: Ensure final section before BSS
> is non-empty" applied:
> 
> % hexdump -Cv u-boot-with-spl.kwb | grep 'd0 0d fe ed' | head -n1
> 00001ed0  6f f0 12 00 70 47 00 bf  d0 0d fe ed 00 29 05 db  |o...pG.......)..|
> 
> % hexdump -Cv spl/u-boot-spl | grep 'd0 0d fe ed'
> 00002ed0  6f f0 12 00 70 47 00 bf  d0 0d fe ed 00 29 05 db  |o...pG.......)..|
> 
> > And while this should then *work* that's luck and not design. If you can
> > confirm that instead 'd0 0d fe ed' is in the middle (and so 4 byte but
> > not 8 byte aligned) it'll at least be the same symptom as before.
> 
> Hmm. My dumps indicate correct 8B alignment, right? Switching over to a branch
> which has the problematic commit reverted and produced images work, I
> get exactly the same output from hexdump on those files, BTW. Does that
> mean we're on the wrong track and my problem is not wrong DTB alignment?

So, I'm not sure. The error message is what shows up quickly from trying
to find the device tree, and not finding it. In debugging the other
times, we did see mysterious shifts 4 bytes in either direction, but
never 8 bytes. I think you might need to start throwing some debug
prints around and seeing where the device tree *is* at run time in
relation to where it's expected to be.

-- 
Tom

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