IMX8MM 4GiB boundary issue
Peng Fan
peng.fan at nxp.com
Fri Oct 2 13:07:35 CEST 2020
> Subject: Re: IMX8MM 4GiB boundary issue
>
> On Sat, Sep 26, 2020 at 7:35 PM Peng Fan <peng.fan at nxp.com> wrote:
> >
> > > Subject: Re: IMX8MM 4GiB boundary issue
> > >
> > > On 9/27/20 2:56 AM, Peng Fan wrote:
> > >
> > > [...]
> > >
> > > >>> I can imagine that either the FEC/SDHCI is limited to 32bit
> > > >>> addressing in hardware (the DMA can only operate on 32bit range
> > > >>> due to it coming from 32bit systems), OR, the drivers need to be
> > > >>> patched to support the 64bit addresses properly on 64bit SoCs
> > > >>> and 64bit variants of the IPs
> > > >>
> > > >> I hadn't thought about the DMA boundary issue. I'll wait for NXP
> > > >> to weigh in before I start digging through drivers. I wonder if
> > > >> there is a simple workaround to make sure U-Boot is running in
> > > >> lower DRAM? I'm not all that clear where U-Boot gets allocated.
> > > >
> > > > The IP only support 32bits DMA, you could let U-Boot only
> > > > relocated to the end of 4GB memory address space using
> > > > get_effective_memsize
> > >
> > > Surely the ARM64 core can address more than 4 GiB of DRAM, and can
> > > execute code from above the 4 GiB boundary, right ?
> >
> > Yes
> >
> > In that case,
> > > get_effective_memsize cannot be used.
> > >
> > > What you describe here is a limitation of the old IP blocks which
> > > were taken from previously 32bit SoCs and they are incapable of
> > > accessing DRAM above the 4 GiB boundary with their limited DMAs. The
> > > solution for that is to fix those drivers, e.g. by placing their
> > > buffers below the 4 GiB boundary, or by using bounce buffers if needed.
> > >
> > > Placing U-Boot below the 4 GiB boundary is NOT a solution in any
> > > way, but a broken workaround. There is still nothing preventing user
> > > from placing a buffer above the 4 GiB boundary and passing that to
> > > the driver, at which point the driver will fail (e.g. a simple "$
> > > load mmc
> > > 0:1 0x100000000 file" will just fail, unless e.g. a bounce buffer is used).
> >
> > That will be several drivers need to use bounce buffer,
> sdhc/fec/usb/nand/video.
> > Let's see how to address the drivers.
> >
>
> Peng,
>
> I assume the Linux sdhc/fec/usb/nand/video drivers take care of those IP's
> only having 32bit DMA's via bounce buffers at the cost of some performance
> hit (like not being able to use zero-copy buffers)? By video I assume you mean
> CSI/DSI bridge has 32bit DMA but hopefully GPU/VPU has 64bit DMA?
I did not check all the IP details. GPU may support 36bit address space.
We use CMA area in 4GB space for DMA usage.
>
> This makes me wonder if >3GiB is worth much on IMX8M
DMA limitation not block using bigger DRAM memory for CPU.
Thanks,
Peng.
>
> Tim
More information about the U-Boot
mailing list