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

[Ilias Apalodimas]

On Wed, 1 Apr 2026 at 11:54, Jonas Karlman <jonas at kwiboo.se> wrote:
>
> 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.

Ok I'll check that on QEMU. If that's true I think this is a better
approach overall. We can skip all the DT parsing and if the iformation
is  filled up before the reloc we can use that to decide on the top
reloc address. Which will also be useful in getting rid of bespoke
board ram init functions, like the one you have in rockpi.

>
> 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.

Depends on how you boot. In the EFI world we add all the memory in the
memmap, but marked the regions above ram_top as reserved (but
reclaimable).
The OS then boots and can use the entire defined DRAM.

>
> 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).

Yea, that's the next problem to fix. We already had a discussion with
Marek on how to fix this.

Thanks
/Ilias
>
> 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;
> >>>  }
> >>>
> >>
>