Flash filesystem questions

[Ricard Wanderlof]

On Fri, 16 Jan 2015, Erik Ekman wrote:

> On Fri, Jan 16, 2015 at 10:33 AM, Ricard Wanderlof
> <ricard.wanderlof at axis.com> wrote:
> >
> > On Thu, 15 Jan 2015, Erik Ekman wrote:
> >
> >> Next problem is bad blocks. I have not found anything in the hardware
> >> that keeps track of them. I am thinking about using the first two
> >> working blocks as maps, one u8 per erase block. Since I only have 8k,
> >> 16k or 32k erase blocks it should not wear them out too much during
> >> updates.
> >
> > Normally flashes never keep track of bad blocks themselves, except that
> > bad blocks are usually marked as such during the manufacturing process,
> > but it is completely up to software to make use of the that information.
> >
> >> Is this a valid strategy or is there a common smart solution?
> >
> > The mtd driver layer has a bad block table mechanism which does all this
> > for you. (see nand_bbt.c). It just has to be enabled using a flag in the
> > board driver.
> 
> I found that, but it requires the driver to be at the nand layer, I am just
> implementing the MTD interface. I saw in some other threads in the list
> that a generic bbt implementation might be needed (for SPI NAND, my
> device, and Dan Ehrenberg).

So you mean you have a driver which behaves like an mtd device, but does 
not use the mtd layer at all?

> My flash complains when writing or erasing to bad blocks, but reads
> return no error. Is that the normal case?

Normally when writing using mtd, there is a software mechanism (in 
nand_base.c) which prevents the erasure of blocks that have been marked 
bad. It's easy to remove or comment out, and when that is done it can be 
possible to erase certain bad blocks.

I say certain, because in my experience there seem to be two types of bad 
blocks.

One I would term 'soft' bad blocks, because after erasure, they 
behave just like good blocks, except that there's probably some region of 
them that is not up to spec. For the 1-2 Gb SLC flashes I have 
experience with, 'soft' bad blocks look like good blocks, except for 
the bad block markers. The main area of the flash is all 0xff, and I can't 
remember if the whole OOB is usually 0x00, or it is just the bad block 
marker byte(s).

The other I would term 'hard' bad blocks. They read as 0x00 (although one 
never gets a read error) and attempting to erase them has no effect. (I 
can't remember if the erase procedure terminates with an error or not).

Because of these different properties, my speculation is that 'hard' bad 
blocks are marked bad during actual chip manufacture, by actually 
disconnecting that block from the rest of the chip, whereas 'soft' bad 
blocks are determined by performance testing after chip manufacture.

As I said I can't remember if erasing or writing to 'hard' bad blocks 
results in an error, but it would not seem unlikely. Writing or erasing 
'soft' bad blocks works just like with the good blocks.

> Should I try making a version of nand_bbt.c for the more generic case?

I'm still trying to figure out exactly what your driver does. Normally one 
would write a driver which would interface with the rest of the NAND 
framework, which can be a relatively small driver as it basically just has 
to implement a couple of functions: a command function to send commands to 
the flash, and a wait function to wait for the flash to become ready. Even 
the data transfer can be handled by the NAND framework if it can be done 
via an 8-bit port associated with a memory address.

If the hardware you have is more complex, or does more work itself (for 
instance, has a DMA for data transfer, or does its own ECC management), 
the resulting board driver will be more complex too, and you sometimes 
have to jump through loops to get interact with the NAND framework, as it 
was originally based on a relatively basic interface, with additional 
parts to handle hardware ECC tacked on afterwards.

/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