[PATCH] lmb: Reinstate access to memory above ram_top

[Marek Vasut]

On 3/23/26 7:18 PM, Tom Rini wrote:
> 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.
Unrelated to whether this is going to be an issue or not, I think we 
have two things to do here:

- Consider ram_top , get input from Heinrich on that
- DMA32 ... how to design that, should that be a special LMB pool ? How 
do we handle hardware which has no memory below 4 GiB, iommu maybe ?