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

Jonathan Larmour wrote:
But this is an open discussion, so I'd appreciate anyone's views. I'd especially value Simon Kallweit's views as someone who has actually used both code implementations which gives him a very good perspective. Although if anyone wants to contribute, please keep it on topic, within this thread, and technical.

I have been following the NAND discussion since it started two weeks ago. I actually don't have much to add, because I think most points have been brought to topic already. Also I currently don't have an immediate necessity for NAND flash support in our products, so it's not of high priority to me at the moment.

I still try to give a quick flashback of my work with both R's and E's implementations. I started out using R's implementation, trying to add a driver for synthetic NAND chips, which would not exist back then. In the meantime Rutger has implemented a synthetic chip, but in form of a NAND controller and not as I have tried, in form of a NAND chip. In retrospective, this seems to be the better (and simpler) approach. What I dislike is how the synthetic chips have to be configured. R's implementation needs the user to assign a valid NAND chip device id, which will then be used through chip interrogation to determine the chips geometry. I find it much more useful if you can directly define the chips geometry in CDL, as it's more explicit. This brings me to my biggest concern with R's design. It's pretty rigid in terms of future chip implementations. Sure if everyone is going to make ONFI chips in the future, that's fine. Otherwise, parts of the layering could be rendered wrong/useless rather soon. I also dislike the generic determination of the chip geometry in io_nand_chip.c:read_id(). IMHO it is already a bit messy by mixing interrogation for small-page, large-page and ONFI chips. This is probably fine, until exceptions have to be implemented to support more exotic chips. I might be wrong, as I think MTD does chip interrogation in a similar way. E's model splits chip interrogation into the drivers, adding more flexibility in turn for a bit of code duplication.

My work with E's framework involved writing basic drivers for the STM32 evaluation board as well as doing a few tests with YAFFS1. This was a breeze. I only implemented the basics, adapting/copying the drivers from Ross. It occurred to me, that a lot of the code could just straight be copied. So there is a certain level of code duplication in E's framework, but as John pointed out, it's questionable if things like address/command writing etc. should be abstracted out, as they are so simple, and may need adjustment in the future for new chips. In general, I think E's code is more lightweight and quite a bit looser in coupling, which I think results in smaller code size, lower overhead but most importantly in more flexibility. Just the right thing for a platform where resources are scarce. My tests with YAFFS1 were promising, but I had to realize that YAFFS just needs too much memory for my current platform, so I abandoned it.

My current preference clearly is with E's framework. But I might be biased, as my current platform is quite low on resources, and I'm looking for a small, simple and lightweight framework.

I will gladly elaborate in more detail if there are further questions about my experience with both frameworks.


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