From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16838 invoked by alias); 10 Nov 2009 10:38:02 -0000 Received: (qmail 16830 invoked by uid 22791); 10 Nov 2009 10:38:01 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Nov 2009 10:37:58 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id E4FA72F7855F; Tue, 10 Nov 2009 10:37:55 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY1zKD8hH38U; Tue, 10 Nov 2009 10:37:52 +0000 (GMT) Message-ID: <4AF94296.7040104@ecoscentric.com> Date: Tue, 10 Nov 2009 10:38:00 -0000 From: Ross Younger User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jonathan Larmour CC: Rutger Hofman , eCos developers Subject: Re: NAND technical review References: <4ACB4B58.2040804@ecoscentric.com> <4ACC61F0.3020303@televic.com> <4AD3E92E.5020301@jifvik.org> <4AD47ADE.9010606@cs.vu.nl> <4AD6A7EC.8080703@jifvik.org> <4ADC452B.5040706@ecoscentric.com> <4ADD14E1.3050702@jifvik.org> <4ADD8E47.1080305@ecoscentric.com> <4ADE6C92.9060300@jifvik.org> <4AE02E54.7000508@ecoscentric.com> <4AF8F6D7.1000709@jifvik.org> In-Reply-To: <4AF8F6D7.1000709@jifvik.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-11/txt/msg00004.txt.bz2 > [syndrome] > So can you just confirm that (E) supports that form of hardware ECC > implementation? I've just googled up the outline of syndrome mode (which seems, incidentally, to be at least a de facto standard term). I don't see any reason I couldn't fit it in given my current hooks. > I also note > with the SAM9260 that the hardware ECC registers get wiped if you start > to read/write another page, so can you confirm or otherwise that no > other NAND API user can cause that to happen in (E)? The standard per-device locking provided by (E) will take care of this. If there is a risk of concurrent access to other devices causing problems it's trivial to add a further board-level lock in the driver. > The SAM9260 also > requires you to read the entire page data, followed immediately by the > spare area locations where the ECC is stored. Is that also supportable > by (E)? It looks like that's standard for syndrome-type ECC. I think this is just a funny OOB area layout, though as ever I'd have to try it and see to be sure. Ross (PS. BTW, I am still working on that fresh anon-based drop I promised the other week, but am trying to find out why the benchmarks are so screwy on the EA LPC2468 before I finish cutting the drop. And - speaking of ECC - sitting in my pile of queued commits I have a major speed-up in software ECC calculation...) -- Embedded Software Engineer, eCosCentric Limited. Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK. Registered in England no. 4422071. www.ecoscentric.com