Re: UBIFS on write-protected NAND

[Steve deRosier <derosier@xxxxxxxxx>]

Hi Leon,

On Mon, Jun 3, 2019 at 12:31 AM Leon Pollak <leon.pollak@xxxxxxxxx> 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/