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!
U-Boot 2026.01-00492-g1d59479362c7 (Jan 15 2026 - 15:48:22 +0000)
CPU: sifive,u54-mc
Model: Microchip PolarFire-SoC Icicle Kit
DRAM: 1020 MiB (total 2 GiB)
Core: 66 devices, 15 uclasses, devicetree: fit
MMC: mmc@20008000: 0
Loading Environment from nowhere... OK
In: serial@20100000
Out: serial@20100000
Err: serial@20100000
Net: eth1: ethernet@20110000, eth0: ethernet@20112000
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:2...
Found U-Boot script /boot.scr
624 bytes read in 8 ms (76.2 KiB/s)
## Executing script at 88100000
Working FDT set to bf349500
6420192 bytes read in 86 ms (71.2 MiB/s)
## Loading kernel (any) from FIT Image at 88100000 ...
Using 'conf-microchip,mpfs-icicle-kit' configuration
Trying 'kernel' kernel subimage
Description: Linux kernel
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x881000cc
Data Size: 6361629 Bytes = 6.1 MiB
Architecture: RISC-V
OS: Linux
Load Address: 0x80200000
Entry Point: 0x80200000
Hash algo: sha256
Hash value: e92dccad51bf9f61f2a08d26a3da904ed5a86950db78d939bd621ef9fe9b95ac
Verifying Hash Integrity ... sha256+ OK
## Loading fdt (any) from FIT Image at 88100000 ...
Using 'conf-microchip,mpfs-icicle-kit' configuration
Trying 'fdt-mpfs-icicle-kit.dtb' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x88711400
Data Size: 24242 Bytes = 23.7 KiB
Architecture: RISC-V
Load Address: 0x8a000000
Hash algo: sha256
Hash value: 2a111f7ecb21056e2e315fab673fef4d566d7cdb0284de3deb3663a4fa07c61f
Verifying Hash Integrity ... sha256+ OK
Loading fdt from 0x88711400 to 0x8a000000
Loading Device Tree to 00000000be331000, end 00000000be339fff ... OK
Working FDT set to be331000
## Loading fdt (any) from FIT Image at 88100000 ...
Using 'conf-microchip,mpfs-icicle-cpu-opp' configuration
Trying 'fdt-mpfs-icicle-cpu-opp.dtbo' fdt subimage
Description: Device Tree blob for CPU Operating Points
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x8871e8a4
Data Size: 1392 Bytes = 1.4 KiB
Architecture: RISC-V
Load Address: 0x8a0c0000
Hash algo: sha256
Hash value: 9355e3feaa4ce663cb5a223ee73a26ef227f02586327b3f9db48b5c35ddcdc78
Verifying Hash Integrity ... sha256+ OK
failed on fdt_open_into for DTO
Could not find a valid device tree
Uncompressing Kernel Image to 80200000
Device tree not found or missing FDT support
### ERROR ### Please RESET the board ###
