From: Sascha Hauer <s.hauer@pengutronix.de>
To: John Ogness <john.ogness@linutronix.de>
Cc: linux-mtd@lists.infradead.org
Subject: Re: mxc nand i.mx35: no OOB with HW_ECC
Date: Thu, 12 Nov 2009 10:35:45 +0100 [thread overview]
Message-ID: <20091112093545.GW30179@pengutronix.de> (raw)
In-Reply-To: <80bpjj7hrd.fsf@merkur.tec.linutronix.de>
Hi John,
On Tue, Nov 03, 2009 at 04:25:10PM +0100, John Ogness wrote:
> Hi,
>
> I spent a while trying to figure out why JFFS2 was getting hardware ECC
> errors on an i.MX35 NANDFC with 2K pages. The problem also existed when
> using nandwrite together with the -n and -o options.
>
> The problem is that for page sizes larger than 512 bytes, the i.MX35
> NANDFC can only write the page and oob data together. When writing the
> page and oob data, the ECC hardware also writes the ECC codes for
> it. This is ok if the filesystem driver or userspace application
> understands that only one write per page+oob is allowed.
>
> But jffs2 and "nandwrite -n -o" assume that they can write the oob data
> and the page data separately. With the recently posted mxc_nand.c
> driver, this results in the NANDFC writing the ECC codes to flash
> twice... with different values. This means the ECC codes that end up on
> the flash chip are garbage.
I can confirm jffs2 errors on i.MX35 with the patches I posted. And yes
you're right, I mostly use UBIFS.
Freescale originally provided two drivers, one for the i.MX27/31 type
nand controller (v1) from which the in kernel driver is derived and one
for the remaining nand controllers (i.mx35/25) (v2). What I did is to
work on both drivers till they both looked (nearly) the same and posted
the patches for the v1 driver.
One remaining difference is in mxc_do_addr_cycle(). Here is the version
from the v2 driver which works with jffs2:
static void mxc_do_addr_cycle(struct mtd_info *mtd, int column, int
page_addr)
{
struct nand_chip *nand_chip = mtd->priv;
struct mxc_nand_host *host = nand_chip->priv;
u32 page_mask = nand_chip->pagemask;
if (column != -1) {
send_addr(host, column & 0xFF, 0);
if (mtd->writesize == 2048) {
/* another col addr cycle for 2k page */
send_addr(host, (column >> 8) & 0xF, 0);
} else if (mtd->writesize == 4096) {
/* another col addr cycle for 4k page */
send_addr(host, (column >> 8) & 0x1F, 0);
}
}
if (page_addr != -1) {
do {
send_addr(host, (page_addr & 0xff), 0);
page_mask >>= 8;
page_addr >>= 8;
} while (page_mask != 0);
}
}
Putting this function into the v1 driver makes the driver work for me on
i.MX35 with jffs2. Can you confirm this?
I haven't looked deeply into the differences and I suspect this version
of mxc_do_addr_cycle() won't work on the v1 type controllers, so this is
not a solution yet.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2009-11-12 9:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-03 15:25 mxc nand i.mx35: no OOB with HW_ECC John Ogness
2009-11-11 7:22 ` Artem Bityutskiy
2009-11-11 9:04 ` John Ogness
2009-11-12 9:35 ` Sascha Hauer [this message]
2009-11-12 10:28 ` Sascha Hauer
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=20091112093545.GW30179@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=john.ogness@linutronix.de \
--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.