On Tue, Jul 5, 2011 at 3:58 PM, Matthew L. Creech mlcre...@gmail.com wrote:
Separately, I set up 2 test devices to run while I was away last week.
One of them contained 2 patches:
- Mike Hench's patch which eliminates this block of code in fsl_elbc_nand.c
- Adam Thomson's patch
On Fri, Jun 17, 2011 at 5:34 PM, Scott Wood scottw...@freescale.com wrote:
It seems that the generic code always passes -1 with PAGEPROG, and only
provides the actual page address on SEQIN.
I don't think the ECC readback is needed, and the fact that it looks like
it has always been broken
On Mon, 2011-06-20 at 07:22 -0400, Atlant Schmidt wrote:
As far as I know (and I'm sure the list will correct
me if I'm wrong! ;-) ), neither UBI nor UBIFS nor any
Linux layer provides this routine scrubbing; you have
to code it up yourself, probably by accessing the
device at the
@lists.ozlabs.org; linux-...@lists.infradead.org
Subject: RE: NAND BBT corruption on MPC83xx
Scott Wood wrote:
As for the corruption, could it be degradation from repeated reads of
that
one page?
Read Disturb. I Did not know SLC did that.
It just takes 10x as long as MLC, on the order of a million
On Fri, Jun 17, 2011 at 5:34 PM, Scott Wood scottw...@freescale.com wrote:
As for the corruption, could it be degradation from repeated reads of that
one page?
Could be. I think Mike's theory was that the -1 page_addr sort of
wrapped around, and caused us to read in the last block on flash
Scott Wood wrote:
As for the corruption, could it be degradation from repeated reads of
that
one page?
Read Disturb. I Did not know SLC did that.
It just takes 10x as long as MLC, on the order of a million reads.
Supposedly erasing the block fixes it.
It is not a permanent damage thing.
I was
On Fri, 17 Jun 2011 16:54:27 -0400
Matthew L. Creech mlcre...@gmail.com wrote:
Hi, I posted this on the Linux-MTD list but haven't gotten any hits.
Since it looks like it could be MPC83xx-specific, I'm reposting here.
Rick Johnson noted a problem in fsl_elbc_nand.c back in May which
might be
