IMX8MM 4GiB boundary issue

[Marek Vasut]

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.