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

[Simon Glass]

Hi,

On Wed, 24 Jun 2026 at 08:05, Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> 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.

+1 that woud be my question too - we are trying to simplify things and
avoid options only used by a few boards, where possible

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

Regards,
Simon