[U-Boot] [PATCH 1/2] mmc: dw_mmc: Increase timeout to 20 seconds

[Przemyslaw Marczak]

Hi Alexey,

On 09/14/2015 12:30 PM, Alexey Brodkin wrote:
> On Fri, 2015-09-11 at 23:45 +0200, Lukasz Majewski wrote:
>> Hi Alexey,
>
>>> FWIW I faced similar problem even reading data.
>>> At least on one of my boards reading of ~8Mb file
>>> took ~1.7 seconds and so 1 second timeout was interrupting data
>>> exchange.
>>
>> Was it SD card or eMMC device?
>
> It was external SD-card.
>
>>>
>>> So indeed we need to have some dirty hack for upcoming release
>>> like bumping timeout to something really huge but later we
>>> need to fix that problem properly.
>>>
>>> I though proper solution would be to set timeout depending of amount
>>> of data to be exchanged... something like take slowest speed of SD/MMC
>>> that is allowed by spec and calculate delay based on how much time it
>>> might take for that slow device and for safety multiply it by say 2.
>>
>> As fair as I remember, card provide this kind of information. We can
>> try to investigate this possibility.
>
> I'm pretty sure card may report a lot of info about itself.
> And if we look at what people do in Linux kernel we may see calculations
> of different timeouts in "drivers/mmc/core/core.c".
>
> But keeping in mind we're not writing another OS kernel but we're just
> dealing with bootloader I'd prefer to keep things simple and do check
> only critical things like totally broken HW. I.e. something simple should
> be enough for U-Boot.
>

The standard doesn't specify the timeout for read/write commands, 
because it is not a constant value. To finish the command, card needs 
make some internal cleanup, which is called "Background operations" in 
Jedec standard.

There is no way to estimate the time to finish the "bkops", maybe the 
card's firmware also doesn't know when it finish.

The 4 min of timeout for background operations is probably a result 
after some tests.

If I good remember only erase timeout is specified by the standard, and 
can be estimated after read some values from EXT_CSD, if the vendor 
provides it.

>>>
>>> Now from this thread I see that there're other reasons that might
>>> affect length of at least write operation. In other words it could be
>>> complicated unfortunately.
>
> -Alexey
>

Some day, I had a device which couldn't boot - it goes down after a 
while, and the console was silent. The device was temporary broken.

After power-up with JTAG, and manually run the "background operations" 
on the card, the device could then boot.

So the conclusion was, that the timeout for read in the bootloader was 
to short, and the tired card tried to make some internal cleanup - so 
the read command could not be finished in the timeout estimated for 
fresh card.

The bkops are supported from eMMC 4.3, and are not supported for SD 
cards. In this case, Linux can trigger the card internal cleanup in it's 
idle state, so the read/write operation will probably finish as fast as 
possible.

It is going to be little frustrating, to wait for the fix, to such 
critical issue...

Best regards,
-- 
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marczak at samsung.com