[PATCHv3 6/6] memory: reserve from start_addr_sp to end_addr_sp

[Randolph Sapp]

On Sat Apr 18, 2026 at 10:52 PM CDT, Simon Glass wrote:
> Hi Randolph,
>
> On 2026-04-13T20:35:52, Randolph Sapp <rs at ti.com> wrote:
>> memory: reserve from start_addr_sp to end_addr_sp
>>
>> Add a new global data struct member called end_addr_sp. This stores the
>> original value of relocaddr, directly from setup_dest_addr. This is
>> specifically to avoid any adjustments made by other init functions.
>>
>> Reserve the memory from gd->start_addr_sp - CONFIG_STACK_SIZE to
>> gd->end_addr_sp instead of gd->ram_top. This allows platform specific
>> relocation addresses to work without unnecessarily painting over a large
>> range.
>>
>> Signed-off-by: Randolph Sapp <rs at ti.com>
>>
>> common/board_f.c                  |  9 ++++++++-
>>  include/asm-generic/global_data.h |  6 ++++++
>>  lib/efi_loader/efi_memory.c       |  4 ++--
>>  lib/lmb.c                         | 41 +++++++--------------------------------
>>  4 files changed, 23 insertions(+), 37 deletions(-)
>
>> diff --git a/include/asm-generic/global_data.h b/include/asm-generic/global_data.h
>> @@ -115,6 +115,12 @@ struct global_data {
>> +     /**
>> +      * @end_addr_sp: the end of memory currently in use by uboot,
>> +      *               should be the original value of the relocaddr before
>> +      *               any other allocations shift it
>> +      */
>> +     unsigned long end_addr_sp;
>
> The naming is confusing, although I realise where it comes from. This
> is actually the top of the U-Boot reserved region - how above
> reserve_top or initial_relocaddr ?

Fair enough. I believe initial_relocaddr is more accurate to it's behavior,
though reserve_top would be more accurate to it's intended use. I'll run with
initial_relocaddr as that kind of hints that it shouldn't be manipulated
externally.

>> diff --git a/lib/lmb.c b/lib/lmb.c
>> @@ -534,46 +534,19 @@ static long lmb_reserve(phys_addr_t base, phys_size_t size, u32 flags)
>> +     if (gd->flags & GD_FLG_SKIP_RELOC)
>> +             lmb_reserve((phys_addr_t)(uintptr_t)_start, gd->mon_len,
>> +                         LMB_NOOVERWRITE);
>> +     else
>> +             lmb_reserve(rsv_start, size, LMB_NOOVERWRITE);
>
> This changes behaviour for GD_FLG_SKIP_RELOC, doesn't it? At present
> both the stack region and the monitor region are reserved, but with
> this only the monitor region is reserved. Is this intentional?
>
> Regards,
> Simon

Ah, good catch. Forgot about that unconditional reservation in the old path.