IMX8MM SD UHS support

Tim Harvey tharvey at gateworks.com
Wed Jan 6 00:09:38 CET 2021 

On Wed, Dec 30, 2020 at 1:00 PM ZHIZHIKIN Andrey
<andrey.zhizhikin at leica-geosystems.com> wrote:
>
> Hello Tim,
>
> > -----Original Message-----
> > From: Tim Harvey <tharvey at gateworks.com>
> > Sent: Wednesday, December 30, 2020 7:48 PM
> > To: Adam Ford <aford173 at gmail.com>
> > Cc: Fabio Estevam <festevam at gmail.com>; ZHIZHIKIN Andrey
> > <andrey.zhizhikin at leica-geosystems.com>; Peng Fan <Peng.Fan at nxp.com>; u-
> > boot <u-boot at lists.denx.de>; Stefano Babic <sbabic at denx.de>
> > Subject: Re: IMX8MM SD UHS support
> >
> >
> > On Wed, Dec 30, 2020 at 10:22 AM Adam Ford <aford173 at gmail.com> wrote:
> > >
> > > On Wed, Dec 30, 2020 at 11:50 AM Fabio Estevam <festevam at gmail.com>
> > wrote:
> > > >
> > > > Hi Tim,
> > > >
> > > > On Wed, Dec 30, 2020 at 1:54 PM Tim Harvey <tharvey at gateworks.com>
> > wrote:
> > > >
> > > > > Andrey,
> > > > >
> > > > > I did mention that I am using the imx8mm-evk. When I saw that my
> > > > > custom board was having issues with sd_get_capabilities() I
> > > > > switched to the imx8mm-evk and confirmed my findings there.
>
> I've missed the part that you've tested the same behavior on i.MX8M Mini EVK in your original message, sorry for that.
>
> > > > >
> > > > > I'm using master (ab865a8ee5c1) with imx8mm_evk_defconfig running
> > > > > on an imx8mm-evk board configured via dip switches to boot from
> > > > > eMMC. I have a SDR104 microSD which detects and operates as such
> > > > > in Linux and this is what I see in U-Boot:
> > > > >
> > > > > U-Boot SPL 2021.01-rc4-00029-gab865a8 (Dec 30 2020 - 08:29:24
> > > > > -0800) Normal Boot
> > > > > WDT:   Started with servicing (60s timeout)
> > > > > Trying to boot from MMC2
> > > > >
> > > > >
> > > > > U-Boot 2021.01-rc4-00029-gab865a8 (Dec 30 2020 - 08:29:24 -0800)
> > > > >
> > > > > CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
> > > > > Reset cause: POR
> > > > > Model: FSL i.MX8MM EVK board
> > > > > DRAM:  2 GiB
> > > > > WDT:   Started with servicing (60s timeout)
> > > > > MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> > > > > Loading Environment from MMC... OK
> > > > > In:    serial
> > > > > Out:   serial
> > > > > Err:   serial
> > > > > Net:   eth0: ethernet at 30be0000
> > > > > Hit any key to stop autoboot:  0
> > > > > u-boot=> mmc dev 1
> > > > > Run CMD11 1.8V switch
> > > > > switch to partitions #0, OK
> > > > > mmc1 is current device
> > > > > u-boot=> mmc info
> > > > > Device: FSL_SDHC
> > > > > Manufacturer ID: 1b
> > > > > OEM: 534d
> > > > > Name: 00000
> > > > > Bus Speed: 50000000
> > > > > Mode: SD High Speed (50MHz)
> > > > > Rd Block Len: 512
> > > > > SD version 3.0
> > > > > High Capacity: Yes
> > > > > Capacity: 14.9 GiB
> > > > > Bus Width: 4-bit
> > > > > Erase Group Size: 512 Bytes
> > > > >
> > > > > You can see that the 1.8V switch succeeds and the card is
> > > > > recognized as high-speed but does not show the SDR104 capability.
>
> Did you actually measured that the signaling voltages are switched to 1v8
> on the test point I've mentioned in my mail?
>
> > > >
> > > > Could you please test this patch from Adam?
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20201230173907.2891555-1-aford173@gmail.com/
> > >
>
> If voltages are not actually switched - then probably another patch from Adam
> might help: http://patchwork.ozlabs.org/project/uboot/patch/20201230141421.2860212-1-aford173@gmail.com/
>

That patch wouldn't help in this case... that's an SPL thing. This
failure is in U-Boot itself.

The NVCC_SD2 rail does indeed switch to 1.8V but for some reason the
card indicates a failure to switch itself to 1.8V I/O as the
mmc_wait_dat0() call at the end of mmc_switch_voltage() fails. It
looks like U-Boot is doing the same steps in the same order as the
Linux driver so I'm not sure what's wrong here. I suspect it is a
timing thing as it works for your card(s) but fails for mine as well
as Adam's card(s). Because Adam verified his card(s) work with another
MMC host in UHS mode that would indicate it is probably something in
fsl_esdhc_imx.c.

I've added all kinds of delays and it doesn't make a difference. I've
also commented out the following as it doesn't seem right to switch
the host to 1.8V within the CMD11 (supposed to be done after the CMD11
and it does get done by esdhc_set_voltage):
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index e5409ad..9e9d4c6 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -514,6 +514,7 @@ static int esdhc_send_cmd_common(struct
fsl_esdhc_priv *priv, struct mmc *mmc,
                goto out;
        }

+#if 0 // esdhc_set_voltage does this and technically it shouldn't be
done until the CMD11 has completed
        /* Switch voltage to 1.8V if CMD11 succeeded */
        if (cmd->cmdidx == SD_CMD_SWITCH_UHS18V) {
                esdhc_setbits32(&regs->vendorspec, ESDHC_VENDORSPEC_VSELECT);
@@ -522,6 +523,7 @@ static int esdhc_send_cmd_common(struct
fsl_esdhc_priv *priv, struct mmc *mmc,
                /* Sleep for 5 ms - max time for card to switch to 1.8V */
                udelay(5000);
        }
+#endif

I'm wondering if all the stuff done in esdhc_send_cmd_common() breaks
the ability to check card failure via mmc_wait_dat0?

Also note that if I comment out the error check from the mmc_wait_dat0
at the end of mmc_switch_voltage() SDR104 mode appears to work just
fine (verified read performance and data integrity).

So at least I've verified that card capability detection is not to blame here.

Tim



>
> > host capabilities: widths [4, 1] modes [MMC
> > legacy, MMC High Speed (26MHz), SD High Speed (50MHz), MMC High Speed
> > (52MHz), UHS DDR50 (50MHz), UHS SDR104 (208MHz)]
>
> Since the only matching mode from host to card is " SD High Speed (50MHz)" - it is the one that has been configured.
>
> > Rd Block Len: 512 SD
> > version 3.0 High Capacity: Yes
> > Capacity: 14.8 GiB
> > Bus Width: 4-bit
> > Erase Group Size: 512 Bytes
> >
> > You can see above the host shows DDR50/SDR104 capability but the card does
> > not. Again, the issue is in sd_get_capabilities()
>
> Here is what puzzles me the most: Kernel *can* operate with this card configured to SDR104,
> but U-Boot simply does not see that the mode is available since it is not reported by the card...
>
> Looking at the other email report from you, I can see that the sd3_bus_mode=0x3, which suggests
> that the card was not setup for high-speed mode, and this is for example what Linux driver checks
> in mmc_sd_card_using_v18 function [drivers/mmc/core/sd.c].
>
> For the record: I do have U-Boot 2020.10 with my patches applied on top, and I'm building image using Yocto.
>
> My setup is: i.MX8M Mini EVK with Intenso 32GB SD Card. As I've already indicated, it is indeed switched to
> SDR104 mode and working proper. I've also successfully tried Sandisk 32 GB SD Card with the same EVK.
>
> I'll apply your patch with debug output on top of my setup to compare which values I do get from my setup.
>
> >
> > Adam / Fabio, what results do you see on your board(s)?
> >
> > Tim
>
> -- Andrey

More information about the U-Boot mailing list