linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dedekind1@gmail.com (Artem Bityutskiy)
To: linux-arm-kernel@lists.infradead.org
Subject: GPMI-NAND Status?
Date: Mon, 15 Aug 2011 19:34:45 +0300	[thread overview]
Message-ID: <1313426095.8691.44.camel@sauron> (raw)
In-Reply-To: <20040.59254.170515.492518@ipc1.ka-ro>

On Mon, 2011-08-15 at 11:31 +0200, Lothar Wa?mann wrote:
> Hi,
> 
> Ivan Djelic writes:
> > On Mon, Aug 15, 2011 at 06:41:23AM +0100, Lothar Wa?mann wrote:
> > > Hi,
> > > 
> > > Ivan Djelic writes:
> > > > On Fri, Aug 05, 2011 at 02:51:33PM +0100, Wolfram Sang wrote:
> > > > (...)
> > > > > 
> > > > > problem overwriting all-0xff data in NAND [2]
> > > > > =============================================
> > > > > 
> > > > > Although it occured only when writing JFFS2 images so far, this is a generic
> > > > > issue and needs to be fixed, right?
> > > > > 
> > > > > 
> > > > (...)
> > > > > [2] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037104.html
> > > > 
> > > > As explained in the thread linked above, this issue should be fixed in your
> > > > flashing tool, _not_ in your driver. The nand device you are using does not
> > > > support programming pages multiple times in a row; pretending it does in the
> > > >
> > > It's not a problem of the device (Samsung K9F1G08U0B in my case)! The
> > > problem is that the controller generates an ECC code that is non-FF
> > > for all-FF data, which JFFS2 cannot handle properly.
> > 
> > JFFS2 has nothing to do with it. JFFS2 does not assume it can program empty
> > pages and then reprogram them on a NAND flash device. You flashing method does.
> > 
> AFAICT JFFS2 checks the flash for areas that contain only FF and
> treats them like erased flash. At least it tries to overwrite such
> areas in flash without erasing it beforehand.

Right, when JFFS2 scans the flash and finds a partially-used eraseblock,
it tries to find out where the data ends and the empty space starts.
JFFS2 assumes that the empty space is usable, and it uses it. JFFS2
author just missed the fact that in case of newly flashed JFFS2 image
this empty space may be unusable. And this was extremely unlikely those
times.

You may teach JFFS2 to avoid using this space or to "clean it up", just
like we taught UBIFS to do this recently. The other option is to change
the flashing method. 

> I avoided the problem by creating JFFS2 images that are padded with
> oxff to page size only instead of eraseblock size.

Right.

> > Therefore... it is simply a matter of avoiding empty page programming, which
> > only happens in your flasher. See also the flashing guidelines [1] as per Artem
> > suggestion.
> > 
> "Your flasher" is the standard mtd-utils mkfs.jffs2 to create an image
> file and the U-Boot commands 'nand erase/nand write' or
> the mtd-utils 'flash_eraseall/nandwrite' to write it to flash.

I do not use these tools, but if they have issues - just fix them and
send patches.

-- 
Best Regards,
Artem Bityutskiy

  parent reply	other threads:[~2011-08-15 16:34 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-05 13:51 GPMI-NAND Status? Wolfram Sang
2011-08-08  6:21 ` Huang Shijie
2011-08-08  9:19   ` Koen Beel
2011-08-08 10:37     ` Huang Shijie
2011-08-08 12:42       ` Koen Beel
2011-08-09  6:36         ` Huang Shijie
2011-08-09  7:58           ` Koen Beel
2011-08-09  8:18             ` Huang Shijie
2011-08-09  8:25               ` Koen Beel
2011-08-09  5:11     ` Huang Shijie
2011-08-09  6:25       ` Koen Beel
2011-08-09  6:40         ` Huang Shijie
2011-08-09  9:45     ` Wolfram Sang
2011-08-09  9:35   ` Wolfram Sang
2011-08-09 10:54     ` Huang Shijie
2011-08-09 20:42       ` Wolfram Sang
2011-08-08  9:12 ` Huang Shijie
2011-08-09  9:19   ` Wolfram Sang
2011-08-09 10:41     ` Huang Shijie
2011-08-09 11:36       ` Lothar Waßmann
2011-08-14  8:11 ` Ivan Djelic
2011-08-14 18:31   ` Wolfram Sang
2011-08-15  5:41   ` Lothar Waßmann
2011-08-15  6:30     ` Lin Tony-B19295
2011-08-15  8:41       ` Ivan Djelic
2011-08-15  8:29     ` Ivan Djelic
2011-08-15  9:31       ` Lothar Waßmann
2011-08-15 12:54         ` Ivan Djelic
2011-08-15 13:37           ` Lothar Waßmann
2011-08-15 16:34         ` Artem Bityutskiy [this message]
2011-08-15 16:18     ` Artem Bityutskiy
2011-08-15 16:22   ` Artem Bityutskiy
2011-08-15 16:57     ` Ivan Djelic

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=1313426095.8691.44.camel@sauron \
    --to=dedekind1@gmail.com \
    --cc=linux-arm-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).