From: Simon Haynes <simon@baydel.com>
To: linux-mtd@lists.infradead.org
Subject: New NAND interface
Date: Mon, 10 May 2004 15:04:58 +0100 [thread overview]
Message-ID: <D917588A7DC5@baydel.com> (raw)
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.
next reply other threads:[~2004-05-10 14:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-10 14:04 Simon Haynes [this message]
2004-05-10 15:32 ` New NAND interface Thomas Gleixner
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=D917588A7DC5@baydel.com \
--to=simon@baydel.com \
--cc=linux-mtd@lists.infradead.org \
/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