Open wico-frad opened 1 week ago
tq-schifferm
commented
1 week ago Hi, the issue was fixed in 19e90b5a4a36c6cd31c9e951f1ae0fdcfbea29c7, so updating to the kirkstone.TQMa8.BSP.SW.0092 release (or the current version of the TQMa8-v2020.04_imx_5.4.70_2.3.0 U-Boot branch if you're not using our Yocto BSP) should help.
(Edit: fixed commit reference, accidentally got the TQMa8MPxL instead of TQMa8MxML version of the fix at first)
wico-frad
commented
6 days ago Hi, the issue was fixed in 19e90b5, so updating to the kirkstone.TQMa8.BSP.SW.0092 release (or the current version of the TQMa8-v2020.04_imx_5.4.70_2.3.0 U-Boot branch if you're not using our Yocto BSP) should help.
(Edit: fixed commit reference, accidentally got the TQMa8MPxL instead of TQMa8MxML version of the fix at first)
Thank you for your prompt reply.
Currently, we are working with the kirkstone.TQMa8MxML.BSP.SW.0091 release (current branch: TQMa8-v2020.04_imx_5.4.70_2.3.0) . We’ve tried cherry-picking the commit 19e90b5, but the issue persists when testing on the hardware.
Any suggestions would be appreciated.
tq-schifferm
commented
6 days ago Hmm, that is unfortunate. The errors we were seeing (also with certain SanDisk SD cards) looked extremely similar, with the card stopping to respond to certain commands after an incomplete reset, resulting in error 110 (ETIMEDOUT) - although I don't remember the error 70 (ECOMM) happening here. However, I think that our issue happened earlier in the boot - as the reset in the SPL was to short, loading the U-Boot proper failed, instead of U-Boot failing to load the OS.
Some things to try:
udelay(2000) in mmc_power_cycle in drivers/mmc/mmc.c. Try increasing the delay, maybe to 10000 as as test.mmc dev 1; mmc info for the used mode. The card will likely show a UHS mode like SDR104. You can try disabling CONFIG_MMC_UHS_SUPPORT in the U-Boot config to check if the issue disappears in slower modes.
tq-niebelm
commented
6 days ago We had a similar sounding problem - U-Boot came up but U-Boot proper could nor read from SD-Card. But the error was seen only on one board for exactly one card type. It was blamed on this board. At this time we picked some patches that correct several issues in the USDHC controller driver and as far as I can tell the problem was solved on this board, too.
I rebased and pushed the patches to branch `testing/v2020.04-imx-sd-card-fixes.
wico-frad
commented
1 day ago Hmm, that is unfortunate. The errors we were seeing (also with certain SanDisk SD cards) looked extremely similar, with the card stopping to respond to certain commands after an incomplete reset, resulting in error 110 (ETIMEDOUT) - although I don't remember the error 70 (ECOMM) happening here. However, I think that our issue happened earlier in the boot - as the reset in the SPL was to short, loading the U-Boot proper failed, instead of U-Boot failing to load the OS.
Some things to try:
* Interrupt the boot in the U-Boot command line, remove and reinsert the SD card to power cycle it, continue boot * U-Boot proper will handle the SD card reset in the real MMC driver, which is the `udelay(2000)` in `mmc_power_cycle` in `drivers/mmc/mmc.c`. Try increasing the delay, maybe to 10000 as as test. * Check `mmc dev 1; mmc info` for the used mode. The card will likely show a UHS mode like SDR104. You can try disabling `CONFIG_MMC_UHS_SUPPORT` in the U-Boot config to check if the issue disappears in slower modes.
Thank you for the suggestions. Here's what we've tried so far:
Interrupting the Boot: We interrupted the boot process in the U-Boot command line, removed and reinserted the SD card to power cycle it, and then continued the boot. Unfortunately, this did not resolve the issue.
Increasing the Delay: We modified the udelay in mmc_power_cycle within drivers/mmc/mmc.c from 2000 to 10000 to see if a longer delay would help the SD card reset. This change did not resolve the problem either.
The i.MX8M Mini can support high-speed grades in the USDHC controllers. Turning off the corresponding configuration option for the TQMa8MxML variant in Kconfig before booting the kernel seems to resolve the issue.
Additionally, we tried capping the USDHC controller's capabilities by disabling the sd-uhs-sdr104 flag in imx8mm-mba8mx-u-boot.dtsi. Surprisingly, this also resolves the issue. I'm still curious why limiting the USDHC controller's capabilities in this way helps. From what I understand, the generic MMC driver uses these flags to set the host capabilities. If anyone has insights into why reducing the speed grades seems to improve stability, I would appreciate your input.
Hi everyone,
We are experiencing boot issues with our embedded module TQMa8MxML when using certain micro SD cards, specifically the SanDisk MAX ENDURANCE microSD™ Card - 32GB Class 10.
The u-boot fails to load the Device Tree Blob from the micro SD card, resulting in the error message: 'WARN: Cannot load the DT!'. The boot log below illustrates the failure after enabling #define CONFIG_MMC_TRACE.
Does anyone have any insights into why this might be occurring?