Thanks Jonas On Fri, 26 Jun 2026 at 03:32, Jonas Karlman <[email protected]> wrote: > > Hi, > > On 6/25/2026 5:18 PM, Tom Rini wrote: > > On Wed, 17 Jun 2026 10:48:18 +0300, Ilias Apalodimas wrote: > > > >> There was a discussion recently on the mailing lists regarding our > >> management of memory above ram_top [0]. The tl;dr is that we have two > >> problems. > >> > >> The first one is that U-Boot always relocates to the top of the first > >> available > >> bank unless there's special board code to sidestep that. The second is we > >> don't > >> successfully deal with devices that can only do 32-bit DMA. > >> > >> [...] > > > > Applied to u-boot/next, thanks! > > > > [1/7] treewide: move bi_dram[] from bd to gd > > commit: 1174c99ab421168221be372bd83a4143bf5f167d > > [2/7] common: move ram_base calculation to independent INITCALL() > > commit: 15b35e4289e11f1ab201701dfb6dc0232b30be48 > > [3/7] common: Clean up setup_dest_addr() > > commit: 0943f107ce4adb47d4b01c06e046dce130a1de50 > > [4/7] rpi: Add a local get_effective_memsize() > > commit: d19d9e1c064b6c782959d1da7bddf1e9da1c55d4 > > [5/7] common: Add an option to relocate on ram top > > commit: 55a34217698491cc0bb8d53d630644dc8756629c > > Ilias pointed out on IRC that Rockchip boards may have been affected by > this series now being merged, and where correct.
Yep, dunno how I missed it before. I checked dram_init_banksize(), get_effective_memsize() and board_get_usable_ram_top(). The 'good' news is that rockchip is the only affected architecture. > > The move of dram_init_banksize() before setup_ram_config() currently > breaks Rockchip boards in next, due to gd->ram_top now being 0 when > Rockchip variant of dram_init_banksize() is called. > > DRAM banks on a RK3568 8 GiB board (RK ATAGS not used) using next: > > DRAM bank = 0x0000000000000000 > -> start = 0x0000000000200000 > -> size = 0xffffffffffe00000 > DRAM bank = 0x0000000000000001 > -> start = 0x0000000100000000 > -> size = 0x0000000100000000 > > expected banks prior to this merge: > > DRAM bank = 0x0000000000000000 > -> start = 0x0000000000200000 > -> size = 0x00000000efe00000 > DRAM bank = 0x0000000000000001 > -> start = 0x0000000100000000 > -> size = 0x0000000100000000 > > 'out of memory' errors are also reported because of the bad bank size: > > Core: 632 devices, 33 uclasses, devicetree: separate > out of memory > ERROR: Out of memory > MMC: mmc@fe2b0000: 1, mmc@fe310000: 0 > > I am also seeing following, not sure it is related or a different issue: > > ERROR: reserving fdt memory region failed (addr=10f000 size=100 flags=2): > -22 > > Current logic in dram_init_banksize() require the final gd->ram_top to > fully function, hopefully we can find a workaround or try to rework the > affected code instead of having to do a partial revert. We could call dram_init_banksize() late, as we used to, if the Kconfig option for relocating to higher addresses is not selected. However, I'd like to find a better solution. Thanks /Ilias > > Regards, > Jonas > > > [6/7] configs: Enable RELOC_ADDR_TOP on arm64 QEMU > > commit: aefd4a769bb6727978c408ff24b93ba9047d535d > > [7/7] doc: Add a warning about using RELOC_ADDR_TOP > > commit: fb537c85bca0e3d29a62fe119181bf1744b8c91a >
