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 > > 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.
The state of the git tree can result in the version string changing and so change the binary. -- Tom
signature.asc
Description: PGP signature
