IMX8MM SD UHS support

Mon Jan 18 20:38:33 CET 2021

Hello Tim,

Sorry it took me quite some time to get this sorted out, but I believe I was able to identify an offending commit that is preventing the USDHC to switch to higher speed modes.

It is in fact b5874b552f ("mmc: fsl_esdhc_imx: add wait_dat0() support"), reverting it makes SD Card to properly report capabilities and switch to high speed modes.

Can you try to revert this on your end to see if the SD Card would start to operate in high speed mode?

I'm still investigating why this addition of wait_dat0() caused this, I believe this is due to the fact that the same wait is already performed while voltage switch to handle the errata, thus this addition wait might erroneously timeout.

++ Haibo Chen <haibo.chen at nxp.com>

Haibo,

Can you please explain the purpose of adding wait_dat0() Introduced with commit b5874b552f? It is not clear from the commit message what was the purpose of adding it. Have you tested the USDHC switch to higher modes with this change?

> -----Original Message-----
> From: Tim Harvey <tharvey at gateworks.com>
> Sent: Wednesday, January 6, 2021 12:10 AM
> To: ZHIZHIKIN Andrey <andrey.zhizhikin at leica-geosystems.com>
> Cc: Adam Ford <aford173 at gmail.com>; Fabio Estevam <festevam at gmail.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
> 
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
> 
> 
> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > 2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F2020123017390
> > > > > 7.2891555-1-
> aford173%40gmail.com%2F&data=04%7C01%7C%7C12ecf6
> > > > >
> da5d4d4b8ea07708d8b1cf01ee%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C
> > > > >
> 0%7C0%7C637454849942704702%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> L
> > > > >
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp
> > > > >
> ;sdata=libCAoYJAg%2Brm2V%2BkrFBK%2FovUaWV0u1kbwHhj7pfues%3D&
> > > > > reserved=0
> > > >
> >
> > If voltages are not actually switched - then probably another patch
> > from Adam might help:
> > https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch
> > work.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20201230141421.2860212-1-
> a
> >
> ford173%40gmail.com%2F&data=04%7C01%7C%7C12ecf6da5d4d4b8ea0770
> 8d8b
> >
> 1cf01ee%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C0%7C0%7C637454849942704
> 70
> >
> 2%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTiI6
> >
> Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oBQ%2BiOr%2B%2BYVmI47EAs
> J%2FIs
> > cet48wzpcUY%2FY%2BcJm2eaY%3D&reserved=0
> >
> 
> 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

-- Andrey