Hello Francesco,

On Wed, Oct 14, 2026 at 11:33:29AM +0200, Francesco Dolcini wrote:
> Hello Andreas,
> 
> On Wed, Oct 14, 2026 at 09:46:44AM +0200, Andreas Henriksson wrote:
> > On boards with >3GiB ram, we can end up with transfers above 4GiB
> > which is not allowed by SDHC driver.
> > 
> > fsl_esdhc_imx.c: esdhc_setup_dma():
> >     if (upper_32_bits(priv->dma_addr))
> >             printf("Cannot use 64 bit addresses with SDMA\n");
> 
> [...]
> 
> > diff --git a/lib/Kconfig b/lib/Kconfig
> > index 021a82d4709..a5f2e3e1058 100644
> > --- a/lib/Kconfig
> > +++ b/lib/Kconfig
> > @@ -1371,7 +1371,7 @@ config SPL_LMB_ARCH_MEM_MAP
> >  config LMB_LIMIT_DMA_BELOW_RAM_TOP
> >     bool
> >     depends on LMB
> > -   default y if ARCH_BCM283X || ARCH_MVEBU || ARCH_ROCKCHIP || 
> > STARFIVE_JH7110
> > +   default y if ARCH_BCM283X || ARCH_IMX8M || ARCH_MVEBU || ARCH_ROCKCHIP 
> > || STARFIVE_JH7110
> >     help
> >       Some architectures can not DMA above ram_top boundary,
> >       which is after 4 GiB or 32-bit boundary too. Limit the
> 
> Is this specific of imx8m? This driver is likely used by other i.MX
> platforms.

Your thought crossed my mind as well, but to me it kind of depends on
if we see this as theoretical or if there actually needs to be a
practical problem.

For me on IMX8M with 4GB of ram, this is a practical problem.
On other ARCH it depends on how much total ram and if that all fits
inside the 4 GiB address space... so where is this a *practical* problem?
I don't know.

AIUI It it also not only the ESHDC driver specifically, so should we go
through all drivers and derive everywhere those are used and set the
limit even if it's never a practical problem?

In my mind, others will have to send additional patches when they
discover that this is also a problem on their ARCH_IMX8, ARCH_IMX9
or whatever. (Or tell me that they have a board in their collection
that is affected and they want me to include theirs in my patch while at
it.)

> 
> Francesco
> 

Regards,
Andreas Henriksson

Reply via email to