[PATCH] lmb: Reinstate access to memory above ram_top

[Mark Kettenis]

> Date: Tue, 24 Mar 2026 13:10:04 +0100
> From: Casey Connolly <casey.connolly at linaro.org>

Hi Casey,

> On 09/02/2026 21:44, Marek Vasut wrote:
> > On 2/9/26 7:45 PM, Casey Connolly wrote:
> > 
> > Hello Casey,
> > 
> >>> 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...
> > 
> > Are those qualcomm devices suffering from 32bit DMA limitation too ?
> 
> Yeah, this is how we handle allocating the framebuffer for
> not-yet-upstream display support.
> 
> Would it be possible to use SMMU TLBs to allow (most) 32-bit-only
> peripherals to access 64-bit addresses?

On Apple systems the IOMMU (DART) is used for USB controllers (PCI &
non-PCI).  There is an API to map/unmap addresses in U-Boot.  But only
the xhci driver uses it.

> >> *casey grumbles something about making relocation optional and merging
> >> the f/r init sequences for most boards*
> > 
> > Can you try CONFIG_SKIP_RELOCATE for your use case ?
> 
> That works fine, I'm mostly frustrated with the whole pre-reloc FDT
> scanning/DM init, lack of dcache, etc... So pretty unrelated issues heh.
> 
> -- 
> // Casey (she/her)
> 
>