All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve deRosier <derosier@gmail.com>
To: Leon Pollak <leon.pollak@gmail.com>
Cc: Richard Weinberger <richard.weinberger@gmail.com>,
	linux-mtd@lists.infradead.org
Subject: Re: UBIFS on write-protected NAND
Date: Mon, 3 Jun 2019 05:32:53 -0700	[thread overview]
Message-ID: <CALLGbRJRLoEPW4dTVCvjp7qBDXEefjBTT4_731m_9XD=KgH8Cw@mail.gmail.com> (raw)
In-Reply-To: <CAM===sSzy4=joOnzLxbSDoC=4HgmXj7QF14vzFCKTWt8z-JLoA@mail.gmail.com>

Hi Leon,

On Mon, Jun 3, 2019 at 12:31 AM Leon Pollak <leon.pollak@gmail.com> wrote:

> > Using a write protected NAND is not recommend.
> > You basically remove the wear-leveling feature from UBI.
> > Blocks can gain bit-flips also in a read-only environment, consider
> > read disturb or other influences such as temperature changes.
> Well, as I said, these NAND is updated not more than 30-40 times in
> all its life.
> So, wear-leveling is not so relevant.
> May be this is relics of the NOR past, but our HW engineers always
> keep flashes write-protected to be on the safe side and avoid possible
> false writes/disturbances/problems at the power spikes.
> The main goal here is to keep the system bootable despite everything
> in the world, except nuclear explosion...:-)
>

Your HW engineers are wrong and did not read and _understand_ the NAND
datasheets. Nor do they understand the software and what it does. The
days of the HW guy designing something and throwing it over the wall
and asking the SW guy to make it work are long over.

If you want NAND to stay bootable "despite everything in the world",
you can't run it write protected. NAND will bit-rot over time. It is
the nature of NAND. UBIFS detects this and will move data around as
necessary to keep it readable. There are certain areas that really
only get read at boot time, so if it's write protected at that point,
you're sunk - UBIFS can't do the work of preserving the NAND that it
is designed to do.

If it were me, in u-boot (or whatever bootloader you're using), I'd
flip the GPIO holding the /WP line to make the NAND writable before I
booted the kernel and then I'd leave it there.

The other way requires more effort - you could go into your NAND
driver, find the low-level write sequences and flip the GPIO to write
and close it to protect after you're done. But, pay very close
attention to your datasheets to be sure you have your setup and hold
times correct if you're going to do that.

The final way to do it is to not use UBIFS at all.  Run a R/O image
like squashfs and run the NAND with way higher ECC than required and
hope that over the lifetime of the device you don't accumulate more
than that bit-flips in any sector that you care about.

- Steve

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  parent reply	other threads:[~2019-06-03 12:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-02 14:08 UBIFS on write-protected NAND Leon Pollak
2019-06-02 20:02 ` Richard Weinberger
2019-06-03  7:31   ` Leon Pollak
2019-06-03 11:11     ` Leon Pollak
2019-06-03 11:31       ` Richard Weinberger
2019-06-03 12:32     ` Steve deRosier [this message]
2019-06-03 12:58       ` Richard Weinberger

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='CALLGbRJRLoEPW4dTVCvjp7qBDXEefjBTT4_731m_9XD=KgH8Cw@mail.gmail.com' \
    --to=derosier@gmail.com \
    --cc=leon.pollak@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard.weinberger@gmail.com \
    /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.