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

Simon Glass sjg at chromium.org
Sun Apr 19 05:52:47 CEST 2026


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 ?

> 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


More information about the U-Boot mailing list