[PATCH v7 0/7] Relocate U-Boot in the last bank

[Ilias Apalodimas]

Thanks Jonas

On Fri, 26 Jun 2026 at 03:32, Jonas Karlman <jonas at kwiboo.se> 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 at fe2b0000: 1, mmc at 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
>