All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard.weinberger@gmail.com>
To: Leon Pollak <leon.pollak@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBIFS on write-protected NAND
Date: Sun, 2 Jun 2019 22:02:31 +0200	[thread overview]
Message-ID: <CAFLxGvymOZbBM=wtK-fcgYOv7OOucpcZ1eZJ9GQmUH8h9Jcc+Q@mail.gmail.com> (raw)
In-Reply-To: <CAM===sSAP-qRv7jxBs9KZDFyuL+Dx3wSkQfSOiSQtp8Z8FQcMw@mail.gmail.com>

On Sun, Jun 2, 2019 at 4:08 PM Leon Pollak <leon.pollak@gmail.com> wrote:
>
> I am sorry to disturb the list with the problem most probably already
> solved ion later versions...
>
> I am running Linux 2.6.32 from TI and my root FS is on NAND UBIFS.
> Linux boots with command line:
> root=ubi0:ubi_rootfs ro noinitrd ubi.mtd=4,2048 rootfstype=ubifs
> Please, note the "ro" in the command line.
> Also the HW write-protect line is always set to "protected" state.
> UBIFS stays most of the time in write protected HW state (system
> requirement) and RO mounted, except the very rare cases when some
> update is required.
>
> For this update purpose:
> - HW write-protect is removed in SW;
> - root FS is remounted to RW (mount -o remount,rw /);
> - the change is performed;
> - sync, sleep 3;
> - mount -o,remount,ro / ;
> - sleep 2, return HW write-protection;
> - reboot.
>
> For some unknown reason (may be you know?), sometimes something still
> remains in journal and on the next boot we receive a bundle of error
> messages with error codes -5 and -30. This happens despite the RO

More details please. Can you share a full back trace?

But in general a re-mount to ro does not guarantee a clean journal.
All it does is making sure that no new files can be opened in write-mode,
it is a VFS thing. UBIFS tries to be nice as possible and disables further
writes. Maybe your kernel has a bug, it is very old. Dunno...

> state of the FS and effectively blocks all the system:
> - after these errors detection, UBIFS switches to read-only state,
> blocking any possible corrections/repairs.
> - we can't remove HW protection to allow it to finish desired work as
> it happens in the Linux boot, when initd is just starting.
>
> Now, I suppose that this issue (that everything is RO and shouldn't be
> tried to recover) is treated already in the new versions. My problem
> is that I can't move to newer Linux because of TI HW.
>
> So, my questions are:
> 1. Where in the code of UBI (UBIFS?) can I insert the HW write-protect
> removal in order to allow the UBI/UBIFS to do its desired work?
> 2. When can I put write-protection back?

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.

-- 
Thanks,
//richard

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

  reply	other threads:[~2019-06-02 20:02 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 [this message]
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

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='CAFLxGvymOZbBM=wtK-fcgYOv7OOucpcZ1eZJ9GQmUH8h9Jcc+Q@mail.gmail.com' \
    --to=richard.weinberger@gmail.com \
    --cc=leon.pollak@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    /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.