[PATCH v1 4/4] common: Add an optionto relocate on ram top

Simon Glass sjg at chromium.org
Sun Apr 5 14:04:05 CEST 2026


Hi Ilias,

On 2026-04-03T09:01:02, Ilias Apalodimas <ilias.apalodimas at linaro.org> wrote:
> common: Add an optionto relocate on ram top
>
> 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.
>
> It's worth noting that there are cases where we must not relocate
> above the 4GiB boundary (64bit hardware with 32bit only capable
> DMA). E.g This will break platforms, if the ethernet
> controller cannot DMA above 4 GiB, and once U-Boot does
> get relocated above 4 GiB, the packet buffer which is built
> into the U-Boot binary is also relocated above 4 GiB.
>
> 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
> [...]

> diff --git a/Kconfig b/Kconfig
> @@ -491,6 +491,14 @@ config SKIP_RELOCATE_CODE_DATA_OFFSET
> +config RELOC_ADDR_TOP
> +     bool "Relocate to the topmost memory address"
> +     help
> +       When U-Boot relocates, it chooses the end of the first memory bank.

Adding an explicit "depends on EXPERT" would be clearer, even though
the surrounding menu structure implies it. Please can you add a
warning in the help text that this should only be used if all devices
can DMA to high memory?

> diff --git a/common/board_f.c b/common/board_f.c
> @@ -353,8 +357,19 @@ static int setup_ram_config(void)
> +#if CONFIG_IS_ENABLED(RELOC_ADDR_TOP)
> +     for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
> +             if (gd->ram_top <= gd->bi_dram[bank].start)
> +                     gd->ram_top = gd->bi_dram[bank].start +
> +                                     gd->bi_dram[bank].size;
> +             total_size += gd->bi_dram[bank].size;
> +     }
> +
> +     gd->ram_size = total_size;
> +#else
> +     gd->ram_top = gd->ram_base + get_effective_memsize();
> +     gd->ram_top = board_get_usable_ram_top(gd->mon_len);
> +#endif

The RELOC_ADDR_TOP path does not call board_get_usable_ram_top()

Some boards override this to keep ram_top below 4 GiB for DMA reasons
(see arch/arm/mach-tegra/board2.c). Bypassing it means those
constraints are silently ignored. Should board_get_usable_ram_top() be
called after the loop?

Regards,
Simon


More information about the U-Boot mailing list