[PATCHv2 1/5] board_f: add a board_setup_dest_addr function

[Ilias Apalodimas]

Hi Randolph

On Tue, 23 Jun 2026 at 22:26, Randolph Sapp <rs at ti.com> wrote:
>
> On Tue Jun 23, 2026 at 2:37 AM CDT, Ilias Apalodimas wrote:
> > Hi Randolph
> >
> > On Mon, 22 Jun 2026 at 22:15, Randolph Sapp <rs at ti.com> wrote:
> >>
> >> On Mon Jun 22, 2026 at 3:12 AM CDT, Ilias Apalodimas wrote:
> >> > Hi Randolph
> >> >
> >> > On Sat, 20 Jun 2026 at 02:17, <rs at ti.com> wrote:
> >> >>
> >> >> From: Randolph Sapp <rs at ti.com>
> >> >>
> >> >> Add a weak definition for board_setup_dest_addr, as a way for specific
> >> >> boards to override the gd->relocaddr address before the relocation
> >> >> actually occurs.
> >> >>
> >> >> Signed-off-by: Randolph Sapp <rs at ti.com>
> >> >> ---
> >> >
> >> > board_get_usable_ram_top() can be used instead.
> >> >
> >> > Cheers
> >> > /Ilias
> >>
> >> It *could*. Just felt a little weird to artificially restrict the usable memory
> >> because the stack just barely runs into one of our reserved regions long enough
> >> to break a dt reserved-memory allocation.
> >
> > I am not sure I understand this without an example. We always relocate
> > to ram_top for now and that's why that function exists. I've already
> > started to clean up the relocations a bit [0]. I don't want to add
> > more functions to tweak the reloc address unless necessary. Generally
> > speaking the reloc address should not be board specific at all imho.
> > If there are areas that we shouldn't use they need to be described in
> > the DT and the core code should look at that. I am ok keeping one
> > function to change this, but not more. We also have
> > arch_setup_dest_addr() which isactually board specific (look at
> > arch/powerpc/lib/stack.c which is the only place we define it).
>
> Alright, I'll add a little information about the specific predicament we're in
> because of this board. Our ram_top is something like ~26MB away from a reserved
> memory region defined in device tree. After the relocation, before we can
> reserve the dt regions, we actually creep past 26MB of utilization. This makes
> the dt reservation fail in the LMB path, but later the utilization retracts.
> This lead me to find that some useful warnings were disabled [1] and other odd
> things were occurring as a result.
>

Thanks this helps.

> We can't even parse the dt without first reaching into one of the reserved
> regions. With everything using physical addresses we can't really relocate the
> active reservations to avoid this.
>
> To be clear, I don't even like the solution I proposed here because it requires
> coordination between a device tree and a local configuration.

I think the reality is that we will always have 'special' cases and
we'll need a board function that tweaks the reloc address. But that
should be the vast minority. I don't think we can solve this with a
single commit. But cleaning up the core code will give as a pretty
good idea of how many 'special' cases we actually have.

>
> There just isn't enough wiggle room here when u-boot doesn't have a real stack
> size limit. We can't fully plan out a memory map ahead of time nor can we
> account for this at runtime. Please inform me if I'm missing something here,
> still fairly new to the way u-boot handles things.

Ok so from what I read board_get_usable_ram_top() does solve your
problem, right?
I suggest you just define that and revisit the whole thing once I
clean up a bit more.
For example, I don't see why we need arch_setup_dest_addr() and we
just can't define board_get_usable_ram_top() for the affected ppc
boards.

>
> Thanks for look at this Ilias. Hard to get these kind of discussions otherwise.

YW, I do care about abstracting this nicely and reducing the board
specific code So if you have more of these cases feel free to cc me.

Thanks
/Ilias
>
> [1] https://lore.kernel.org/u-boot/20260604155038.3182-2-rs@ti.com/
>
> >>
> >> Initially this was proposed because there are multiple runtimes with their own
> >> allocation techniques that could potentially take advantage of that space. If
> >> it's still preferable to use board_get_usable_ram_top though I will change it.
> >
> > [0] https://lore.kernel.org/u-boot/20260617074846.84362-1-ilias.apalodimas@linaro.org/
> >
> > Thanks
> > /Ilias
> >> >>  common/board_f.c | 9 +++++++++
> >> >>  1 file changed, 9 insertions(+)
> >> >>
> >> >> diff --git a/common/board_f.c b/common/board_f.c
> >> >> index fdb3577fec09..d9d09ac94bf2 100644
> >> >> --- a/common/board_f.c
> >> >> +++ b/common/board_f.c
> >> >> @@ -328,6 +328,11 @@ __weak int arch_setup_dest_addr(void)
> >> >>         return 0;
> >> >>  }
> >> >>
> >> >> +__weak int board_setup_dest_addr(void)
> >> >> +{
> >> >> +       return 0;
> >> >> +}
> >> >> +
> >> >>  static int setup_dest_addr(void)
> >> >>  {
> >> >>         int ret;
> >> >> @@ -362,6 +367,10 @@ static int setup_dest_addr(void)
> >> >>         if (ret)
> >> >>                 return ret;
> >> >>
> >> >> +       ret = board_setup_dest_addr();
> >> >> +       if (ret)
> >> >> +               return ret;
> >> >> +
> >> >>         gd->initial_relocaddr = gd->relocaddr;
> >> >>         return 0;
> >> >>  }
> >> >> --
> >> >> 2.54.0
> >> >>
> >>
>