This is the mail archive of the
mailing list for the eCos project.
Re: NAND technical review
- From: Rutger Hofman <rutger at cs dot vu dot nl>
- To: Jonathan Larmour <jifl at jifvik dot org>
- Cc: Jürgen Lambrecht <J dot Lambrecht at televic dot com>, Ross Younger <wry at ecoscentric dot com>, eCos developers <ecos-devel at ecos dot sourceware dot org>, Deroo Stijn <S dot Deroo at televic dot com>
- Date: Tue, 13 Oct 2009 16:24:48 +0200
- Subject: Re: NAND technical review
- References: <4ACB4B58.firstname.lastname@example.org> <4ACC61F0.email@example.com> <4AD3E92E.firstname.lastname@example.org>
Jonathan Larmour wrote:
Jürgen Lambrecht wrote:
- Two: also the Micron MT29F2G08AACWP-ET:D 256MB 3V3 NAND FLASH (2kB
page size, x8)
Because if this chip, Rutger adapted the hardware ECC controller code,
because our chip uses more bits (for details, ask Stijn or Rutger).
I'd be interested in what the issue was. From admittedly a quick look I
can't find anything about this in the code.
As things go with NAND, this was not a chip issue but a controller
issue. This controller has a different approach to hardware ECC than
most; it doesn't export the ECC sum values, but the ECC syndromes --
values that in their bit pattern indicate where any bit errors are. I
added ECC_SYNDROME support to my generic controller code. If I compare
with MTD, I think with this addition, R kind/a covers the range of ECC
hardware support types that currently are in existence.
I don't know whether Televic (Stijn) actually uses the ECC_SYNDROME
code. Last thing I heard, coincident with my adding ECC_SYNDROME, is
that they had already solved their performance issues differently, but I
don't know what happened after that.