All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Scian <rnd4@dave-tech.it>
To: "Jeff Lauruhn (jlauruhn)" <jlauruhn@micron.com>,
	Andrea Marson - DAVE Embedded Systems <andrea.marson@dave.eu>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>,
	"dedekind1@gmail.com" <dedekind1@gmail.com>,
	mtd_mailinglist <linux-mtd@lists.infradead.org>,
	Richard Weinberger <richard@nod.at>
Subject: Re: RFC: detect and manage power cut on MLC NAND
Date: Tue, 17 Mar 2015 09:00:39 +0100	[thread overview]
Message-ID: <5507DF27.7050300@dave-tech.it> (raw)
In-Reply-To: <0D23F1ECC880A74392D56535BCADD7354973DFE3@NTXBOIMBX03.micron.com>


Dear Jeff,

Il 16/03/2015 17:02, Jeff Lauruhn (jlauruhn) ha scritto:
> "What if it is set low while NAND is ready - that is it can accept new commands - but an erase operation is in progress?".  Again, the likelihood is low, in this case a block that was intended to be erased my not be fully erase, it can be fully erased when power returns.  No data will lost because the block was intended to be erased anyway. 

AFAIK the real problem here is how to detect that the in-progress erase
has not been terminated completely
The block seems to be erased (it contains all 0xFF) but it can lead to
some failure when writing or reading
(I have some indirect experience in it, when doing some power-cut test
on MLC but I cannot say for sure that it was caused by not completed
erase operation. See also this reference
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits)

> "Does the erase operation complete anyway?"  There has been a lot of work done to mitigate power loss on NAND, but I haven't ever seen a design from any NAND vendor that is 100%.  Surprise power loss should be avoided on NAND or consider power detection and elegant shutdown circuitry.

IIUC we have two workaround here:
- power detection and clean shutdown. This implies, of course, some
hardware implementation and a piece of software able to intercept the
hardware event, block all the NAND operation apart the one that is
currently running. This is the topic of my initial RFC. I got a first
implementation but, IMHO, is too strictly related to the NAND controller
(I've placed the event handler inside it and just lock the NAND access
by hacking chip->select_chip())
I think that power fail detection can be useful in some other context
too inside Linux kernel, so probably it may have a more general
implementation. However (and unfortunately) I'm not so involved in
mainline kernel so I don't really know if this topic has been discussed
or not

- detection of interrupted operations: having some kind of journal that
record the last running operation and fix it on next reboot. AFAIK this
is what commercial FTL and flash memory controller do, using a lot of
patented piece of software.
I'm not so aware of UBI/MTD internals but I think this is hard to
implement using a general approach. It should be easier to implement
such a logic having some additional hardware support (the first that
come into my mind is battery backed SRAM, e.g. the one that we find
inside RTC devices)

Best Regards,

-- 

Andrea SCIAN

DAVE Embedded Systems

  reply	other threads:[~2015-03-17  8:01 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-10 11:57 RFC: detect and manage power cut on MLC NAND Andrea Scian
2015-03-10 12:51 ` Richard Weinberger
2015-03-11  7:20   ` Artem Bityutskiy
2015-03-11  8:57     ` Richard Weinberger
2015-03-11  9:05       ` Artem Bityutskiy
2015-03-11  9:09         ` Richard Weinberger
2015-03-11 17:01           ` Andrea Scian
2015-03-11 17:23             ` Jeff Lauruhn (jlauruhn)
2015-03-11 17:29               ` Richard Weinberger
2015-03-11 21:16                 ` Jeff Lauruhn (jlauruhn)
2015-03-12 10:28                   ` Richard Weinberger
2015-03-12 22:57                     ` Jeff Lauruhn (jlauruhn)
2015-03-13 20:31                       ` Boris Brezillon
2015-03-13 23:51                         ` Jeff Lauruhn (jlauruhn)
2015-03-14  9:46                           ` Andrea Marson - DAVE Embedded Systems
2015-03-16 16:02                             ` Jeff Lauruhn (jlauruhn)
2015-03-17  8:00                               ` Andrea Scian [this message]
2015-03-14 10:32                           ` Boris Brezillon
2015-03-16 21:11                             ` Jeff Lauruhn (jlauruhn)
2015-03-17  9:30                               ` Andrea Scian
2015-03-17 10:02                                 ` Boris Brezillon
2015-03-17 16:42                                   ` Jeff Lauruhn (jlauruhn)
2015-03-18  8:45                                     ` RFC: detect and manage power cut on MLC NAND (linux-mtd Digest, Vol 144, Issue 70) Andrea Marson
2015-03-18  9:07                                       ` Boris Brezillon
2015-03-18  9:56                                         ` Andrea Marson
2015-03-18 10:03                                           ` Boris Brezillon
2015-03-18 12:07                                         ` Richard Weinberger
2015-03-18 17:11                                           ` Jeff Lauruhn (jlauruhn)
2015-03-18 16:12                                       ` Jeff Lauruhn (jlauruhn)
2015-03-19  8:47                                         ` RFC: detect and manage power cut on MLC NAND Andrea Marson
2015-03-19  9:12                                           ` Boris Brezillon
2015-03-19 17:45                                             ` Jeff Lauruhn (jlauruhn)
2015-03-20  0:25                                             ` Iwo Mergler
2015-03-20  3:38                                               ` nick
2015-03-20  5:40                                                 ` Iwo Mergler
2015-03-20  8:26                                               ` Boris Brezillon
2015-03-20 17:15                                                 ` Nick Krause
2015-03-22 23:45                                                 ` Iwo Mergler
2015-03-23  2:18                                                 ` Iwo Mergler
2015-03-23  7:06                                                   ` Artem Bityutskiy
2015-03-23 19:05                                                     ` Boris Brezillon
2015-03-24  7:05                                                       ` Artem Bityutskiy
2015-03-19 18:00                                           ` Jeff Lauruhn (jlauruhn)
2015-03-20  8:07                                             ` Andrea Marson
2015-03-17 17:04                                 ` Jeff Lauruhn (jlauruhn)
2015-03-16  9:01                         ` Ricard Wanderlof
2015-03-16 17:27                           ` Jeff Lauruhn (jlauruhn)
2015-03-14 10:03                       ` Richard Weinberger
2015-03-12  9:32               ` Ricard Wanderlof
2015-03-23  4:08           ` Iwo Mergler
2015-03-23 21:15             ` Jeff Lauruhn (jlauruhn)
2015-03-24  1:17               ` Iwo Mergler
2015-03-24 16:50                 ` Jeff Lauruhn (jlauruhn)
2015-03-25  3:38                   ` Iwo Mergler
2015-03-25  8:33                     ` Ricard Wanderlof
2015-03-26  1:57                       ` Jeff Lauruhn (jlauruhn)
2015-03-26  8:55                         ` Ricard Wanderlof
2015-03-11  7:21 ` Artem Bityutskiy
  -- strict thread matches above, loose matches on Subject: below --
2015-03-12 10:31 Andrea Marson - DAVE Embedded Systems
     [not found] <mailman.37176.1426610573.22890.linux-mtd@lists.infradead.org>

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5507DF27.7050300@dave-tech.it \
    --to=rnd4@dave-tech.it \
    --cc=andrea.marson@dave.eu \
    --cc=boris.brezillon@free-electrons.com \
    --cc=dedekind1@gmail.com \
    --cc=jlauruhn@micron.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.