[PATCH] lmb: Reinstate access to memory above ram_top

[Tom Rini]

On Mon, Mar 23, 2026 at 06:26:01PM +0100, Marek Vasut wrote:
> On 3/23/26 6:11 PM, Gary Guo wrote:
> > On Sun Mar 22, 2026 at 11:25 PM GMT, Mark Kettenis wrote:
> > > > Date: Sun, 22 Mar 2026 22:59:53 +0100
> > > > 
> > > > On 3/22/26 10:45 PM, Gary Guo wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > > Is your malloc area by any chance above the 4 GiB boundary ? Or how come
> > > > > > does EFI allocate pages from above 4 GiB range? It should not be doing
> > > > > > that and that is what should be fixed, at least until the DMA32
> > > > > > allocator is in place.
> > > > > > 
> > > > > > Please keep in mind, that revering this patch breaks other use cases,
> > > > > > like loading into the DRAM above 4 GiB.
> > > 
> > > Well, technically it doesn't break things as this is new
> > > functionality.
> > > 
> > > > > Code in lib/efi_loader uses efi_allocate_pool (in lib/efi_loader/efi_memory.c)
> > > > > whenever it allocates, which calls efi_allocate_pages, which calls into
> > > > > lmb_alloc_mem. There's no malloc here.
> > > > Does something like this make the issue go away ?
> > > > 
> > > > "
> > > > diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> > > > index b77c2f980cc..44eccc0cf35 100644
> > > > --- a/lib/efi_loader/efi_memory.c
> > > > +++ b/lib/efi_loader/efi_memory.c
> > > > @@ -475,8 +475,10 @@ efi_status_t efi_allocate_pages(enum
> > > > efi_allocate_type type,
> > > >           flags = LMB_NOOVERWRITE | LMB_NONOTIFY;
> > > >           switch (type) {
> > > >           case EFI_ALLOCATE_ANY_PAGES:
> > > > +               addr = map_to_sysmem((void *)(uintptr_t)0xffff0000);
> > > > +
> > > >                   /* Any page */
> > > > -               err = lmb_alloc_mem(LMB_MEM_ALLOC_ANY, EFI_PAGE_SIZE, &addr,
> > > > +               err = lmb_alloc_mem(LMB_MEM_ALLOC_MAX, EFI_PAGE_SIZE, &addr,
> > > >                                       len, flags);
> > > >                   if (err)
> > > >                           return EFI_OUT_OF_RESOURCES;
> > > > "
> > > > 
> > > > If so, then maybe we need a temporary config option which limits the
> > > > EFI_ALLOCATE_ANY_PAGES below 4 GiB on hardware that has DMA limitations.
> > > 
> > > Note that some arm64 systems (e.g. Apple Silicon) have *no* memory
> > > below 4 GiB.  So that change must indeed be behind a config option and
> > > care must be taken on what systems to enabled it.
> > 
> > Perhaps a good short-term fix it to use gd->ram_top here rather than hardcoding
> > 4 GiB. This way it should work on all systems without a config option.
> Looking at my notes from last DMA32 investigation, this may indeed do the
> trick in the meantime. But it would be really good to have this temporary
> workaround guarded by some Kconfig symbol, so it can be fixed up once the
> DMA32 allocator is available.

As my recent patches show, I'm digging around a bunch of Kconfig things
at the moment and I want to cauation against thinking that a symbol
guard will lead to someone doing some required fixup work. At least
filing an issue under https://source.denx.de/u-boot/u-boot/-/issues/
means we can track it for later and put links to relevant threads as
comments, when someone has time and interest in picking it up.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260323/b43e1941/attachment.sig>