[PATCH] lmb: Reinstate access to memory above ram_top

[Gary Guo]

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);
 		if (err)
 			return EFI_OUT_OF_RESOURCES;