[PATCH v2 2/2] dm: core: Default to using DEVRES outside of xPL

[Tom Rini]

On Wed, Jan 14, 2026 at 02:33:04PM +0000, Jamie.Gibbons at microchip.com 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260114/69c6b4db/attachment.sig>