Destructive nandtest?

Brian Norris computersforpeace at gmail.com
Tue Sep 16 12:26:10 PDT 2014


Hi,

On Tue, Sep 16, 2014 at 06:22:35PM +0200, Rostislav Lisovy wrote:
> I need to test a NAND flash on my embedded device running GNU/Linux.
> I thought the nandtest utility will work just fine, however I hit some
> unpleasant behavior.
> My requirement is to perform a non-destructive test. The nandtest
> utility seems to support it with the "-k, --keep  Restore existing
> contents after test" option, however the reality is different.
> The testing scenario (performed by the nandtest) is
> * Backup the original eraseblock (EB) data
> * Generate some random data
> * Erase the EB
> * Store the random data
> * Read the stored data and compare with the generated buffer
> * Erase the EB, Write the original content
> 
> Everything seems to make sense until we ask the question "what about the
> OOB data?". Is the original OOB data saved? The answer is: No, it is
> not.
> This will somehow work in cases the OOB stores only the ECC for the
> written pages -- if we read the page (OOB contains the ECC), erase the
> EB and then write the same page back, the OOB will once again contain
> the same ECC. What if there will be some "extra data" stored in the OOB
> (I think JFFS2 does this)? This data will be lost.

Right.

BTW, this may be acceptable for UBI-based systems, where OOB is never
used for metadata. But I agree it's broken in general.

> Another sneaky misbehavior is "restoring of erased pages". If the EB is
> erased (all 0xFF), the nandtest reads the "data stored in the EB",
> performs the tests and then restores the "data" back by filling all the
> pages with 0xFF -- this will not only fill the OOB with ECC for the
> newly written "data" but will deplete the "maximum per-page-write
> limit" (which is either 1x after each erase or more if the sub-page
> write is supported by the device).

Correct. That's the one I noticed most prominently, and I believe I've
seen a few others trip over this.

> All this described behavior was discovered after long hours of analyzing
> different nanddumps.

Sorry :(

> What do you think about the issue? Is this the "normal nanddump"
> behavior or a hidden fault? Do we need a new nandtest or at least remove
> the "-k, --keep  Restore existing contents after test" option?
> I will appreciate your thoughts.

All of your analysis looks accurate to me. Personally, I never used
'nandtest' much myself, because of glaring ommissions like you've
noticed. I wouldn't mind just dropping the '--keep' option, since it's a
lot of work to try to do correctly, and in its current state, it is
completely broken and misleading.

Brian



More information about the linux-mtd mailing list