Hi Michael,
Did a little bit more checking. The smallest block size appears to be 512
bytes. The more common block size is 1024 bytes to 2048 bytes for the larger
cards. At the time of the document in 2003 they were saying that for a 4 mega
byte area they allotted a 3 percent amount of cells or 234 512 byte blocks as a
buffer or wear leveling area. First they wear level over the 4 MB zone. Then
as sections hit the wear out limit they take them out of service and mark them
as used up. Once the 234 blocks are gone the part will fail critically. At
that point the part will not be able to hide the faults from you. If you look
at the fist page of SanDisk patent 6,594,183 it shows a nice diagram of the
address translation table to block scheme. The diagram is also on page 4
figure 2. There are some other SanDisk patents that clearly show the SD card
arrangement in more detail, but the one noted has some good diagrams. In some
of the original SD cards they actually had a controller/interface chip coupled
to an off the shelf flash chip. Think of the controller as an address
translation engine more than anything else.
Bobby
----- Original Message -----
From: Michael Schnell
To: uClinux development list
Sent: Friday, March 27, 2009 6:42 AM
Subject: Re: [uClinux-dev] SD card corruption upon reboot and de-power
Not exactly. The 4MB zone is just the area that they give 3 percent
additional memory cells. Each 4MB zone would have the extra 3 percent.
I can't imagine how this is supposed to work, as I don't believe that such a
4MB area can be partly erased, (as small erase blocks result in a high hardware
price.
But maybe there is some kind of trick that I don't understand yet.
-Michael
------------------------------------------------------------------------------
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
