On Sat, 30 May 2026 at 14:28, Marek Vasut <[email protected]> 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.
I have no idea how LMB works so please send a patch that does that.
