Re: Questions about ubifs,ubi and mtd?

[Steve deRosier <derosier@xxxxxxxxx>]

On Thu, Dec 13, 2018 at 3:36 AM Richard Weinberger <richard@xxxxxx> wrote:
>
> Hello Katsuaki Takei,
>
> Am Donnerstag, 13. Dezember 2018, 11:45:36 CET schrieb 武井 克明:
> > Dear Richard,
> >
> > We appreciate your precious advice.
> > We understood the quality status of kernel 3.2.26.
> > From now on, we would like to backport from the latest UBI and UBIFS.
> > Do you think that it is enough to backport the next part?
> >  - drivers/mtd
> >  - drivers/mtd/ubi
> >  - fs/ubifs
>
> Under the assumption that the root of the problem is the MTD/UBI stack,
> your problem should go away.
>

Katsuaki Takei,

Note that the MTD/UBI stack being at fault is an assumption. There's
other things that might be at fault, and in my experience, you usually
have multiple problems that all need to be solved.  Here's some other
possible issues (might not be everything):

1. Does your hardware work? Are you meeting all the setup and hold
times on all signals at all times.
2. Does the driver work? Could be a bug, especially a subtle one where
it usually works fine, but a missed command makes it unstable.
3. Does the rest of the MTD/UBI stack work?
4. Is your ECC on the NAND setup right and working?
5. Does whatever hardware or software you're using calculate the ECC
bits correctly? For example, on some Atmel processors, there's a bug
in the in-ROM PMECC algos so updated software does it in software
instead of using the ROM code, but older bootstraps used the ROM algo
and thus were bugged.
6. Are you flashing your NAND base image correctly (including getting
all the ECC bits in the right place and correct)?
7. When you flash updated images, is that done correctly?
8. During your writing of the filesystem that goes bad, do you write
it correctly and sync after each write? Note that 0-size files when
you know you wrote something is a key indicator of this problem.
9. When erasing the NAND, you do retain and honor the bad-block markers, yes?

Only if the problem's root is in cases 2 and 3 will backporting
patches even help. And for the driver case, only if the relevant fix
is there.

(getting on my soapbox)
IMHO, the effort to backport the entire subsystem from HEAD will
actually be more effort than just upgrading your kernel to the most
recent LTS kernel. It is exceptionally rare that a kernel _can't_ be
upgraded, so it's likely more correct in referring to not wanting to
or your bosses not wanting you to, or not understanding how to upgrade
the kernel. And in any case, even _can't_ is an artificial existence
caused by external forces (loosing certifications or similar) and can
always be overcome. But doing so is an engineering tradeoff either
way. Staying on a kernel that is seven years old is a huge risk.
Upgrading your kernel is a huge benefit in security and bug fixes. But
more than that, once you get current (and it is a big effort), you can
simply stay current and everything gets easier going forward from
there. You end up leveraging all the work the community does in giving
you one of the highest quality and most complex code bases anywhere.
(stepping off)

In any case, I highly recommend you check all the other things too.
You might have multiple problems, and some of them may be easy to fix.

Good luck,
- Steve

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