All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Djelic <ivan.djelic@parrot.com>
To: "Lothar Waßmann" <LW@KARO-electronics.de>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Shawn Guo <shawn.guo@freescale.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [i.MX28 GPMI] problem overwriting all-0xff data in NAND
Date: Mon, 18 Jul 2011 16:56:44 +0200	[thread overview]
Message-ID: <20110718145635.GA24419@parrot.com> (raw)
In-Reply-To: <20004.12663.29494.339601@ipc1.ka-ro>

On Mon, Jul 18, 2011 at 02:13:27PM +0100, Lothar Waßmann wrote:
> Hi,
> 
> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
> encountered some problems with jffs2 when overwriting pages that have
> been written with 0xff (e.g. from padding from the file system image
> file).
> 
> The problem is that the ECC info for an all-0xff block is not all-0xff
> and thus a newly erased block is different from a block that has been
> written with 0xff.
> If such a block is being altered (jffs2 thinking it can simply
> overwrite it without erasing first) the ECC information will be
> corrupted and will produce ECC errors upon read.

Hello Lothar,

Can you describe more precisely what is happening ? How did you come to the
conclusion that JFFS2 "thinks it can simply overwrite a block without erasing it
first" ?

JFFS2 normally marks a block as clean just after it has erased it; it won't
blindly assume a block is erased and write to it.

I am not very familiar with how JFFS2 metadata work, but I doubt it would
confuse a blank page with a page containing a piece of file with 0xff bytes.

Are you sure your gpmi-nfc driver is not writing ECC info when JFFS2 writes its
cleanmarker, like in the issue previously discussed in
http://lists.infradead.org/pipermail/linux-mtd/2011-June/036538.html ?

BR,

Ivan

WARNING: multiple messages have this Message-ID (diff)
From: ivan.djelic@parrot.com (Ivan Djelic)
To: linux-arm-kernel@lists.infradead.org
Subject: [i.MX28 GPMI] problem overwriting all-0xff data in NAND
Date: Mon, 18 Jul 2011 16:56:44 +0200	[thread overview]
Message-ID: <20110718145635.GA24419@parrot.com> (raw)
In-Reply-To: <20004.12663.29494.339601@ipc1.ka-ro>

On Mon, Jul 18, 2011 at 02:13:27PM +0100, Lothar Wa?mann wrote:
> Hi,
> 
> with the gpmi-nfc driver for imx28 from Shawn Guo on a TX28 I
> encountered some problems with jffs2 when overwriting pages that have
> been written with 0xff (e.g. from padding from the file system image
> file).
> 
> The problem is that the ECC info for an all-0xff block is not all-0xff
> and thus a newly erased block is different from a block that has been
> written with 0xff.
> If such a block is being altered (jffs2 thinking it can simply
> overwrite it without erasing first) the ECC information will be
> corrupted and will produce ECC errors upon read.

Hello Lothar,

Can you describe more precisely what is happening ? How did you come to the
conclusion that JFFS2 "thinks it can simply overwrite a block without erasing it
first" ?

JFFS2 normally marks a block as clean just after it has erased it; it won't
blindly assume a block is erased and write to it.

I am not very familiar with how JFFS2 metadata work, but I doubt it would
confuse a blank page with a page containing a piece of file with 0xff bytes.

Are you sure your gpmi-nfc driver is not writing ECC info when JFFS2 writes its
cleanmarker, like in the issue previously discussed in
http://lists.infradead.org/pipermail/linux-mtd/2011-June/036538.html ?

BR,

Ivan

  reply	other threads:[~2011-07-18 14:56 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-18 13:13 [i.MX28 GPMI] problem overwriting all-0xff data in NAND Lothar Waßmann
2011-07-18 13:13 ` Lothar Waßmann
2011-07-18 14:56 ` Ivan Djelic [this message]
2011-07-18 14:56   ` Ivan Djelic
2011-07-19  5:59   ` Lothar Waßmann
2011-07-19  5:59     ` Lothar Waßmann
2011-07-19  6:48     ` Ivan Djelic
2011-07-19  6:48       ` Ivan Djelic
2011-07-18 16:43 ` Shawn Guo
2011-07-18 16:43   ` Shawn Guo
2011-07-19  2:12   ` Huang Shijie
2011-07-19  2:12     ` Huang Shijie
2011-07-19  6:02     ` Lothar Waßmann
2011-07-19  6:02       ` Lothar Waßmann
2011-07-19  7:03       ` Huang Shijie
2011-07-19  7:03         ` Huang Shijie
2011-07-19  9:55         ` Lothar Waßmann
2011-07-19  9:55           ` Lothar Waßmann
2011-07-19 13:36           ` Wolfram Sang
2011-07-19 13:36             ` Wolfram Sang
2011-07-20  2:18             ` Huang Shijie
2011-07-20  2:18               ` Huang Shijie
2011-07-20  8:51               ` Wolfram Sang
2011-07-20  8:51                 ` Wolfram Sang
2011-07-20 10:34                 ` Huang Shijie
2011-07-20  4:55           ` Huang Shijie
2011-07-20  4:55             ` Huang Shijie
2011-07-20  6:22             ` Lothar Waßmann
2011-07-20  6:22               ` Lothar Waßmann
2011-07-20  5:16     ` Artem Bityutskiy
2011-07-20  5:16       ` Artem Bityutskiy
2011-07-20  5:19       ` Artem Bityutskiy
2011-07-20  5:19         ` Artem Bityutskiy
2011-07-19  6:00   ` Lothar Waßmann
2011-07-19  6:00     ` Lothar Waßmann
2011-07-20  6:44   ` Huang Shijie
2011-07-20  6:44     ` Huang Shijie
2011-07-20  8:10     ` Lothar Waßmann
2011-07-20  8:10       ` Lothar Waßmann
2011-07-20  8:35     ` Artem Bityutskiy
2011-07-20  8:35       ` Artem Bityutskiy
2011-07-20  5:12 ` Artem Bityutskiy
2011-07-20  5:12   ` Artem Bityutskiy

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=20110718145635.GA24419@parrot.com \
    --to=ivan.djelic@parrot.com \
    --cc=LW@KARO-electronics.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=shawn.guo@freescale.com \
    /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.