Re: UBIFS on write-protected NAND

[Leon Pollak <leon.pollak@xxxxxxxxx>]

Thank you, Richard.

On Sun, 2 Jun 2019 at 23:02, Richard Weinberger
<richard.weinberger@xxxxxxxxx> wrote:
>
> On Sun, Jun 2, 2019 at 4:08 PM Leon Pollak <leon.pollak@xxxxxxxxx> 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?
This is an example:
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB
1600:2048, written 0 bytes
UBI: run torture test for PEB 1600
UBI error: do_sync_erase: cannot erase PEB 1600, error -5
UBI error: erase_worker: failed to erase PEB 1600, error -5
UBI: mark PEB 1600 as bad
UBI error: ubi_io_mark_bad: cannot mark PEB 1600 bad, error -30
UBI warning: ubi_ro_mode: switch to read-only mode
UBI error: do_work: work failed with error code -30
UBI error: ubi_thread: ubi_bgt0d: work failed with error code -30


> 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...
OK, I understand. Is there any way to flush ALL data?
If "sync" and "ro" doesn't do the job, is there something more? Some IOCTL?...
Solving this issue will be the best possible for us.

> > 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.
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...:-)

Thank you for your help!

Leon

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