[PATCH] lmb: Reinstate access to memory above ram_top

[Marek Vasut]

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