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@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/
BTW, could this be queued for upstream? We depend on it now.
Thanks,
Jan
PS: Subject has a typo ("correspnding").
