Jan, On 23/07/20 8:55 am, Faiz Abbas wrote: > Jan, > > On 21/07/20 10:52 pm, Jan Kiszka wrote: >> On 21.07.20 19:03, Faiz Abbas wrote: >>> Jan, >>> >>> On 21/07/20 12:06 pm, Jan Kiszka wrote: >>>> On 21.07.20 01:23, Jaehoon Chung wrote: >>>>> On 7/20/20 10:21 AM, Peng Fan wrote: >>>>>> Hi Jan, >>>>>> >>>>>>> Subject: am654_sdhci: mmc fail to send stop cmd >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> on one device with one specific SD-card (possibly an aging one), I'm >>>>>>> seeing >>>>>>> frequent "mmc fail to send stop cmd" messages, followed by read errors >>>>>>> when loading kernel and dtb. -ETIMEDOUT is returned by mmd_send_cmd. >>>>>>> However, I can always resolve this by simply retrying the stop command >>>>>>> like >>>>>>> this: >>>>>>> ... >>>> >>> >>> Its a command timeout for which we cannot program a higher timeout. >>> >>> Can you send a full failure log? >>> >> >> [unrelated fsbl, spl stuff] >> >> U-Boot 2020.07-00883-g4d6da10ce6-dirty (Jul 20 2020 - 06:30:08 +0200) >> >> Model: Siemens IOT2050 Advanced Base Board >> DRAM: 2 GiB >> MMC: sdhci@4f80000: 1, sdhci@04FA0000: 0 >> Loading Environment from SPI Flash... SF: Detected w25q128 with page size >> 256 Bytes, erase size 64 KiB, total 16 MiB >> OK >> In: serial >> Out: serial >> Err: serial >> Hit any key to stop autoboot: 0 >> stat: 18000 >> stat: 18000 >> stat: 208000 >> switch to partitions #0, OK >> mmc1(part 0) is current device >> ** No partition table - mmc 1 ** >> switch to partitions #0, OK >> mmc0 is current device >> Scanning mmc 0:1... >> Found U-Boot script /boot/boot.scr >> 784 bytes read in 2 ms (382.8 KiB/s) >> ## Executing script at 83000000 >> 65329 bytes read in 11 ms (5.7 MiB/s) >> stat: 18000 >> mmc fail to send stop cmd, -110 >> retrying... >> 17113096 bytes read in 1409 ms (11.6 MiB/s) >> Moving Image from 0x80080000 to 0x80200000, end=812c0000 >> ## Flattened Device Tree blob at 82000000 >> Booting using the fdt blob at 0x82000000 >> Loading Device Tree to 00000000fdf0f000, end 00000000fdf21f30 ... OK >> >> [kernel boot] >> >> The diff I'm carrying on top of [1] is below. >> >>> Also, does the same card + board combination work in kernel? That should >>> help us point to hardware vs U-boot. >>> >> >> The same card on the same board works without complaints with the kernel >> driver (5.8-rc5 at the moment). Even more strange, the same card a >> different board (IOT2050 Basic, some SoC series, slightly different >> type) does not throw those errors with the same U-Boot. > > Was this card working with an older U-boot version and only failing in > mainline? > >> >> Note that we are still carrying those clock swapping changes in [2]. >> I've also tried to remove it, but it has no impact on this issue. >> > > One more thing to try is to reduce the speed mode to default as we are > already gating frequency > to 25 MHz. Can you modify the sdhci-caps-mask to the following for sdhci1? > > sdhci-caps-mask = <0x7 0x200000>; >
You'll need to apply this fix for this mask to work: https://patchwork.ozlabs.org/project/uboot/patch/20200723041219.2438-1-faiz_ab...@ti.com/ Thanks, Faiz
