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 > 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
