> Date: Wed, 28 Jan 2026 12:43:28 +0100 > From: Marek Vasut <[email protected]>
Hi Marek, > 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. What do you want to do with that memory in U-Boot? You can't really use it to load a kernel into if there is a 32-bit DMA limitations in, for example, your MMC controller... Are there boards that don't have enough memory below the 4GB address boundary? > > 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. Unfortunately hardware with 32-bit DMA constraints is very common. There are device trees with dma-ranges properties that imply DMA constraints. That is mostly about restrictions of busses that have a limited number of address lines so it certainly doesn't cover everything. My list of additonal SoCs with restrictions in OpenBSD has the Raspberry Pi 4 and Rockchip RK356x and RK3588 on it. > 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. We have bounce buffers in the EFI loader. There is a more genric bounce buffer implementation in U-Boot as well, but that is only used to solve DMA cache coherency issues. But this suggests that solving things in generic code instead of drivers might be feasable (at the price of extra memery copying). That said, is there really a benefit in giving U-Boot more memory on systems that typically have 2GB or more below the 4GB address boundary?
