#9692 HIGH 1.5: XO-1.5 needs delay in powering off the internal SD card

Zarro Boogs per Child bugtracker at laptop.org
Wed Nov 18 01:03:52 EST 2009


#9692: XO-1.5 needs delay in powering off the internal SD card
-------------------------------------------+--------------------------------
           Reporter:  wad                  |       Owner:  rsmith      
               Type:  enhancement          |      Status:  new         
           Priority:  high                 |   Milestone:  1.5         
          Component:  embedded controller  |     Version:  1.5-B3      
         Resolution:                       |    Keywords:  sdmmc XO-1.5
        Next_action:  design               |    Verified:  0           
Deployment_affected:                       |   Blockedby:              
           Blocking:                       |  
-------------------------------------------+--------------------------------

Comment(by gnu):

 It would be best to run a protocol with the SD card, rather than use a
 fixed N millisecond timeout.  This avoids both too-long and too-short
 errors.

 SD Card Simplfied Spec version 2.0 says, sec. 4.3.3:

   "The Read operation from SD Memory Card may be interrupted by turning
 the power off. The SD Memory Card ensures that data is not destroyed
 during all the conditions except write or erase operations issued by the
 host even in the event of sudden shut down or removal."

 Section 6.1-6.3 which cover hot insertion/removal, card detection, and
 power protection, is unfortunately removed in the Simplfied Specification.

 There appears to be no well-defined way to ask an SD card whether it has
 finished all buffered writes.  But see 4.3.4:

   "Send Number of Written Blocks
   Systems that use Pipeline mechanism for data buffers management are, in
 some cases, unable to determine which block was the last to be well
 written to the flash if an error occurs in the middle of a Multiple Blocks
 Write operation. The card will respond to ACMD22 with the number of well
 written blocks."

 Perhaps the driver can issue ACMD22 and loop looking for the right
 response, before powering down.

 Erases appear to be synchronous, so if you can do a basic status command,
 it's done. (Note ACMD23 allows pre-erasure before a multi-block write
 command, which occurs as part of the write).

-- 
Ticket URL: <http://dev.laptop.org/ticket/9692#comment:5>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system


More information about the Bugs mailing list