Re: NAND & YAFFS

[Rutger Hofman <rutger at cs dot vu dot nl>]

Well, it is certainly time for me to voice my reaction to this news; 
sorry for the delay, caused by slow communication with my direct boss 
(on the CC:) because she is currently at the opposite side of the globe 
(and parental leave days).

My employer (the VU Amsterdam, i.c. Prof. Andrew Tanenbaum's group) and 
the funder of our project had me spend 2..3 months in designing and 
making a NAND flash package from scratch plus an interface layer for 
YAFFS, with the explicit side-goal of contributing something substantial 
to the open-source community, i.c. eCos. I dutifully followed eCos' 
outlined procedures to avoid double work, and did RFCs and notification 
of early release (including the statement that it is complete on my 
BlackFin hardware, and that it had survived some long YAFFS tests). 
Sure, I picked up the comments made by Andrew Lunn.

Allow me to confess that I am disappointed that the work I put into NAND 
flash for eCos has not been considered by eCosPro. The main reason they 
give is that it is in alpha state, and that my time line was unknown. I 
think that it would have been entirely possible and very much 
appropriate if eCosPro had asked me about stability and about my 
timeline. These questions for sure wouldn't have harmed confidentiality.

The answer to the questions would have been: I say it is in alpha state 
because features that cannot be tested on my hardware are actually 
untested: e.g. the small-page chip instruction set or multiple, 
heterogeneous controllers/chips. My package has been stress-tested on my 
hardware, both NAND- and YAFFS-wise; it has been ported by Televic.be to 
their platform, and I am proud to report that no bugs came out even 
though their controller and ECC are entirely different (except for one 
thingy in a debug check, where my precautions to cover against YAFFS's 
unaligned struct fields proved insufficient).

Another reason that I think eCosPro has not chosen the wisest course 
here is the shadow it throws into the future. Isn't it an unattractive 
proposition for anyone who would want to contribute that they will only 
afterwards be informed that their work may be out-competed by eCosPro 
themselves?

So, the current state is that there are two NAND flash packages, both of 
which are complete and tested as far as their developer's hardware 
allows: single controller and single NAND chip. Work on YAFFS 
interfacing is complete and stress-tested (me) or nearing completion 
(eCosPro).

Kind regards,

Rutger Hofman
VU Amsterdam

Ross Younger wrote:
> Dear maintainers,
>
> We (eCosCentric) have been working on a NAND layer for eCos and integration
> with YAFFS, which we intend to contribute. Unfortunately, due to commercial
> considerations - including licensing and technical discussions with Aleph
> One - we have previously had to keep quiet about it. We can now talk about
> this work publicly, and would like to explore how the best overall solution
> for the eCos project can be pulled together.
>
> Obviously two alternative implementations and further duplication of work is
> best avoided, so we have opened a discussion with Rutger to see if there are
> ways in which we can work together to try and find a common "best of breed"
> technical solution.
>
> It seems sensible that the maintainers are aware of this discussion and have
> the opportunity to provide input and direction.
>
> A quick overview of our status:
>
> * We have developed a NAND interface library, drivers for a single
> chip+board combination and a synthetic pseudo-device, and an adaptation
> layer to bring YAFFS into eCos via the fileio layer. Specific further
> support for RedBoot is also in the works.
> * The NAND layer is complete and fully documented; YAFFS integration is
> approaching completion.
> * Written testcases exist for the NAND layer and YAFFS, and they will be
> subject to the same rigorous in-house automated test processes we use for
> all eCosPro code.
> * All of our code is intended to be contributed back to eCos, except of
> course the GPL parts of YAFFS itself. We have included in our plan building
> YAFFS as a separate .epk file so users who are happy with the GPL can easily
> download it and install using ecosadmin.tcl.
>
> We had looked at Rutger's early work, but decided against using it. Part of
> the reason for this was that integrating alpha code from other sources is
> always difficult, and we were (still are) operating under commercial time
> pressures. It would have been difficult for us to go public before now
> without sounding like we were taking advantage of Rutger's work, or
> compromising the project's earlier need for confidentiality. There were also
> some technical considerations; our NAND library has fewer layers, and our
> YAFFS integration is subtly different.
>
> Please let me know your thoughts. I can provide an interim documentation or
> code drop if you'd like to see one. (The NAND layer is complete; YAFFS is
> still being worked on, and RedBoot will be next.)
>
> Regards,
>
>
> Ross