RE: NAND technical review

> -----Original Message-----
> From: [email protected] [mailto:ecos-devel-
> [email protected]] On Behalf Of Rutger Hofman
> Sent: dinsdag 13 oktober 2009 16:25
> To: Jonathan Larmour
> Cc: Lambrecht Jürgen; Ross Younger; eCos developers; Deroo Stijn
> Subject: Re: NAND technical review
>
> Jonathan Larmour wrote:
> > Jürgen Lambrecht wrote:
> [snip]
> >> - 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.
Indeed, we have not yet used it. Maybe by the end of the year.
Regards,
Jürgen

>
> Rutger