From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9868 invoked by alias); 10 Nov 2009 05:15:18 -0000 Received: (qmail 9843 invoked by uid 22791); 10 Nov 2009 05:15:15 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from virtual.bogons.net (HELO virtual.bogons.net) (193.178.223.136) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Nov 2009 05:15:10 +0000 Received: from jifvik.dyndns.org (jifvik.dyndns.org [85.158.45.40]) by virtual.bogons.net (8.10.2+Sun/8.11.2) with ESMTP id nAA5F6429874; Tue, 10 Nov 2009 05:15:06 GMT Received: from [172.31.1.126] (neelix.jifvik.org [172.31.1.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jifvik.dyndns.org (Postfix) with ESMTP id BCD2F3FF4; Tue, 10 Nov 2009 05:15:05 +0000 (GMT) Message-ID: <4AF8F6D7.1000709@jifvik.org> Date: Tue, 10 Nov 2009 05:15:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) MIME-Version: 1.0 To: Ross Younger 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> In-Reply-To: <4AE02E54.7000508@ecoscentric.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00002.txt.bz2 [ Sorry all for the loss of momentum. Real life intervened for a while. ] Ross Younger wrote: > Jonathan Larmour wrote: > >>Can you at least shed light on the API changes (by cut'n'pasting >>relevant sections of headers/code even if not the whole thing)? > > > I have changed the device interface (nand_device.h) by carving up the read > and write page functions into three. (The prototype changes are the same for > both, with only the obvious semantic differences when writing, so I'll only > paste in read for the sake of brevity.) > > Reading a page used to be an all-in-one call: > > int (*read_page) (cyg_nand_device *dev, cyg_nand_page_addr page, > void * dest, size_t size, void * spare, size_t spare_size); > > Now, the NAND layer calls "begin" once to set up the read: > > int (*read_begin)(cyg_nand_device *dev, cyg_nand_page_addr page); > > ... "stride" one or more times to actually transfer data > > int (*read_stride)(cyg_nand_device *dev, void * dest, size_t size); > > ... and then "finish" once to do the spare area and any finishing up that > may be necessary (e.g. send the "program confirm" command, unlock the device). > > int (*read_finish)(cyg_nand_device *dev, > void * spare, size_t spare_size); > > The ECC interface (nand_ecc.h, not well documented) has also expanded > slightly. I had had just a 'calc' call, but have now added an 'init' call so > that any device-specific registers can be tweaked. The interaction is > perhaps best sketched out as pseudocode; here's what the NAND library looks > like in a call to read a page: > > dev->read_begin(page number); > while (there are still bytes to send) { > ecc->init(); // may be a no-op > dev->read_stride(ecc->datasize bytes); > if (ecc is hardware) > ecc->calc(the block we've just read); > } > dev->read_finish(spare data); > if (ecc is software) > ecc->calc(the whole thing); > ecc->repair(the whole block, looping as necessary, comparing the > calculated ECC against what's in the spare area); > > > I have renamed the device interface struct and macros on the grounds of > "change the interface, change the name" (but not the ECC interface, because > nothing outside that package had used it before now). This seems reasonable at first glance. But to double check.... if you have an SoC with both built-in NFC and hardware ECC, it may be able to calc the ECC automatically as the pages are read/written through the NFC. What you can then get with reads is a direct result of whether the ECC has failed, whether it's recoverable or not. You don't have to actually look at the ECC value itself at any point. This is what Rutger calls ECC "syndrome" mode, which isn't a very descriptive term, but OTOH I can't think of anything much better either!). You can consider the Atmel SAM9260 to be a concrete example if that helps (although in that particular case you can see the actual computed ECC too - but (R) implies that that may not always be the case for reads). So can you just confirm that (E) supports that form of hardware ECC implementation? Or does it actually require the ECC to be directly available (as opposed to potentially just being a token)? 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 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 does seem that it is supported by (R), albeit complicated by the abstracted scatter-gather spare layout management. Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine