Destructive nandtest?

Destructive nandtest?

[Rostislav Lisovy]

Hello;
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.

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).
All this described behavior was discovered after long hours of analyzing
different nanddumps.

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.

Best regards;
Rostislav Lisovy

Re: Destructive nandtest?

[Brian Norris]

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

Re: Destructive nandtest?

[Rostislav Lisovy]

Hello Brian;
Thanks for your reply.

On Út, 2014-09-16 at 12:26 -0700, Brian Norris wrote:
> 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.

I have some proof-of-concept code that does store the OOB (and restores
it later) and is able to distinguish if the page is erased or not (in a
bit naive manner -- if the page is all 0xff and particular ECCs as well)
and decide is the data should be restored or not.
I hope I will be able to post the code soon.

Best regards;
Rostislav

Re: Destructive nandtest?

[Artem Bityutskiy]

On Wed, 2014-09-17 at 17:31 +0200, Rostislav Lisovy wrote:
> I have some proof-of-concept code that does store the OOB (and
> restores
> it later) and is able to distinguish if the page is erased or not (in
> a
> bit naive manner -- if the page is all 0xff and particular ECCs as
> well)
> and decide is the data should be restored or not.
> I hope I will be able to post the code soon.

Ideally, the relevant pieces of code should be shared between nanddump,
nandwrite, and nanttest.

-- 
Best Regards,
Artem Bityutskiy