From: Amit Virdi <amit.virdi@st.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/3] mtd/NAND: Add FSMC driver support
Date: Fri, 2 Mar 2012 16:46:48 +0530 [thread overview]
Message-ID: <4F50AC20.8010507@st.com> (raw)
In-Reply-To: <4F4FE9AF.303@freescale.com>
Hello Scott,
On 3/2/2012 2:57 AM, Scott Wood wrote:
> On 02/27/2012 03:38 AM, Amit Virdi wrote:
>> + /*
>> + * This is a temporary erase check. A newly erased page read
>> + * would result in an ecc error because the oob data is also
>> + * erased to FF and the calculated ecc for an FF data is not
>> + * FF..FF.
>> + * This is a workaround to skip performing correction in case
>> + * data is FF..FF
>> + */
>> + for (k = 0; k< eccsize; k++) {
>> + if (*(p + k) != 0xff)
>> + break;
>> + }
>
> Shouldn't this apply over the whole page (including the ECC bytes
> themselves), not just the ECC chunk? The data could legitimately be all
> 0xff except for one bit, and that bit could have flipped...
So you're saying that such a page is wrongly interpreted as "erased
page" and ecc check is skipped! Yes, you are very right. This check
should be applied to the whole page and not only the chunk.
>
> Will a freshly erased page show up as having correctable errors, or
A newly erased page contains 0xff in data as well as spare area. So most
likely, it shows up as having uncorrectable errors.
> uncorrectable? If the latter, just hold off on declaring the page as an
> ECC fail until you've read the whole thing, and then if you're about to
> mark it failed, check wheter it's freshly erased.
So do you mean to say:
stat = chip->ecc.correct(mtd, p, &ecc_code[i],
&ecc_calc[i]);
if (stat < 0) {
if (data as well as the oob is 0xff)
do nothing;
else
mtd->ecc_stats.failed++;
} else
mtd->ecc_stats.corrected += stat;
Can we have a scenario like this:
A page has been erased - so it contains 0xff in data area as well as
spare area. Somehow, a bit in either or say both areas are flipped, then
the SW will not be able to distinguish if it's and erased page or a page
with data and uncorrectable errors. How do we take care of such scenarios?
>
>> + nand->options = 0;
>> +#if defined(CONFIG_SYS_FSMC_NAND_16BIT)
>> + nand->options |= NAND_BUSWIDTH_16;
>> +#endif
>
> No on-flash BBT?
>
No, not implemented yet.
>> + /* Detect NAND chips */
>> + if (nand_scan_ident(mtd, 1, NULL))
>> + return -ENXIO;
>
> You should #define CONFIG_SYS_NAND_SELF_INIT if you want to call this
> yourself (see the documentation for what else you need to do).
>
Ok. I see this is the new philosophy that is encouraged even for the
existing drivers.
>> +/*
>> + * There are 13 bytes of ecc for every 512 byte block and it has to be read
>> + * consecutively and immediately after the 512 byte data block for hardware to
>> + * generate the error bit offsets
>> + * Managing the ecc bytes in the following way is easier. This way is similar to
>> + * oobfree structure maintained already in u-boot nand driver
>> + */
>> +#define MAX_ECCPLACE_ENTRIES 32
>
> No FSMC namespace... is/will this file included by anything but the FSMC
> driver?
>
Sorry, it didn't get you here. This file (fsmc_nand.h) shall be included
by board files.
Thanks
Amit Virdi
next prev parent reply other threads:[~2012-03-02 11:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-27 9:38 [U-Boot] [PATCH 0/3] mtd/NAND: Support for FSMC controller Amit Virdi
2012-02-27 9:38 ` [U-Boot] [PATCH 1/3] mtd/NAND: Add FSMC driver support Amit Virdi
2012-03-01 21:27 ` Scott Wood
2012-03-02 11:16 ` Amit Virdi [this message]
2012-03-05 23:39 ` Scott Wood
2012-02-27 9:38 ` [U-Boot] [PATCH 2/3] SPEAr: Configure FSMC driver for NAND interface Amit Virdi
2012-02-27 10:02 ` Stefan Roese
2012-02-27 10:15 ` Amit Virdi
2012-02-27 22:32 ` Scott Wood
2012-02-29 10:11 ` Amit Virdi
2012-02-29 18:03 ` Scott Wood
2012-03-02 11:24 ` Amit Virdi
2012-03-02 13:44 ` Stefan Roese
2012-03-02 17:19 ` Scott Wood
2012-02-29 10:09 ` Amit Virdi
2012-02-27 9:38 ` [U-Boot] [PATCH 3/3] mtd/NAND: Remove obsolete SPEAr specific NAND drivers Amit Virdi
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=4F50AC20.8010507@st.com \
--to=amit.virdi@st.com \
--cc=u-boot@lists.denx.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 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.