[PATCH v2 4/4] common: Allow relocations on the top of the last bank

[Jonas Karlman]

On 4/1/2026 10:31 AM, Ilias Apalodimas wrote:
> Hi Jonas
> 
> [...]
> 
>>>  #if defined(CFG_SYS_SDRAM_BASE) && CFG_SYS_SDRAM_BASE > 0
>>>       /*
>>>        * Detect whether we have so much RAM that it goes past the end of our
>>> @@ -321,6 +323,19 @@ __weak phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
>>>                */
>>>               return 0;
>>>  #endif
>>> +     if (IS_ENABLED(CONFIG_RELOCATE_LAST_BANK)) {
>>> +             phys_addr_t old_top = gd->ram_top;
>>> +
>>> +             ret = fdtdec_setup_mem_ram_top();
>>
>> This seem to make assumption that memory is already fully described in
>> FDT? Maybe this should instead be based on gd->bd->bi_dram, however that
>> is possible initialized at a later initcall.
> 
> It is. That was my first approach in fixing it, but the
> gd->bd->bi_dram contained garbage at that point.
> 
>>
>> If I got the call chain correct board_get_usable_ram_top() is normally
>> called from INITCALL(setup_dest_addr), and gd->bd->bi_dram banks are
>> typically initialized in INITCALL(dram_init_banksize), a later initcall.
> 
> Yes
> 
>>
>> On e.g. Rockchip there is no memory bank information in FDT at that
>> stage and memory banks is populated to gd->bd->bi_dram based on
>> information from dram init and only later possible added to the FDT for
>> booting OS.
> 
> And that happens after u-boot has relocated or before?

gd->bd->bi_dram is populated during dram_init_banksize() so I think it
should be almost just before u-boot is relocated.

I am not sure when or how, but the OS knows about the bank information
populated to bi_dram, not sure if some fdt fixup is happening just
before jumping to OS.

On Rockchip we keep gd->ram_top below 4 GiB to work around any >32-bit
DMA issues, however we do populate ram_size and bi_dram with correct
info gathered during the initial dram init (U-Boot TPL or external TPL).

Regards,
Jonas

> 
>>
>> Rockchip does have a platform board_get_usable_ram_top() so this will
>> not be an issue, but the new generic Kconfig option added here seem to
>> have a dependency on FDT containing memory bank information, if I am not
>> mistaken. Maybe something worth mentioning in help and commit message?
> 
> I can amend the Kconfig option. However, people using that default
> function are already aware of this.
> 
> Thanks
> /Ilias
>>
>> Regards,
>> Jonas
>>
>>> +             if (ret)
>>> +                     debug("failed to relocate to ram top");
>>> +             ret = fdtdec_setup_ram_size();
>>> +             if (ret) {
>>> +                     debug("failed to calculate RAM size");
>>> +                     gd->ram_top = old_top;
>>> +             }
>>> +     }
>>> +
>>>       return gd->ram_top;
>>>  }
>>>
>>