On Sun, Sep 27, 2020 at 7:47 AM Marek Vasut <[email protected]> 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 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? Best Regards, Tim
