This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: NAND technical review


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]