IMX8MM 4GiB boundary issue
Tim Harvey
tharvey at gateworks.com
Wed Sep 30 22:18:12 CEST 2020
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?
This makes me wonder if >3GiB is worth much on IMX8M
Tim
More information about the U-Boot
mailing list