This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: NAND technical review
- From: Jonathan Larmour <jifl at jifvik dot org>
- To: Rutger Hofman <rutger at cs dot vu dot nl>
- Cc: eCos developers <ecos-devel at ecos dot sourceware dot org>, Ross Younger <wry at eCosCentric dot com>
- Date: Tue, 10 Nov 2009 07:03:02 +0000
- Subject: Re: NAND technical review
- References: <4AC6218C.20407@jifvik.org> <4ACB4B58.2040804@ecoscentric.com> <4ACC0722.9020601@jifvik.org> <4ACCC13F.40009@cs.vu.nl> <4AD69BBE.6070103@jifvik.org> <4AD73386.4030300@cs.vu.nl> <4AD7CD29.1050701@jifvik.org> <4ADC777F.4020506@cs.vu.nl> <4ADD2CAB.4010000@jifvik.org> <4ADDAC7A.1070206@cs.vu.nl> <4ADE679D.1050900@jifvik.org> <4ADEFCFE.9060603@cs.vu.nl> <4AE1B864.1040409@jifvik.org> <4AE1CAD0.4080206@cs.vu.nl>
Rutger Hofman wrote:
Jonathan Larmour wrote:
Rutger Hofman wrote:
Jonathan Larmour wrote:
Rutger Hofman wrote:
[on adding support for other NAND chips than raw NAND]
I guess that this refactoring will take something like one or a few
days' work, including having ANC call the controller over a dispatch
table. I'll be glad to do it (ETA: somewhere in the next 1 to 1.5
months).
I would be very surprised by a day!
Yesterday, there was an unexpected lull in the usual storm of work.
Basically, the refactoring is done so R can support hardware other than
raw NAND. I must still update the documentation, though. The structure
is a bit different than I first thought; there is a package IO_NAND for
the general stuff (anc, ecc, bbt), and a package IO_NAND_RAW for the raw
NAND. So, if somebody wants NAND but not raw NAND, that package isn't
included so no raw NAND code.
Wow! That's very interesting and despite what I said at the outset, I've
got your updated code and will now be referring to it. I see a few rough
edges but it appears you're already aware of some of them. It's a shame
more of the spare layout code wasn't potentially shareable.
I think I really have to get some comparative measurements on code size
and performance at least. It's tricky when there is no common hardware.
Not even a common architecture (given Jurgen's SAM9260 port isn't public).
And no common chip even then. I think that unless someone is willing to
port one or other to a common piece of hardware, then the only recourse is
the synthetic target.
I've now built both implementations and run all tests successfully on
synth for both. Now I "just" need to finish porting rwbenchmark.c to (R).
Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine