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