On Wed, Dec 30, 2020 at 1:30 AM ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com wrote:
Hello Tim,
-----Original Message----- From: Tim Harvey tharvey@gateworks.com Sent: Wednesday, December 30, 2020 12:22 AM To: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Peng Fan Peng.Fan@nxp.com; u-boot u-boot@lists.denx.de Cc: Fabio Estevam festevam@gmail.com; Stefano Babic sbabic@denx.de Subject: IMX8MM SD UHS support
Greetings,
In 50b1a69cee0d ("ARM: dts: imx8m: add UHS or HS400/HS400ES properties") u-boot dt props were added to enable UHS and HS400 on a couple of IMX8MM boards including the imx8mm-evk and in the subsequent patch enabled the config items.
While I see this making a huge difference for eMMC performance in U-Boot I find it doesn't do anything for microSD performance.
The issue appears to be that sd_get_capabilities() is not appropriately detecting UHS speeds on cards that appropriately detect as SDR104/DDR50 in Linux:
u-boot=> mmc info Device: FSL_SDHC Manufacturer ID: 1b OEM: 534d Name: 00000 Bus Speed: 50000000 Mode: SD High Speed (50MHz) card capabilities: widths [4, 1] modes [MMC legacy, SD High Speed (50MHz)] ^^^^ no SDR104 detected for this card 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)] Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 14.9 GiB Bus Width: 4-bit Erase Group Size: 512 Bytes
The same card in Linux shows the following upon insertion and performance tests show that it is operating at SDR104 speeds: mmc1: new ultra high speed SDR104 SDHC card at address 0001
I haven't found very good documentation on the SD switch settings to understand if something is wrong in the U-Boot implementation of of sd_get_capabilities() and I suppose it also could be an issue in sdhci-esdhc-imx.c.
In order to SD Card to operate in High Speed modes, the signaling voltage should be switched from 3v3 to 1v8. Otherwise, higher clock rates cannot be applied and card continues to be operating with lower speed modes.
Have you verified that the NVCC_SD2 is switched to 1v8 in your case?
Since you did not indicate which board you're using - it is hard for me to suggest on how measure this voltages. If you're using i.MX8M Mini EVK, then you can verify this by measuring the voltage at the test point called "NVCC_SD2" located on the Core Module in the PMIC area.
Any ideas where to look?
Anyone see SDR104 cards being detected properly for other platforms?
Yes, in fact I do see that SD Card is recognized for me as UHS SD104:
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: 9f OEM: 5449 Name: 00000 Bus Speed: 200000000 Mode: UHS SDR104 (208MHz) Rd Block Len: 512 SD version 3.0 High Capacity: Yes Capacity: 29.8 GiB Bus Width: 4-bit Erase Group Size: 512 Bytes
Please pay attention to the output, which says "Run CMD11 1.8V switch".
Do you also observe the same output?
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'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@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.
Adding the following debugging: diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index a6394bc..663bf3d 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -1365,6 +1365,10 @@ static int sd_get_capabilities(struct mmc *mmc) return 0;
sd3_bus_mode = __be32_to_cpu(switch_status[3]) >> 16 & 0x1f; +printf("%s %s sd3_bus_mode=0x%x\n", __func__, mmc->dev->name, sd3_bus_mode); +for (int i = 0; i < 16; i++) { + printf("switch_status[%d]=0x%08x\n", i, switch_status[i]); +} if (sd3_bus_mode & SD_MODE_UHS_SDR104) mmc->card_caps |= MMC_CAP(UHS_SDR104); if (sd3_bus_mode & SD_MODE_UHS_SDR50)
Shows: u-boot=> mmc dev 1 Run CMD11 1.8V switch sd_get_capabilities mmc@30b50000 sd3_bus_mode=0x3 switch_status[0]=0x0180c800 switch_status[1]=0x01800180 switch_status[2]=0x01800180 switch_status[3]=0x00000380 switch_status[4]=0x00000001 switch_status[5]=0x00000000 switch_status[6]=0x00000000 switch_status[7]=0x00000000 switch_status[8]=0x00000000 switch_status[9]=0x00000000 switch_status[10]=0x00000000 switch_status[11]=0x00000000 switch_status[12]=0x00000000 switch_status[13]=0x00000000 switch_status[14]=0x00000000 switch_status[15]=0x00000000 switch to partitions #0, OK mmc1 is current device
What board and U-Boot sha/config are you using? Do you have the ability to confirm my findings on an imx8mm-evk?
The code in sd_get_capabilities differs greatly from what Linux does. I don't have documentation on the MMC switch settings so I can't understand if what is being done is correct but it is interesting that your card is detected as SDR104.
The card I'm using above is a Samsung PRO 16GB but I've repeated the findings on a dozen cards that support either SD104 or DDR50 (again, proven in Linux).
Best regard,
Tim