All of lore.kernel.org
 help / color / mirror / Atom feed
From: ZHIZHIKIN Andrey <andrey.zhizhikin@leica-geosystems.com>
To: u-boot@lists.denx.de
Subject: IMX8MM SD UHS support
Date: Wed, 30 Dec 2020 21:00:16 +0000	[thread overview]
Message-ID: <AM6PR06MB4691A8CE29586691DE7F177BA6D70@AM6PR06MB4691.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <CAJ+vNU0HLjLdW0z2dE3YU5sKNYMyKUxN2JivuZmONVhO+t+AVA@mail.gmail.com>

Hello Tim,

> -----Original Message-----
> From: Tim Harvey <tharvey@gateworks.com>
> Sent: Wednesday, December 30, 2020 7:48 PM
> To: Adam Ford <aford173@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>; ZHIZHIKIN Andrey
> <andrey.zhizhikin@leica-geosystems.com>; Peng Fan <Peng.Fan@nxp.com>; u-
> boot <u-boot@lists.denx.de>; Stefano Babic <sbabic@denx.de>
> Subject: Re: IMX8MM SD UHS support
> 
> 
> On Wed, Dec 30, 2020 at 10:22 AM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Wed, Dec 30, 2020 at 11:50 AM Fabio Estevam <festevam@gmail.com>
> wrote:
> > >
> > > Hi Tim,
> > >
> > > On Wed, Dec 30, 2020 at 1:54 PM Tim Harvey <tharvey@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 at 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 at 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

  parent reply	other threads:[~2020-12-30 21:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20201229232204epcas1p473b2ffe2ae0b94c91e6a2d99304805fe@epcas1p4.samsung.com>
2020-12-29 23:21 ` IMX8MM SD UHS support Tim Harvey
2020-12-29 23:43   ` Jaehoon Chung
2020-12-29 23:56     ` Tim Harvey
2020-12-30  9:30   ` ZHIZHIKIN Andrey
2020-12-30 16:54     ` Tim Harvey
2020-12-30 17:50       ` Fabio Estevam
2020-12-30 18:21         ` Adam Ford
2020-12-30 18:47           ` Tim Harvey
2020-12-30 20:41             ` Adam Ford
2020-12-30 21:00             ` ZHIZHIKIN Andrey [this message]
2021-01-05 23:09               ` Tim Harvey
2021-01-18 19:38                 ` ZHIZHIKIN Andrey
2021-01-19 17:32                   ` Tim Harvey
2021-01-19 20:47                     ` ZHIZHIKIN Andrey
2021-01-19 20:52                       ` Adam Ford
2021-01-22 12:41                       ` Bough Chen
2021-01-25 10:43                         ` Bough Chen
2022-01-11 23:32                           ` Adam Ford
2022-01-14  3:12                             ` Bough Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM6PR06MB4691A8CE29586691DE7F177BA6D70@AM6PR06MB4691.eurprd06.prod.outlook.com \
    --to=andrey.zhizhikin@leica-geosystems.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.