All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Finney <saf76@earthlink.net>
To: linux-mtd@lists.infradead.org
Subject: NAND OOB Questions...
Date: Thu, 1 Jun 2006 09:38:47 -0700 (GMT-07:00)	[thread overview]
Message-ID: <32905508.1149179928067.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> (raw)

I have 3 questions about OOB and NAND chips that I'm
hoping someone can answer. Per an earlier post, I think
there may be two (obscure?) bugs in nand_base.c, but
there's too much I don't know about NAND (and the code) to be sure.
I believe the following description applies to the most recent
stable kernel source (2.6.16.19).

1) The Samsung K9F56* NAND chip allows doing more than one write
to the OOB area of a page without an erase; the second write
may zero bits that were set to 1 by the first write. Is the Samsung
chip unusual in this, or is this normal NAND behavior? (I believe
this would be normal for NOR flash).

2) In nand_base.c:nand_write_page(), OOB data is written even when
NAND_ECC_NONE is set. Under what circumstances is this useful?
(The issue with this is that, in conjunction with (1), this may
overwrite OOB in a circumstance where you're trying to write it
yourself from user space; pernaps this is something that's only relevant
for diagnostics/debugging).

3) nand_prepare_oobbuf() makes a point of setting the internal oobbuf
to 0xFF if it's had ECC bytes written to it (based on the this->oobdirty
flag). However, the default case (which includes hardware ECC) in
nand_write_page() can write the internal oobbuf without setting
this->oobdirty, and thus not triggering the later reset to 0xFF. Is
there a rationale for this? (The OOB issue induced by 1 & 2 would be
benign if oobbuf was cleared to 0xFF).

Thanks for any info.
sf

             reply	other threads:[~2006-06-01 16:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-01 16:38 Steve Finney [this message]
2006-06-05  8:14 ` NAND OOB Questions Thomas Gleixner
2006-06-05  9:23   ` Charles Manning
     [not found] <21148625.1149520632350.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net>
2006-06-06  5:38 ` Thomas Gleixner
     [not found] <15200571.1149603155027.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net>
2006-06-06 15:03 ` Thomas Gleixner

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=32905508.1149179928067.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net \
    --to=saf76@earthlink.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.