public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
* bad block replacement
@ 2004-03-31  2:18 William J. Beksi
  2004-03-31  7:15 ` Thomas Gleixner
  2004-03-31  7:26 ` Charles Manning
  0 siblings, 2 replies; 3+ messages in thread
From: William J. Beksi @ 2004-03-31  2:18 UTC (permalink / raw)
  To: linux-mtd

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?

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.

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?

thank you
-Bill

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: bad block replacement
  2004-03-31  2:18 bad block replacement William J. Beksi
@ 2004-03-31  7:15 ` Thomas Gleixner
  2004-03-31  7:26 ` Charles Manning
  1 sibling, 0 replies; 3+ messages in thread
From: Thomas Gleixner @ 2004-03-31  7:15 UTC (permalink / raw)
  To: William J. Beksi, linux-mtd

On Wednesday 31 March 2004 04: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.

The generic nand driver knows all about this. ECC is implemented and bad block 
management is done in  NAND aware filesystems. 

Using cramfs on NAND is not really a good idea. Cramfs is _NOT_ aware of NAND 
flash. There exist JFFS2 (compressing) and YAFFS (not compressing), which are 
NAND aware. Use one of those and you are done with out any changes in the 
code. 

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: bad block replacement
  2004-03-31  2:18 bad block replacement William J. Beksi
  2004-03-31  7:15 ` Thomas Gleixner
@ 2004-03-31  7:26 ` Charles Manning
  1 sibling, 0 replies; 3+ messages in thread
From: Charles Manning @ 2004-03-31  7:26 UTC (permalink / raw)
  To: William J. Beksi, linux-mtd

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-03-31  7:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-31  2:18 bad block replacement William J. Beksi
2004-03-31  7:15 ` Thomas Gleixner
2004-03-31  7:26 ` Charles Manning

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox