[PATCH v2 6/6] common: Add an option to relocate on ram top

[Marek Vasut]

On 4/27/26 8:20 AM, Ilias Apalodimas wrote:
> Hi Marek,
> 
> On Sun, 26 Apr 2026 at 19:35, Marek Vasut <marek.vasut at mailbox.org> wrote:
>>
>> On 4/16/26 7:59 AM, Ilias Apalodimas wrote:
>>> 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.
>>
>> 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.
>>>
> 
> [...]
> 
>>
>>> +
>>>    endif # EXPERT
>>>
>>>    config PHYS_64BIT
>>> diff --git a/common/board_f.c b/common/board_f.c
>>> index 4ac22dca9e7c..f95e789257ad 100644
>>> --- a/common/board_f.c
>>> +++ b/common/board_f.c
>>> @@ -339,7 +339,22 @@ static int setup_ram_base(void)
>>>    static int setup_ram_config(void)
>>>    {
>>>        debug("Monitor len: %08x\n", gd->mon_len);
>>> -#if CONFIG_VAL(SYS_MEM_TOP_HIDE)
>>> +
>>> +     if (CONFIG_IS_ENABLED(RELOC_ADDR_TOP)) {
>>> +             int bank;
>>> +             phys_size_t total_size = 0;
>>> +
>>> +             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;
>>
>> Shouldn't this also apply board_get_usable_ram_top() to be consistent ?
> 
> Simon asked the same thing. I'd rather keep this option strict for now
> and always relocate to the upper memory boundary fnor now. Once I do
> further cleanups, I can either add it or remove the function entirely
> since dram_init_banksize() (which hs also board specific) runs really
> early now.

Maybe the default board_get_usable_ram_top() can return the ram top if 
CONFIG_IS_ENABLED(RELOC_ADDR_TOP) ? That would still allow users to use 
board_get_usable_ram_top() consistently to reduce the ram top.

>>> +     } else {
>>> +             gd->ram_top = gd->ram_base + get_effective_memsize();
>>> +             gd->ram_top = board_get_usable_ram_top(gd->mon_len);
>>
>> Should this really use gd->mon_len as a parameter, or gd->ram_top?
> 
> I haven't really thought about thism since it's what we currently do.
> In any case that's a change that needs to go on another patch.
Indeed.