Problems with NAND support

Problems with NAND support

[Juan Ramon Jimenez]

-- 

   Hi all

    We are trying to compile a kernel with MTD support but we have
some problems to get it. We have probed with several kernel sources
(2.4.3, 2.4.6, 2.4.7) and with the same sources replacing the mtd
files with the cvs directory files from infredead.org. In both cases
we have the same results: We only can get a kernel image if we don't
enable NAND device support.  The problem is that we really need it. Do
you know why?

Also we have seen that we _must_ set a value for 'physical start
address of flash mapping' But we have read in 'mtd-jffs-HOWTO.txt':

   ' If you leave the address blank (or just don't enable the advanced 
     options), the code will *auto probe*. This works quite well (at 
     least for me). Try it first.'

What's the problem then?


   We have used  gcc 2.96 and egcs 2.91.66 with a Red Hat 7.0 (kernel
2.2.17-8)  

   Any comment or solution will be welcome. Thanks
   J


                                ///
                               (@ @)
 ------------------------oOO----(_)----OOo-------------------------

 - No comas todo lo que puedes, no gastes todo lo que tienes,
   no creas todo lo que oigas, no digas todo lo que sabes.
   - Proverbio chino.

 ------------------------------------------------------------------

 ¤º°°º¤ø,¸¸,ø¤º°°º¤ø,¸¸,ø¤º°`°º¤ø,¸

    Juan Ramón Jiménez García
    Hispafuentes
    Tfno 91 4575330
    jjimenez@aucland.com
    juan@hispafuentes.com

 ¤º°°º¤ø,¸¸,ø¤º°°º¤ø,¸¸,ø¤º°`°º¤ø,¸

Re: Problems with NAND support

[David Woodhouse]

juan@hispafuentes.com said:
>  We only can get a kernel image if we don't enable NAND device
> support.  The problem is that we really need it. Do you know why? 

If you're using raw NAND chips you'll need a tiny board-specific glue 
driver like spia.c to let the generic nand code know how to access the 
chips.

You can't use FTL on it because that's for NOR flash. You can't use NFTL 
because that requires the DiskOnChip ECC hardware, and in many places both 
suffer from patent problems.

You can use JFFS on it, but JFFS2 hasn't yet been made to deal with NAND 
flash - I'm happy to give you pointers if you want to fix that.

I'd also like to see someone write a SmartMedia-compatible translation 
layer driver - that ought to be fairly simple to do too.

--
dwmw2

RE: Problems with NAND support

[James, Laura]

We're going to be working on a new board with large amounts of NAND flash in
the immediate future. It would seem to be a much better idea to go with
jffs2 than jffs.  What will we need to do to get it working? 

Any pointers you can give will be very much appreciated.

Laura

> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: Tuesday, August 07, 2001 3:26 AM
> To: juan@hispafuentes.com
> Cc: linux-mtd@lists.infradead.org
> Subject: Re: Problems with NAND support 
> 
> 
> 
> 
> juan@hispafuentes.com said:
> >  We only can get a kernel image if we don't enable NAND device
> > support.  The problem is that we really need it. Do you know why? 
> 
> If you're using raw NAND chips you'll need a tiny board-specific glue 
> driver like spia.c to let the generic nand code know how to 
> access the 
> chips.
> 
> You can't use FTL on it because that's for NOR flash. You 
> can't use NFTL 
> because that requires the DiskOnChip ECC hardware, and in 
> many places both 
> suffer from patent problems.
> 
> You can use JFFS on it, but JFFS2 hasn't yet been made to 
> deal with NAND 
> flash - I'm happy to give you pointers if you want to fix that.
> 
> I'd also like to see someone write a SmartMedia-compatible 
> translation 
> layer driver - that ought to be fairly simple to do too.
> 
> --
> dwmw2
> 
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

Re: Problems with NAND support

[David Woodhouse]

laurajames@attlabs.att.com said:
> We're going to be working on a new board with large amounts of NAND
> flash in the immediate future. It would seem to be a much better idea
> to go with jffs2 than jffs.  What will we need to do to get it
> working? 

> Any pointers you can give will be very much appreciated.

Mainly:

1. Deal with the 10-write-per-page restriction on NAND chips. Probably just 
by keeping track of the number of writes to a page and when dishing out the 
tenth chunk (which will be rare, most nodes will be greater than 1/10 of a 
page) mark the remainder of the page as obsolete.

2. Ideally, we should do ECC instead of just the CRC we have at the moment.
We need to invent two new node types with ECC to parallel the original inode
and dirent nodes.

3. Be better about detecting bad blocks and treating them appropriately. 

--
dwmw2