From: "David A. Marlin" <dmarlin@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: MTD List <linux-mtd@lists.infradead.org>
Subject: additional error checks for AG-AND erase/write
Date: Tue, 18 Jan 2005 09:43:47 -0600 [thread overview]
Message-ID: <41ED2EB3.1070203@redhat.com> (raw)
The Renesas AG-AND chips support additional error checking on erase and
write operations beyond just checking the operation status. I think the
logic is that since ECC can correct 2-bit errors on read, if only a
single bit error occurs on and erase or write the operation should not
be considered FAIL. Even if a single bit error occurs on read (in
addition to the single bit error on write), it will still be corrected
and no data will be lost.
I'm looking at how to implement the additional status checks, and am
considering adding an optional callback routine to nand_base that, if
defined, would be called in the event of an erase or write error before
returning a FAIL status. The nand_write routine would need to be
modified to perform the callback routine as follows:
<pseudocode>
command(SEQIN) // begin auto page programming
enable_hwecc(WRITE)
write_buffer(data)
calculate the ECC // from FPGA
write_buffer(ECC)
command(PAGE_PROGRAM)
+ if READY && (status & 0x01) // Program Fail (I/O1=1)
+ && error_status_callback // and there is a callback
+ status = error_status_callback(page)
+ endif
if READY && (status & 0x01) // Program Fail (I/O1=1)
return error
endif
// The callback routine itself would need to perform the following:
error_status_callback(page)
status = read_error_status
if !(status & 0x20) // ECC not available (I/O6=0)
return error
else
ReadECCcheck(page) // Read the data and check the status
if (!1_bit_error) // if Not 1 bit error
return error
endif
endif
return ok
</pseudocode>
One problem I see is that in order to determine if there is a 1-bit
error, we must perform a "read" of the page in question, but the erase
and write routines both hold a "lock" on the device through
'nand_get_device'. This would prevent the read from proceeding until
the erase or write completed (deadlock).
Is there a better place to include additional status checks, or a more
appropriate method of implementing this? I would appreciate any
suggestions.
Thank you,
d.marlin
next reply other threads:[~2005-01-18 15:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-18 15:43 David A. Marlin [this message]
2005-01-18 17:19 ` additional error checks for AG-AND erase/write Thomas Gleixner
2005-01-18 18:08 ` David A. Marlin
2005-01-18 21:15 ` Thomas Gleixner
2005-01-20 22:35 ` David A. Marlin
2005-01-21 9:27 ` Thomas Gleixner
2005-01-21 15:04 ` David A. Marlin
2005-01-22 9:05 ` 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=41ED2EB3.1070203@redhat.com \
--to=dmarlin@redhat.com \
--cc=linux-mtd@lists.infradead.org \
--cc=tglx@linutronix.de \
/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