bad block replacement

Charles Manning manningc2 at actrix.gen.nz
Wed Mar 31 02:26:20 EST 2004


On Wednesday 31 March 2004 14:18, William J. Beksi wrote:
> I'm using a Samsung KM29U256T 32Mb nand flash with 4 partitions on a
> cramfs. I'm trying to implement ECC and a method for replacing bad
> blocks. The spare array consists of 16 bytes, positions 512-528, the
> 517th position being reserved for the bad block marker.
>
> Can I arbitrarily pick where to store the 6 byte ECC code in the spare
> array as long as I don't erase and/or overwrite the bad block marker?

Yes you can so long as there is no conflict with any hardware ECC etc. Since 
I know you're using software ECC that is not a problem.

>
> Concerning the replacement of bad blocks, Samsung guarantees that the
> 1st or 2nd page of every invalid block has non-FFh data at the 517th
> position of the array. They recommend keeping a table of valid/invalid
> blocks.

Generally (speaking for YAFFS and JFFS2 here) we don't keep a table like that 
for devices like this since we can just look at the 517th byte. 

>
> When replacing blocks, should one start at the end of the flash and
> replace a bad block with a good free block? How many free good blocks
> should one typically allocate for the duration of the flash's life?

Perhaps a better way is to save some sort of index marker in thespare area 
(ie some block id). Look at how SmartMedia does it. This should work for what 
you want. The SmartMedia block handling algorithms are on the Samsung www.

Spare blocks can be left in the erased state (ie. kept as a "free pool"). 
When you erase blocks they are released back into the "free pool". Just never 
erase a bad block!

At boot time you can then just scan the blocks to determine the logical to 
physical mapping.

Allowing 2% for all bad blocks is a GoodThing and is what SmartMedia does. 
ie. For each 1024 blocks you round it to 1000.

-- Charles




More information about the linux-mtd mailing list