New NAND interface

New NAND interface

[Simon Haynes]

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.

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) ?

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.

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

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. 

Can anyone explain how I should do this ?


Cheers

Simon.

Re: New NAND interface

[Thomas Gleixner]

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

Re: New NAND interface

[Simon Haynes]

On Monday 10 May 2004 4:32 pm, Thomas Gleixner wrote:
> On Monday 10 May 2004 16:04, Simon Haynes wrote:
> > I explained, recently, on #mtd, that jffs2 was generating bad crc
>
> Yep. I explained this in
> http://lists.infradead.org/pipermail/linux-mtd/2004-April/009632.html
>

Sorry, I should have looked at the archives. This makes it all clear to me.

> > 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 ?
>

I have spoken to David about this and I am more than happy to provide the 
source to anyone. David, kindly, suggested I send the code to him and he 
would have a look before integrating it into the CVS system. I have not sent 
it to David as there are restrictions which would not make it suitable for 
all. I had planned to remove these and tidy things up but I just have not 
made the time. 

> > 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.
>

I guess JFFS2 and YAFFS will not bothered about my NAND driver doing auto 
placement as they have their own schemes ?


> Secondly my SSFDC layer will only work with my NAND driver.
> 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.
>

As I said, I will supply you the code but I do not expect you to support it
and I do regard it as, incomplete, for gereral use.

> Thomas
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Thomas, 

Thankyou for your support, again :-). At some time I will look into how I can 
change the SSFDC layer to interface properly to mtd/nand. As my frig seems to 
work for now I am inclined to go with it, unless you think this otherwise.

Cheers 

Simon.

Re: New NAND interface

[Thomas Gleixner]

On Monday 10 May 2004 18:35, Simon Haynes wrote:
> On Monday 10 May 2004 4:32 pm, Thomas Gleixner wrote:
> > On Monday 10 May 2004 16:04, Simon Haynes wrote:
> > > I explained, recently, on #mtd, that jffs2 was generating bad crc
> >
> > Yep. I explained this in
> > http://lists.infradead.org/pipermail/linux-mtd/2004-April/009632.html
>
> Sorry, I should have looked at the archives. This makes it all clear to me.

No problem.

> > > 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 ?
>
> I have spoken to David about this and I am more than happy to provide the
> source to anyone. David, kindly, suggested I send the code to him and he
> would have a look before integrating it into the CVS system. I have not
> sent it to David as there are restrictions which would not make it suitable
> for all. I had planned to remove these and tidy things up but I just have
> not made the time.

Ok

> > > 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.
>
> I guess JFFS2 and YAFFS will not bothered about my NAND driver doing auto
> placement as they have their own schemes ?

Yep. The decision is:

Use the caller provided scheme else use the default autoplacement scheme.

> > Secondly my SSFDC layer will only work with my NAND driver.
> > 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.
>
> As I said, I will supply you the code but I do not expect you to support it
> and I do regard it as, incomplete, for gereral use.

In general I try to support every known NAND driver client. I would be 
interested to look into the SSFDC code also to help to fix it so it can be 
included in the source base.

> Thankyou for your support, again :-). At some time I will look into how I
> can change the SSFDC layer to interface properly to mtd/nand. As my frig
> seems to work for now I am inclined to go with it, unless you think this
> otherwise.

Cheers 

Thomas

Re: New NAND interface

[Simon Haynes]

On 11 May 2004 at 10:53, Thomas Gleixner wrote:

> On Monday 10 May 2004 18:35, Simon Haynes wrote:
> > On Monday 10 May 2004 4:32 pm, Thomas Gleixner wrote:
> > > On Monday 10 May 2004 16:04, Simon Haynes wrote:
> > > > I explained, recently, on #mtd, that jffs2 was generating bad
> > > > crc
> > support it and I do regard it as, incomplete, for gereral use.
> 
> In general I try to support every known NAND driver client. I would be
> interested to look into the SSFDC code also to help to fix it so it
> can be included in the source base.
> 

Thomas, 

I will email you the code, if you don't want it just junk it. I had a look at the YAFFS 
stuff last night. As I understand it I could just replace my calls to mtd->read and 
mtd->write with the ecc versions. I would then specify NULL for oob_buf and set 
oobinfo->useecc to MTD_NANDECC_OFF. 

Then I could put the NAND driver back to normal.


Thanks

Simon. 
__________________________

Simon Haynes - Baydel 
Phone : 44 (0) 1372 378811
Email : simon@baydel.com
__________________________