This is the mail archive of the
mailing list for the eCos project.
Re: NAND review
- From: Rutger Hofman <rutger at cs dot vu dot nl>
- To: Simon Kallweit <simon dot kallweit at intefo dot ch>
- Cc: Jonathan Larmour <jifl at jifvik dot org>, "ecos-devel at ecos dot sourceware dot org" <ecos-devel at ecos dot sourceware dot org>
- Date: Wed, 20 May 2009 13:16:44 +0200
- Subject: Re: NAND review
- References: <4A126D59.email@example.com> <4A134A31.firstname.lastname@example.org> <4A13AD30.email@example.com>
Simon Kallweit wrote:
Jonathan Larmour wrote:
that). But I'm also concerned about possibly having too much layering
in Rutger's version for small simple implementations.
Well, there is one obvious candidate for being thinned out in my NAND
implementation: the ANC layer that hides the presence of multiple
controllers and/or chips. Making this optional for the (common) case of
one controller and one (or multiple identical) chips will be easy.
This leaves 3 layers:
- common controller code, which takes care of unavoidable nuisances like
spare layout, ECC handling, etc;
- controller-specific driver code;
- chip code that does interrogation and bad-block management; this, as
often as not, is just the common large-page regular chip implementation,
so no chip-specifics. Later in life we will see ONFI chips rule (maybe!)
-- no chip-specifics here either.
I dislike the idea of code duplication, and so much is common across
controller functionality. Hence the split into common and
device-specific code, which enforces an API in-between. I did my best to
design this API in a way that is flexible and powerful, but of course I
cannot rule out that controllers exist that fit this interface only with
a lot of workarounds. Needless to say, I am very much open to
suggestions for improvement.
AFAIK, Linux's MTD also has an API between common and specific
controller code, but it allows even more pluggability for controllers
than my design. I wouldn't be surprised if all common code can be
run-time replaced in MTD.