am654_sdhci: mmc fail to send stop cmd

Faiz Abbas faiz_abbas at ti.com
Tue Jul 21 19:03:00 CEST 2020


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:
>>>>
>>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
>>>> f36d11ddc8..9019d9f2ed 100644
>>>> --- a/drivers/mmc/mmc.c
>>>> +++ b/drivers/mmc/mmc.c
>>>> @@ -406,7 +406,11 @@ static int mmc_read_blocks(struct mmc *mmc, void
>>>> *dst, lbaint_t start,  #if !defined(CONFIG_SPL_BUILD) ||
>>>> defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
>>>>               pr_err("mmc fail to send stop cmd\n");  #endif
>>>> -            return 0;
>>>> +            pr_err("retrying...\n");
>>>> +            if (mmc_send_cmd(mmc, &cmd, NULL)) {
>>>> +                pr_err("failed again\n");
>>>> +                return 0;
>>>> +            }
>>>>           }
>>>>       }
>>>>
>>>>
>>>> Hardware is our IOT2050, baseline is today's master (1c4b5038afcc) with
>>>> board-enabling and a bunch of patches from your tree [1]. However, already
>>>> 4d6da10ce611 exposes the problem.
>>>>
>>>> What could cause this?
>>>
>>> Where the timeout happen in driver?
>>>
>>> Did you try enlarge the timeout value?
>>
>> how about adding SDHCI_QUIRK_WAIT_SEND_CMD?
> 
> I tried that already, but the result was even worse, a non-working mmc.
> 
>> And as Peng's comment, It needs to find where return error in driver code.
>>
> 
> As written in my other reply:
> https://gitlab.denx.de/u-boot/u-boot/-/blob/f12341a9529540113f01989149bbbeb68662a829/drivers/mmc/sdhci.c#L385
> Thus, it's reported by the hw.
> 

Its a command timeout for which we cannot program a higher timeout.

Can you send a full failure log?

Also, does the same card + board combination work in kernel? That should help us point to hardware vs U-boot.

Thanks,
Faiz


More information about the U-Boot mailing list