From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Sun, 27 Sep 2020 16:45:36 +0200 Subject: IMX8MM 4GiB boundary issue In-Reply-To: References: <759d14eb-f461-accf-5c95-ce85892a0778@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.