Paul Fertser wrote: > Is it supposed to be compatible with GTA01? Probably almost.
Yes, NUM_BLOCKS should be different and the comment about the ECC layout would be wrong, but I think that's all. > Thinking about this a bit more i think that "scrub" is on over-kill to > the problem of write without flash_eraseall. Yeah, it has much of the ruggedly pragmatic simplicity of dynamite fishing ;-) > If kernel marks those bad > blocks only in BBT, then probably the most easiest way is to sync BBT > contents to the OOB data I wouldn't even look at the OOB data and just work on the BBT: if you're in the process of recovering from a nandwrite -m disaster, any block that is marked as worn-out is probably just incorrectly marked. As you've written, you can always clean up with nandtest or similar. However, there's the little problem of the MTD user space API fiercely defending the BBT against getting erased ... > 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). Yup, good point about Qi. But propagating worn-out blocks from BBT to OOB during this sort of recovery isn't enough, because not everyone will have made a recovery and blocks can go bad also after it. Seems that Qi really has to use the BBT to skip bad blocks when reading :-( > This whole NAND business is a complex mess :-/ Yeah :-( - Werner
