On Sat, May 30, 2026 at 03:24:43PM +0200, Marek Vasut wrote: > On 5/29/26 6:30 PM, Peter Robinson wrote: > > 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. > > The revert is wrong as that breaks other things , like use of DRAM above 4 > GiB boundary, which is exactly why this change was implemented. If RPi has > limitations, then those limitations should be imposed on RPi, not globally, > so add the LMB reservations on RPi.
Isn't the case you describe still a theoretical and not used in tree case? And note that Ilias' patches to relocate to the top of memory also fail on Pi. So there's something to be debugged here and worked out before we add this seemingly enhanced behavior. Hence, the need to revert it for now until it can be fixed. -- Tom
signature.asc
Description: PGP signature
