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.
 - This happens regardless of overlay usage or FDT environment settings.

Regards,
Jamie

Reply via email to