[PATCHv3 2/6] lmb: add LMB_FDT for fdt reserved regions
Simon Glass
sjg at chromium.org
Thu Apr 16 23:20:31 CEST 2026
Hi Randolph,
On Fri, 17 Apr 2026 at 09:12, Randolph Sapp <rs at ti.com> wrote:
>
> On Thu Apr 16, 2026 at 4:02 PM CDT, Simon Glass wrote:
> > Hi Randolph,
> >
> > On Tue, 14 Apr 2026 at 08:36, <rs at ti.com> wrote:
> >>
> >> From: Randolph Sapp <rs at ti.com>
> >>
> >> Add an LMB_FDT bit for fdt reserved regions, so we can reclaim them when
> >> parsing a new device tree and properly warn people when a reservation
> >> overlaps with an existing allocation.
> >>
> >> If we don't at least warn the user of these reservation failures,
> >> there's a chance that this region could be freed and reallocated for
> >> something important later.
> >>
> >> This useful warning mechanism was broken in:
> >> 5a6aa7d5913 ("boot: fdt: Handle already reserved memory in boot_fdt_reserve_region()")
> >>
> >> Signed-off-by: Randolph Sapp <rs at ti.com>
> >> ---
> >> boot/image-fdt.c | 5 ++++-
> >> include/lmb.h | 14 ++++++++++++++
> >> lib/lmb.c | 33 +++++++++++++++++++++++++++++----
> >> 3 files changed, 47 insertions(+), 5 deletions(-)
> >>
> >
> > With bootstd we maintain a list of images attached to each bootflow,
> > including the address when loaded. Could that provide a solution here?
> >
> > Regards,
> > Simon
>
> Hey Simon, you may have to elaborate on that a little more. Are you suggesting
> we treat FDT reserved regions as dummy bootstd binary entries? That might work
> if it counts as an LMB reservation and we can dynamically update it if the FDT
> is reloaded/changed. I haven't looked into that too much yet.
Not so much dummies, I mean real bootflows. I am not sure if you are
using bootstd, though?
Basically, once you have a bootflow there is a list of images attached
- see struct bootflow_img
Each image has a type so you can see if it is an FDT.
This is just an idea though...I'm not sure if you are even using bootstd.
Regards,
Simon
More information about the U-Boot
mailing list