On Fri, 29 May 2026 at 16:44, Tom Rini <[email protected]> wrote: > > 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.
Sent.
