This is the mail archive of the ecos-devel@sourceware.org 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] |
Jonathan Larmour wrote: [snip]
A device number does seem to be a bit limiting, and less deterministic. OTOH, a textual name arguably adds a little extra complexity.
I note Rutger's layer needs an explicit init call, whereas yours DTRT using a constructor, which is good.
Does your implementation _require_ a BBT in its current implementation? For simpler NAND usage, it may be overkill e.g. an application where the number of rewrites is very small, so the factory bad markers may be considered sufficient.
(b) Dynamic memory allocation
R's layer mandates the provision of malloc and free, or compatible functions. These must be provided to the cyg_nand_init() call.
That's unfortunate - that limits its use in smaller boot loaders - a key application.
E's doesn't; instead it declares a small number of static buffers.
I assume everything is keyed off CYGNUM_NAND_PAGEBUFFER, and there are no other variables. Again I'm thinking of the scenario of single firmware - different board revs. Can you confirm?
Andrew Lunn opined on 6/3/09 that R's requirement for malloc is not a major
issue because the memory needs of that layer are well-bounded; I think I
broadly agree, though the situation is not ideal in that it forces somebody
who wants to use a lean, mean eCos configuration to work around.
The overhead of including something like malloc/free in the image may compare badly with the amount of memory R's needs to allocate in the first place. I also note that if R's implementation has program verifies enabled it allocates and frees a page _every_ time. If nothing else this could lead to heap fragmentation.
- R's model shares the command sequence logic amongst all chips,
differentiating only between small- and large-page devices. (I do not know
whether this is correct for all current chips, though going forwards seems
less likely to be an issue as fully-ONFI-compliant chips become the norm.)
Hmm. Nevertheless, this is a concern for me with R's. I'm concerned it may be too prescriptive to be robustly future-proof.
One could say that makes it a more realistic emulation. But yes I can see disadvantages with a somewhat rigid world view. Thinking out loud, I wonder if Rutger's layer could work with something like Samsung OneNAND.
Incidentally I note Rutger has a "Samsung" ECC implementation, whereas you support Samsung K9 chips, but use the normal ECC algorithm. Did Samsung change their practice?
I would certainly appreciate feedback from anyone who has used R's layer. What you say would seem to imply that both small page and OFNI are untested in R's layer.
I'd need feedback from Rutger as to what level of testing has been done with his.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |