SD cards and DATA_STAT_AFTER_ERASE

James Cameron quozl at laptop.org
Mon Apr 18 05:07:14 EDT 2011


On Thu, Apr 14, 2011 at 05:00:07PM +0100, Daniel Drake wrote:
> Currently, when installing software, OLPC firmware erases the entire
> disk then writes the entire disk contents, even if most of that is
> zeroes.

I'm having trouble proving that "entire disk contents" part of what you
wrote.  It might not be happening correctly.  But fixing it doesn't
change timing any.

--

Looking at : zblocks: in fsupdate.fth, the #image-eblocks value is taken
from the .zd file, and then used in a call to the erase-blocks method,
unchanged.

Now, for os860.zd, the value of #image-eblocks is 0x7331.

In erase-blocks in sdhci.fth, we should have " 0 7331 " on stack, and we
have " 1- bounds " which changes this to " 7330 0 ".  CMD32
ERASE_WR_BLK_START consumes the 0, and CMD32 ERASE_WR_BLK_END consumes
the 7331, and this seems right except that the values are in units of
0x20000 bytes, not 0x200 bytes as specified in the documents I'm looking
at.

Now, after execution with these parameters, it seems that only 512-byte
blocks 0 through to 0x7331 on the microSD card have been erased, not the
whole card.  Reproducer:

1.  boot Q3A64, to ok prompt,

2.  perform the same erasure sequence manually:

open-nand
0 7331 " erase-blocks" $call-nand  \ WARNING: DESTROYS DATA
close-nand
bye

3.  check with "dir int:\", response is "Can't open directory",

4.  boot Linux from USB, and dump the microSD card:

dd if=/dev/mmcblk0 bs=512 | od -a -A x | head -20

Shows the first non-zero data is beyond file offset 0xe80400, which is
offset 0x7402.

--

Now, assuming I'm misled by an already erased card, let's fill it with
urandom data to 0x7332 by 0x200 bytes:

dd if=/dev/urandom bs=512 count=29490 of=/dev/mmcblk0

Erase again using erase-blocks to 0x7331, then find the first non-zero
data ... it is at 0xe66200.  Spot on.

So, it seems to me that fs-update is not erasing the card, and that to
fix this the number of blocks must first be multiplied by 0x20000 then
divided by 0x200.  Or just multipled by 0x100, of course.

When I do this manually, the whole 4GB card is erased, less the bit
between the end of the image and the end of the card.  The first
non-zero data is at file offset 0xe6620000.  Spot on.

--

Changing zblocks: call to erase-blocks (local build Q3A64Q) and doing
two fs-update timings with two of the Toshiba microSD cards here, I
don't see any impact.

QUOZL-S 8GB microSD os860.zd 4GB Q3A64Q, 13:53.
QUOZL-S 8GB microSD os860.zd 4GB Q3A64,  13:59.
QUOZL-T 4GB microSD os860.zd 4GB Q3A64Q, 14:01.
QUOZL-T 4GB microSD os860.zd 4GB Q3A64,  14:09.

-- 
James Cameron
http://quozl.linux.org.au/



More information about the Devel mailing list