This is the mail archive of the 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

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.


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?

--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

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