RE: Questions about ubifs,ubi and mtd?

[Katsuaki Takei/OKI/JP <takei744@xxxxxxx>]

Dear Steve,

 I am very thankful for your advice.
 I would like to read your advice carefully, understand what to do and respond.

Best ragards,
Katsuaki Takei/Oki Electric Industry Co., Ltd./JP


> -----Original Message-----
> From: Steve deRosier <derosier@xxxxxxxxx>
> Sent: Friday, December 14, 2018 2:19 AM
> To: 武井 克明 <takei744@xxxxxxx>
> Cc: linux-mtd@xxxxxxxxxxxxxxxxxxx; Richard Weinberger <richard@xxxxxx>
> Subject: Re: Questions about ubifs,ubi and mtd?
> 
> 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/