CONFIG_MTD_NAND_VERIFY_WRITE with Software ECC

Ricard Wanderlof ricard.wanderlof at axis.com
Fri Feb 25 04:09:15 EST 2011


On Fri, 25 Feb 2011, Artem Bityutskiy wrote:
> 
> > On Thu, 2011-02-17 at 11:04 +0100, Ricard Wanderlof wrote:
> > Which all goes to say that as Cooke notes in his document above, it is 
> > necessary for the software to keep track of the number of erase cycles, 
> > and not just rely in the erase/write status that the chip itself reports.
> 
> Yeah, in UBI we do keep have erase counters, but we do not actually use
> them to make decisions about whether to mark a block as good or bad.
> Probably we should.

It's a difficult call. How bad is bad? If the spec says 100 000 cycles, 
should we mark a block bad after that time, or could we in a certain case 
go to 200 000 cycles and still get reasonable performance? It would all 
depend on the application and the also specs of the actual chip in 
question, which is something that cannot be read from the chip so it would 
have to be configured.

I think the best way is for UBI to provide only wear levelling, in order 
to use the flash optimally, then it's up to the system designer to design 
the system so that the maxium erase cycle spec is not exceeded for the 
life of the system.

Hm, perhaps there could be a tuning option, first to enable bad block 
marking when the erase counters reach a certain value, and secondly a 
parameter specifying the number of cycles. Most users would probably not 
bother about this, but it would be there for those who want to make sure 
that blocks are not used that potentially could be out of spec.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30



More information about the linux-mtd mailing list