New NAND interface

Thomas Gleixner tglx at linutronix.de
Mon May 10 11:32:23 EDT 2004


On Monday 10 May 2004 16:04, Simon Haynes wrote:
> I explained, recently, on #mtd, that jffs2 was generating bad crc messages
> when running an NAND, smc. It was suggested that I get the latest code from
> CVS. I did this and it has taken me a while to get things going.
>
> Firstly nand_scan() now checks that data_buf and oob_buf have been
> assigned. Previously I only allocated space for data_buf and I did this
> after nand_scan had, conveniently, filled in some sizes fo me.
> It would seem now that the nand driver needs to select the appropriate
> sizes. In some ways I feel this duplicates what nand_scan does the table in
> nand_ids.c.

The ids provide information about the chip and its features. nand_scan is a 
bit more complicated now, as we read the extended id to get more information 
about the chip. This allows us to use one driver setup for different 
chiptypes.

> I was also unsure as to the size of the oob_buf. After looking at nand.c it
> seems that this should be the oobsize * (erasesize / blockize) ?

Yep. I explained this in 
http://lists.infradead.org/pipermail/linux-mtd/2004-April/009632.html

> I guess this makes sense as each block will have it's own oob.
>
> After this I ran into problems with an SSFDC module. This module provides
> an SSFDC compatible block interface. It uses the mtd layer to read/write
> it's own data and oob. I noticed data corruption via this interface and
> started to investigate.
>
> It would appear that the NAND layer now assigns automatic oob placements
> for NAND drivers which do not specify autooob. In my case this meant that
> when the SSFDC module called nand_write oob data was calculated and
> written. The module then called nand_write_oob to write it's own oob. Two
> writes like this could destroy the oob data and data integrity. For the
> moment I have fixed this in my NAND driver by specifying autooob with the
> useecc field set to 0.

Sorry, I was not aware that you have a block driver for SM-FAT. Is this driver 
available anywhere ? 

> Firstly I am concerned that this might cause problems with other users of
> the NAND driver.  Is there cause for concern ?

AFAIK, are JFFS2 and YAFFS the only clients of NAND driver, except your SSFDC 
module.

> Secondly my SSFDC layer will only work with my NAND driver.
> I guess what I really need to do is change the SSFDC layer but I am not
> sure how to go about this. I do not simply what to change ECC positions but
> the contents of the oob.

Yep. Have a look at YAFFS or JFFS2. There we build a oob layout where the ECC 
placement is defined. The useecc member is set to MTD_NANDECC_PLACE, which 
means you define the ECC positions.
The data for the oob area can either be programmed seperately or written along 
with the main area data. See http://linux-mtd.infradead.org/tech/nand.html or 
have a look into the YAFFS code.

If you have more questions feel free to ask or let me have a look into the 
code so I can give you more detailed hints.

Thomas




More information about the linux-mtd mailing list