From: Phil Sutter <phil@nwl.cc>
To: Tom Rini <trini@konsulko.com>
Cc: u-boot@lists.denx.de,
Marek Vasut <marek.vasut+renesas@mailbox.org>,
Beleswar Padhi <b-padhi@ti.com>,
"NXP i.MX U-Boot Team" <uboot-imx@nxp.com>,
Adam Ford <aford173@gmail.com>,
Andre Przywara <andre.przywara@arm.com>,
Aspeed BMC SW team <BMC-SW@aspeedtech.com>,
Chia-Wei Wang <chiawei_wang@aspeedtech.com>,
Eugen Hristev <eugen.hristev@linaro.org>,
Fabio Estevam <festevam@gmail.com>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Jagan Teki <jagan@amarulasolutions.com>,
Joel Stanley <joel@jms.id.au>,
Kever Yang <kever.yang@rock-chips.com>,
Michal Simek <michal.simek@amd.com>,
Philipp Tomsich <philipp.tomsich@vrull.eu>,
Richard Henderson <richard.henderson@linaro.org>,
Ryan Chen <ryan_chen@aspeedtech.com>,
Stefano Babic <sbabic@nabladev.com>
Subject: Re: [PATCH 02/10] arm: Update linker scripts to ensure appended device tree is aligned
Date: Thu, 5 Feb 2026 00:48:43 +0100 [thread overview]
Message-ID: <aYPa2_YU04etfIv9@orbyte.nwl.cc> (raw)
In-Reply-To: <20260204233550.GH2603314@bill-the-cat>
On Wed, Feb 04, 2026 at 05:35:50PM -0600, Tom Rini wrote:
> On Thu, Feb 05, 2026 at 12:29:52AM +0100, Phil Sutter wrote:
> > On Wed, Feb 04, 2026 at 05:04:16PM -0600, Tom Rini wrote:
> > > 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.
> >
> > FDT_MAGIC sequence is found 12B before 'blob' as passed to
> > fdtdec_prepare_fdt(). I searched in a range of (-128;127), it was the
> > only offset which matched.
>
> So, our mysterious 4 shift is now 12. If you undo the patch I asked you
> to test, is it now 4B before? I basically want to confirm that my newest
> patch just changes when we hit this problem and doesn't solve it, only
> changes the mystery shift. Oh, and can you please readelf -S the
> spl/u-boot-spl for both with my patch and current master AND the one you
> made work? Thanks again!
Sorry for the mess, I did my FDT_MAGIC search with master branch, so not
with your patch applied. Readelf prints:
% readelf -S spl/u-boot-spl
There are 20 section headers, starting at offset 0x127d54:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 40004030 001030 009c1e 00 AX 0 0 16
[ 2] .rodata PROGBITS 4000dc50 00ac50 0016f9 00 A 0 0 4
[ 3] .data PROGBITS 4000f360 00c360 0042e0 00 WA 0 0 32
[ 4] __u_boot_list PROGBITS 40013640 010640 000594 00 WA 0 0 4
[ 5] .binman_sym_table NOBITS 40013bd4 010bd4 000004 00 WA 0 0 1
[ 6] .bss NOBITS 40013be0 010bd4 000728 00 WA 0 0 32
[ 7] .ARM.attributes ARM_ATTRIBUTES 00000000 010bd4 000029 00 0 0 1
[ 8] .comment PROGBITS 00000000 010bfd 000012 01 MS 0 0 1
[ 9] .debug_line PROGBITS 00000000 010c0f 02844f 00 0 0 1
[10] .debug_info PROGBITS 00000000 03905e 076ced 00 0 0 1
[11] .debug_abbrev PROGBITS 00000000 0afd4b 00f697 00 0 0 1
[12] .debug_aranges PROGBITS 00000000 0bf3e8 002430 00 0 0 8
[13] .debug_str PROGBITS 00000000 0c1818 00d85c 01 MS 0 0 1
[14] .debug_loc PROGBITS 00000000 0cf074 044a87 00 0 0 1
[15] .debug_ranges PROGBITS 00000000 113b00 006578 00 0 0 8
[16] .debug_frame PROGBITS 00000000 11a078 0069c0 00 0 0 4
[17] .symtab SYMTAB 00000000 120a38 004d10 10 18 888 4
[18] .strtab STRTAB 00000000 125748 002539 00 0 0 1
[19] .shstrtab STRTAB 00000000 127c81 0000d3 00 0 0 1
Next try with your patch applied on top of master:
FDT_MAGIC is found at offset -8. Readelf:
There are 19 section headers, starting at offset 0x127d34:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 40004030 001030 009c1e 00 AX 0 0 16
[ 2] .rodata PROGBITS 4000dc50 00ac50 0016f9 00 A 0 0 4
[ 3] .data PROGBITS 4000f360 00c360 0042e0 00 WA 0 0 32
[ 4] __u_boot_list PROGBITS 40013640 010640 000598 00 WA 0 0 4
[ 5] .bss NOBITS 40013be0 010bd8 000728 00 WA 0 0 32
[ 6] .ARM.attributes ARM_ATTRIBUTES 00000000 010bd8 000029 00 0 0 1
[ 7] .comment PROGBITS 00000000 010c01 000012 01 MS 0 0 1
[ 8] .debug_line PROGBITS 00000000 010c13 02844f 00 0 0 1
[ 9] .debug_info PROGBITS 00000000 039062 076ced 00 0 0 1
[10] .debug_abbrev PROGBITS 00000000 0afd4f 00f697 00 0 0 1
[11] .debug_aranges PROGBITS 00000000 0bf3e8 002430 00 0 0 8
[12] .debug_str PROGBITS 00000000 0c1818 00d85c 01 MS 0 0 1
[13] .debug_loc PROGBITS 00000000 0cf074 044a87 00 0 0 1
[14] .debug_ranges PROGBITS 00000000 113b00 006578 00 0 0 8
[15] .debug_frame PROGBITS 00000000 11a078 0069c0 00 0 0 4
[16] .symtab SYMTAB 00000000 120a38 004d00 10 17 887 4
[17] .strtab STRTAB 00000000 125738 002539 00 0 0 1
[18] .shstrtab STRTAB 00000000 127c71 0000c1 00 0 0 1
Finally, with problematic patches reverted:
FDT_MAGIC is found at offset 0 (obviously). Readelf:
There are 19 section headers, starting at offset 0x1284a0:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 40004030 001030 009c1e 00 AX 0 0 16
[ 2] .rodata PROGBITS 4000dc50 00ac50 0016f9 00 A 0 0 4
[ 3] .data PROGBITS 4000f360 00c360 0042e0 00 WA 0 0 32
[ 4] __u_boot_list PROGBITS 40013640 010640 000594 00 WA 0 0 4
[ 5] .bss PROGBITS 40013bd4 010bd4 000734 00 W 0 0 4
[ 6] .ARM.attributes ARM_ATTRIBUTES 00000000 011308 000029 00 0 0 1
[ 7] .comment PROGBITS 00000000 011331 000012 01 MS 0 0 1
[ 8] .debug_line PROGBITS 00000000 011343 02844f 00 0 0 1
[ 9] .debug_info PROGBITS 00000000 039792 076ced 00 0 0 1
[10] .debug_abbrev PROGBITS 00000000 0b047f 00f697 00 0 0 1
[11] .debug_aranges PROGBITS 00000000 0bfb18 002430 00 0 0 8
[12] .debug_str PROGBITS 00000000 0c1f48 00d85c 01 MS 0 0 1
[13] .debug_loc PROGBITS 00000000 0cf7a4 044a87 00 0 0 1
[14] .debug_ranges PROGBITS 00000000 114230 006578 00 0 0 8
[15] .debug_frame PROGBITS 00000000 11a7a8 0069c0 00 0 0 4
[16] .symtab SYMTAB 00000000 121168 004d20 10 17 887 4
[17] .strtab STRTAB 00000000 125e88 002557 00 0 0 1
[18] .shstrtab STRTAB 00000000 1283df 0000c1 00 0 0 1
HTH, Phil
next prev parent reply other threads:[~2026-02-04 23:48 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-15 22:19 [PATCH 00/10] Update linker scripts to ensure appended device tree is correctly aligned Tom Rini
2026-01-15 22:19 ` [PATCH 01/10] Makefile: Have binary_size_check report only first match of _image_binary_end Tom Rini
2026-01-22 9:07 ` Marek Vasut
2026-01-22 14:21 ` Tom Rini
2026-01-15 22:19 ` [PATCH 02/10] arm: Update linker scripts to ensure appended device tree is aligned Tom Rini
2026-01-16 9:59 ` Ilias Apalodimas
2026-01-16 14:40 ` Tom Rini
2026-01-20 8:38 ` Ilias Apalodimas
2026-01-20 14:27 ` Tom Rini
2026-01-16 10:00 ` Michal Simek
2026-01-22 3:08 ` Fabio Estevam
2026-01-22 3:33 ` Fabio Estevam
2026-01-22 11:22 ` Marek Vasut
2026-01-22 14:23 ` Tom Rini
2026-01-22 18:47 ` Fabio Estevam
2026-01-22 19:10 ` Tom Rini
2026-01-22 19:19 ` Fabio Estevam
2026-01-22 19:28 ` Tom Rini
2026-01-22 19:32 ` Fabio Estevam
2026-01-22 19:42 ` Tom Rini
2026-01-22 22:56 ` Fabio Estevam
2026-01-22 23:24 ` Tom Rini
2026-01-23 0:25 ` Fabio Estevam
2026-01-23 0:52 ` Fabio Estevam
2026-01-23 14:27 ` Tom Rini
2026-01-23 15:45 ` Fabio Estevam
2026-01-23 15:50 ` Tom Rini
2026-01-22 14:25 ` Tom Rini
2026-02-04 21:16 ` Phil Sutter
2026-02-04 21:20 ` Tom Rini
2026-02-04 21:27 ` Phil Sutter
2026-02-04 21:31 ` Tom Rini
2026-02-04 21:40 ` Phil Sutter
2026-02-04 21:50 ` Tom Rini
2026-02-04 23:00 ` Phil Sutter
2026-02-04 23:04 ` Tom Rini
2026-02-04 23:29 ` Phil Sutter
2026-02-04 23:35 ` Tom Rini
2026-02-04 23:48 ` Phil Sutter [this message]
2026-02-05 18:01 ` Tom Rini
2026-01-15 22:19 ` [PATCH 03/10] m68k: " Tom Rini
2026-01-15 22:19 ` [PATCH 04/10] microblaze: " Tom Rini
2026-01-16 9:59 ` Michal Simek
2026-01-16 10:00 ` Ilias Apalodimas
2026-01-15 22:19 ` [PATCH 05/10] mips: " Tom Rini
2026-01-20 13:57 ` Daniel Schwierzeck
2026-01-15 22:19 ` [PATCH 06/10] nios2: " Tom Rini
2026-01-16 10:00 ` Ilias Apalodimas
2026-01-15 22:19 ` [PATCH 07/10] powerpc: " Tom Rini
2026-02-06 7:18 ` Christophe Leroy (CS GROUP)
2026-01-15 22:19 ` [PATCH 08/10] riscv: " Tom Rini
2026-01-16 1:27 ` Leo Liang
2026-01-16 9:49 ` Ilias Apalodimas
2026-01-15 22:19 ` [PATCH 09/10] sandbox: " Tom Rini
2026-01-15 22:19 ` [PATCH 10/10] x86: " Tom Rini
2026-01-20 18:08 ` [PATCH 00/10] Update linker scripts to ensure appended device tree is correctly aligned Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aYPa2_YU04etfIv9@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=BMC-SW@aspeedtech.com \
--cc=aford173@gmail.com \
--cc=andre.przywara@arm.com \
--cc=b-padhi@ti.com \
--cc=chiawei_wang@aspeedtech.com \
--cc=eugen.hristev@linaro.org \
--cc=festevam@gmail.com \
--cc=ilias.apalodimas@linaro.org \
--cc=jagan@amarulasolutions.com \
--cc=joel@jms.id.au \
--cc=kever.yang@rock-chips.com \
--cc=marek.vasut+renesas@mailbox.org \
--cc=michal.simek@amd.com \
--cc=philipp.tomsich@vrull.eu \
--cc=richard.henderson@linaro.org \
--cc=ryan_chen@aspeedtech.com \
--cc=sbabic@nabladev.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=uboot-imx@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox