Hi Tom, Marek et el,
This is still broken on Raspberry Pis, at least RPi4/RPi5 against RC3.
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.
I was seeing a "Synchronous Abort" triggered, but now now I am seeing:
Hit any key to stop autoboot: 0
Cannot persist EFI variables without system partition
** Booting bootflow '<NULL>' with efi_mgr
Not a PE-COFF file
Loading Boot0000 'mmc 0' failed
EFI boot manager: Cannot load any image
Boot failed (err=-14)
** Booting bootflow '[email protected]_1' with efi
Booting /\EFI\BOOT\BOOTAA64.EFI
Platform does not support this image
Failed to read header: Unsupported
Failed to load image: Unsupported
start_image() returned Unsupported
## Application failed, r = 3
Boot failed (err=-22)
Now, that is easy to fix with the following diff:
Simon sent something similar [1] but it didn't fix the problem, nor
address the RPi4.
[1]
https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/
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).
The Raspberry Pi has a number of devices which are only accessible at
lower memory access, the mailbox is only accessible < 1Gb too.
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.
Yes, I agree here.
