[PATCH] lmb: Reinstate access to memory above ram_top

Marek Vasut marek.vasut at mailbox.org
Tue Mar 24 15:22:13 CET 2026


On 3/24/26 10:48 AM, Ilias Apalodimas wrote:

Hello Ilias,

>> "
>> 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);
> 
> This kind of breaks the EFI spec. The description in the spec is
> "Allocation requests of Type AllocateAnyPages allocate any available
> range of pages that satisfies the request. On
> input, the address pointed to by Memory is ignored."
> 
> so in theory *addr should be ignored and in fact it's overwritten by
> lmb_alloc_mem(). The reason it works is becase you change the argument
> from _ANY to _MAX below.

Indeed

> I am noit against deviating a bit from the spec as long as we get
> things working and have a long term plan on fixing it properly.
> I'll go through the entire thread and see if there's an easier way out.
The more I am thinking about this, I think what we need are two things:

1) A way to allocate memory at specific addresses / with specific 
constraints (e.g. below 4 GiB, below 1 GiB for the RPi etc.)

2) A generic bounce buffer which would allocate memory with matching 
constraints per driver instance and either copy or data between HW 
accessible and inaccessible memory or set up IOMMU to avoid the copy.

The 1) would enable implementation of 2) as well as allow removal of 
static ethernet packet buffer that is currently built into U-Boot 
binary. If the ethernet packet buffer would be allocated using 1), it 
would allow us to relocate U-Boot to the end of DRAM (there might be 
more such surprises).

The remaining question is, where does 2) go, whether into drivers or 
whether it should be core code that invokes 2) and then passes valid 
buffers to drivers. What you mentioned already, that drivers should 
describe their constraints, would allow the later.

Thoughts ?


More information about the U-Boot mailing list