IMX8MM 4GiB boundary issue

Marek Vasut marex at denx.de
Fri Sep 25 19:55:36 CEST 2020


On 9/25/20 5:12 PM, Tim Harvey wrote:
> On Fri, Sep 25, 2020 at 8:05 AM Marek Vasut <marex at 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 at 30be0000 (eth0) using random MAC address - ea:22:3a:4d:8f:d5
>>> eth0: ethernet at 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.


More information about the U-Boot mailing list