Questions about ubifs,ubi and mtd?

Questions about ubifs,ubi and mtd?

[武井 克明]

Hi all,

We are developing the product using file system using ubi, ubifs on hardware with NAND flash memory.

Although the development of the product was completed, we are seeking your help as the customer who is using it is having trouble with it.

The product we have developed has 6 MTD partitions for NAND flash memory.
These consist of 6 MTDs named 'kernel-a' 'kernel-b', 'rootfs-a', 'rootfs-b', 'data-1', 'data-2', and online program only accesses 'data-1' and 'data-2' for write access.
Nevertheless, when loading our program from 'rootfs-a', trying to read the inode with the ubifs_read_node() function will result in "bad node type" (ex: 193 but expected 9) and the LEB can not be read with the expected value. (Even though you do not have write access to rootfs)
In addition, the file size may be 0 byte in some cases.

Is there anyone who encountered such a problem? Is there patch?

Please let me know, if you have any questions.

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

Re: Questions about ubifs,ubi and mtd?

[Richard Weinberger]

On Tue, Dec 11, 2018 at 3:09 PM 武井 克明 <takei744@oki.com> wrote:
>
> Hi all,
>
> We are developing the product using file system using ubi, ubifs on hardware with NAND flash memory.
>
> Although the development of the product was completed, we are seeking your help as the customer who is using it is having trouble with it.
>
> The product we have developed has 6 MTD partitions for NAND flash memory.
> These consist of 6 MTDs named 'kernel-a' 'kernel-b', 'rootfs-a', 'rootfs-b', 'data-1', 'data-2', and online program only accesses 'data-1' and 'data-2' for write access.
> Nevertheless, when loading our program from 'rootfs-a', trying to read the inode with the ubifs_read_node() function will result in "bad node type" (ex: 193 but expected 9) and the LEB can not be read with the expected value. (Even though you do not have write access to rootfs)
> In addition, the file size may be 0 byte in some cases.
>
> Is there anyone who encountered such a problem? Is there patch?

Well, are you using a recent kernel?

RE: Questions about ubifs,ubi and mtd?

[武井 克明]

Dear Richard,
 Thank you for your comment.
 We are using kernel 3.2.26 for reasons.
 I can not update the kernel right now.

To everyone
Is there a lot of fixes and patches for processing that causes abnormal behavior as I asked you?
We hope to solve the problem by patch to kernel 3.2.26. if possible.
Shyly, I have little experience of developing ubifs or ubi, and I can not yet figure out which program is likely to be involved in this abnormal operation(ref. Note*).

Note*:
Nevertheless, when loading our program from 'rootfs-a', trying to read the inode with the ubifs_read_node() function will result in "bad node type" (ex: 193 but expected 9) and the LEB can not be read with the expected value. (Even though you do not have write access to rootfs) In addition, the file size may be 0 byte in some cases.

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


> -----Original Message-----
> From: Richard Weinberger <richard.weinberger@gmail.com>
> Sent: Wednesday, December 12, 2018 2:10 AM
> To: 武井 克明 <takei744@oki.com>
> Cc: linux-mtd@lists.infradead.org
> Subject: Re: Questions about ubifs,ubi and mtd?
> 
> On Tue, Dec 11, 2018 at 3:09 PM 武井 克明 <takei744@oki.com> wrote:
> >
> > Hi all,
> >
> > We are developing the product using file system using ubi, ubifs on hardware
> with NAND flash memory.
> >
> > Although the development of the product was completed, we are seeking
> your help as the customer who is using it is having trouble with it.
> >
> > The product we have developed has 6 MTD partitions for NAND flash
> memory.
> > These consist of 6 MTDs named 'kernel-a' 'kernel-b', 'rootfs-a', 'rootfs-b',
> 'data-1', 'data-2', and online program only accesses 'data-1' and 'data-2' for
> write access.
> > Nevertheless, when loading our program from 'rootfs-a', trying to read
> > the inode with the ubifs_read_node() function will result in "bad node type"
> (ex: 193 but expected 9) and the LEB can not be read with the expected value.
> (Even though you do not have write access to rootfs) In addition, the file size
> may be 0 byte in some cases.
> >
> > Is there anyone who encountered such a problem? Is there patch?
> 
> Well, are you using a recent kernel?

Re: Questions about ubifs,ubi and mtd?

[Richard Weinberger]

Hello Katsuaki Takei,

Am Mittwoch, 12. Dezember 2018, 02:07:33 CET schrieb 武井 克明:
> Dear Richard,
>  Thank you for your comment.
>  We are using kernel 3.2.26 for reasons.
>  I can not update the kernel right now.

3.2.x is dead.
It contains bugs, security problems, is unmaintained, etc...
Shipping with 3.2.x is a very bad idea.
 
> To everyone
> Is there a lot of fixes and patches for processing that causes abnormal behavior as I asked you?
> We hope to solve the problem by patch to kernel 3.2.26. if possible.
> Shyly, I have little experience of developing ubifs or ubi, and I can not yet figure out which program is likely to be involved in this abnormal operation(ref. Note*).
> 
> Note*:
> Nevertheless, when loading our program from 'rootfs-a', trying to read the inode with the ubifs_read_node() function will result in "bad node type" (ex: 193 but expected 9) and the LEB can not be read with the expected value. (Even though you do not have write access to rootfs) In addition, the file size may be 0 byte in some cases.

The problem could be anything.
Both UBI and UBIFS faced tons of fixes over the last years.
Maybe it is also bug somewhere else.

You could try backporting the whole UBI and UBIFS subsystems to your kernel.

Thanks,
//richard

RE: Questions about ubifs,ubi and mtd?

[武井 克明]

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

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


> -----Original Message-----
> From: Richard Weinberger <richard@nod.at>
> Sent: Wednesday, December 12, 2018 6:20 PM
> To: 武井 克明 <takei744@oki.com>; linux-mtd@lists.infradead.org
> Subject: Re: Questions about ubifs,ubi and mtd?
> 
> Hello Katsuaki Takei,
> 
> Am Mittwoch, 12. Dezember 2018, 02:07:33 CET schrieb 武井 克明:
> > Dear Richard,
> >  Thank you for your comment.
> >  We are using kernel 3.2.26 for reasons.
> >  I can not update the kernel right now.
> 
> 3.2.x is dead.
> It contains bugs, security problems, is unmaintained, etc...
> Shipping with 3.2.x is a very bad idea.
> 
> > To everyone
> > Is there a lot of fixes and patches for processing that causes abnormal
> behavior as I asked you?
> > We hope to solve the problem by patch to kernel 3.2.26. if possible.
> > Shyly, I have little experience of developing ubifs or ubi, and I can not yet
> figure out which program is likely to be involved in this abnormal operation(ref.
> Note*).
> >
> > Note*:
> > Nevertheless, when loading our program from 'rootfs-a', trying to read the
> inode with the ubifs_read_node() function will result in "bad node type" (ex: 193
> but expected 9) and the LEB can not be read with the expected value. (Even
> though you do not have write access to rootfs) In addition, the file size may be 0
> byte in some cases.
> 
> The problem could be anything.
> Both UBI and UBIFS faced tons of fixes over the last years.
> Maybe it is also bug somewhere else.
> 
> You could try backporting the whole UBI and UBIFS subsystems to your kernel.
> 
> Thanks,
> //richard
> 

Re: Questions about ubifs,ubi and mtd?

[Martin Lund]

On Thu, Dec 13, 2018 at 11:45 AM 武井 克明 <takei744@oki.com> wrote:
>
> 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
>

I recommend you first take a close look at the git history of Linux
3.2.26 and onward to see if there are any immediate UBI/UBIFS fixes
available that might relate/solve the issue you are seeing. It might
be an easier path than jumping into a big task like back porting
latest UBI/UBIFS to such an old kernel.

/Martin

Re: Questions about ubifs,ubi and mtd?

[Richard Weinberger]

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.

Thanks,
//richard

Re: Questions about ubifs,ubi and mtd?

[Richard Weinberger]

Martin,

Am Donnerstag, 13. Dezember 2018, 12:32:43 CET schrieb Martin Lund:
> On Thu, Dec 13, 2018 at 11:45 AM 武井 克明 <takei744@oki.com> wrote:
> >
> > 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
> >
> 
> I recommend you first take a close look at the git history of Linux
> 3.2.26 and onward to see if there are any immediate UBI/UBIFS fixes
> available that might relate/solve the issue you are seeing. It might
> be an easier path than jumping into a big task like back porting
> latest UBI/UBIFS to such an old kernel.

Given the age of this kernel it will be massive pain in any case.
Digging through the history, identifying and backporting fixes sounds
more easier than it actually is.
Small fixes often depend on larger patches which are hard to apply
to old kernels.

Thanks,
//richard 

RE: Questions about ubifs,ubi and mtd?

[武井 克明]

Dear Richard,
Dera Martin,

We are very grateful for the advice that made you well.
We would like to investigate further and decide the best path after considering it.
If you have anything to notice in the future, feel free to advise and comment.

Thank you again for everything you have done.

=====
Katsuaki Takei/Oki Electric Industry Co., Ltd./JP


> -----Original Message-----
> From: Richard Weinberger <richard@nod.at>
> Sent: Thursday, December 13, 2018 8:38 PM
> To: Martin Lund <martin.lund@keep-it-simple.com>
> Cc: 武井 克明 <takei744@oki.com>; linux-mtd@lists.infradead.org
> Subject: Re: Questions about ubifs,ubi and mtd?
> 
> Martin,
> 
> Am Donnerstag, 13. Dezember 2018, 12:32:43 CET schrieb Martin Lund:
> > On Thu, Dec 13, 2018 at 11:45 AM 武井 克明 <takei744@oki.com> wrote:
> > >
> > > 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
> > >
> >
> > I recommend you first take a close look at the git history of Linux
> > 3.2.26 and onward to see if there are any immediate UBI/UBIFS fixes
> > available that might relate/solve the issue you are seeing. It might
> > be an easier path than jumping into a big task like back porting
> > latest UBI/UBIFS to such an old kernel.
> 
> Given the age of this kernel it will be massive pain in any case.
> Digging through the history, identifying and backporting fixes sounds more
> easier than it actually is.
> Small fixes often depend on larger patches which are hard to apply to old
> kernels.
> 
> Thanks,
> //richard
> 

Re: Questions about ubifs,ubi and mtd?

[Steve deRosier]

On Thu, Dec 13, 2018 at 3:36 AM Richard Weinberger <richard@nod.at> 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

Re: Questions about ubifs,ubi and mtd?

[Richard Weinberger]

Steve,

Am Donnerstag, 13. Dezember 2018, 18:18:49 CET schrieb Steve deRosier:
> On Thu, Dec 13, 2018 at 3:36 AM Richard Weinberger <richard@nod.at> 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.
 
Thanks a lot for your great summary!
IMHO it makes sense to put this in form of a checklist to the MTD website.
What do you think?

Thanks,
//richard

Re: Questions about ubifs,ubi and mtd?

[Steve deRosier]

On Thu, Dec 13, 2018 at 1:16 PM Richard Weinberger <richard@nod.at> wrote:
>
> Steve,
>
> Am Donnerstag, 13. Dezember 2018, 18:18:49 CET schrieb Steve deRosier:
> > On Thu, Dec 13, 2018 at 3:36 AM Richard Weinberger <richard@nod.at> 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.
>
> Thanks a lot for your great summary!
> IMHO it makes sense to put this in form of a checklist to the MTD website.
> What do you think?
>
> Thanks,
> //richard
>
>

Richard,

Please do. Perhaps in a "What should I check when I get errors on a
NAND using MTD and UBIFS?" FAQ entry? I'd be happy to author a more
extensive entry on NAND MTD/UBIFS troubleshooting in the future too if
desired; though not right away, I'm a bit slammed between holidays and
work for the next few weeks.

Thanks,
- Steve

RE: Questions about ubifs,ubi and mtd?

[Katsuaki Takei/OKI/JP]

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@gmail.com>
> Sent: Friday, December 14, 2018 2:19 AM
> To: 武井 克明 <takei744@oki.com>
> Cc: linux-mtd@lists.infradead.org; Richard Weinberger <richard@nod.at>
> Subject: Re: Questions about ubifs,ubi and mtd?
> 
> On Thu, Dec 13, 2018 at 3:36 AM Richard Weinberger <richard@nod.at> 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

RE: Questions about ubifs,ubi and mtd?

[Katsuaki Takei/OKI/JP]

Dear Mr.Richard, Mr.Martin, and Mr.Steve

 Thanks to your first advice, we were able to get a lot of valuable information.
 And again, I thank Richard, Martin, and Steve.

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



> -----Original Message-----
> From: Richard Weinberger <richard@nod.at>
> Sent: Friday, December 14, 2018 6:16 AM
> To: Steve deRosier <derosier@gmail.com>
> Cc: 武井 克明 <takei744@oki.com>; linux-mtd@lists.infradead.org;
> goliath@sigma-star.at
> Subject: Re: Questions about ubifs,ubi and mtd?
> 
> Steve,
> 
> Am Donnerstag, 13. Dezember 2018, 18:18:49 CET schrieb Steve deRosier:
> > On Thu, Dec 13, 2018 at 3:36 AM Richard Weinberger <richard@nod.at>
> 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.
> 
> Thanks a lot for your great summary!
> IMHO it makes sense to put this in form of a checklist to the MTD website.
> What do you think?
> 
> Thanks,
> //richard
> 

Re: Questions about ubifs,ubi and mtd?

[Miquel Raynal]

Hi Steve,

Great summary!

Steve deRosier <derosier@gmail.com> wrote on Thu, 13 Dec 2018 14:22:37
-0800:

> On Thu, Dec 13, 2018 at 1:16 PM Richard Weinberger <richard@nod.at> wrote:
> >
> > Steve,
> >
> > Am Donnerstag, 13. Dezember 2018, 18:18:49 CET schrieb Steve deRosier:  
> > > On Thu, Dec 13, 2018 at 3:36 AM Richard Weinberger <richard@nod.at> 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.

I think this is a very important point, most of the UBI/UBIFS issues
that were reported to me were just the consequence of an earlier
error that happened at the NAND controller driver level. People
reporting bugs tend to only copy/paste the last error they see (which
usually is UBI/UBIFS complaining), forgetting about the root cause
which has been printed earlier in the dmesg.

> > > 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.  
> >
> > Thanks a lot for your great summary!
> > IMHO it makes sense to put this in form of a checklist to the MTD website.
> > What do you think?

I also like the idea!

Thanks,
Miquèl

RE: Questions about ubifs,ubi and mtd?

[武井 克明]

Dear Ævar Arnfjörð Bjarmason,

 Thank you for your advice.
 I will ask my question to ML who told me.

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

> -----Original Message-----
> From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> Sent: Monday, December 10, 2018 11:47 PM
> To: 武井 克明 <takei744@oki.com>
> Cc: git@vger.kernel.org
> Subject: Re: Questions about ubifs,ubi and mtd?
> 
> 
> On Mon, Dec 10 2018, 武井 克明 wrote:
> 
> > Hi all,
> >
> > We are developing the product using file system using ubi, ubifs on hardware
> with NAND flash memory.
> >
> > Although the development of the product was completed, we are seeking
> your help as the customer who is using it is having trouble with it.
> >
> > The product we have developed has 6 MTD partitions for NAND flash
> memory.
> > These consist of 6 MTDs named 'kernel-a' 'kernel-b', 'rootfs-a', 'rootfs-b',
> 'data-1', 'data-2', and online program only accesses 'data-1' and 'data-2' for
> write access.
> > Nevertheless, when loading our program from 'rootfs-a', trying to read
> > the inode with the ubifs_read_node() function will result in "bad node
> > type" (ex: 193 but expected 9) and the LEB can not be read with the
> > expected value. (Even though you do not have write access to rootfs)
> >
> > Is there anyone who encountered such a problem? Is there patch?
> >
> > Please let me know, if you have any questions.
> >
> > Best regards,
> > Katsuaki Takei/Oki Electric Industry Co., Ltd./JP
> 
> Hi. I think you're on the wrong mailing list (git@). You probably want to contact
> one of the linux lists, perhaps
> http://lists.infradead.org/mailman/listinfo/linux-mtd ?

Re: Questions about ubifs,ubi and mtd?

[Ævar Arnfjörð Bjarmason]

On Mon, Dec 10 2018, 武井 克明 wrote:

> Hi all,
>
> We are developing the product using file system using ubi, ubifs on hardware with NAND flash memory.
>
> Although the development of the product was completed, we are seeking your help as the customer who is using it is having trouble with it.
>
> The product we have developed has 6 MTD partitions for NAND flash memory.
> These consist of 6 MTDs named 'kernel-a' 'kernel-b', 'rootfs-a', 'rootfs-b', 'data-1', 'data-2', and online program only accesses 'data-1' and 'data-2' for write access.
> Nevertheless, when loading our program from 'rootfs-a', trying to read the inode with the ubifs_read_node() function will result in "bad node type" (ex: 193 but expected 9) and the LEB can not be read with the expected value. (Even though you do not have write access to rootfs)
>
> Is there anyone who encountered such a problem? Is there patch?
>
> Please let me know, if you have any questions.
>
> Best regards,
> Katsuaki Takei/Oki Electric Industry Co., Ltd./JP

Hi. I think you're on the wrong mailing list (git@). You probably want
to contact one of the linux lists, perhaps
http://lists.infradead.org/mailman/listinfo/linux-mtd ?

Questions about ubifs,ubi and mtd?

[武井 克明]

Hi all,

We are developing the product using file system using ubi, ubifs on hardware with NAND flash memory.

Although the development of the product was completed, we are seeking your help as the customer who is using it is having trouble with it.

The product we have developed has 6 MTD partitions for NAND flash memory.
These consist of 6 MTDs named 'kernel-a' 'kernel-b', 'rootfs-a', 'rootfs-b', 'data-1', 'data-2', and online program only accesses 'data-1' and 'data-2' for write access.
Nevertheless, when loading our program from 'rootfs-a', trying to read the inode with the ubifs_read_node() function will result in "bad node type" (ex: 193 but expected 9) and the LEB can not be read with the expected value. (Even though you do not have write access to rootfs)

Is there anyone who encountered such a problem? Is there patch?

Please let me know, if you have any questions.

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