[PATCH] lmb: Reinstate access to memory above ram_top

[Gary Guo]

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.

In the mean time, I think this patch should be reverted. I can confirm that my
system boots fine with this reverted.

Best,
Gary