This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: NAND technical review
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.
I will put up a next release when the documentation is done. I am aware
that changing the code while you are reviewing it is not very polite;
maybe you prefer to stick with the code that you have right now, and
just acknowledge any updates/refactoring I did.
An unusual problem has cropped up in my synth build. After having run my
tests on the BlackFin, I built for synth and I am now meeting weird
alignment behaviour in the HAL_TABLE device tabs. My gcc (gcc-4.2.real
(GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)) for synth generates a directive
.align 32 in the declaration of a device struct in the appropriate
section, but the HAL_TABLE array has align=4. In consequence, the
pointer to traverse the device table has the wrong stride. 'Proof': if I
hand-align the device struct to be a multiple of 32, things work
correctly in synth. Anybody any idea what I should do? Put in an
align(32) directive on the device struct definitions? That is a hack to
work around a compiler bug just for one platform, I'd say; OTOH it's bad
that it might just bite *any* synth device driver table, not only mine.
Finally, are there any questions about E's layer that you think I should
ask about which I haven't?
I am sorry, I have had no time to review E's layer. My boss tells me
loudly that doing so is not on the critical path of our project...
Rutger