On Thu, Jan 22, 2026 at 04:19:55PM -0300, Fabio Estevam wrote: > On Thu, Jan 22, 2026 at 4:10 PM Tom Rini <[email protected]> wrote: > > > Can you please share it with my off-list maybe? I'm still confused as to > > My work-in-progress tree is at: > > https://github.com/fabioestevam/u-boot/commits/rv1103_prep/ > > This tree boots fine. After rebasing these patches to the top of the > tree, it fails to boot.
OK. FWIW, I can't reproduce those linker messages about ".sdram" and ".sram", even when I point ROCKCHIP_TPL at the right binary file (per the docs). > > Well, where is the dtb ending up in the resulting binary? The addresses > > are aligned correctly, but the dtb isn't where it's supposed to be, > > where is it instead? A challenge here is that I could only check the > > linker script used by about half of the 32bit ARM boards > > (arch/arm/mach-omap2/u-boot-spl.lds) and not the one used by the other > > half (arch/arm/cpu/u-boot-spl.lds). The initial error you reported makes > > me wonder if we can somehow unify these two afterall, which would be > > good in general to do. > > The spl/u-boot-spl.bin file is 4 bytes longer in the failing case. > > Let me know if you need any further clarification or if you'd like me > to test something. I think you need to figure out where the mismatch is between where the device tree is appended in the binary, and where it's expected to be, in the binary, and then why something is writing it to the incorrect spot. At run time, in xPL (and this is lib/fdtdec.c) we look at either _image_binary_end if SEPARATE_BSS is enabled, or __bss_end if not. Looking at the config, I see we are not SEPARATE_BSS here, so it needs to be at __bss_end. And in both works and fails branches (my own quick rebase -q origin/master), for me, __bss_end is the same location. -- Tom
signature.asc
Description: PGP signature
