On 9/25/20 5:12 PM, Tim Harvey wrote:
On Fri, Sep 25, 2020 at 8:05 AM Marek Vasut marex@denx.de wrote:
On 9/25/20 4:52 PM, Tim Harvey wrote:
Greetings,
I'm working with an IMX8MM board that has 4GiB of DRAM. I've found that in this configuration the MMC driver and FEC network driver appear to have some issues with crossing the 4GiB address space. If I tell U-Boot I have 3GiB everything is ok, but when I set it to 4GiB I see the following:
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... Error found for upper 32 bits Error found for upper 32 bits Error found for upper 32 bits *** Warning - No block device, using default environment
In: serial Out: serial Err: serial Net: DP83867 Warning: ethernet@30be0000 (eth0) using random MAC address - ea:22:3a:4d:8f:d5 eth0: ethernet@30be0000 [PRIME] Hit any key to stop autoboot: 0
On the FEC ethernet side I don't see any errors reported but ping's fail with 4GiB DRAM.
I suspect drivers have 32bit addressing issues as the base of mem for IMX8MM is 1GiB so anything over 3GiB of DRAM runs you over the 32bit boundary.
Anyone run into this yet?
I saw similar things on RCar3 with 32bit IPs and used bounce buffers to work around the 32bit limitations where applicable.
Marek, I noticed you are the maintainer for the technexion pico-imx8mq which has support for 1, 2, 3, and 4 GiB DRAM. Did you encounter such issues on the 4GiB variant?
I dont have the 4 GiB variant.
ah... that explains why you didn't see it. Note a patch I just sent 'imx8m: fix cache setup for dynamic sdram size' that your board will need as well in order to boot with 4GiB.
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.
Use the whole DRAM and fix the drivers. U-Boot gets relocated to the end of DRAM by default.