u-boot.git/common/board_f.c, branch main

common: Add an option to relocate on ram top

2026-06-25T00:13:24Z

Right now we only relocate u-boot to the top of the first memory bank unless the board specific code overwrites it. This is problematic when loading big binaries as it fragments the contiguous memory space for no apparent reason. On certain platforms, it is currently not possible to relocate U-Boot above the 32bit boundary, due to various dependencies on content located below the 32bit boundary. One such example is ethernet, where the packet buffer built into U-Boot binary is placed below the 32bit boundary and allows loading of data via ethernet even above 32bit boundary due to memory copy from the packet buffer to the destination location. A previous patch moves the bi_dram[] info from bd to gd and make the memory bank information available early. So move the dram_init_banksize() INITCALL before the relocation address calculation and use it to derive the address. Also add a Kconfig option and allow the common code to relocate U-Boot to the top of the last discovered bank. It's worth noting that this patch changes when dram_init_banksize() is called. It's now called much earlier in the board init process. That is a significant ordering change for every board with a custom dram_init_banksize(), and it is unconditional (not gated on RELOC_ADDR_TOP). Reviewed-by: Marek Vasut Reviewed-by: Simon Glass Tested-by: Simon Glass # Radxa ROCK 5B Signed-off-by: Ilias Apalodimas Tested-by: Christophe Leroy (CS GROUP)

common: Clean up setup_dest_addr()

2026-06-25T00:13:24Z

Right now the function does - Re-adjust the ram_size based on Kconfig options - Set ram_top - Set the relocation address It also does not set the ram_size in case ram_top grew from it's initial value. But ram_top and ram_size should always be changed together. So let's make things a bit cleaner and move the ram calculations in their own INITCALL Reviewed-by: Simon Glass Tested-by: Anshul Dalal Tested-by: Michal Simek # Versal Gen 2 Vek385 Reviewed-by: Marek Vasut Signed-off-by: Ilias Apalodimas Tested-by: Christophe Leroy (CS GROUP)

common: move ram_base calculation to independent INITCALL()

2026-06-25T00:13:24Z

Currently, ram_base is calculated within setup_dest_addr(). However, upcoming patches that enable U-Boot relocation to the highest DRAM bank require ram_base to be initialized earlier. The default dram_init_banksize() definition relies on ram_base to calculate the start of the first bank. But following patches will move that function to execute immediately before setup_dest_addr(). So let's split the ram_base initialization in its own INITCALL. Reviewed-by: Simon Glass Tested-by: Anshul Dalal Tested-by: Michal Simek # Versal Gen 2 Vek385 Reviewed-by: Marek Vasut Signed-off-by: Ilias Apalodimas Tested-by: Christophe Leroy (CS GROUP)

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

bloblist: Rework bloblist_init and bloblist_maybe_init

2026-06-02T15:30:28Z

With bloblist, we need to both see if one already exists as well as create one if it does not. However, the current implementation leads to odd cases where we attempt to create a bloblist before this is possible and have things be overly complicated when we are given one to work with. This reworks things to instead have a bloblist_exists function, which as the name implies checks for an existing bloblist. This is used in the case of booting, to see if we have one and in turn if we have a device tree there as well as in the bloblist_init function to see if we need to do anything. In practical details, we move the logic from bloblist_init that was checking for a bloblist to the new bloblist_exists function and then can clarify the logic as it is much easier to state when we know we do not have one rather than all the ways we might have one. Then we have the locations that set gd->bloblist now also set the GD_FLG_BLOBLIST_READY flag. Reviewed-by: Raymond Mao Tested-by: Alexander Stein Signed-off-by: Tom Rini

Merge patch series "Linux compat improvements and CCF prep"

2026-04-21T17:21:59Z

Casey Connolly says: This series implements various improvements to Linux header compatibility, largely in preparation for a full port of Linux CCF but many of these changes would also be helpful when porting other drivers. Beside the basic header/compat stuff there are a few larger patches: Patch 1 adds the "%pOF" format specifier to vsprintf, this behaves the same as it does in Linux printing the name of the ofnode, but notably it expects an ofnode pointer rather than a device_node. Patch 2 adds an option to skip doing a full DM scan pre-relocation. Some platforms like Qualcomm don't actually need devices to be probed prior to relocation, it is also quite slow to scan the entire FDT before caches are up. This option gets us to main loop 30-50% faster. Unfortunately it isn't possible to totally skip DM since U-Boot will panic if it can't find a serial port, but the serial uclass code will bind the serial port itself by reading /chosen/stdout-path, however any dependencies like clocks won't be found so this should only be enabled if the serial driver gracefully handles missing clocks. Patch 3 adds [k]strdup_const(), this works the same as the Linux version saving a small amount of memory by avoiding duplicating strings stored in .rodata, this is particularly useful for CCF. Patch 4 adds 64-bit versions of some 32-bit ofnode utilities functions, making it possible to parse 64-bit arrays. Patch 6 provides a simple implementation of kref, this will be used by CCF. Patch 9 adds devm_krealloc() support to devres, it relies on storing allocation sizes in the devres struct which will add a small overhead. Link: https://lore.kernel.org/r/20260401-casey-ccf-compat-v2-0-414d5b7f040b@linaro.org

common: add an option to skip DM pre-relocation

2026-04-21T17:19:49Z

For some platforms like Qualcomm, it isn't necessary to perform a full DM init and scan prior to relocation, it's also particularly slow since it runs with dcache disabled and prior to building the livetree. The only device which needs to be probed pre-reloc is the serial port (otherwise U-Boot will panic), however this can be found through /chosen/stdout-path. Therefore we can avoid scanning the entire FDT and binding devices, instead just binding the serial port and clock driver on-demand. This decreases the total time from power on to reaching the interactive U-Boot shell be about 50% (from ~2.8s to 1.8s). Signed-off-by: Casey Connolly

arm: relocate: Introduce data-only relocation mode

2026-03-27T19:29:31Z

Introduce new mode of relocation which relocates only data, not code. This is mainly meant to relocate data to read-write portion of the RAM, while the code remains in read-only portion of the RAM from which it is allowed to execute. This split configuration is present on various secure cores. The result of the relocation is U-Boot running at its original address, data relocated to the end of DRAM, but with added read-write area offset. The U-Boot binary area is not reserved from the end of the DRAM in this relocation mode, because U-Boot itself is not relocated. Signed-off-by: Marek Vasut