Hi Randolph On Tue, 23 Jun 2026 at 22:26, Randolph Sapp <[email protected]> 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 <[email protected]> wrote: > >> > >> On Mon Jun 22, 2026 at 3:12 AM CDT, Ilias Apalodimas wrote: > >> > Hi Randolph > >> > > >> > On Sat, 20 Jun 2026 at 02:17, <[email protected]> wrote: > >> >> > >> >> From: Randolph Sapp <[email protected]> > >> >> > >> >> 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 <[email protected]> > >> >> --- > >> > > >> > 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/[email protected]/ > > >> > >> 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/[email protected]/ > > > > 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 > >> >> > >> >
