IMX8MM 4GiB boundary issue

[Marek Vasut]

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 ? 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).