[PATCH] arm: Remove rel.dyn from SPL linker scripts

Thu Jan 29 17:39:17 CET 2026

On Fri, Jan 30, 2026 at 12:35 AM Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Jan 30, 2026 at 12:29:56AM +0800, Sune Brian wrote:
> > On Fri, Jan 30, 2026 at 12:22 AM Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Fri, Jan 30, 2026 at 12:09:26AM +0800, Sune Brian wrote:
> > > > On Fri, Jan 30, 2026 at 12:08 AM Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Fri, Jan 30, 2026 at 12:07:25AM +0800, Sune Brian wrote:
> > > > > > On Fri, Jan 30, 2026 at 12:03 AM Tom Rini <trini at konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Jan 29, 2026 at 11:58:50PM +0800, Sune Brian wrote:
> > > > > > > > On Thu, Jan 29, 2026 at 11:46 PM Tom Rini <trini at konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Jan 29, 2026 at 11:43:02PM +0800, Sune Brian wrote:
> > > > > > > > > > On Thu, Jan 29, 2026 at 11:34 PM Tom Rini <trini at konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Jan 29, 2026 at 11:31:51PM +0800, Sune Brian wrote:
> > > > > > > > > > > > On Thu, Jan 29, 2026 at 11:26 PM Tom Rini <trini at konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Jan 29, 2026 at 11:25:03PM +0800, Sune Brian wrote:
> > > > > > > > > > > > > > On Thu, Jan 29, 2026 at 11:19 PM Tom Rini <trini at konsulko.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Thu, Jan 29, 2026 at 11:06:59PM +0800, Sune Brian wrote:
> > > > > > > > > > > > > > > > On Thu, Jan 29, 2026 at 10:54 PM Tom Rini <trini at konsulko.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Thu, Jan 29, 2026 at 10:58:21AM +0800, Sune Brian wrote:
> > > > > > > > > > > > > > > > > > On Wed, Jan 28, 2026 at 10:51 PM Tom Rini <trini at konsulko.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Wed, Jan 28, 2026 at 10:49:37PM +0800, Sune Brian wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The commits after c08da5d03c2a0b72e81a11ff7ca507e3a6414db3
> > > > > > > > > > > > > > > > > > > > All Cyclone V boards are unable to boot, not sure this patch is the fix?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Yes, those commits were unintentional and have been reverted.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Had tested the last commit 6a1bdb7e952d5841f42742fefa907cae5dc8d50a
> > > > > > > > > > > > > > > > > > Same situation that the boards are unable to enter the SPL phase.
> > > > > > > > > > > > > > > > > > The commit 8de6e8f8a076d2c9b6d38d8563db135c167077ec works properly.
> > > > > > > > > > > > > > > > > > After that things are broken.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Please give
> > > > > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20260129035512.639362-1-marek.vasut+renesas@mailbox.org/
> > > > > > > > > > > > > > > > > a try as I think it might have been working before by alignment luck
> > > > > > > > > > > > > > > > > rather than design.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > It is the revert itself that is broken.
> > > > > > > > > > > > > > > > I tested f4dfa5d3c2680322fd17fcc7c6221876e00a03c2
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > U-Boot SPL 2026.01-00754-gf4dfa5d3c268-dirty (Jan 29 2026 - 22:56:17 +0800)
> > > > > > > > > > > > > > > > Trying to boot from MMC1
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Which revert is correct.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > But once dc2d8423b19d30472b02e02b41504226908a4291
> > > > > > > > > > > > > > > > And revert to 431f1ce46bbffff0db8f03437a34400b11b30175
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Then all these broken I don't understand why even file diff cannot
> > > > > > > > > > > > > > > > show any changes.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Do you mean the revert is broken and fixed by alignment?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I mean that arbitrary changes (as part of testing these things, the
> > > > > > > > > > > > > > > "-dirty" in the version string would lead to failing trees now passing)
> > > > > > > > > > > > > > > can make the difference between pass/fail to boot. Did you try Marek's
> > > > > > > > > > > > > > > patch I linked to?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, I had tried. Cannot boot same as I had mentioned failing commit #.
> > > > > > > > > > > > > > I apply that patch on the latest master commit.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The other, maybe, thing is you need a bigger SPL_SYS_MALLOC_F_LEN ?
> > > > > > > > > > > > > Otherwise, you'll need to dig more and see why the device tree isn't
> > > > > > > > > > > > > being found where expected on your platform, and possibly where it is
> > > > > > > > > > > > > instead.
> > > > > > > > > > > >
> > > > > > > > > > > > No the failing point is done after
> > > > > > > > > > > >
> > > > > > > > > > > > f4dfa5d3c2680322fd17fcc7c6221876e00a03c2
> > > > > > > > > > > > Revert "arm: spl: Correct alignment of .rel.dyn section"
> > > > > > > > > > > > This reverts commit 380ddb4. Signed-off-by: Tom Rini <trini at konsulko.com>
> > > > > > > > > > > >
> > > > > > > > > > > > This commit I tried to boot and works..
> > > > > > > > > > > >
> > > > > > > > > > > > Then this commit
> > > > > > > > > > > >
> > > > > > > > > > > > dc2d8423b19d30472b02e02b41504226908a4291
> > > > > > > > > > > > count rel_dyn
> > > > > > > > > > > > Signed-off-by: Tom Rini <trini at konsulko.com>
> > > > > > > > > > > >
> > > > > > > > > > > > I manually replaced the old Makefile.xpl and also worked it boot.
> > > > > > > > > > > >
> > > > > > > > > > > > Then 431f1ce46bbffff0db8f03437a34400b11b30175
> > > > > > > > > > > >
> > > > > > > > > > > > Revert a number of incorrect commits
> > > > > > > > > > > > As part of debugging the appended device tree failure, I inadvertently
> > > > > > > > > > > > committed some changes as I was debugging to master, and not a private
> > > > > > > > > > > > branch, and pushed them as part of the release. This reverts commit
> > > > > > > > > > > > dc2d842 through 380ddb4. Signed-off-by: Tom Rini <trini at konsulko.com>
> > > > > > > > > > > >
> > > > > > > > > > > > This is the point that everything no longer boots.
> > > > > > > > > > > >
> > > > > > > > > > > > But between those commits there are no extra codes.
> > > > > > > > > > > >
> > > > > > > > > > > > After that all things no longer work.
> > > > > > > > > > >
> > > > > > > > > > > Yes, and I need you to investigate your failure case here. There is no
> > > > > > > > > > > code change between a working commit and a failing commit, which leads
> > > > > > > > > > > me to the suggestions I gave for debugging.
> > > > > > > > > >
> > > > > > > > > > I even tried a fresh clone from https://github.com/u-boot/u-boot.
> > > > > > > > > > Same situation.
> > > > > > > > > > I don't understand.
> > > > > > > > > > The commit missed or messed up?
> > > > > > > > >
> > > > > > > > > You need to look at the resulting binaries and see why the device tree
> > > > > > > > > is not where it's expected to be.
> > > > > > > > >
> > > > > > > > > You might find it helpful looking through
> > > > > > > > > https://lore.kernel.org/u-boot/CAOMZO5BiQcp2HYJgrYnPQLn8Q52Z05FKjbqVKPXxKa8D3Cny5Q@mail.gmail.com/
> > > > > > > > > for some ideas.
> > > > > > > >
> > > > > > > > So you are suggesting even the commit between revert could introduce this issue?
> > > > > > > > Aren't the revert only applied to two changes?
> > > > > > >
> > > > > > > What I'm saying is that the underlying issue is that the device tree is
> > > > > > > not where it's expected to be. The likely root cause is that we now
> > > > > > > require the device tree to be (correctly!) 8 byte aligned in memory and
> > > > > > > not 4 byte aligned. In the case of appending a device tree to our binary
> > > > > > > any sort of change in the code can change the size of the binary and in
> > > > > > > turn mean that the address where the device tree is ends up being at a
> > > > > > > different alignment.
> > > > > >
> > > > > > You are correct on this, but I don't understand why even reverting to
> > > > > > two code changes
> > > > > > could introduce this issue.
> > > > > >
> > > > > > The revert also included other commits?
> > > > > >
> > > > > > "
> > > > > > Revert a number of incorrect commits
> > > > > > As part of debugging the appended device tree failure, I inadvertently
> > > > > > committed some changes as I was debugging to master, and not a private
> > > > > > branch, and pushed them as part of the release. This reverts commit
> > > > > > dc2d842 through 380ddb4.
> > > > > > "
> > > > > >
> > > > > > This is my debug case:
> > > > > >
> > > > > > Correct boot:
> > > > > > hexdump -Cv spl/u-boot-spl.sfp | grep 'd0 0d fe ed'
> > > > > > 00001ba0  08 00 70 47 6f f0 12 00  70 47 00 bf d0 0d fe ed  |..pGo...pG......|
> > > > > > 0000beb0  00 00 00 00 00 00 00 00  d0 0d fe ed 00 00 08 c8  |................|
> > > > > >
> > > > > > Fail boot:
> > > > > > hexdump -Cv u-boot-spl_a.sfp | grep 'd0 0d fe ed'
> > > > > > 00001ba0  08 00 70 47 6f f0 12 00  70 47 00 bf d0 0d fe ed  |..pGo...pG......|
> > > > > > 0000beb0  00 00 00 00 00 00 00 00  00 00 00 00 d0 0d fe ed  |................|
> > > > >
> > > > > Yup, so it's mis-aligned. I guess can you tell me what the defconfig
> > > > > you're using is?
> > > >
> > > > socfpga_cyclone5_defconfig
> > >
> > > You might need to do some debugging yourself on this. Is that also where
> > > __bss_end is? This looks like the exact case that
> > > 5ffc1dcc26d3df9e2b192151936cb98014fb6e49 should have fixed. And locally,
> > > I see it being aligned, and then also just making a trival change (git
> > > tree is dirty) that used to lead to mis-alignment, retaining alignment.
> >
> > I have a question I still don't understand.
> > The example you gave me is even earlier than
> > f4dfa5d3c2680322fd17fcc7c6221876e00a03c2.
> > But build on f4dfa5d3c2680322fd17fcc7c6221876e00a03c2 can boot normally.
> > So what 431f1ce46bbffff0db8f03437a34400b11b30175 actually reverted and
> > could introduce this shift from first place.
> >
> > I really need this to clear out for me to debug the issue.
>
> You might need to build with V=1 and see what's being generated to go in
> to the binary file, and look at spl/u-boot-spl.map to see if things like
> __bss_end match. You need to ignore the 3 commits I reverted because
> they were debug things that did not work. They change behavior because
> they make changes in the linker scripts and so change alignments.

Yes this is understood for debugging but even reverting and only building at
the reverted commit fails to boot properly this is what I am kept mentioning.

This is why I don't understand how could no code change can even shift or
change the build result this is not possible or I really missed hidden
revert commit
from the first place.

>
> --
> Tom