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

[Randolph Sapp]

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.

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.

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.

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

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