Stomping bad block

[Jim Carter]

I have a Nokia 770 Internet Tablet with 128 Mb of NAND flash memory
containing the root filesystem etc. as JFFS2.  It's using kernel 2.6.16
for TI OMAP-1710 (ARM family).  I believe I have two adjacent bad bytes
(16 bits): the symptom is that every few months a system file (e.g.
/usr/lib/libopera.so) will turn up with an incorrect checksum from a
tripwire-type program I wrote, and plausibly related buggy behavior will
be seen (so far not fatal, cross fingers).  I use "od" on the desktop
machine to compare the file from the flash image with the file currently
on the Nokia 770, and I always find two adjacent bytes of 0.

At that point I use rsync -I to copy the image file to a temporary name
on the device, and it then renames the new instance replacing the
corrupt file, which then has no links and is removed (allocated blocks
abandoned).  My understanding is that the garbage collector would sooner
or later erase the abandoned erase blocks.  Then when new data was
written, or when old data was churned for wear leveling, a read check
would fail, and if this happened three times in succession, the block
would be marked bad permanently.

But the bad erase block is still in service.  My guess is that upon 
rewriting it can be read-checked without errors, but after some time 
passes, seconds to weeks, the bits return to zero.  How could I stomp this 
block manually?  I think the answer will have two parts: how do I translate 
an offset in a JFFS2 file to an erase block number, and what do I do once I 
have this number (i.e. how do I alter the out of band byte 5)?


James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc at math.ucla.edu  http://www.math.ucla.edu/~jimc (q.v. for PGP key)