The previously mentioned commit didn't resolve the issue. When testing I made a mistake.
The workaround I'm using to resolve the issue is by disabling the DDR mode juste before re-init happens (DDR mode will be automatically enabled later in the init process). Now I don't know if this is really a bug in the mmc driver, or I'm just missing some additional configuration to work with the eMMC in DDR mode ! Le mar. 27 juil. 2021 à 15:14, Abder <[email protected]> a écrit : > Hi Jaehoon, > yes, DDR mode works fine before executing "mmc dev 2" command. > However, for "mmc rescan" command or "mmc info" to work, I need to first > select the correct mmc device using the "mmc dev 2" command, cuz the > default one is device 0 in my case which is empty. > > OTOH, after hours of debugging I found the origin of the issue. In fact, > the "mmc dev 2" command forces a reinitialization of the emmc, and if the > emmc was already initialized in DDR mode at boot up, the implemented > re-init flow leads to bad clock settings. > (basicly the host tries to set the clock of the emmc to 400KHz > (identification mode), but as the DDR mode is still enabled, the > configured clock corresponds to the half of that = 200KHz). The mismatch in > frequency is what caused the -70 ECOM error. > and as the command fails, the emmc stays at 200KHz, which leads any > attempt to interact with the emmc afterwards to failure. > > I found out that this bug was patched recently in > 390f9bddb9c84f75649024b41b8cf2a766379ce0 in the main u-boot. > > Anyhow.. Thanks for your replies. > > Best regards, > Abder > > > Le mar. 27 juil. 2021 à 04:03, Jaehoon Chung <[email protected]> a > écrit : > >> On 7/26/21 5:36 PM, Abder wrote: >> > Hi Jaehoon, >> > This is the output with MMC_TRACE enabled >> > >> > U-Boot >mmc dev 2 >> > blk_find_device: if_type=6, devnum=2: [email protected], 6, 2 >> > ofnode_read_u32: vmmc-supply: 0x33 (51) >> > ofnode_read_u32: vqmmc-supply: 0x33 (51) >> > clock is disabled (0Hz) >> > fixed_regulator_set_enable: dev='3p3v', enable=1, delay=0, has_gpio=0 >> > clock is enabled (400000Hz) >> > CMD_SEND:0 >> > ARG 0x00000000 >> > MMC_RSP_NONE >> > CMD_SEND:8 >> > ARG 0x000001aa >> > RET -110 >> > CMD_SEND:55 >> > ARG 0x00000000 >> > RET -110 >> > CMD_SEND:0 >> > ARG 0x00000000 >> > MMC_RSP_NONE >> > CMD_SEND:1 >> > ARG 0x00000000 >> > MMC_RSP_R3,4 0x00ff8080 >> > CMD_SEND:1 >> > ARG 0x40300000 >> > MMC_RSP_R3,4 0x00ff8080 >> > CMD_SEND:0 >> > ARG 0x00000000 >> > MMC_RSP_NONE >> > CMD_SEND:1 >> > ARG 0x40300000 >> > MMC_RSP_R3,4 0x00ff8080 >> > CMD_SEND:1 >> > ARG 0x40300000 >> > MMC_RSP_R3,4 0x00ff8080 >> > CMD_SEND:1 >> > ARG 0x40300000 >> > MMC_RSP_R3,4 0x00ff8080 >> > CMD_SEND:1 >> > ARG 0x40300000 >> > MMC_RSP_R3,4 0xc0ff8080 >> > CMD_SEND:2 >> > ARG 0x00000000 >> > RET -70 >> > CMD_SEND:2 >> > ARG 0x00000000 >> > RET -70 >> > CMD_SEND:2 >> > ARG 0x00000000 >> > RET -70 >> > CMD_SEND:2 >> > ARG 0x00000000 >> > RET -70 >> > CMD_SEND:2 >> > ARG 0x00000000 >> > RET -70 >> > CMD_SEND:2 >> > ARG 0x00000000 >> > RET -70 >> > Command failed, result=1 >> > U-Boot > >> > >> > I believe the -70 error is an ECOM error (Communication error on send). >> > However this does not occur when eMMC is in HS mode for example. >> > and even in DDR mode, before executing the "mmc dev 2" cmd, the >> > communication with the emmc with "load" works without a hitch. >> >> Sorry. I didn't understand clearly. >> Does DDR mode work fine before "mmc dev 2" command? >> Did you try to run other command? e,g) mmcinfo or mmc rescan? >> >> It seems that error is returned in fsl_esdhc_imx.c. >> Well, it seems that not cleared something after some operation. >> It needs to check full log and sequence. >> >> Best Regards, >> Jaehoon Chung >> >> > >> > >> > >> > Le lun. 26 juil. 2021 à 10:03, Jaehoon Chung <[email protected]> a >> > écrit : >> > >> >> Hi, >> >> >> >> On 7/26/21 4:41 PM, Abder wrote: >> >>> Hi, >> >>> >> >>> I have been trying recently to optimize the boot time on a customized >> >> board >> >>> based on the IMX6DP. >> >>> >> >>> For the time being, I succeeded in enabling the DDR (dual data rate) >> mode >> >>> for the emmc to speed up the data rate for read and write cycles in >> >> u-boot. >> >>> >> >>> By reading a file from the emmc using the "load" command (e.g. load >> mmc >> >> 2:1 >> >>> 0x12000000 file), I can see that the data rate has doubled, confirming >> >> that >> >>> the DDR mode is enabled. >> >>> >> >>> However, the problem I have is that when I execute the u-boot command >> >> "mmc >> >>> dev 2" to switch the current device to the onboard eMMC, the command >> >> fails >> >>> with the output below : (with DEBUG enabled) >> >> >> >> If you can enable CONFIG_MMC_TRACE, then you can get more information >> >> relevant to MMC. >> >> Could you also share log after enabled MMC_TRACE? >> >> >> >> Best Regards, >> >> Jaehoon Chung >> >> >> >>> >> >>> U-Boot >mmc dev 2 >> >>> blk_find_device: if_type=6, devnum=2: [email protected], 6, 2 >> >>> ofnode_read_u32: vmmc-supply: 0x33 (51) >> >>> ofnode_read_u32: vqmmc-supply: 0x33 (51) >> >>> clock is disabled (0Hz) >> >>> fixed_regulator_set_enable: dev='3p3v', enable=1, delay=0, has_gpio=0 >> >>> clock is enabled (400000Hz) >> >>> Command failed, result=1 >> >>> U-Boot > >> >>> >> >>> and after this command, any attempt to interact with the emmc (e.g. >> fatls >> >>> mmc 2:1 ) ends with failure. >> >>> >> >>> To enable the DDR mode, all I did was define the macro >> >>> CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE in the header of my board. >> >>> >> >>> Any help is greatly appreciated ! >> >>> >> >>> -- >> >>> >> >>> Abder, >> >>> >> >> >> >> >> > >> >>
