When boot_fdt_handle_region() attempts to reserve a DTS reserved-memory
region via lmb_alloc_mem(), it may receive -EINVAL if the region's
physical address falls outside the LMB-managed memory range (i.e.
below PHYS_SDRAM on platforms where U-Boot does not manage the lower
DRAM window).
A typical example is platforms like i.MX95 where PHYS_SDRAM starts at
0x90000000, but remoteproc/rpmsg carveouts (vdev vrings, vdev buffer,
resource table) are placed at 0x88xxxxxx by hardware convention. Those
addresses are unreachable by U-Boot's allocator anyway, so failing to
mark them reserved has no practical consequence -- U-Boot will never
accidentally place the initrd or FDT blob there.
Printing ERROR for a condition that is harmless and expected on many
platforms is misleading. Downgrade the -EINVAL case to debug() to
suppress the spurious output while preserving full visibility under
DEBUG/log builds.
Real failures (e.g. -EEXIST from an overlapping reservation) continue
to be reported as ERROR.
Fixes: 623f6c5b6ab7 ("boot: image-fdt: free old dtb reservations")
Signed-off-by: Joseph Guo <[email protected]>
---
boot/image-fdt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/boot/image-fdt.c b/boot/image-fdt.c
index
9e0e0f93edd34ae9056926883b1a802858e179d9..2175fa338f55110862100fa9f491a0957e85ce56
100644
--- a/boot/image-fdt.c
+++ b/boot/image-fdt.c
@@ -95,6 +95,9 @@ static void boot_fdt_handle_region(u64 addr, u64 size, u32
flags, bool free)
debug(" %s fdt memory region: addr=%llx size=%llx flags=%x\n",
free ? "freed" : "reserved", (unsigned long long)addr,
(unsigned long long)size, flags);
+ } else if (ret == -EINVAL) {
+ debug(" skipping fdt memory region outside LMB range
(addr=%llx size=%llx flags=%x)\n",
+ (unsigned long long)addr, (unsigned long long)size,
flags);
} else {
printf("ERROR: %s fdt memory region failed (addr=%llx size=%llx
flags=%x): %ld\n",
free ? "freeing" : "reserving", (unsigned long long)addr,
---
base-commit: 6741b0dfb41dc82a284ab1cff4c58af6ef2f3f9c
change-id: 20260713-downgrade-f8319ab2d75b
Best regards,
--
Joseph Guo <[email protected]>
