Some questions on bit-flips and JFFS2

[Ricard Wanderlof]

On Wed, 12 May 2010, Thorsten Mühlfelder wrote:

>> I don't know if this is a good way, but you could patch your kernel so it
>> doesn't stop you from erasing/writing badblocks.
>
> So the only way to get bad blocks erased (scrubbed) in Linux is to have a
> patched kernel? This would be a problem, because I don't know any way of
> getting a new kernel to already deployed systems without deleting the Sam-ba
> bad blocks before.

Another option would be to write a kernel module that bypasses mtd. But 
the mtd write routine is very adament about not erasing bad blocks.

> So IMHO there are only 2 options:
> - Within a running Linux remove/erase all bad blocks from beginning of kernel
> image to end of the partition, test the erased area with nandtest and mark
> real bad blocks as bad, write the new kernel image to the right address again

Testing for bad blocks is something you can't do in practice on a device. 
At the factory, AFAIK, they perform bad blocks tests while operating the 
chip at the limits of its specification, to try and catch all blocks which 
are marginal. Testing if such a block is 'bad' in an existing system most 
often doesn't give the expected result. On our development boards, it 
happens sometimes that someone manages to erase the whole flash including 
bad block markers, we then routinely just assume all blocks are good which 
works well enough in the lab, although I would never sell a product with a 
flash that had been erased that way.

> - Or write some tool, that can distinguish between real bad blocks and the
> Sam-ba 2.5 created bad blocks, unmark the false bad blocks. But perhaps this
> is not possible at all.

It depends on how exactly Sam-ba 2.5 overwrites the existing bad block 
markers.

> Perhaps somebody knows where I can find detailed information about
> these "spare area bytes reserved to tag bad blocks"? As far as I understand

The nand flash data sheets from the manufacturers have information both on 
the memory array layout and how the bad blocks are marked.

> Is the OOB part of a page or does each page have an extra OOB (2048+64 bytes)?

The OOB (in this case) is an 'extra' 64 bytes per 2048 byte page.

> Is the OOB located at the beginning or at the end of each page?

Conceptually it is at the end, although it is normally accessed and read 
in a separate read operation. I think you can perform a sequential read on 
a nand flash which will read the page + oob in succession.

/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