[PATCH] lmb: Reinstate access to memory above ram_top

[Marek Vasut]

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.

Does the gd->ram_top fix the RPi5 too ?