Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Mar 2011 00:40:11 GMT
From:      Ian Lepore <freebsd@damnhippie.dyndns.org>
To:        freebsd-arm@FreeBSD.org
Subject:   Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards
Message-ID:  <201103030040.p230eBIt023558@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR arm/155214; it has been noted by GNATS.

From: Ian Lepore <freebsd@damnhippie.dyndns.org>
To: ticso@cicely.de
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern
 large SD cards
Date: Wed, 02 Mar 2011 17:21:09 -0700

 On Thu, 2011-03-03 at 00:52 +0100, Bernd Walter wrote:
 > On Wed, Mar 02, 2011 at 02:53:18PM -0700, Ian Lepore wrote:
 > > 
 > > >Number:         155214
 > > >Category:       arm
 > > >Synopsis:       [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards
 > > >Confidential:   no
 > > >Severity:       serious
 > > >Priority:       medium
 > > >Responsible:    freebsd-arm
 > > >State:          open
 > > >Quarter:        
 > > >Keywords:       
 > > >Date-Required:
 > > >Class:          sw-bug
 > > >Submitter-Id:   current-users
 > > >Arrival-Date:   Wed Mar 02 22:10:10 UTC 2011
 > > >Closed-Date:
 > > >Last-Modified:
 > > >Originator:     Ian Lepore <freebsd@damnhippie.dyndns.org>
 > > >Release:        FreeBSD 8.2-RC3 arm
 > > >Organization:
 > > none
 > > >Environment:
 > > FreeBSD dvb 8.2-RC3 FreeBSD 8.2-RC3 #49: Tue Feb 15 22:52:14 UTC 2011     root@revolution.hippie.lan:/usr/obj/arm/usr/src/sys/DVB  arm
 > > 
 > > Included patch is against -current even though the problem was first seen on
 > > 8.2-RC3
 > > 
 > > The problem was seen on AT91RM9200 hardware, but presumably also affects the
 > > SAM9 series which uses the same driver code.
 > > 
 > > >Description:
 > > With the latest generation of large-capacity SD cards, write speeds as low as
 > > 20 kbytes/sec are seen.  These modern cards have erase-block sizes as large as 
 > > 8192K (compared to 32K typical on previous generations).  The at91_mci driver 
 > > does only single-sector IO; apparently this requires the SD card to internally 
 > > perform an expensive read-erase-modify-write cycle for each 512 byte block 
 > > written to the card.
 > 
 > The complete details of this problem are completely known.
 > However the RM9200 has many hardware problems to be worked around and
 > so far noone actually did.
 > Your patch is quite large, so I would like to ask you explicitly:
 > Did you test your patch with an AT91RM9200 system?
 > You did enable multisector support for reading and (more important) for
 > writing?
 > But you didn't activate 4bit mode?
 > With 4bit mode there is no hardware bug, but when the driver was written
 > is was just done in a lazy way because activating 4bit on SD cards require
 > special handling - in the meantime the SD layer itself was extracted and
 > has 4bit support, but the at91_mci driver was never updated to use that.
 > 
 > PS: I'm very pleased to see your work since SD write speed was a
 > major show stopper for some applications
 > 
 
 Yes, the patch is large, partly because I included comments about the
 hardware problems I found and how the code works around them (and also
 to help the next person understand the flow).
 
 My changes support multi-sector IO for both reads and writes.
 
 The company I work for uses the AT91RM9200 on custom-designed boards in
 8 products, all with substantially similar board designs.  So far we've
 tested these changes on 4 of them, with no problems found.
 
 I have not tested with 4-bit enabled; I wasn't aware (but in retrospect
 I probably should have assumed) that the hardware bugs are different
 with 4-bit enabled.  I'm not even sure our hardware design carries all 4
 lines to the card; I'll look at the schematics and if they're connected
 I'll see about testing that mode.  (And if they're not I'll see about
 having our designers wire up all 4 lines on future designs.)
 
 I also haven't tested with the SAM9-series, because I don't have that
 hardware available.  (I hope to convince our hardware designers to
 migrate us to SAM9 this year.)
 
 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201103030040.p230eBIt023558>