From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 1 Sep 2015 17:35:57 +0200 Subject: [U-Boot] [PATCH 1/2] mmc: dw_mmc: Increase timeout to 20 seconds In-Reply-To: <20150901172500.00634a8f@amdc2363> References: <1440769821-24005-1-git-send-email-l.majewski@samsung.com> <201509011333.13433.marex@denx.de> <20150901172500.00634a8f@amdc2363> Message-ID: <201509011735.57154.marex@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tuesday, September 01, 2015 at 05:25:00 PM, Lukasz Majewski wrote: > Hi Marek, > > > On Tuesday, September 01, 2015 at 01:19:09 PM, Lukasz Majewski wrote: > > > Hi Marek, > > > > Hi! > > > > > > On Saturday, August 29, 2015 at 06:38:48 PM, Lukasz Majewski > > > > > > > > wrote: > > > > > Hi Marek, > > > > > > > > Hi Lukasz, > > > > > > > > > > On Saturday, August 29, 2015 at 01:55:36 PM, Lukasz Majewski > > > > > > > > > > > > wrote: > > > > > > > On Fri, 28 Aug 2015 23:55:17 +0200 > > > > > > > > > > > > Hi! > > > > > > > > > > > > > Marek Vasut wrote: > > > > > > > > On Friday, August 28, 2015 at 03:50:20 PM, Lukasz Majewski > > > > > > > > > > > > > > > > wrote: > > > > > > > > > The commit: d9dbb97be0e4a550457aec5f11afefb446169c90 > > > > > > > > > "mmc: dw_mmc: Zap endless timeout" removed endless loop > > > > > > > > > waiting for end of dw mmc transfer. > > > > > > > > > > > > > > > > > > For some workloads - dfu test @ Odroid XU3 (sending 8MiB > > > > > > > > > file) - and SD cards (e.g. MicroSD Kingston 4GiB, Adata > > > > > > > > > 4GiB) the default timeout is to short. > > > > > > > > > > > > > > > > > > The new value - 20 seconds - takes into account the > > > > > > > > > situation when SD card triggers internal clean up. Such > > > > > > > > > process may take more than 10 seconds on some cards. > > > > > > > > > > > > > > > > What happens if you pull the SD card out of the slot > > > > > > > > during such a process? > > > > > > > > > > > > > > Then we would wait 20 seconds :-) to proceed. > > > > > > > > > > > > Oops, I think I was not clear here. I was wondering what > > > > > > happens to the card if you yank it out of the slot whole it's > > > > > > performing it's internal cleanup or whatever. Is it possible > > > > > > that the card suffers data corruption, effectively trashing > > > > > > user data ? > > > > > > > > > > I think that only the card manufacturer may reveal what can > > > > > happen with the card (what policy have been implemented in > > > > > their FW). > > > > > > > > > > I guess that you may lost data in such case. > > > > > > > > Uuuurgh, that's seriously shitty. > > > > > > > > > > Is this behavior > > > > > > specific to Samsung SD cards ? > > > > > > > > > > I've experienced the problem with Kingston (brand new one) and > > > > > Adata MicroSD HC (4GiB) cards. > > > > > > > > I had bad previous experience with Kingston too. > > > > > > > > > > > To be clear - the mentioned patch introduced regression. > > > > > > > > > > > > That's a bug, not a regression, but anyway, > > > > > > that's not the point. I do > > > > > > agree with you that we do have a problem and I'm inclined to > > > > > > Ack this patch, I'd like to understand what the real > > > > > > implications of such a behavior of these cards are. > > > > > > > > > > > > > It works for > > > > > > > small files on a commonly available SD cards (like 4 GiB > > > > > > > Kingston/Adata). > > > > > > > > > > > > > > When I ran DFU tests I've discovered that there is a problem > > > > > > > with storing 8MiB file (dat_8M.img). > > > > > > > > > > > > > > Even worse - when one wants to store Image.itb file (which > > > > > > > might be 4-6 MiB) it sometimes works and sometimes not. > > > > > > > Nightmare for debugging. > > > > > > > > > > > > Ew, that's one crappy card you have there. I'm reading the SD > > > > > > card "Physical Layer Simplified Specification Version > > > > > > 4.10" (part1_410.pdf) section 4.6.2.2 and it states that for > > > > > > SDHC cards, the write operation should take at most 250mS, > > > > > > for SDXC it's 500mS. Could it be that your card is violating > > > > > > the spec ? > > > > > > The "timeout" error is for situation when you issue write command > > > (either single or multiple block) and you don't receive any response > > > from the card. > > > > > > In our case we use multiblock transfer (CMD25) with either set > > > number of block to transfer (CMD23) or explicit end of transmission > > > (CMD12). > > > > > > Let's consider the second case. > > > > > > We setup data and issue CMD25. Then we check the CMD25 status (if we > > > don't receive reply in 250 ms we would get timeout error). > > > Afterwards data from buffer is transmitted to the card and flashed. > > > This operation may take long time. During this process you can issue > > > CMD13 (SEND_STATUS) to receive information about card state ([*] > > > 4.10. - page 85). > > > > Maybe we should implement such polling through CMD13 then ? But, this > > should be a matter for next MW, this MW we should go with increasing > > the timeout to some 20 or 30 second. What do you think ? > > For next release we can increase the timeout. Rewritting eMMC subsystem > code is a challenging task and we will not finish until the next u-boot > release. Yeah, we're in agreement.