Hi Tom, On Thu, 2026-01-15 at 13:31 -0600, Tom Rini wrote: > On Thu, Jan 15, 2026 at 04:59:19PM +0000, > [email protected] wrote: > > Hi Tom, > > > > On Thu, 2026-01-15 at 16:16 +0000, Jamie Gibbons wrote: > > > Hi Tom, > > > > > > On Wed, 2026-01-14 at 08:58 -0600, Tom Rini wrote: > > > > On Wed, Jan 14, 2026 at 02:33:04PM +0000, > > > > [email protected] wrote: > > > > > Hi all, > > > > > > > > > > On Sat, 2025-12-27 at 16:37 -0600, Tom Rini wrote: > > > > > > The devm alloc functions that we have may follow the Linux > > > > > > kernel > > > > > > model > > > > > > where allocations are (almost always) automatically > > > > > > free()'d. > > > > > > However, > > > > > > quite often we don't enable, in full U-Boot, the tracking > > > > > > and > > > > > > free()'ing > > > > > > functionality. This in turn leads to memory leaks because > > > > > > the > > > > > > driver > > > > > > author expects that since the functions have the same name > > > > > > as in > > > > > > the > > > > > > Linux Kernel they have the same behavior. In turn we then > > > > > > get > > > > > > functionally correct commits such as commit 00e1fed93c8c > > > > > > ("firmware: > > > > > > ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource") > > > > > > that > > > > > > manually > > > > > > add these calls. Rather than manually tracking allocations > > > > > > and > > > > > > implementing free()s, rework things so that we follow > > > > > > expectations > > > > > > by > > > > > > enabling the DEVRES functionality (outside of xPL phases). > > > > > > > > > > > > This turns DEVRES from a prompted symbol to a symbol that > > > > > > must > > > > > > be > > > > > > select'd, and we now remove our non-managed alloc/free > > > > > > functions > > > > > > from > > > > > > outside of xPL builds. > > > > > > > > > > > I’ve encountered a regression on the Microchip PolarFire SoC > > > > > Icicle > > > > > Kit > > > > > with mainline U-Boot. > > > > > > > > > > After commit 217cf656e249 - the application of this patch > > > > > (“dm: > > > > > core: > > > > > Default to using DEVRES outside of xPL”), U-Boot fails to boot > > > > > on > > > > > this > > > > > board. After this patch was applied the Icicle kit no longer > > > > > boots > > > > > and > > > > > crashes immediately after OpenSBI. Between this patch and > > > > > master > > > > > HEAD > > > > > the following errors are found - please see attached logs for > > > > > more > > > > > detail: > > > > > > > > > > Failed to reserve memory for fdt at 0xbf386210 > > > > > Required FDT relocation for applying DTOs failed: 1 > > > > > Could not find a valid device tree > > > > > Device tree not found or missing FDT support > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > Sometimes, I also see an “Unhandled exception: Illegal > > > > > instruction” > > > > > and > > > > > a reset. > > > > > > > > > > The last known good commit is before this commmit. I used `git > > > > > bisect` > > > > > to confirm that 217cf656e249 (this patch) is the first bad > > > > > commit. > > > > > > > > > > Steps to reproduce: > > > > > - Build U-Boot for MPFS Icicle Kit > > > > > - Boot using HSS payload as usual - I use our build system > > > > > Buildroot > > > > > for > > > > > this > > > > > - Observe the boot failure after the above commit > > > > > > > > > > Any advise on the problem? > > > > > > > > It's really strange that it bisects down to this commit, rather > > > > than > > > > something device tree related. Do you still have > > > > fdt_high=0xffffffff > > > > or > > > > so set in the environment? It was in at least one of the logs, > > > > but I > > > > can't see for sure if it's just that the other log is from > > > > before > > > > the > > > > commit that added the print warning about not doing that, or if > > > > it > > > > wasn't set. > > > > > > > Apologies for the daly in my response, I wanted to do some more > > > debugging before getting back to you. > > > > > > Thanks for the suggestion about fdt_high. We have it set in our > > > boot > > > scripts. I chased this down with a bisect to 9235da9446e (boot: > > > Warn > > > users about fdt_high=~0 usage). I have now set fdt_high to our > > > maximum > > > addressable value instead of ~0. This does get rid of the warning > > > about > > > fdt_high in U-Boot, so that part is resolved. > > > > > > However, it doesn’t fix the underlying boot issue — U-Boot still > > > fails > > > to boot altogether. During some bisections it often fails to apply > > > device tree overlays and doesn’t boot the kernel - I have attached > > > the > > > latest crash log. > > > > > > From my bisecting, the overlay breakage seems to start with the > > > DTC/libfdt update commit (0535e46d55d...). After that, overlay > > > application consistently fails, regardless of the fdt_high > > > settings. > > > As > > > an additional piece of information disabling MULT_DTB_FIT allows > > > the > > > board to boot as far as fdt error. > > > > > > Let me know if you have any other ideas. > > > > > > Thanks! > > > > Just for some further clarity, before the DEVRES Commit: > > - U-Boot boots fine with overlays disabled and fdt_high reset. > > - Overlay application causes FDT errors, but base boot works. > > After this DEVRES Commit (dm: core: Default to using DEVRES outside > > of > > xPL): > > - U-Boot does not boot at all — no output, total crash. > > So to be clear, there's just nothing on the serial port from power on? > The initial logs I think confused the situation slightly. If no > output, > I would suggest bumping up SYS_MALLOC_F_LEN a little bit (maybe 0x2800 > instead of 0x2000) and see. > Sorry for the confusion and thank you for your suggestion. I will attempt to clarify below.
In summary, I found three issues in mainline U-Boot between the v2026.01 tag and the master branch. 1. No boot (no output at all from U-Boot on the serial port) - introduced by 217cf656e24 dm: core: Default to using DEVRES outside of xPL - fixed by your suggestion above: s/CONFIG_SYS_MALLOC_F_LEN=0x2000/ CONFIG_SYS_MALLOC_F_LEN=0x2800 in u-boot defconfigs 2. fdt_high warning - introduced by 9235da9446e boot: Warn users about fdt_high=~0 usage - fixed by: s/setenv fdt_high 0xffffffffffffffff/setenv fdt_high 0xbfffffffin in our build systems boot scripts 3. failed on fdt_open_into for DTO, i.e. overlay application fdt error - introduced by 0535e46d55d scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c - no fix implemented as of yet. Any suggestions on this are appreciated also. Thank you again, Jamie.
