From: Thomas Gleixner <tglx@linutronix.de>
To: Steve Finney <saf76@earthlink.net>
Cc: linux-mtd@lists.infradead.org
Subject: Re: NAND OOB Questions...
Date: Tue, 06 Jun 2006 07:38:49 +0200 [thread overview]
Message-ID: <1149572330.11983.25.camel@localhost.localdomain> (raw)
In-Reply-To: <21148625.1149520632350.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net>
On Mon, 2006-06-05 at 08:17 -0700, Steve Finney wrote:
> >From: Thomas Gleixner <tglx@linutronix.de>
> >The buffer is usually 0xff except when a caller provides content.
>
> I'm not going to repeat all the previous content, but from what you've said,
> it confirms that there is a bug in the current nand_base.c code under the following particular
> set of circumstances:
>
> 1) A NAND flash that allows more than one cycle of writing between erases (at
> least in the OOB area). (e.g., the Samsung K9F* chip).
> 2) Using hardware ECC (e.g., the Samsung S3C2410 processor).
> 3) A sequence in which you initially write to the device with ECC, and then
> turn off ECC and do additional writes including the OOB area.
>
> In the above sequence, the ECC the user writes to the OOB may get corrupted.
Yeah. I did not think about that abstruse scenario :) What the hell is
this for ?
> I have an (ugly) user-level workaround: before I turn off the ECC, I write a
> block that I know will generate ECC bytes consisting of 0xFF. Then the subsequent
> user ECC writes are OK.
>
> It's obscure enough that it's probably not worth fixing (well, I'm not going to try to
> fix it :-) ), and hopefully it's fixed in the refactoring.
Should be.
tglx
next parent reply other threads:[~2006-06-06 5:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <21148625.1149520632350.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net>
2006-06-06 5:38 ` Thomas Gleixner [this message]
[not found] <15200571.1149603155027.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net>
2006-06-06 15:03 ` NAND OOB Questions Thomas Gleixner
2006-06-01 16:38 Steve Finney
2006-06-05 8:14 ` Thomas Gleixner
2006-06-05 9:23 ` Charles Manning
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=1149572330.11983.25.camel@localhost.localdomain \
--to=tglx@linutronix.de \
--cc=linux-mtd@lists.infradead.org \
--cc=saf76@earthlink.net \
/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