[PATCH] lmb: Reinstate access to memory above ram_top

[Gary Guo]

On Sun Mar 22, 2026 at 9:30 PM GMT, Marek Vasut wrote:
> On 3/22/26 10:15 PM, Gary Guo wrote:
>> On Fri Mar 13, 2026 at 8:54 PM GMT, Tom Rini wrote:
>>> On Wed, 28 Jan 2026 00:48:40 +0100, Marek Vasut wrote:
>>>
>>>> Revert commit eb052cbb896f ("lmb: add and reserve memory above ram_top")
>>>> and commit 1a48b0be93d4 ("lmb: prohibit allocations above ram_top even from
>>>> same bank"). These are based on incorrect premise of the first commit, that
>>>> "U-Boot does not use memory above ram_top". While U-Boot itself indeed does
>>>> not and should not use memory above ram_top, user can perfectly well use
>>>> that memory from the U-Boot shell, for example to load content in there.
>>>>
>>>> [...]
>>>
>>> Applied to u-boot/next, thanks!
>>>
>>> [1/1] lmb: Reinstate access to memory above ram_top
>>>        commit: a3075db94d49f415658bf7e961e1eae90d9abc33
>> 
>> (Cc RPI maintainers)
>> 
>> Hi Tom,
>> 
>> I'm testing out latest u-boot/next on my Raspberry Pi 5 8GB, and I am running
>> into issues caused by this patch.

For some additional context, my setup is a fairly standard u-boot ->
systemd-boot -> Linux bootflow, with u-boot built on eb00c710508d with
rpi_arm64_defconfig, booting from SD card.

>> 
>> I have EFI enabled, and efi_allocate_pages will call into lmb to allocate pages
>> and start accessing them. However on RPI5, only 1G is mapped, so I got hit with
>> an "Synchronous Abort" triggered at address 0x1_ffff_f000.
>> 
>> Now, that is easy to fix with the following diff:
>> 
>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>> index 7a1de22e0aef..1db2e37c44f4 100644
>> --- a/arch/arm/mach-bcm283x/init.c
>> +++ b/arch/arm/mach-bcm283x/init.c
>> @@ -69,10 +69,10 @@ static struct mm_region bcm2711_mem_map[MEM_MAP_MAX_ENTRIES] = {
>>   
>>   static struct mm_region bcm2712_mem_map[MEM_MAP_MAX_ENTRIES] = {
>>   	{
>> -		/* First 1GB of DRAM */
>> -		.virt = 0x00000000UL,
>> -		.phys = 0x00000000UL,
>> -		.size = 0x40000000UL,
>> +		/* 16GB of DRAM max */
>> +		.virt = 0x000000000UL,
>> +		.phys = 0x000000000UL,
>> +		.size = 0x400000000UL,
>>   		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>>   			 PTE_BLOCK_INNER_SHARE
>>   	}, {
>> 
>> and that indeed makes my system go past the init. However, I found that while it
>> is fine to boot into systemd-boot, systemd-boot cannot boot into kernel. After
>> some investigation, it turns out that efi_load_image_from_file uses
>> efi_allocate_pages to allocate pages, and then feed this to f->read. This all
>> eventually trickles down to the MMC driver, and MMC is doing a 32-bit DMA and it
>> fails to write to the buffer allocated (which is above 4G).
>> 
>> This could be all fixed by having dma_map_single use a bounce buffer and copy
>> back the contents on unmap similar to kernel's swiotlb, but that's going to be
>> some major work.
>
> The DMA32 allocator is on my list of things to fix.
>
>> In the mean time, I think this patch should be reverted. I can confirm that my
>> system boots fine with this reverted.

> 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.

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.

Best,
Gary