This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: NAND technical review
- From: Rutger Hofman <rutger at cs dot vu dot nl>
- To: Jonathan Larmour <jifl at jifvik dot org>
- Cc: Jürgen Lambrecht <J dot Lambrecht at televic dot com>, Ross Younger <wry at ecoscentric dot com>, eCos developers <ecos-devel at ecos dot sourceware dot org>, Deroo Stijn <S dot Deroo at televic dot com>
- Date: Tue, 13 Oct 2009 15:04:30 +0200
- Subject: Re: NAND technical review
- References: <4ACB4B58.2040804@ecoscentric.com> <4ACC61F0.3020303@televic.com> <4AD3E92E.5020301@jifvik.org>
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