public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
From: Ross Younger <wry@ecoscentric.com>
To: ecos-maintainers@ecos.sourceware.org
Cc: Rutger Hofman <rutger@cs.vu.nl>,
	  Simon Kallweit <simon.kallweit@intefo.ch>,
	 Sergei Gavrikov <sergei.gavrikov@gmail.com>
Subject: NAND & YAFFS
Date: Wed, 13 May 2009 13:59:00 -0000	[thread overview]
Message-ID: <4A0AD212.60208@ecoscentric.com> (raw)

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

-- 
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071.                  www.ecoscentric.com

             reply	other threads:[~2009-05-13 13:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-13 13:59 Ross Younger [this message]
2009-05-13 14:22 ` Simon Kallweit
2009-05-13 16:28   ` Sergei Gavrikov
2009-05-13 19:03 ` John Dallaway
2009-05-15 16:50   ` Ross Younger
2009-05-16 10:43     ` Andrew Lunn
2009-05-16 12:50       ` Ross Younger
2009-05-18  7:13     ` Andrew Lunn
2009-05-18 10:42       ` Rutger Hofman
2009-06-02 18:18       ` John Dallaway
2009-06-03  6:55         ` Andrew Lunn
2009-05-14 18:41 ` Rutger Hofman
2009-05-15  9:48   ` John Dallaway
2009-05-15  9:52   ` Andrew Lunn
2009-05-15 10:18     ` Simon Kallweit
2009-05-16  9:50       ` Andrew Lunn
2009-05-18  9:39         ` Paul Beskeen
2009-05-18  9:55           ` Simon Kallweit
2009-05-15 16:19     ` Paul Beskeen
2009-05-15  6:44 cetoni GmbH - Uwe Kindler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A0AD212.60208@ecoscentric.com \
    --to=wry@ecoscentric.com \
    --cc=ecos-maintainers@ecos.sourceware.org \
    --cc=rutger@cs.vu.nl \
    --cc=sergei.gavrikov@gmail.com \
    --cc=simon.kallweit@intefo.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).