From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3993 invoked by alias); 13 Oct 2009 12:59:15 -0000 Received: (qmail 3980 invoked by uid 22791); 13 Oct 2009 12:59:14 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-vbr9.xs4all.nl (HELO smtp-vbr9.xs4all.nl) (194.109.24.29) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Oct 2009 12:59:09 +0000 Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id n9DCwx4w056494; Tue, 13 Oct 2009 14:59:05 +0200 (CEST) (envelope-from rutger@cs.vu.nl) Message-ID: <4AD47ADE.9010606@cs.vu.nl> Date: Tue, 13 Oct 2009 12:59:00 -0000 From: Rutger Hofman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jonathan Larmour CC: =?ISO-8859-1?Q?J=FCrgen_Lambrecht?= , Ross Younger , eCos developers , Deroo Stijn Subject: Re: NAND technical review References: <4ACB4B58.2040804@ecoscentric.com> <4ACC61F0.3020303@televic.com> <4AD3E92E.5020301@jifvik.org> In-Reply-To: <4AD3E92E.5020301@jifvik.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/msg00015.txt.bz2 Jonathan Larmour wrote: [snip] >> We also prefer R's model of course because we started with R's model >> and use it now. > > You haven't done any profiling by any luck have you? Or code size > analysis? Although I haven't got into the detail of R's version yet > (since I was starting with dissecting E's), both the footprint and the > cumulative function call and indirection time overhead are concerns of > mine. In a first step in mitigating the 'footprint pressure', I have added CDL options to configure in/out support for the various chips types, to wit: - ONFI chips; - 'regular' large-page chips; - 'regular' small-page chips. It is in r678 on my download page (http://www.cs.vu.nl/~rutger/software/ecos/nand-flash/). As I had suggested before, this was a very small refactoring (although code has moved about in io_nand_chip.c to save on the number of #ifdefs). One more candidate for a reduce in code footprint: I can add a CDL option to configure out support for heterogeneous controllers/chips. The ANC layer will become paper-thin then. If this change will make any difference, I will do it within, say, a week's time. As regards the concerns for (indirect) function call overhead: my intuition is that the NAND operations themselves (page read, page write, block erase) will dominate. It takes 200..500us only to transfer a page over the data bus to the NAND chip; one recent data sheet mentions program time 200us, erase time 1.5ms. I think only a very slow CPU would show the overhead of less than 10 indirect function calls. Rutger