All of lore.kernel.org
 help / color / mirror / Atom feed
From: pieterg@gmx.com (pieterg)
To: linux-arm-kernel@lists.infradead.org
Subject: pxa3xx_nand issues
Date: Fri, 1 Oct 2010 08:55:52 +0200	[thread overview]
Message-ID: <201010010855.52532.pieterg@gmx.com> (raw)
In-Reply-To: <201010010215.09514.marek.vasut@gmail.com>

On Friday 01 October 2010 02:15:09 Marek Vasut wrote:
> Dne Po 27. z??? 2010 19:39:04 pieterg napsal(a):
> > On Monday 27 September 2010 15:50:50 pieterg wrote:
> > > On Monday 27 September 2010 14:22:37 Lei Wen wrote:
> > > > Does your jffs2 image make correct? Page size and block size set
> > > > right?
> > >
> > > I think so.
> > > --eraseblock=0x20000 --pad --no-cleanmarkers
> >
> > Well... that caused most of my problems.
> > --pad means pad to eraseblock size, not pagesize.
> > So the first writes in the new filesystem would cause pages in that
> > last eraseblock to be overwritten.
> > With SLC I always got away with that, but with MLC, clearly not.
> >
> > (now I'm still left with lots of singlebit errors, and occasional jffs2
> > CRC errors, pxa3xx_nand was obviously not meant to deal with such low
> > quality MLC, no action is taken on bit errors, but at least everything
> > can be explained now)
> >
> > Thanks everybody for helping me find the cause of this problem.
>
> So this is closed?

Yes, I guess what remains (many single bit errors, and occasional double bit 
errors) is 'normal' for this type of MLC NAND.
Still not happy with it, especially since there is no way to recover when 
double bit errors occur, but for now this will have to do.

> btw. wont ubifs be better choice for such a big flash ?

Certainly, it's on my list (after I've updated to the latest u-boot to get 
ubi support there as well)

Rgds, Pieter

  reply	other threads:[~2010-10-01  6:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-22 17:12 pxa3xx_nand issues pieterg
2010-09-23  6:05 ` Eric Miao
2010-09-23 11:32   ` pieterg
2010-09-23 15:29     ` pieterg
2010-09-23 18:03       ` Matt Reimer
2010-09-25  2:50       ` Haojian Zhuang
2010-09-27 11:38         ` pieterg
2010-09-26 14:32       ` Lei Wen
2010-09-27 11:54         ` pieterg
2010-09-27 12:22           ` Lei Wen
2010-09-27 13:50             ` pieterg
2010-09-27 17:39               ` pieterg
2010-10-01  0:15                 ` Marek Vasut
2010-10-01  6:55                   ` pieterg [this message]
2010-10-01  7:25                     ` Marek Vasut

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=201010010855.52532.pieterg@gmx.com \
    --to=pieterg@gmx.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 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.