JFFS2 NAND support?

JFFS2 NAND support?

[Fry, Dan]

Newbie Questions:

I'm currently working on a project that is switching from Intel Strata Flash
to a Toshiba TC58V64AFT part.  I've been using JFFS2 on the Intel and wanted
to continue on the Toshiba part.  Is anyone working on provisioning JFFS2
with NAND support?   

If no one is currently working on this could someone explain what's involved
in getting JFFS2 to function with a raw NAND flash?

Also what's the best strategy for handling bad blocks in MTD.  Should NFTL
be modified to eliminate its current dependency on DiskOnChip ECC hardware?
If not what's the best course of action? 

Thanks,


Dan Fry
Software Engineer

DIRECTV Broadband, Inc.
490 Race Street, San Jose, CA 95126
Phone - (408) 863-8313
Fax - (408) 861-8613

Re: JFFS2 NAND support?

[kira brown]

On Thu, 6 Sep 2001, Fry, Dan wrote:
> Also what's the best strategy for handling bad blocks in MTD.  Should NFTL
> be modified to eliminate its current dependency on DiskOnChip ECC hardware?

NFTL is not licenced for use on hardware not supplied by M-Systems,
basically;  of course this isn't a problem for those of us in the Free
World where the patent doesn't hold water, but it would cause problems for
anyone in the US.

kira.

What abount NAND driver in current MTD snapshot?

[Kim Jong-chan]

I've just looked up MTD NAND driver for recent several days.

I think it's almost done. But the driver itself has no bad block handling.

Is it right?

If it is right, where is the bad block handling?

Is NFTL capable of handling bad block? 

then, Can I use NAND driver & NFTL combined and put any filesystem on it?

On Thu, Sep 06, 2001 at 05:19:34PM +0100, kira brown wrote:
> 
> 
> On Thu, 6 Sep 2001, Fry, Dan wrote:
> > Also what's the best strategy for handling bad blocks in MTD.  Should NFTL
> > be modified to eliminate its current dependency on DiskOnChip ECC hardware?
> 
> NFTL is not licenced for use on hardware not supplied by M-Systems,
> basically;  of course this isn't a problem for those of us in the Free
> World where the patent doesn't hold water, but it would cause problems for
> anyone in the US.
> 
> kira.
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: What abount NAND driver in current MTD snapshot?

[David Woodhouse]

kernelhacker@hartford.siteprotect.co.kr said:
> I've just looked up MTD NAND driver for recent several days.
> I think it's almost done. But the driver itself has no bad block
> handling.

> Is it right? If it is right, where is the bad block handling?

The hardware driver itself has no bad block handling, yes - that should be 
done in the next layer up. Each format which you might put onto a NAND 
flash may have its own way of dealing with bad blocks. 

> Is NFTL capable of handling bad block? 

The NFTL format is capable of dealing with bad blocks, yes. But I don't
believe the Linux code currently does so with blocks which go bad at
runtime, only blocks which are marked bad during the initial format. A 
relatively simple exercise for the reader :)

> then, Can I use NAND driver & NFTL combined and put any filesystem on
> it? 

Technically, yes. But you probably shouldn't use NFTL. 

Firstly, as Kira says, NFTL suffers from patent problems, so you may find
it's not legal to use it. I'm not sure whether the M-Systems patents are
valid in Korea. 

More importantly, I think NFTL is just the wrong approach to putting a 
filesystem on a flash chip. NFTL is a form of pseudo-filesystem, used to 
emulate a block device. On top of that filesystem, you're going to have to 
put another journalling filesystem, like ext3. It is far more efficient 
just to put a filesystem directly on the flash chips. 

I think the best approach would be to add the necessary support for NAND 
chips to the JFFS2 code. Getting JFFS2 to deal with the 10-write-per-page 
restriction should be fairly simple, and the bad block code in JFFS2 is in 
much the same state as that in the NFTL code - we can deal with bad blocks 
appropriately but don't yet actually detect bad blocks and mark them as 
such. So if you're going to add badblock detection code, you might as well 
add it to JFFS2.

--
dwmw2