This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: NAND technical review
Rutger Hofman wrote:
Jonathan Larmour wrote:
Rutger Hofman wrote:
but I would hope the BBT implementation would support different
controllers without a lot of reworking - right now, accessing the
chip already goes through controller calls. The indirections would be
few: one for each top-level API call (unless the ANC must
redistribute application pages to chip pages, which is only in case
of heterogeneous chips).
It's not just indirecting the functions, but checking what may need
changing for anything which accesses the controller data, e.g. the
contents of struct CYG_NAND_CTL.
OK, to answer this question, the level of detail will go up considerably.
Lots of CYG_NAND_CTL is pointers to higher layers (anc) and lower layers
(funs, priv, chip stuff). These would remain, although the function
dispatch table would be reused (or unused, I don't know about OneNAND
varieties). The ECC fields would remain too (if applicable, but nowadays
that is a CDL option) and likewise mutex. I would guess that any state
for the different class of controller/chip could be incorporated into priv.
Ok. And associated code updates of course.
So, (surprisingly to me because I didn't consider anything else than raw
NAND), CYG_NAND_CTL seems generic enough to incorporate other types of
NAND chip. I'd say the controller-common API must stay -- if it doesn't,
I would be doubtful to fit it into a NAND harness. Reminder to self: ANC
must call the controller over a function dispatcher.
Although there are other ways to test code than requiring it to have an
abstract API in order to access internals. Having the anc/controller/chip
layers as self-contained APIs necessarily incurs some overheads.
CYG_NAND_CHIP would need to be split into a generic part that has page
size, block size, num blocks, and type-specific stuff like timing and
like the bucket-full of ONFI parameters.
Also looking at all the source files there are quite a few parts which go
straight to the chip layer. Again I'm not saying it can't be done, but it
looks like it requires a lot of unpicking, and making sure the right bits
end up in the most appropriate places.
[snip]
Thanks for the various outlines.
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!
Personal note: I am glad with this kind of detailed feedback. Still, I
would have preferred to get it when I put up the NAND design for
discussion, about a year ago.
Obviously Andrew was able to advise on some aspects at the time. But also
at that point in time, my own understanding of the requirements of a NAND
layer wasn't as developed as it has now become so I wouldn't have been
able to give you that level of feedback then anyway.
Although I'm reluctant to do so, I think it would probably prove valuable
to the decision process if I could do some size and timing measurements.
I'll have to look at that, but as I'll need to adapt E's rwbenchmark.c to
R, it'll take me a little time.
Finally, are there any questions about E's layer that you think I should
ask about which I haven't?
Jifl
--
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine