IMX8MM 4GiB boundary issue

[Marek Vasut]

On 10/1/20 6:33 PM, Tim Harvey wrote:
> On Sun, Sep 27, 2020 at 7:47 AM Marek Vasut <marex at denx.de> wrote:
>>
>> On 9/27/20 4:35 AM, Peng Fan 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.
>>
>> R-Car had the same problem, so you can look there.
> 
> Marek,
> 
> Are you referring to d2661d8: mmc: tmio: sdhi: Use bounce buffer to
> avoid DMA limitations

Yes, but on R-Car3 this could also be solved better by using IOMMU
(Linux does it). IOMMU isn't available on MX8M though, to my knowledge.

> Do you know the state of the Linux kernel drivers with regards to this
> issue and if there is a performance hit due to the bounce buffers?

In Linux, R-Car3 uses IOMMU, so there is no performance hit on that
specific hardware. On iMX8M, you would likely need to set some bit which
indicates the hardware supports only 32bit DMA, so the DMA buffers would
be allocated below the 32bit barrier, also no big problem. I think it is
one of the DMA flags, DMA_BIT_MASK(32) or so.