[PATCH 0/8] Qi solve GTA02 dynparts compatability and parse idenity partition

Paul Fertser fercerpav at gmail.com
Thu Feb 5 09:30:29 CET 2009


Werner Almesberger <werner at openmoko.org> writes:
> I wrote:
>> Anyway, my plan is to hack a NAND badness dumper. That will tell if
>> a device can be safely "scrubbed". For those that can't, a bit more
>> work is needed.
>
> Done:
> http://svn.openmoko.org/developers/werner/badnand/
>
> Invoke with
> badnand /dev/mtd6
>
> If it reports 0 factory-bad blocks, then it's safe to "scrub" the
> NAND.

Cool :)

Is it supposed to be compatible with GTA01? Probably almost.

Thinking about this a bit more i think that "scrub" is on over-kill to
the problem of write without flash_eraseall. If kernel marks those bad
blocks only in BBT, then probably the most easiest way is to sync BBT
contents to the OOB data (as we will have some nasty effects with
worn-out blocks anyway, they will be detected again pretty soon). I
think even nandwrite with proper parameters and file can used to
"reset" BBT. Then nandtest will perform tests, hopefully find all the
bad blocks and write new proper BBT. Or your utility can be a bit
extended to just mark bad in BBT the blocks that are bad in OOB.

On the other hand, really dedicated (to NAND breakage) user can use
nandwrite to mess with factory OOB data... In this case probably one
needs to reset BBT, use nandtest to find all blocks that are really
bad, then sync from BBT to per-block OOB (or else Qi won't know about
bad blocks, as it uses OOB).

This whole NAND business is a complex mess :-/ I might be
misunderstanding something again.

Thank you for your efforts!

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav at gmail.com




More information about the openmoko-kernel mailing list