All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Steve deRosier <derosier@gmail.com>
Cc: Richard Weinberger <richard.weinberger@gmail.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Leon Pollak <leon.pollak@gmail.com>
Subject: Re: UBIFS on write-protected NAND
Date: Mon, 3 Jun 2019 14:58:10 +0200 (CEST)	[thread overview]
Message-ID: <1496138474.79078.1559566690511.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <CALLGbRJRLoEPW4dTVCvjp7qBDXEefjBTT4_731m_9XD=KgH8Cw@mail.gmail.com>

----- Ursprüngliche Mail -----
> 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.

Amen. :-)

Thanks,
//richard

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

      reply	other threads:[~2019-06-03 12:58 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
2019-06-03 12:58       ` Richard Weinberger [this message]

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=1496138474.79078.1559566690511.JavaMail.zimbra@nod.at \
    --to=richard@nod.at \
    --cc=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.