[PATCH] lmb: Reinstate access to memory above ram_top

[Marek Vasut]

On 1/28/26 5:41 AM, Heinrich Schuchardt wrote:
> Am 28. Januar 2026 00:48:40 MEZ schrieb Marek Vasut <marek.vasut+renesas at mailbox.org>:
>> 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.
>>
>> Currently, attempt to use that memory to load large image using TFTP ends
>> with "TFTP error: trying to overwrite reserved memory...". With this change
>> in place, the memory can be used again.
> 
> IIRC there are drivers that have issues with memory above 4 GiB and boards that artificially set ram_top to 4 GiB to work around these issues.

I thought I had all of those solved, but apparently not, please read on.

> We need to carefully consider why the reverted patch was introduced.

I didn't find much on either commit. I believe the premise on which the 
original patch was introduced is wrong, cf this commit message. We 
should allow U-Boot to access the memory above ram_top, we should not 
allow U-Boot to use it for its data structures because of the possible 
32bit DMA limitations.

> Why does your board use a 4GiB ram_top and not place ram_top at the physical top?
Originally, I thought it was only a remnant from the past which kept 
U-Boot and all its data structures, stack, heap in the first DRAM bank 
in 32bit space, so I tried to remove that. It turns out there are still 
a couple of problems that have to be solved to make it possible to 
relocate U-Boot fully into the 64bit space.

The first one is the standard parsing of DRAM size / ram_top / DRAM 
banks order in common/board_f.c , which probably hides a lot of issues 
on various boards, pretty much what you wrote above. In short, 
dram_init() only sets up gd->ram_base and gd->ram_size , which is often 
the first continuous DRAM bank which is in 32bit space. The follow up 
setup_dest_addr() uses that information to set up U-Boot relocation 
address at the end of that first continuous bank. And then 
dram_init_banksize() parses the rest of the DRAM banks into gd->bd 
(gd->bd is set up after setup_dest_addr() is called, in reserve_board()).

This above is fixable and I already have some clean up patches for that, 
which I implemented while writing this email.

But then I found out, that the ravb ethernet driver also has 32bit 
limited DMA, which breaks if I relocate U-Boot to the 64bit range. It 
worked thus far, because U-Boot was in 32bit space, so were mallocated 
DMA descriptors, so was the net_pkt_buf[] array (which is in .data 
section). I didn't find any other breakage thus far.

Which means, before we can really start switching boards to relocate to 
64bit space, we need to find all these remaining 32bit limitation sites 
and fix them first. And to do that, we would need some way to force 
allocation from 32bit space for drivers which need that ... do we 
already have such a thing ? I couldn't find anything.