RFC: detect and manage power cut on MLC NAND
Hi Jeff,
thank you for your availability. I'd really love to discuss in more detail these matters.
About Write Protect (WP) pin, IIUC it must respect several constraints. For example it must not be transitioned while NAND is busy. What if it is set low while NAND is ready - that is it can accept new commands - but an erase operation is in progress? Does the erase operation complete anyway?
Andrea Marson
*DAVE Embedded Systems*
Quoted 82 lines
Power loss is actually very complex. The Write Protect (WP) pin was added = to NAND help lock the NAND when a power loss event is detected. I have ext= ensive information on NAND and would be happy to discuss. =20
Jeff Lauruhn
NAND Application Engineer
Embedded Business Unit
Micron Technology, Inc-----Original Message-----
From: linux-mtd [mailto:[email protected]] On Behalf Of=
Andrea Scian
Sent: Wednesday, March 11, 2015 10:01 AM
To: Richard Weinberger; [email protected]
Cc:mtd_mailinglist
Subject: Re: RFC: detect and manage power cut on MLC NANDHi all,
and thanks for you feedback.
You can find my comments below.Il 11/03/2015 10:09, Richard Weinberger ha scritto:
Quoted 8 lines
Am 11.03.2015 um 10:05 schrieb Artem Bityutskiy:
Quoted 7 lines · Richard Weinberger
Quoted 6 lines
Hi!
Am 11.03.2015 um 08:20 schrieb Artem Bityutskiy:
Quoted 3 lines · Richard Weinberger
Quoted 2 lines
Quoted 2 lines
WDYT about this?
If it sounds reasonable is there any suggestion where to place such =a code?
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Customers often use DYI uninterruptible power supplies using capacito=
rs.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
But managing a power cut is the least problem you have with MLC NAND.
Why is it the least problem, what is the hardest one? I thought=20 this one is the hardest.
IMHO the hardest ones are the problems we don't know yet as NAND=20 vendors are not really chatty about the MLC constraints. We don't know much about data retention for example. At least we=20 have not much hard facts. Most of our knowledge is hearsay.
Quoted 6 lines
Quoted 4 lines
Well, but from the problems we know paired pages seems to be the=20 biggest one. E.g., what do we do if VID header gets corrupted because=20 of an interrupted write to the page paired with the VID header page?=20 Sounds like a hard problem to me.
It is a hard problem. But at least we know about it.
IIUC can I summarize like the following
1) power cut is one of the big problem we know about MLC NAND flash with UB= I
2) we are unaware of other big issue with MLC NANDUnfortunately I don't really know the MTD/UBI/UBIFS internals but (correct = me if I'm wrong) to me solving the power cut issue only by software (by usi= ng proper data structure, redundancy, NAND flash operation jornal and so on= ) is pretty hard to implement inside the Linux MTD stack.
On the other hand, stuff like scrubbing (e.g. having a task like GC that pe= riodically scrub the required NAND erase block), paired page (e.g. carefully selecting LEB to PEB mapping to avoid reading/writing data into p= aired page in a wrong way) are still to be implemented but have, somehow, l= ess impact on the whole MTD stack.
For sure I'm missing some other MLC NAND issue, but the above are the one t= hat I'm aware of.
WDYT?
Best Regards,
--=20
Andrea SCIAN
DAVE Embedded Systems