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. 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. 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
