On 9/25/20 5:12 PM, Tim Harvey wrote: > On Fri, Sep 25, 2020 at 8:05 AM Marek Vasut <ma...@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.
