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. Thanks, Brian > > -- > Tom
