U-Boot LMB Reservations: Verify Firmware Regions Enter the Allocator’s Map

A firmware region can be documented in a board memory map and still
be absent from the allocator used by a bootloader operation. When a
later load damages a framebuffer or resident firmware area, the first
question is not simply whether the destination address looked unused. It
is whether the relevant reservation reached the allocator before that
operation.

This article follows U-Boot v2025.01’s logical memory block
implementation, or LMB. It focuses on reservation provenance and import
boundaries, rather than choosing FIT load and entry addresses. A
Buildroot product must verify the actual U-Boot configuration and
downstream changes before applying this model.

Separate
physical ownership from allocator knowledge

Maintain an ownership ledger for memory that must survive bootloader
activity. Each entry needs a physical interval, an owner, its lifetime
and the source of that requirement. Possible owners include resident
firmware, a display buffer or another processor. These examples are
categories to investigate, not claims that every board reserves them
automatically.

Beside each ownership entry, record how U-Boot learns about it. A
comment in a linker script, a Linux-only tree and an allocator
reservation are different forms of evidence. A region can be correctly
reserved for Linux yet remain unavailable to an earlier bootloader’s
reservation import path.

The tagged
LMB implementation initializes available and used-region lists. Its
normal memory-addition path obtains DRAM banks from board information
and reserves memory beyond the configured RAM top. An
architecture-specific memory-map option can supply a different path.
Review the branch selected by the product rather than assuming the
generic setup is universal.

Identify the tree
imported at initialization

In the main relocated stage, lmb_init() calls the common
reservation helper with gd->fdt_blob. That helper
reserves the bootloader region and, when the relevant FDT support is
enabled, imports reservations from that tree. SPL uses a separate helper
with different reservations.

This is a concrete reason to record tree identity and timing. If an
operating-system tree is loaded later, its mere presence on storage
cannot establish what the initial LMB map contained. Additional
boot-path processing may import further reservations, but that requires
tracing the actual caller and observing the map at the relevant
operation.

For a reported collision, reconstruct the sequence: allocator
initialization, board-specific additions, tree import, buffer allocation
and handoff. Place each reservation on that timeline. “The property
exists” is incomplete if it was interpreted only after the conflicting
allocation had already happened.

Check what the
importer actually recognizes

The v2025.01
FDT reservation importer handles the tree’s memory-reservation
entries and then examines children of /reserved-memory. For
those children, it requests resource index zero from reg
and checks that the node is enabled before adding a region.

That is narrower than promising full interpretation of every possible
reserved-memory description. In particular, this function is not
evidence that a size-only dynamic allocation request is resolved, or
that every tuple in a multi-range reg property is imported.
Such designs need their own implementation check and observed
reservation entries.

The importer also applies reservation flags. The tagged
LMB interface distinguishes ordinary reservations, no-overwrite
behavior and no-map attributes. Do not flatten these into a single vague
“protected” label. Record the actual flags and check the consuming
path’s behavior. An allocator record alone is not proof of hardware
access isolation.

Compare intervals,
including the missing ones

Export or inspect the available and reserved ranges using diagnostics
supported by the selected build. The implementation contains an LMB dump
routine that reports region bases, sizes and flags. Availability through
a particular console command remains configuration-dependent.

Normalize the ownership ledger and observed map to one interval
convention. For example, use start-inclusive, end-exclusive intervals in
the review worksheet, while retaining the raw diagnostic output. Compute
the end from the base and length with overflow checks. Comparing only
starting addresses can miss a large request that crosses into a reserved
range.

Match every expected owner to an observed region or a documented
reason it is managed elsewhere. Coalesced adjacent entries may represent
several owners, so a one-row-per-owner display is not required. What
matters is coverage of the full protected interval with the intended
semantics. Unexpected missing coverage deserves investigation before any
real transfer is attempted.

Qualify the reservation
boundary safely

A useful proposed test uses a harmless reserved region in a
recovery-capable fixture. Verify that the reservation exists before
asking an LMB-participating path for an overlapping allocation. Compare
a nonoverlapping request, an overlap at each edge and a request entirely
within the reserved interval. Keep the request sizes small and the
fixture independent of live firmware data.

Also test a disabled reservation node and a deliberately unsupported
description in an isolated environment, if the product’s test setup
permits it. Those cases distinguish parser coverage from assumptions in
the board design. Never validate the boundary by intentionally
overwriting resident firmware on a production unit.

Finally, identify operations outside this allocator contract. Direct
writes, a custom loader or another processor may not consult LMB at all.
Their safety needs separate controls. A successful LMB test cannot
certify those paths.

Make reservation
evidence part of the release

Retain the board memory ledger, exact tree identity, generated
configuration, relevant source branch and observed allocator map
together. Recheck them when firmware layout, DRAM capacity or boot-stage
ownership changes.

The useful acceptance statement is that each required interval is
represented before its participating consumers allocate memory, with
uncovered paths reviewed separately. No hardware execution or collision
test is claimed here. The workflow is designed to expose missing
reservation knowledge before an apparently reasonable load address
becomes a destructive choice.