From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Date: Thu, 13 Aug 2020 11:09:35 +0200 Subject: am654_sdhci: mmc fail to send stop cmd In-Reply-To: <31e0ef3b-49d5-801c-70ce-2093d6d94eba@ti.com> References: <6d0ae269-6104-02e8-be21-d3840cd6b327@web.de> <42da5436-fd43-efd0-5a43-4e63226fbdc8@samsung.com> <31e0ef3b-49d5-801c-70ce-2093d6d94eba@ti.com> Message-ID: <14607234-d102-3e50-258c-079da7c017ee@web.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 23.07.20 06:14, Faiz Abbas wrote: > 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 at 4f80000: 1, sdhci at 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_abbas at ti.com/ > BTW, could this be queued for upstream? We depend on it now. Thanks, Jan PS: Subject has a typo ("correspnding").