Maturity of JFFS2 + MTD NAND Flash Support?

Maturity of JFFS2 + MTD NAND Flash Support?

[Johnson, Charles F]

Folks,

I've been browsing the mailing list archives and trying to determine
maturity of JFFS2 + MTD NAND Flash support.  Particularlly with the
latest 2.6.x Linux kernels.  (I think 2.6.x is the only kernel where
NAND is supported, correct ?)  Does anyone have a list of comercial
products known to be shipping with this ??  Any support yet in MTD for
ONFI 1.0 ??  (I couldn't find anything in the 2.6.20rc6 kernel I was
browsing.)

Thanks.

Charles Johnson
Ultra-Mobility Group
Platform Software Engineering
Intel Corporation
charles.f.johnson@intel.com

Re: Maturity of JFFS2 + MTD NAND Flash Support?

[David Woodhouse]

On Mon, 2007-02-26 at 12:07 -0800, Johnson, Charles F wrote:
> I've been browsing the mailing list archives and trying to determine
> maturity of JFFS2 + MTD NAND Flash support.  Particularlly with the
> latest 2.6.x Linux kernels.  (I think 2.6.x is the only kernel where
> NAND is supported, correct ?) 

Effectively, yes.

>  Does anyone have a list of comercial products known to be shipping
> with this ?? 

The Nokia 770 and 800 are using it, certainly. And the $100 laptop.
Not sure what else.

> Any support yet in MTD for ONFI 1.0 ??  (I couldn't find anything in
> the 2.6.20rc6 kernel I was browsing.) 

I've not heard of ONFI. What's that?

-- 
dwmw2

Re: Maturity of JFFS2 + MTD NAND Flash Support?

[Josh Boyer]

On 2/26/07, David Woodhouse <dwmw2@infradead.org> wrote:
> > Any support yet in MTD for ONFI 1.0 ??  (I couldn't find anything in
> > the 2.6.20rc6 kernel I was browsing.)
>
> I've not heard of ONFI. What's that?

I assume this:

http://www.onfi.org/

But that looks more like a hardware interface than software.  Which
means MTD has nothing to do with it.

josh

RE: Maturity of JFFS2 + MTD NAND Flash Support?

[Johnson, Charles F]

Of the ONFI 1.0 spec, section 5, page 39 describes the command set.  I
assume you'd need a MTD driver to implement this command set ? 


Charles Johnson
Ultra-Mobility Group
Platform Software Engineering
Intel Corporation
charles.f.johnson@intel.com
503-712-5181

-----Original Message-----
From: Josh Boyer [mailto:jwboyer@gmail.com] 
Sent: Monday, February 26, 2007 2:22 PM
To: David Woodhouse
Cc: Johnson, Charles F; linux-mtd@lists.infradead.org
Subject: Re: Maturity of JFFS2 + MTD NAND Flash Support?

On 2/26/07, David Woodhouse <dwmw2@infradead.org> wrote:
> > Any support yet in MTD for ONFI 1.0 ??  (I couldn't find anything in
> > the 2.6.20rc6 kernel I was browsing.)
>
> I've not heard of ONFI. What's that?

I assume this:

http://www.onfi.org/

But that looks more like a hardware interface than software.  Which
means MTD has nothing to do with it.

josh

Re: Maturity of JFFS2 + MTD NAND Flash Support?

[Josh Boyer]

On 2/26/07, Johnson, Charles F <charles.f.johnson@intel.com> wrote:
> Of the ONFI 1.0 spec, section 5, page 39 describes the command set.  I
> assume you'd need a MTD driver to implement this command set ?

Yes, MTD would need to use those opcodes to talk to an ONFI compliant
chip.  But that is
still more of a HW detail.  It's really no different than supporting
any other chip.  And from
what I can tell, most of those opcodes are already used in MTD.  So
basically, someone
would have to try and use MTD on an OFNI compliant chip and see what's lacking.

josh

Re: Maturity of JFFS2 + MTD NAND Flash Support?

[Matthieu CASTET]

David Woodhouse a écrit :
> On Mon, 2007-02-26 at 12:07 -0800, Johnson, Charles F wrote:
>> I've been browsing the mailing list archives and trying to determine
>> maturity of JFFS2 + MTD NAND Flash support.  Particularlly with the
>> latest 2.6.x Linux kernels.  (I think 2.6.x is the only kernel where
>> NAND is supported, correct ?) 
> 
> Effectively, yes.

AFAIK, jffs2 doesn't handle correctly bit flip on read : it won't try to 
  copy the data on another block while the data can still be recovered 
by ecc.

I believe it could be a big issue for commercial product where no 
corruption should happen.


Matthieu

Re: Maturity of JFFS2 + MTD NAND Flash Support?

[Ensar Gul]

> AFAIK, jffs2 doesn't handle correctly bit flip on read : it won't try to 
> copy the data on another block while the data can still be recovered 
> by ecc.
>
> I believe it could be a big issue for commercial product where no 
> corruption should happen.
>
>
> Matthieu

Is there a solution to the problem stated above yet?

By the way, I also used JFFS2 on NAND flash as root filesystem in a 
telecom product. but the root filesystem infrequently becomes corrupt 
without any apparent reason. I`m considering to redesign the hardware 
and use an alternative device instead of NAND flash.

any comments on this issue will be appreciated.

rgds

Ensar

Re: Maturity of JFFS2 + MTD NAND Flash Support?

[Bill Gatliff]

Ensar Gul wrote:
>> AFAIK, jffs2 doesn't handle correctly bit flip on read : it won't try to 
>> copy the data on another block while the data can still be recovered 
>> by ecc.
>>
>> I believe it could be a big issue for commercial product where no 
>> corruption should happen.
>>
>>
>> Matthieu
> 
> Is there a solution to the problem stated above yet?

YAFFS?


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: Maturity of JFFS2 + MTD NAND Flash Support?

[Ricard Wanderlof]

On Fri, 12 Sep 2008, Ensar Gul wrote:

>> AFAIK, jffs2 doesn't handle correctly bit flip on read : it won't try to
>> copy the data on another block while the data can still be recovered
>> by ecc.
>>
>> I believe it could be a big issue for commercial product where no
>> corruption should happen.
>>
>>
>> Matthieu
>
> Is there a solution to the problem stated above yet?

I belive UBI has some form of block scrubbing to minimize the problem, 
there should be more info on the mtd homepage.

> By the way, I also used JFFS2 on NAND flash as root filesystem in a 
> telecom product. but the root filesystem infrequently becomes corrupt 
> without any apparent reason. I`m considering to redesign the hardware 
> and use an alternative device instead of NAND flash.

A while ago, there was a bug in the ECC code whereby a single-bit error in 
the actual ECC bytes was not handled (i.e. corrected) correctly and 
resulted in the corresponding data to be considered faulty (as if a 
multiple-bit error had occurred). This was several Linux versions ago, I 
don't remember the exact version.

/Ricard
--
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30