On 28/01/2026 12:43, Marek Vasut wrote:
> On 1/28/26 5:41 AM, Heinrich Schuchardt wrote:
>> Am 28. Januar 2026 00:48:40 MEZ schrieb Marek Vasut
>> <[email protected]>:
>>> 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.
For some (non-upstream) Qualcomm drivers we have just used lmb with
LMB_ALLOC_MAX and passed in 4GB as the max address, it would be nice to
have a wrapper function for this.
Maybe this would just cause a whole bunch of other issues but perhaps it
would be easiest to have a config option to place the malloc arena in
32-bit memory rather than always directly below U-Boot? Then again I
imagine this is something that has been bikeshed in the past...
*casey grumbles something about making relocation optional and merging
the f/r init sequences for most boards*
--
// Casey (she/her)
