From mboxrd@z Thu Jan 1 00:00:00 1970 From: Przemyslaw Marczak Date: Mon, 14 Sep 2015 13:15:27 +0200 Subject: [U-Boot] [PATCH 1/2] mmc: dw_mmc: Increase timeout to 20 seconds In-Reply-To: <1442226651.9459.16.camel@synopsys.com> References: <1440769821-24005-1-git-send-email-l.majewski@samsung.com> <20150909090130.4385204c@amdc2363> <201509091334.20746.marex@denx.de> <1441991999.10291.15.camel@synopsys.com> <20150911234528.6ba30dbe@jawa> <1442226651.9459.16.camel@synopsys.com> Message-ID: <55F6AC4F.4000809@samsung.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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