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
next prev parent 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