> -----Original Message----- > From: ecos-devel-ow...@ecos.sourceware.org [mailto:ecos-devel- > ow...@ecos.sourceware.org] 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
