[PATCH v5 5/7] common: Add an option to relocate on ram top

[Ilias Apalodimas]

Hi Simon,


On Mon, 8 Jun 2026 at 16:00, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Ilias,
>
> On Mon, 8 Jun 2026 at 01:44, Ilias Apalodimas
> <ilias.apalodimas at linaro.org> wrote:
> >
> > Hi Simon,
> >
> > [...]
> >
> > >
> > > I'm just a bit concerned about what this changes...see below.
> > >
> > > > diff --git a/common/board_f.c b/common/board_f.c
> > > > @@ -339,7 +344,24 @@ 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 i;
> > > > +             phys_addr_t top;
> > > > +
> > > > +             gd->ram_size = 0;
> > > > +             for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> > > > +                     top = get_mem_top(gd->dram[i].start, gd->dram[i].size,
> > > > +                                       ALIGN(gd->mon_len, SZ_1M),
> > > > +                                       (void *)gd->fdt_blob);
> > > > +                     gd->ram_top = max(top, gd->ram_top);
> > > > +                     gd->ram_size += gd->dram[i].size;
> > > > +             }
> > > > +             gd->ram_top = board_get_usable_ram_top(gd->ram_size);
> > > > +     } else {
> > > > +             gd->ram_top = gd->ram_base + get_effective_memsize();
> > > > +             gd->ram_top = board_get_usable_ram_top(gd->mon_len);
> > > > +     }
> > > >       /*
> > > >        * Subtract specified amount of memory to hide so that it won't
> > > >        * get 'touched' at all by U-Boot. By fixing up gd->ram_size
> > > > @@ -350,10 +372,9 @@ static int setup_ram_config(void)
> > > >        * memory size from the SDRAM controller setup will have to
> > > >        * get fixed.
> > > >        */
> > > > +#if CONFIG_VAL(SYS_MEM_TOP_HIDE)
> > > >       gd->ram_size -= CONFIG_SYS_MEM_TOP_HIDE;
> > > >  #endif
> > > > -     gd->ram_top = gd->ram_base + get_effective_memsize();
> > > > -     gd->ram_top = board_get_usable_ram_top(gd->mon_len);
> > >
> > > This reorders SYS_MEM_TOP_HIDE relative to the ram_top calculation in
> > > the non-RELOC_ADDR_TOP path. Previously gd->ram_size was reduced first
> > > and get_effective_memsize() (which reads gd->ram_size) then yielded a
> > > ram_top below the hidden region.
> > >
> > > After this patch ram_top is computed from the full size and the
> > > subtraction happens afterwards, so ram_top (and hence relocaddr) now
> > > lands inside the region SYS_MEM_TOP_HIDE is meant to keep U-Boot out
> > > of
> > >
> > > Quite a few defconfigs still set CONFIG_SYS_MEM_TOP_HIDE (e.g. odroid)
> > > and look like they would regress here. Please keep the old ordering
> > > for the else branch, or do the subtraction up front and feed the
> > > reduced size to both branches.
> >
> > Yea that's true, however how that's used is weird because
> > get_effective_memsize() is board specific and it doesn't always use
> > ram_size.
> > So perhaps we should deduct the same value from ram_top and keep the
> > call last ? That way we can keep the functionality for both cases.
>
> That makes sense to me, yes. It seems more in keeping with
> board-specific functions. This is likely another area to clean up one
> day...

Ok, I'll send a v6 tomorrow with the change and yes this is another
area that needs a cleanup. The rough plan is
- land this
- Go through the board specific code and remove anything that's not
needed anymore
- revisit the reloc and make it even more abstract. The rough idea is
to keep the same structure. IOW calculate a reloc address and override
is with board_get_usable_ram_top(). But depending on the cleanup we
might actually be able to get rid of the old option and make
RELOC_ADDR_TOP the default. I just have to see how many boards would
be problematic. One idea is to define a board_get_usable_ram_top()
that returns valid memory < 4GiB and point the problematic boards to
that.

[...]

Regards
Ilias