From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29361 invoked by alias); 13 Oct 2009 19:58:59 -0000 Received: (qmail 29353 invoked by uid 22791); 13 Oct 2009 19:58:58 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from ip2.televic.com (HELO lx-dmz.televic.com) (81.82.194.222) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Oct 2009 19:58:54 +0000 Received: (qmail 5999 invoked from network); 13 Oct 2009 19:58:51 -0000 Received: from srv-vs06.televic.com (10.0.0.46) by lx-dmz.televic.com with (RC4-MD5 encrypted) SMTP; 13 Oct 2009 19:58:51 -0000 Received: from SRV-VS06.TELEVIC.COM ([10.0.0.46]) by SRV-VS06.TELEVIC.COM ([10.0.0.46]) with mapi; Tue, 13 Oct 2009 21:58:52 +0200 From: =?iso-8859-1?Q?Lambrecht_J=FCrgen?= To: 'Rutger Hofman' , Jonathan Larmour CC: Ross Younger , eCos developers , Deroo Stijn Date: Tue, 13 Oct 2009 19:58:00 -0000 Subject: RE: NAND technical review Message-ID: <6EE7D1502C48E44E92DCADF9DD3E0DB9012151FBEFDB@SRV-VS06.TELEVIC.COM> References: <4ACB4B58.2040804@ecoscentric.com> <4ACC61F0.3020303@televic.com> <4AD3E92E.5020301@jifvik.org> <4AD48DB0.1090309@cs.vu.nl> In-Reply-To: <4AD48DB0.1090309@cs.vu.nl> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-10/txt/msg00018.txt.bz2 > -----Original Message----- > From: ecos-devel-owner@ecos.sourceware.org [mailto:ecos-devel- > owner@ecos.sourceware.org] On Behalf Of Rutger Hofman > Sent: dinsdag 13 oktober 2009 16:25 > To: Jonathan Larmour > Cc: Lambrecht J=FCrgen; Ross Younger; eCos developers; Deroo Stijn > Subject: Re: NAND technical review > > Jonathan Larmour wrote: > > J=FCrgen 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=FCrgen > > Rutger