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

Dne P? 1. ??jna 2010 08:55:52 pieterg napsal(a):
> 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)

I'm currently fixing 2010.09, there were some changes that broke support for 
every pxa (or rather every ARM) machine. I have two machines fixed, but those are 
still pxa2xx. PXA3xx is on the list and thanks to this, pxa3xx should soon also 
hit mainline (well ... when, that depends on Wolfgang).

Cheers
> 
> Rgds, Pieter

      reply	other threads:[~2010-10-01  7:25 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
2010-10-01  7:25                     ` Marek Vasut [this message]

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=201010010925.34759.marek.vasut@gmail.com \
    --to=marek.vasut@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 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.