arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards

Bernd Walter ticso at cicely7.cicely.de
Thu Mar 3 03:07:29 UTC 2011


On Wed, Mar 02, 2011 at 07:56:36PM -0500, Greg Ansley wrote:
> On 3/2/11 7:40 PM, Ian Lepore wrote:
> >The following reply was made to PR arm/155214; it has been noted by GNATS.
> >
> >From: Ian Lepore<freebsd at damnhippie.dyndns.org>
> >To: ticso at cicely.de
> >Cc: FreeBSD-gnats-submit at 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 at 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 at 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.)
> >
> With the current code (prepatch) 4bit mode is known to work at least on 
> the SAM9G20 with kernel option AT91_MCI_HAS_4WIRE.  I'll be working on 
> the SAM9G20 in the next few days and I can test the patch on both a 
> RM9200 (1 bit only) and on a couple of SAM9G20 designs with 4bit hardware.

Oh - we already have such a feature - cool.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.


More information about the freebsd-arm mailing list