public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: tglx@linutronix.de (Thomas Gleixner)
To: simon@baydel.com, linux-mtd@lists.infradead.org
Subject: Re: New NAND interface
Date: Mon, 10 May 2004 17:32:23 +0200	[thread overview]
Message-ID: <200405101732.23971.tglx@linutronix.de> (raw)
In-Reply-To: <D917588A7DC5@baydel.com>

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

  reply	other threads:[~2004-05-10 15:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-10 14:04 New NAND interface Simon Haynes
2004-05-10 15:32 ` Thomas Gleixner [this message]
2004-05-10 16:35   ` Simon Haynes
2004-05-11  8:53     ` Thomas Gleixner
2004-05-11  9:47       ` Simon Haynes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200405101732.23971.tglx@linutronix.de \
    --to=tglx@linutronix.de \
    --cc=linux-mtd@lists.infradead.org \
    --cc=simon@baydel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox