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

[Ilias Apalodimas]

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.

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

>
> [...]