On Fri, Jan 30, 2026 at 12:52 AM Tom Rini <[email protected]> wrote:
>
> On Fri, Jan 30, 2026 at 12:43:51AM +0800, Sune Brian wrote:
> > On Fri, Jan 30, 2026 at 12:41 AM Tom Rini <[email protected]> wrote:
> > >
> > > On Fri, Jan 30, 2026 at 12:39:17AM +0800, Sune Brian wrote:
> > > > On Fri, Jan 30, 2026 at 12:35 AM Tom Rini <[email protected]> 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 <[email protected]>
> > > > > > 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 <[email protected]>
> > > > > > > > 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
> > > > > > > > > > <[email protected]> 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
> > > > > > > > > > > > <[email protected]> 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
> > > > > > > > > > > > > > <[email protected]> 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
> > > > > > > > > > > > > > > > <[email protected]> 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
> > > > > > > > > > > > > > > > > > <[email protected]> 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 <[email protected]> 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 <[email protected]> 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/[email protected]/
> > > > > > > > > > > > > > > > > > > > > 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 <[email protected]>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This commit I tried to boot and works..
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Then this commit
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > dc2d8423b19d30472b02e02b41504226908a4291
> > > > > > > > > > > > > > > > count rel_dyn
> > > > > > > > > > > > > > > > Signed-off-by: Tom Rini <[email protected]>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 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 <[email protected]>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 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/caomzo5biqcp2hyjgrynpqln8q52z05fkjbqvkpxxka8d3cn...@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
> >
> > For the __bss_end:
> >
> > Boot case:
> >
> > hexdump -Cv 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
> > |................|
> >
> > arm-none-eabi-readelf -s spl/u-boot-spl | grep __bss_end
> > 1196: ffffbeb8 0 NOTYPE GLOBAL DEFAULT 6 __bss_end
> >
> > This makes sense to me because it matched.
> >
> > Fail boot cas:
> >
> > 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
> > |................|
> >
> > arm-none-eabi-readelf -s spl/u-boot-spl | grep __bss_end
> > 1196: ffffbeb8 0 NOTYPE GLOBAL DEFAULT 6 __bss_end
>
> FWIW, I use: grep -E '__bss_(start|end)' spl/u-boot-spl.map
>
> > So this is indeed broken as it now should be beb'C'?
>
> It shouldn't be 'bebc' as that is not 8 byte aligned.
>
> > Where to change this may I ask?
>
> That's what I'm asking you to figure out. The __bss_end symbol is at
> beb8, which is aligned, but there's 4 extra bytes between where the dtb
> should be, and where it's being placed. I thought I had fixed that.
> Maybe the rule for -pad.bin in scripts/Makefile.xpl is getting something
> wrong (see the reverted commits for when I was investigating that) but
> maybe not.
I made a mistake but I think the situation still holds. I forgot to pull back
to master.
After build and fail to 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......|
0000bec0 00 00 00 00 d0 0d fe ed 00 00 08 c8 00 00 00 48 |...............H|
grep -E '__bss_(start|end)' spl/u-boot-spl.map
0x00000000ffffbe58 __bss_start = .
0x00000000ffffbec8 __bss_end = .
0x0000000000000070 __bss_size =
(__bss_end - __bss_start)
arm-none-eabi-readelf -s spl/u-boot-spl | grep __bss_end
1195: ffffbec8 0 NOTYPE GLOBAL DEFAULT 6 __bss_end
The byte is 4 byte less, not 4 byte more in this latest master commit.
Brian
>
> --
> Tom
