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

Ilias Apalodimas ilias.apalodimas at linaro.org
Wed Apr 1 11:35:36 CEST 2026


Replying to myself here but,

On Wed, 1 Apr 2026 at 12:21, Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> 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.

So the calculations for ram_top are done ad-hoc in setup_dest_addr().
The dram_init_banksize() gets called afterwards, but before the time
we relocate. So I think I'll completely change the direction of this
patchset.

We can still apply #1 & #2 from Marek, since it's a cleanup. We can
then add another INITCALL if the CONFIG_RELOCATE_LAST_BANK is enabled
and calculate a new ram_top and and ram_size based on the discovered
bank info. That will obviously disregard board_get_usable_ram_top()
and will be generic for any board that selects it. But I think that's
a convenient side effect, since we can start enabling it on boards,
and if it works get rid of the board specific variants.

Thoughts?
>
> >
> > 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;
> > >>>  }
> > >>>
> > >>
> >


More information about the U-Boot mailing list