Hi, On Wed, 24 Jun 2026 at 08:05, Ilias Apalodimas <[email protected]> wrote: > > 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.
+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/[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 > > >> >> > > >> > > Regards, Simon
