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

Thu Jan 29 17:03:15 CET 2026

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260129/44994bc1/attachment.sig>