IMX8MM SD UHS support

ZHIZHIKIN Andrey andrey.zhizhikin at leica-geosystems.com
Wed Dec 30 22:00:16 CET 2020


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/

This is my pure guess, as neither I tested it myself nor I have a fixed regulator option enabled in my
build for SPL, but still I see that SD Card I have is switched into SDR104 mode.

> > My patch probably won't do much more than the one from Andrey.  From
> > what I could gather, the generic mmc driver uses those flags to enable
> > the host caps.  My enables the same host caps by checking the
> > structure so the device tree flags are not needed.
> >
> > The UHS and HS200/HS400 config options need to be enabled in Kconfig
> > for them to make a difference.  Part of me wonders if they should be
> > implied-on if USHDC is set, but that's a different issue.
> >
> > If Tim is not seeing the SDR104 negotiated from Andrey's patch, it
> > probably won't change with mine.
> >
> 
> Right, the issue is not the host caps.
> 
> If I enable the calls to mmc_dump_capabilities() I see:
> u-boot=> mmc info
> Device: FSL_SDHC
> Manufacturer ID: 3
> OEM: 5344
> Name: SL16G
> Bus Speed: 50000000
> Mode: SD High Speed (50MHz)
> card capabilities: widths [4, 1] modes [MMC legacy, SD High Speed (50MHz), UHS
> SDR12 (25MHz), UHS SDR25 (50MHz)]

I actually don't see that the card reports an SDR104 mode support here, and clocks can only be
configured as high as 50 MHz which we do see in the "Bus speed" output.

> 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