[PATCH] lmb: Reinstate access to memory above ram_top

[Ilias Apalodimas]

On Mon, 23 Mar 2026 at 20:07, Gary Guo <gary at garyguo.net> wrote:
>
> On Mon Mar 23, 2026 at 5:26 PM GMT, 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:
> >>>> 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.
> >
> > Does the gd->ram_top fix the RPi5 too ?
>
> Yes, I can boot my RPi5 with the following diff, which makes sense as it has
> ram_top of 0x3fc00000. Testing on devices with ram_top > 4 GiB would be needed
> to know if this is a proper fix.
>
> Best,
> Gary
>
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index b77c2f980cc0..76ae89e31f47 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 *)gd->ram_top);
> +
>                 /* 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);

When you boot to linux, what does the memory map say ? Can you try
booting with efi=debug and paste the dmg output?

Thanks
/Ilias
>                 if (err)
>                         return EFI_OUT_OF_RESOURCES;