[PATCHv3 2/6] lmb: add LMB_FDT for fdt reserved regions

[Randolph Sapp]

On Thu Apr 16, 2026 at 4:20 PM CDT, Simon Glass wrote:
> 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

Oh, the issue isn't in the region reserved to load the FDT itself, it's the
regions the FDT reserves for other components. Specifically the
"reserved-memory" nodes and other things like that.