Back up of the "Factory Bad Block Table" BBT, needed or a waste of time?

Harald Welte laforge at
Sun Jul 29 19:10:40 CEST 2007

On Sun, Jul 29, 2007 at 05:26:06PM +0200, Visti Andresen wrote:

> > > and inside the bad block table (BBT), I guess that the BBT isn't located 
> > > inside the 4. partition and therefor not backed up?
> > >
> > 
> > well, technically it is in the rootfs partition... but in blocks that
> > are marked as bad blocks ;) so depending on the method of your backup,
> > you will either have it or not.
> I suppose it is marked as a bad block inside JFS2?

jffs2 uses mtd, which in turn uses the bbt

> Should I go look for the OOB special markers (BBT0/BBT1)?
> or can I simply look for 
> "the last two good blocks at the end of NAND" as suggested by:

the OOB special markers are definitely the way more reliable method.
the last two blocks of NAND is misleading, since those last two could be
_real_ bad blocks, and the BBT thus in the previous blocks.

using the same algorithm like the mtd code makes sense:  Start from the
end of the device backwards and look for the OOB special markers.

> I'm currently experimenting with creating a program that reads the
> "Bad Block Table".  It also seams I can get a list of bad nand blocks
> using the "nand bad" u-boot command

yes, you can get the list from 'nand bad'.  However, that list will only
provide 1 bit information (bad/non-bad) whereas the actual BBT uses 2
bit per block (good/factory bad/wear-out bad).

> I was thinking more along the lines of, if they were writing it with bit patterns
> like memtest86 to detect the bad blocks.

unfortunately this is not a reliable method to detect factory-marked bad
blocks.  Those blocks might work just fine, but e.g. lose their
information later on.  Or only work for way less erase cycles than other

I'd recommend googling for some general information on NAND before
implementing such algorithms (based on wrong assumptions).
> If they were probing the values of the ones and zeros to determine a 
> statistical probability that the cell is faulty.

there really is no method, sorry.

> The data sheet don't tell how they do it, so I'm assuming you don't
> know either...

you cannot do it by software. you have to do actualy (I guess even
analogue) measurements on the cells.

> It seems that the factory bad block info is located in the sixth OOB byte
> in the first or second page of a nand block.
> Any non 0xff values marks the block as bad.
> I'm updating the bad block wiki to include this info...
> Please correct me if I'm wrong.

that's correct.  however, you can easily erase the OOB area of a bad
block, resulting with that byte becoming 0xff ;)
- Harald Welte <laforge at>         
Software for the world's first truly open Free Software mobile phone

More information about the community mailing list