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.marc...@samsung.com
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
