u-boot.git/lib/lmb.c, branch main

treewide: move bi_dram[] from bd to gd

2026-06-25T00:13:24Z

Currently, the bi_dram[] information is stored in the board info structure (bd). Because bd is only valid after reserve_board(), dram_init_banksize() must be called late in the initialization process. This limitation is problematic, as it forces us to rely on a variety of bespoke functions to determine board RAM, bank memory sizes, and other early setup requirements. By moving bi_dram[] into the global data (gd), we can run it earlier. This is particularly convenient since boards define their own dram_init_banksize() routines, which do not always rely on parsing Device Tree (DT) memory nodes. Additionally, U-Boot defaults to relocating to the top of the first memory bank. While boards currently use custom functions to override this behavior, having the DRAM bank information available earlier in gd makes relocating to a different bank trivial and standardizes the process. Reviewed-by: Anshul Dalal Tested-by: Michal Simek # Versal Gen 2 Vek385 Tested-by: Anshul Dalal Reviewed-by: Simon Glass Signed-off-by: Ilias Apalodimas Tested-by: Christophe Leroy (CS GROUP)

Merge patch series "various memory related fixups"

2026-06-15T17:04:48Z

rs@ti.com says: From: Randolph Sapp Nitpicks and fixes from the discovery thread on adding PocketBeagle2 support [1]. This does a lot of general setup required for the device, but these modifications themselves aren't device specific. For those specifically interested in PocketBeagle2 support and don't care about these details, my development branch is public [2]. That first patch may provoke some opinions, but honestly if that warning was still present I wouldn't have spent a week poking holes in both the EFI and LMB allocations systems. Please let me know if there is a specific usecase that it breaks though. [1] https://lore.kernel.org/all/DHHC66BBMD27.YHGIH43C6XBK@ti.com/ [2] https://github.com/StaticRocket/u-boot/tree/feature/pocketbeagle2 Link: https://lore.kernel.org/r/20260604155038.3182-1-rs@ti.com

memory: reserve from start_addr_sp to initial_relocaddr

2026-06-15T17:04:39Z

Add a new global data struct member called initial_relocaddr. This stores the original value of relocaddr, directly from setup_dest_addr. This is specifically to avoid any adjustments made by other init functions. Reserve the memory from gd->start_addr_sp - CONFIG_STACK_SIZE to gd->initial_relocaddr instead of gd->ram_top. This allows platform specific relocation addresses to work without unnecessarily painting over a large range. Signed-off-by: Randolph Sapp Reviewed-by: Simon Glass Reviewed-by: Ilias Apalodimas

lmb: Rename LMB_LIMIT_DMA_BELOW_4G to LMB_LIMIT_DMA_BELOW_RAM_TOP

2026-06-08T19:28:49Z

Rename LMB_LIMIT_DMA_BELOW_4G to LMB_LIMIT_DMA_BELOW_RAM_TOP to make the Kconfig option more descriptive. No functional change. Suggested-by: Ilias Apalodimas Signed-off-by: Marek Vasut Reviewed-by: Ilias Apalodimas

lmb: Optionally limit available memory to 4 GiB on limited systems

2026-06-04T14:26:41Z

Some architectures can not DMA above 4 GiB boundary, limit available memory to memory below 4 GiB boundary. Signed-off-by: Marek Vasut Reviewed-by: Ilias Apalodimas Tested-by: Ilias Apalodimas #rpi4 8GiB

lmb: Reinstate access to memory above ram_top

2026-03-13T19:20:11Z

Revert commit eb052cbb896f ("lmb: add and reserve memory above ram_top") and commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank"). These are based on incorrect premise of the first commit, that "U-Boot does not use memory above ram_top". While U-Boot itself indeed does not and should not use memory above ram_top, user can perfectly well use that memory from the U-Boot shell, for example to load content in there. Currently, attempt to use that memory to load large image using TFTP ends with "TFTP error: trying to overwrite reserved memory...". With this change in place, the memory can be used again. Fixes: eb052cbb896f ("lmb: add and reserve memory above ram_top") Fixes: 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from same bank") Reported-by: Yuya Hamamachi Signed-off-by: Marek Vasut

lmb: Remove unreachable code

2025-07-22T17:29:33Z

Code after a break is unreachable so remove it. Signed-off-by: Andrew Goodbody

arm: fix lmb region reservation when PRAM is defined

2025-07-22T17:29:31Z

PRAM usage is not taken into account when reserving lmb for ARM architecture, this means that predefined PRAM region is marked as reserved by the architecture and cannot be used by other users. Signed-off-by: Holger Brunck

lmb: add missing fallthrough in lmb_alloc_mem()

2025-07-09T16:39:37Z

Add fallthrough to clarify the intent. Addresses-Coverity-ID: CID 569481: Control flow issues (MISSING_BREAK) Signed-off-by: Heinrich Schuchardt Acked-by: Sughosh Ganu Reviewed-by: Ilias Apalodimas

lmb: use a single function to check for allocation and reservation requests

2025-06-25T15:50:37Z

The functions that handle allocation requests check if a region of memory overlaps with a used region. This is done through lmb_overlaps_region(). Similar checks are done for reservation requests made to the LMB module, where the caller asks specifically for a particular region of memory. These checks are being done through lmb_can_reserve_region(). There are subtle differences in the checking needed for allocation requests, as against reservation requests. In the former, it is only needed to be checked if a region is overlapping with an existing used region, and return as soon as an overlap is found. For reservation request checks, because U-Boot allows for re-use of in-use regions with a particular memory attribute, this check has to iterate through all the regions that might overlap with the requested region, and then check that the necessary conditions are met to allow for the overlap. Combine these two checks in a single function, lmb_overlap_checks() as both lmb_overlaps_region() and lmb_can_reserve_region() are pretty similar otherwise. Signed-off-by: Sughosh Ganu Reviewed-by: Ilias Apalodimas