From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30892 invoked by alias); 8 Oct 2009 12:31:56 -0000 Received: (qmail 30880 invoked by uid 22791); 8 Oct 2009 12:31:55 -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; Thu, 08 Oct 2009 12:31:45 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 6EFDB2F78034; Thu, 8 Oct 2009 13:31:43 +0100 (BST) 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 F+TFpozZ1rPk; Thu, 8 Oct 2009 13:31:41 +0100 (BST) Message-ID: <4ACDDBB5.9060902@ecoscentric.com> Date: Thu, 08 Oct 2009 12:31:00 -0000 From: Ross Younger User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Rutger Hofman CC: Jonathan Larmour , eCos developers Subject: Re: NAND technical review References: <4AC6218C.20407@jifvik.org> <4ACB4B58.2040804@ecoscentric.com> <4ACC8640.6080605@cs.vu.nl> In-Reply-To: <4ACC8640.6080605@cs.vu.nl> 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-10/txt/msg00009.txt.bz2 Rutger Hofman wrote: > R has part-read and part-write support. One thing that has always > puzzled me is how this interacts with ECC. ECC often works on a complete > subpage, like 256 bytes on a 2KB page chip; then I understand. But what > if the read/write is not of such a subpage? This is a very good question - I revisited it the other day when working on hardware ECC support for the customer port I'm working on - and I don't have a particularly good answer for it. If the read is less than an ECC stride[*], one could perhaps fill in the ECC calculation by reading the rest of that stride's worth anyway and not passing it to the caller. Similarly, a write that is less than a stride could be "filled in" with 0xFF for the purposes of computing its ECC. How this would be achieved efficiently is an exercise for the reader as a bit of refactoring is likely to be involved... [*] I'm using "stride" here to mean the amount of data that an ECC calculation operates over. The Samsung algorithm which computes 22 bits of ECC over 256 bytes of data is common, not least of which because that's the one used by the Linux MTD layer. I did wonder about not supporting less-than-page reads and writes at all, but my code currently tries its best on the grounds of being liberal in what it accepts. In passing, I note that some large page devices allow the data and spare areas to be written in subpages (e.g. this Samsung K9 chip to hand - 2048 main + 64 spare per page - allows writes in units of 512 main and 16 spare); there might be a use to be found here in allowing an application to treat a large page device as if it were a small-page device. Ross -- Embedded Software Engineer, eCosCentric Limited. Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK. Registered in England no. 4422071. www.ecoscentric.com