IMX8MM 4GiB boundary issue

[Peng Fan]

> Subject: Re: IMX8MM 4GiB boundary issue
> 
> 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.

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

Regards,
Peng.

> 
> Tim