On Fri, May 29, 2026 at 01:10:14PM +0100, Peter Robinson wrote:
> 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.Can you please post the revert Peter? Thanks. -- Tom
signature.asc
Description: PGP signature
