u-boot.git/boot/image-board.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)

boot: fit: support generating DM verity cmdline parameters

2026-05-27T19:41:33Z

Add fit_verity_build_cmdline(): when a FILESYSTEM loadable carries a dm-verity subnode, construct the dm-mod.create= kernel cmdline parameter from the verity metadata (block-size, data-blocks, algo, root-hash, salt) and append it to bootargs. Also add dm-mod.waitfor=/dev/fit0[,/dev/fitN] for each dm-verity device so the kernel waits for the underlying FIT block device to appear before setting up device-mapper targets. This is needed when the block driver probes late, e.g. because it depends on NVMEM calibration data. The dm-verity target references /dev/fitN where N is the loadable's index in the configuration -- matching the order Linux's FIT block driver assigns block devices. hash-start-block is read directly from the FIT dm-verity node; mkimage ensures its value equals num-data-blocks by invoking veritysetup with --no-superblock. Signed-off-by: Daniel Golle Reviewed-by: Simon Glass

lmb: replace the lmb_alloc() and lmb_alloc_base() API's

2025-06-25T15:50:37Z

There currently are two API's for requesting memory from the LMB module, lmb_alloc() and lmb_alloc_base(). The function which does the actual allocation is the same. Use the earlier introduced API lmb_alloc_mem() for both types of allocation requests. Signed-off-by: Sughosh Ganu Acked-by: Ilias Apalodimas

lmb: replace lmb_reserve() and lmb_alloc_addr() API's

2025-06-25T15:50:37Z

There currently are multiple allocation API's in the LMB module. There are a couple of API's for allocating memory(lmb_alloc() and lmb_alloc_base()), and then there are two for requesting a reservation for a particular memory region (lmb_reserve() and lmb_alloc_addr()). Introduce a single API lmb_alloc_mem() which will cater to all types of allocation requests and replace lmb_reserve() and lmb_alloc_addr() with the new API. Moreover, the lmb_reserve() API is pretty similar to the lmb_alloc_addr() API, with the one difference being that the lmb_reserve() API allows for reserving any address passed to it -- the address need not be part of the LMB memory map. The lmb_alloc_addr() does check that the address being requested is actually part of the LMB memory map. There is no need to support reserving memory regions which are outside the LMB memory map. Remove the lmb_reserve() API functionality and use the functionality provided by lmb_alloc_addr() instead. The lmb_alloc_addr() will check if the requested address is part of the LMB memory map and return an error if not. Signed-off-by: Sughosh Ganu Acked-by: Ilias Apalodimas

Merge patch series "upl: Prerequite patches for updated spec"

2025-01-22T23:08:47Z

Simon Glass says: The current UPL spec[1] has been tidied up and improved over the last year, since U-Boot's original UPL support was written. This series includes some prerequisite patches needed for the real UPL patches. It is split from [2] [1] https://github.com/UniversalPayload/spec/tree/3f1450d [2] https://patchwork.ozlabs.org/project/uboot/list/?series=438574&state=* Link: https://lore.kernel.org/r/20250111000029.245022-1-sjg@chromium.org

boot: Rename fit_image_get_data_and_size()

2025-01-22T21:58:04Z

This function is really just getting the data. The size comes along for the ride. In fact this function is only reliable way to obtain the data for an image in a FIT, since the FIT may use external data. Rename it to fit_image_get_data() Signed-off-by: Simon Glass

lmb: Remove lmb_alloc_base_flags()

2024-12-30T19:21:55Z

lmb_alloc_base() is just calling lmb_alloc_base_flags() with LMB_NONE. There's not much we gain from this abstraction, so let's remove the former add the flags argument to lmb_alloc_base() and make the code a bit easier to follow. Reviewed-by: Sam Protsenko Tested-by: Sam Protsenko Signed-off-by: Ilias Apalodimas

lmb: Remove lmb_reserve_flags()

2024-12-30T19:21:55Z

lmb_reserve() is just calling lmb_reserve_flags() with LMB_NONE. There's not much we gain from this abstraction. So let's remove the latter, add the flags argument to lmb_reserve() and make the code a bit easier to follow. Reviewed-by: Tom Rini Reviewed-by: Sam Protsenko Tested-by: Sam Protsenko Signed-off-by: Ilias Apalodimas

boot/image-board.c: boot_get_fpga(): pass compatible flag to fpga_load()

2024-11-15T13:32:47Z

For E.G. signed FPGA bitstreams, similar to how it is done for the FPGA loading from SPL since commit 71f1a5392aad ("spl: fit: pass real compatible flags to fpga_load()"). Signed-off-by: Peter Korsgaard Link: https://lore.kernel.org/r/20241105162136.839633-1-peter@korsgaard.com Signed-off-by: Michal Simek

Merge patch series "Make LMB memory map global and persistent"

2024-09-03T20:09:30Z

Sughosh Ganu says: This is a follow-up from an earlier RFC series [1] for making the LMB and EFI memory allocations work together. This is a non-rfc version with only the LMB part of the patches, for making the LMB memory map global and persistent. This is part one of a set of patches which aim to have the LMB and EFI memory allocations work together. This requires making the LMB memory map global and persistent, instead of having local, caller specific maps. This is being done keeping in mind the usage of LMB memory by platforms where the same memory region can be used to load multiple different images. What is not allowed is to overwrite memory that has been allocated by the other module, currently the EFI memory module. This is being achieved by introducing a new flag, LMB_NOOVERWRITE, which represents memory which cannot be re-requested once allocated. The data structures (alloced lists) required for maintaining the LMB map are initialised during board init. The LMB module is enabled by default for the main U-Boot image, while it needs to be enabled for SPL. This version also uses a stack implementation, as suggested by Simon Glass to temporarily store the lmb structure instance which is used during normal operation when running lmb tests. This does away with the need to run the lmb tests separately. The tests have been tweaked where needed because of these changes. The second part of the patches, to be sent subsequently, would work on having the EFI allocations work with the LMB API's. [1] - https://lore.kernel.org/u-boot/20240704073544.670249-1-sughosh.ganu@linaro.org/T/#t Notes: 1) These patches are on next, as the alist patches have been applied to that branch. 2) I have tested the boot on the ST DK2 board, but it would be good to get a T-b/R-b from the ST maintainers. 3) It will be good to test these changes on a PowerPC platform (ideally an 85xx, as I do not have one).