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 <[email protected]>
> > > > > >
> > > > > > 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/[email protected]/
> > > > > 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=mxzcc7qftgo...@mail.gmail.com/
> https://lore.kernel.org/u-boot/[email protected]/
>
> 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?
Cheers, Phil
