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. -- Tom
signature.asc
Description: PGP signature
