U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Randolph Sapp <rs@ti.com>
To: Simon Glass <sjg@chromium.org>, <rs@ti.com>
Cc: <robertcnelson@gmail.com>, <ayush@beagleboard.org>,
	<Erik.Welsh@octavosystems.com>, <anshuld@ti.com>, <bb@ti.com>,
	<trini@konsulko.com>, <afd@ti.com>, <xypron.glpk@gmx.de>,
	<ilias.apalodimas@linaro.org>, <u-boot@lists.denx.de>
Subject: Re: [PATCHv6 3/3] memory: reserve from start_addr_sp to initial_relocaddr
Date: Mon, 11 May 2026 14:41:02 -0500	[thread overview]
Message-ID: <DIG3Q08V6K3T.3CISX3G3X19LO@ti.com> (raw)
In-Reply-To: <CAFLszTjPttabQ-Pqm3JrHmV8vBY77NFJmUKixkwEYYytkshgjA@mail.gmail.com>

On Mon May 11, 2026 at 1:28 PM CDT, Simon Glass wrote:
> Hi Randolph,
>
> On 2026-05-08T22:29:09, Randolph Sapp <rs@ti.com> wrote:
>> memory: reserve from start_addr_sp to initial_relocaddr
>>
>> Add a new global data struct member called initial_relocaddr. 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->initial_relocaddr instead of gd->ram_top. This allows platform
>> specific relocation addresses to work without unnecessarily painting
>> over a large range.
>>
>> Since PRAM comes out of this initial area up to initial_relocaddr, we no
>> longer need to account for it separately.
>>
>> Signed-off-by: Randolph Sapp <rs@ti.com>
>>
>> common/board_f.c                  |  9 ++++++++-
>>  include/asm-generic/global_data.h |  7 +++++++
>>  lib/efi_loader/efi_memory.c       |  2 +-
>>  lib/lmb.c                         | 39 ++++++---------------------------------
>>  4 files changed, 22 insertions(+), 35 deletions(-)
>
> BTW I am missing a change long in this patch, so a bit of guesswork here.

I tend to keep the changelogs for a series in the series cover letter. I assume
tracking per patch is the preference for this list based on this message.

>> diff --git a/common/board_f.c b/common/board_f.c
>> @@ -330,6 +330,8 @@ __weak int arch_setup_dest_addr(void)
>>
>>  static int setup_dest_addr(void)
>>  {
>> +     int ret;
>> +
>>       debug("Monitor len: %08x\n", gd->mon_len);
>>       /*
>>        * Ram is setup, size stored in gd !!
>> @@ -356,7 +358,12 @@ static int setup_dest_addr(void)
>>       gd->relocaddr = gd->ram_top;
>>       debug("Ram top: %08llX\n", (unsigned long long)gd->ram_top);
>>
>> -     return arch_setup_dest_addr();
>> +     ret = arch_setup_dest_addr();
>> +     if (ret != 0)
>> +             return ret;
>> +
>> +     gd->initial_relocaddr = gd->relocaddr;
>> +     return ret;
>>  }
>
> Please use 'if (ret)' to match U-Boot style. The trailing 'return
> ret;' is misleading since ret is known to be zero - make it 'return
> 0;'.
>
>> diff --git a/include/asm-generic/global_data.h b/include/asm-generic/global_data.h
>> @@ -107,6 +107,13 @@ struct global_data {
>>        * GDB using the 'add-symbol-file u-boot <relocaddr>' command.
>>        */
>>       unsigned long relocaddr;
>> +     /**
>> +      * @initial_relocaddr: end of memory currently in use by uboot
>> +      *
>> +      * This should be the original value of relocaddr before any other
>> +      * allocations or reservations shift it.
>> +      */
>> +     unsigned long initial_relocaddr;
>
> The kerneldoc summary is misleading: 'currently in use' suggests live
> state, but this is written once at the end of setup_dest_addr() and
> never updated. Please reword to something like 'initial top of the
> U-Boot reservation' and note that it is set once in setup_dest_addr().
> Also 'uboot' should be 'U-Boot'.
>
>> 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)
>>
>>  static void lmb_reserve_uboot_region(void)
>>  {
>> -     int bank;
>> -     ulong end, bank_end;
>> +     ulong size;
>>       phys_addr_t rsv_start;
>> -     ulong pram = 0;
>>
>>       rsv_start = gd->start_addr_sp - CONFIG_STACK_SIZE;
>> -     end = gd->ram_top;
>> +     size = gd->initial_relocaddr - rsv_start;
>>
>> -     /*
>> -      * Reserve memory from aligned address below the bottom of U-Boot stack
>> -      * until end of RAM area to prevent LMB from overwriting that memory.
>> -      */
>> -     debug("## Current stack ends at 0x%08lx ", (ulong)rsv_start);
>> +     debug("## Current stack ends at 0x%08lx\n", (ulong)rsv_start);
>
> Please keep a trimmed version of the explanatory comment - it
> documents the intent of this reservation and is more useful than the
> surrounding context.
>
>> 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)
>> -     for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
>> -             if (!gd->bd->bi_dram[bank].size ||
>> -                 rsv_start < gd->bd->bi_dram[bank].start)
>> -                     continue;
>> -             /* Watch out for RAM at end of address space! */
>> -             bank_end = gd->bd->bi_dram[bank].start +
>> -                     gd->bd->bi_dram[bank].size - 1;
>> -             if (rsv_start > bank_end)
>> -                     continue;
>> -             if (bank_end > end)
>> -                     bank_end = end - 1;
>> +     lmb_reserve(rsv_start, size, LMB_NOOVERWRITE);
>
> The old code walked CONFIG_NR_DRAM_BANKS and clamped the reservation
> to the bank containing rsv_start. The new code drops that and just
> reserves [rsv_start, initial_relocaddr). On platforms with
> non-contiguous banks (where U-Boot occupies the top bank and there is
> a hole below it), this can mark a range that is not all RAM. Is that
> intentional? If so the commit message should call it out; if not,
> please re-add a sanity check so we do not reserve across holes.

I had a few thoughts about this in the past week. Initially this bank walking
behavior seemed more than a little unusual to me. It appears here and in 2 other
places. (FDT and kernel image loading, if I recall correctly.)

I was mulling over adding it back in as-is, but this really feels like something
LMB should be aware of and should handle on it's own during the reservation of
those regions. Something akin to the EFI allocator's conventional memory overlap
check.

Seems like most of the infrastructure for that is already there. We have a
separate list tracking memory banks already. It was just bothering me that there
are quite a few instances where the allocator is blindly receiving external
information instead of taking more agency in the act of reserving that memory.

Suppose I'll just reinstate that old logic though as this series has drug out
much longer than I initially intended.

>> 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)
>> -#ifdef CFG_PRAM
>> -     pram = env_get_ulong('pram', 10, CFG_PRAM);
>> -     pram = pram << 10; /* size is in kB */
>> -#endif
>
> PRAM previously sat above the LMB reservation (the old code subtracted
> pram from the size so PRAM was left out of used_mem). With this patch,
> PRAM ends up inside the [rsv_start, initial_relocaddr) range and is
> now marked LMB_NOOVERWRITE - likely this is more correct, but it is a
> behaviour change for boards setting pram at runtime to be larger than
> CFG_PRAM - those bytes used to be available to LMB clients and now are
> not.
>
> Please spell this out in the commit message rather than the brief
> 'PRAM comes out of this initial area' line, so reviewers on PRAM-using
> boards know to look.
>
>> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>> @@ -869,7 +869,7 @@ static void add_u_boot_and_runtime(void)
>>       /* Add U-Boot */
>>       uboot_start = ((uintptr_t)map_sysmem(gd->start_addr_sp, 0) -
>>                      uboot_stack_size) & ~EFI_PAGE_MASK;
>> -     uboot_pages = ((uintptr_t)map_sysmem(gd->ram_top - 1, 0) -
>> +     uboot_pages = ((uintptr_t)map_sysmem(gd->initial_relocaddr, 0) -
>>                      uboot_start + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
>
> Hmmm, the current expression uses ram_top - 1 (inclusive top byte) and
> then rounded up via EFI_PAGE_MASK. The new one passes
> initial_relocaddr without the - 1 - so when initial_relocaddr is
> page-aligned this adds an extra page. What is the intention here?
>
> Regards,
> Simon

This stemmed from the misinterpretation of board_get_usable_ram_top being
exclusive. This is to be adjusted in the next revision.

  reply	other threads:[~2026-05-11 19:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-08 22:29 [PATCHv6 0/3] various memory related fixups rs
2026-05-08 22:29 ` [PATCHv6 1/3] sandbox: add board_get_usable_ram_top rs
2026-05-11 18:26   ` Simon Glass
2026-05-11 18:44     ` Randolph Sapp
2026-05-11 19:22       ` Simon Glass
2026-05-08 22:29 ` [PATCHv6 2/3] boot_fdt_add_mem_rsv_regions: free old dtb reservations rs
2026-05-11 18:27   ` Simon Glass
2026-05-11 23:17     ` Randolph Sapp
2026-05-08 22:29 ` [PATCHv6 3/3] memory: reserve from start_addr_sp to initial_relocaddr rs
2026-05-11 18:28   ` Simon Glass
2026-05-11 19:41     ` Randolph Sapp [this message]
2026-05-13 16:39       ` Simon Glass
2026-05-11 18:28 ` [PATCHv6,0/3] various memory related fixups Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DIG3Q08V6K3T.3CISX3G3X19LO@ti.com \
    --to=rs@ti.com \
    --cc=Erik.Welsh@octavosystems.com \
    --cc=afd@ti.com \
    --cc=anshuld@ti.com \
    --cc=ayush@beagleboard.org \
    --cc=bb@ti.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=robertcnelson@gmail.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox