public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
* NAND & YAFFS
@ 2009-05-13 13:59 Ross Younger
  2009-05-13 14:22 ` Simon Kallweit
                   ` (2 more replies)
  0 siblings, 3 replies; 20+ messages in thread
From: Ross Younger @ 2009-05-13 13:59 UTC (permalink / raw)
  To: ecos-maintainers; +Cc: Rutger Hofman, Simon Kallweit, Sergei Gavrikov

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-05-13 13:59 NAND & YAFFS Ross Younger
@ 2009-05-13 14:22 ` Simon Kallweit
  2009-05-13 16:28   ` Sergei Gavrikov
  2009-05-13 19:03 ` John Dallaway
  2009-05-14 18:41 ` Rutger Hofman
  2 siblings, 1 reply; 20+ messages in thread
From: Simon Kallweit @ 2009-05-13 14:22 UTC (permalink / raw)
  To: Ross Younger; +Cc: ecos-maintainers, Rutger Hofman, Sergei Gavrikov

Ross Younger wrote:
> 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.)

Well, I certainly stop working on the NAND simulator then. Looks like 
this was just a first exercise into NAND flash then :) I'll be happy to 
work on device drivers for the STM32 if you haven't already written one. 
Also, I'm still interested in porting the UFFS filesystem.

I would be very glad to get the documentation and code of the NAND layer 
so I can start working.

Best regards
Simon

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-05-13 14:22 ` Simon Kallweit
@ 2009-05-13 16:28   ` Sergei Gavrikov
  0 siblings, 0 replies; 20+ messages in thread
From: Sergei Gavrikov @ 2009-05-13 16:28 UTC (permalink / raw)
  To: Simon Kallweit; +Cc: Ross Younger, ecos-maintainers, Rutger Hofman

Simon Kallweit wrote:
> Ross Younger wrote:
>> 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.)
>
> Well, I certainly stop working on the NAND simulator then. Looks like  
> this was just a first exercise into NAND flash then :) I'll be happy to  
> work on device drivers for the STM32 if you haven't already written one.  
> Also, I'm still interested in porting the UFFS filesystem.
>
> I would be very glad to get the documentation and code of the NAND layer  
> so I can start working.

And I stop work on that UFFS stub package for SIMRAM, as UFFS is getting
now a chance to seat on the offered Flash NAND layer from eCosCentric.
This is great, thank you.

Only one thing. I disliked an idea "a package upon your request". IMHO,
if eCosCentric said "A", let they say and "B": public the URL for their
GPLed package(s). It seems for me that companies which worry by "The GPL
Infection" will not use it and if they will, that's a care their lawyers.
But hobby projects will say THANKS for such an open ecos package(s).
Excuse this thought.

Regards,

Sergei

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-05-13 13:59 NAND & YAFFS Ross Younger
  2009-05-13 14:22 ` Simon Kallweit
@ 2009-05-13 19:03 ` John Dallaway
  2009-05-15 16:50   ` Ross Younger
  2009-05-14 18:41 ` Rutger Hofman
  2 siblings, 1 reply; 20+ messages in thread
From: John Dallaway @ 2009-05-13 19:03 UTC (permalink / raw)
  To: Ross Younger
  Cc: ecos-maintainers, Rutger Hofman, Simon Kallweit, Sergei Gavrikov

Hi Ross

Ross Younger wrote:

> 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.

Good news!

> 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.

[ snip ]

> 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.)

Which board have you targeted initially?

One of my concerns is that the NAND subsystem interfaces are appropriate
for other filesystems (such as UFFS) and for a broad range of NAND
devices. An interim code drop with any existing documentation would be
very welcome to kick-start the discussion.

John Dallaway

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-05-13 13:59 NAND & YAFFS Ross Younger
  2009-05-13 14:22 ` Simon Kallweit
  2009-05-13 19:03 ` John Dallaway
@ 2009-05-14 18:41 ` Rutger Hofman
  2009-05-15  9:48   ` John Dallaway
  2009-05-15  9:52   ` Andrew Lunn
  2 siblings, 2 replies; 20+ messages in thread
From: Rutger Hofman @ 2009-05-14 18:41 UTC (permalink / raw)
  To: Ross Younger
  Cc: ecos-maintainers, Simon Kallweit, Sergei Gavrikov,
	Melanie Rieback, Paul Beskeen

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
> 

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-05-14 18:41 ` Rutger Hofman
@ 2009-05-15  9:48   ` John Dallaway
  2009-05-15  9:52   ` Andrew Lunn
  1 sibling, 0 replies; 20+ messages in thread
From: John Dallaway @ 2009-05-15  9:48 UTC (permalink / raw)
  To: ecos-maintainers
  Cc: Ross Younger, Simon Kallweit, Sergei Gavrikov, Melanie Rieback,
	Paul Beskeen, Rutger Hofman

Rutger Hofman wrote:

> 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?

I have already responded to Rutger privately and am sure eCosCentric
will respond in due course. In the meantime, I would like to remind
everyone that the eCos maintainers operate independently of any
commercial organisation they may be a affiliated to. They try to ensure
the best possible outcome for the eCos project at two levels:

a) Technical progress
b) Health and growth of the user community

Be assured that all contributions are evaluated on their own technical
merits and that the views of the community will be taken into account.

John Dallaway
eCos maintainer

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  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-15 16:19     ` Paul Beskeen
  1 sibling, 2 replies; 20+ messages in thread
From: Andrew Lunn @ 2009-05-15  9:52 UTC (permalink / raw)
  To: Rutger Hofman
  Cc: Ross Younger, ecos-maintainers, Simon Kallweit, Sergei Gavrikov,
	Melanie Rieback, Paul Beskeen

Hi Folks

As an eCos maintainer i've been taking a back seat recently, pursuing
other interest etc. However i'm probably the most independent
maintainer since i've never worked for eCosCentric. 

[...]

> 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.

I fully agree with you here. You did all the right things. 

I wish i could of helped some more, but i have no real knowledge of
NAND, don't have any hardware which uses it and no real personal need
for it. I did consider writing a synth NAND emulator, as a way to get
into the subject more, but there is no really itch i needed to
scratch. 

Anyway, this is getting away from the point of the email...

> Allow me to confess that I am disappointed that the work I put into NAND  
> flash for eCos has not been considered by eCosPro. 

[...]
>
> 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?

This is also not the first time this has happened. A recent example
would be the Cortex-M3 work. If i dug into the email archives i could
find other examples. There is a possibility of it happening again soon
as well. eCosCentric have a more modern lwIP port in there tree than
the current in anoncvs. I understand they have optimized it for small
platform and made it more stable. There is the current effort going on
to update the anoncvs lwip code. When this reaches maturity, which
looks like will happen soon, are eCosCentric going to pull out there
trump card again and contribute there lwip port? 

In most of these cases there has been early communication from the
community. eCosCentric don't take part in such communications, which
is find disappointing. In fact the only module i can think of which
had open discussion between an open community development and
eCosCentric payed for by contract was the flash_v2 code.

They are a commercial organization, so do have some restrictions.
Fixed delivery dates, NDAs with customers, the desire to sell
something a couple of times to recoup their costs etc.  They also need
to defend against the case that somebody says they are going to
develop feature X, which eCosCentric already have, in a hope that
eCosCentric will make there version available for free. It seems to me
eCosCentric waits for the open version of feature X to reached beta
quality, is clearly going to be useable, but is incompatible to there
implementation. They then make there own available to easy there own
integration problems. By this time, whoever has implemented the open
version has spent a few man months and is not happy about there wasted
effort and maybe then being forced to port there device drivers etc to
eCosCentric infrastructure, so causing them more effort.

How can things be better? I would say eCosCentric needs to find a way
to be more open about what they are doing. Was this level of secrecy
needed for a NAND infrastructure? What has been gained by eCosCentrics
customer by keeping it secret? Why could eCosCentric, when it got the
contract, not jump into the discussion, suggest changes to the
proposed API and get it frozen. Maybe offered to take over development
of the core and ask Rutger to work on drivers for his specific devices
using the frozen API? If this could not be done out in the open would
it not of been possible to setup an NDA with Rutger and do it behind
closed doors until it was ready for release?

eCosCentric is also not benefiting from the community. They have lost
3 man months of effort from Rutger which could of been used for nearly
free to fulfil there customer contract! Once they released there
Cortex-M3 port a few bugs where quickly found which with a more open
development process would of been found earlier. There own products
could be made better from more interaction with the community.

How do we go forward with the NAND work? First impressions is that the
two implementations are roughly equal. So we need an open review of
both. Since eCosCentric are offering to contribute theres, please post
it to ecos-patches along side Rutgers, so all interested parties can
take part in the review.

     Andrew

        

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-05-15  9:52   ` Andrew Lunn
@ 2009-05-15 10:18     ` Simon Kallweit
  2009-05-16  9:50       ` Andrew Lunn
  2009-05-15 16:19     ` Paul Beskeen
  1 sibling, 1 reply; 20+ messages in thread
From: Simon Kallweit @ 2009-05-15 10:18 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Rutger Hofman, Ross Younger, ecos-maintainers, Sergei Gavrikov,
	Melanie Rieback, Paul Beskeen

Andrew Lunn wrote:
> Hi Folks
> 
> This is also not the first time this has happened. A recent example
> would be the Cortex-M3 work. If i dug into the email archives i could
> find other examples. There is a possibility of it happening again soon
> as well. eCosCentric have a more modern lwIP port in there tree than
> the current in anoncvs. I understand they have optimized it for small
> platform and made it more stable. There is the current effort going on
> to update the anoncvs lwip code. When this reaches maturity, which
> looks like will happen soon, are eCosCentric going to pull out there
> trump card again and contribute there lwip port? 

Well well, I almost saw that coming :/

I just wanted to say that I fully agree with your views Andrew. I really 
  hope the situation can be improved in the future. I think all parties 
could win by collaborating more with each other. Most of what can be 
improved here unfortunately seems to be in the hands of eCosCentric. 
They are the main force behind eCos development, invest lots of man-time 
into the project and therefore have quite a bit of authority over 
development. Unless the community wants to fork the project and go their 
own way, communication between eCosCentric and the community needs to be 
improved. Or at least we need a clear statement from eCosCentric towards 
what the community can and cannot expect.

Simon

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-05-15  9:52   ` Andrew Lunn
  2009-05-15 10:18     ` Simon Kallweit
@ 2009-05-15 16:19     ` Paul Beskeen
  1 sibling, 0 replies; 20+ messages in thread
From: Paul Beskeen @ 2009-05-15 16:19 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Rutger Hofman, Ross Younger, ecos-maintainers, Simon Kallweit,
	Sergei Gavrikov, Melanie Rieback

Hi Andrew,

You bring up some fair points (as do others in this thread) and I want
to respond to them separately from the necessary ongoing technical
discussion on the NAND layer front.

Andrew Lunn wrote:
> Hi Folks
> 
> As an eCos maintainer i've been taking a back seat recently, pursuing
> other interest etc. However i'm probably the most independent
> maintainer since i've never worked for eCosCentric. 
> 
> [...]
> 
>> 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.
> 
> I fully agree with you here. You did all the right things. 
> 
> I wish i could of helped some more, but i have no real knowledge of
> NAND, don't have any hardware which uses it and no real personal need
> for it. I did consider writing a synth NAND emulator, as a way to get
> into the subject more, but there is no really itch i needed to
> scratch. 
> 
> Anyway, this is getting away from the point of the email...
> 
>> Allow me to confess that I am disappointed that the work I put into NAND  
>> flash for eCos has not been considered by eCosPro. 
> 
> [...]
>> 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?
> 
> This is also not the first time this has happened. A recent example
> would be the Cortex-M3 work. If i dug into the email archives i could
> find other examples. There is a possibility of it happening again soon
> as well. eCosCentric have a more modern lwIP port in there tree than
> the current in anoncvs. I understand they have optimized it for small
> platform and made it more stable. There is the current effort going on
> to update the anoncvs lwip code. When this reaches maturity, which
> looks like will happen soon, are eCosCentric going to pull out there
> trump card again and contribute there lwip port? 
> 
> In most of these cases there has been early communication from the
> community. eCosCentric don't take part in such communications, which
> is find disappointing. In fact the only module i can think of which
> had open discussion between an open community development and
> eCosCentric payed for by contract was the flash_v2 code.
> 
> They are a commercial organization, so do have some restrictions.
> Fixed delivery dates, NDAs with customers, the desire to sell
> something a couple of times to recoup their costs etc.  They also need
> to defend against the case that somebody says they are going to
> develop feature X, which eCosCentric already have, in a hope that
> eCosCentric will make there version available for free. It seems to me
> eCosCentric waits for the open version of feature X to reached beta
> quality, is clearly going to be useable, but is incompatible to there
> implementation. They then make there own available to easy there own
> integration problems. By this time, whoever has implemented the open
> version has spent a few man months and is not happy about there wasted
> effort and maybe then being forced to port there device drivers etc to
> eCosCentric infrastructure, so causing them more effort.
> 
> How can things be better? I would say eCosCentric needs to find a way
> to be more open about what they are doing. Was this level of secrecy
> needed for a NAND infrastructure? What has been gained by eCosCentrics
> customer by keeping it secret? Why could eCosCentric, when it got the
> contract, not jump into the discussion, suggest changes to the
> proposed API and get it frozen. Maybe offered to take over development
> of the core and ask Rutger to work on drivers for his specific devices
> using the frozen API? If this could not be done out in the open would
> it not of been possible to setup an NDA with Rutger and do it behind
> closed doors until it was ready for release?
> 
> eCosCentric is also not benefiting from the community. They have lost
> 3 man months of effort from Rutger which could of been used for nearly
> free to fulfil there customer contract! Once they released there
> Cortex-M3 port a few bugs where quickly found which with a more open
> development process would of been found earlier. There own products
> could be made better from more interaction with the community.

I completely agree that it would have been better if eCosCentric could
have discussed development with Rutger earlier, and for that on behalf
of eCosCentric I offer an unreserved apology to Rutger. I wish we could
have handled this differently.

As you note above, sometimes commercial confidentiality issues do come
in to play and that unfortunately was the reason for the delayed
discussion of this work. Specifically there were two main elements at
play a) negotiations with Aleph One, and b) negotiations with customers.
As a golden rule we do not discuss our commercial plans and those of our
customers or partners in public. eCosCentric's standard commercial
contracting mode is not a time and material basis; but fixed price, fix
delivery date contracts. We have an built a reputation for delivering
complex but reliable software on time. A necessary side-effect of this
is that you want to have control over all of the parameters that may
effect this. This can make development in an open mode very difficult.
At the time the decision was made the Rutger's code had only just been
made available. The default was that we would base our work on it, but
after technical review we determined that (from our standpoint) it was
not ready for commercial use, and most importantly its layering and
organization was not the most appropriate design.

I hope this serves as a more detailed explanation of how this panned
out. As regards how we can better manage and communicate these kind of
aspects in future - we are very open to discussion with the maintainers
as to how this can be improved.

Although eCosCentric employed maintainers are the driving force behind
all our engineering and are well aware of the commercial aspects of the
business, they are fiercely independent as regards their maintainer
roles. We shouldn't and don't expect them to represent the companies
interests in this role. Although they, and we as a company, cannot share
commercially sensitive information with the community as a whole,
perhaps there are ways that we can be more open with the maintainer
group. I'm not sure that NDA's are viable in this context, but it would
be good to find appropriate ways to communicate and share some
commercially sensitive info and ongoing development plans.

Regarding contributions in general - it can be difficult for us to
determine when and if we should make a contribution to the community.
When we invest time and money into development of a specific feature we
need to see some level of ROI, otherwise that development would not have
existed in the first place. There is always ongoing debate within
eCosCentric as to how we should manage this - viable open source
business models are complex to get right! At the heart of this though we
want the best and most appropriate technical solutions for the eCos
project. Competition and choice can be a healthy thing in this regard.

Apart from contributions we do also play a major role in the more
thankless heavy lifting - as evidenced for example by our major
commitment of time and resources to getting eCos 3.0 out. You all know
our heritage and passion to improve eCos - and doing this in beneficial
and constructive way with the wider community *is* important to us, and
I'm sure we can find ways to improve our interaction to everyone's
benefit. We understand that a fundamental level, what benefits eCos also
benefits eCosCentric.

> How do we go forward with the NAND work? First impressions is that the
> two implementations are roughly equal. So we need an open review of
> both. Since eCosCentric are offering to contribute theres, please post
> it to ecos-patches along side Rutgers, so all interested parties can
> take part in the review.

Ross will post the documentation followed by a code drop shortly.

Paul.
--

Paul Beskeen
Chairman
eCosCentric
http://www.ecoscentric.com/
phone: +44 1223 245571

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-05-13 19:03 ` John Dallaway
@ 2009-05-15 16:50   ` Ross Younger
  2009-05-16 10:43     ` Andrew Lunn
  2009-05-18  7:13     ` Andrew Lunn
  0 siblings, 2 replies; 20+ messages in thread
From: Ross Younger @ 2009-05-15 16:50 UTC (permalink / raw)
  To: John Dallaway
  Cc: ecos-maintainers, Rutger Hofman, Simon Kallweit, Sergei Gavrikov

Hi John,

John Dallaway wrote:
> Which board have you targeted initially?

The Embedded Artists LPC2468.

> One of my concerns is that the NAND subsystem interfaces are appropriate
> for other filesystems (such as UFFS) and for a broad range of NAND
> devices. An interim code drop with any existing documentation would be
> very welcome to kick-start the discussion.

I've now created an interim drop of the docs and posted it to bugzilla:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000770

As it turns out, the eCos and eCosPro HALs for the EA LPC2468 target are
different, so I've spent a little time earlier this week patching my work up
so it can work on either. This code needs a little cleaning up before it
will be ready for public consumption, but I hope to do that and be able to
post it to the ticket on Monday. (I guess that most people on this
distribution subscribe to ecos-patches, so there's no particular need for me
to announce here when I update the ticket?)

Cheers,


Ross

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-05-15 10:18     ` Simon Kallweit
@ 2009-05-16  9:50       ` Andrew Lunn
  2009-05-18  9:39         ` Paul Beskeen
  0 siblings, 1 reply; 20+ messages in thread
From: Andrew Lunn @ 2009-05-16  9:50 UTC (permalink / raw)
  To: Simon Kallweit
  Cc: Rutger Hofman, Ross Younger, ecos-maintainers, Sergei Gavrikov,
	Melanie Rieback, Paul Beskeen

On Fri, May 15, 2009 at 12:18:49PM +0200, Simon Kallweit wrote:
> Andrew Lunn wrote:
>> Hi Folks
[...]
>> There is a possibility of it happening again soon
>> as well. eCosCentric have a more modern lwIP port in there tree than
>> the current in anoncvs. I understand they have optimized it for small
>> platform and made it more stable. There is the current effort going on
>> to update the anoncvs lwip code. When this reaches maturity, which
>> looks like will happen soon, are eCosCentric going to pull out there
>> trump card again and contribute there lwip port? 
>
> Well well, I almost saw that coming :/

Would eCosCentric like to make a comment regarding this subject?

      Andrew

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  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
  1 sibling, 1 reply; 20+ messages in thread
From: Andrew Lunn @ 2009-05-16 10:43 UTC (permalink / raw)
  To: Ross Younger
  Cc: John Dallaway, ecos-maintainers, Rutger Hofman, Simon Kallweit,
	Sergei Gavrikov

> I've now created an interim drop of the docs and posted it to bugzilla:
> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000770

Hi Ross

Im having trouble getting my head around partitions. 

If i understand the documentation correctly, the only thing the
concept does it prevent a buggy filesystem or application reading data
from a different partition than it "opened" with
cyg_nand_get_partition(). The partition has zero affect on addressing.

Am i missing something? What else are partitions good for?

   Andrew

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-05-16 10:43     ` Andrew Lunn
@ 2009-05-16 12:50       ` Ross Younger
  0 siblings, 0 replies; 20+ messages in thread
From: Ross Younger @ 2009-05-16 12:50 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: John Dallaway, ecos-maintainers, Rutger Hofman, Simon Kallweit,
	Sergei Gavrikov

Hi Andrew,

> Im having trouble getting my head around partitions. 
> 
> If i understand the documentation correctly, the only thing the
> concept does it prevent a buggy filesystem or application reading data
> from a different partition than it "opened" with
> cyg_nand_get_partition(). The partition has zero affect on addressing.
> 
> Am i missing something? What else are partitions good for?

Partitions may be a bit of a misleading term for it, but it's the best I 
could come up with. It seems quite common for boards (both dev boards, and 
deployed products) to have a single NAND device or array, carved up into two 
(or more) separate filesystems. As you observe, addressing is completely 
unaffected, and this is based on my observations of other devices; I added 
in the boundary enforcement purely out of paranoia.

To take the example of the embedded Linux world, typically the primary boot 
loader uses the filesystem on the first partition (think of it as "/boot") 
to get a kernel or application image, which then uses the second (much 
larger) partition as its root filesystem. These two partitions could be the 
same filesystem, or the boot partition could be something simpler to 
simplify the boot loader.

Also, having the partition information in one place means that filesystems 
can read out their limits from it, rather than having to be configured 
separately.


Ross

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

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-05-15 16:50   ` Ross Younger
  2009-05-16 10:43     ` Andrew Lunn
@ 2009-05-18  7:13     ` Andrew Lunn
  2009-05-18 10:42       ` Rutger Hofman
  2009-06-02 18:18       ` John Dallaway
  1 sibling, 2 replies; 20+ messages in thread
From: Andrew Lunn @ 2009-05-18  7:13 UTC (permalink / raw)
  To: Ross Younger
  Cc: John Dallaway, ecos-maintainers, Rutger Hofman, Simon Kallweit,
	Sergei Gavrikov

Hi Folks

An FYI for some of the newbies who are maybe not subscribed to all the
ecos-mailing lists:

After checking with Ross and Paul, i've taken the technical discussion
about eCosCentrics's NAND implementation over to ecos-devel.

      Andrew

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-05-16  9:50       ` Andrew Lunn
@ 2009-05-18  9:39         ` Paul Beskeen
  2009-05-18  9:55           ` Simon Kallweit
  0 siblings, 1 reply; 20+ messages in thread
From: Paul Beskeen @ 2009-05-18  9:39 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: Simon Kallweit, ecos-maintainers

Andrew Lunn wrote:
> On Fri, May 15, 2009 at 12:18:49PM +0200, Simon Kallweit wrote:
>> Andrew Lunn wrote:
>>> Hi Folks
> [...]
>>> There is a possibility of it happening again soon
>>> as well. eCosCentric have a more modern lwIP port in there tree than
>>> the current in anoncvs. I understand they have optimized it for small
>>> platform and made it more stable. There is the current effort going on
>>> to update the anoncvs lwip code. When this reaches maturity, which
>>> looks like will happen soon, are eCosCentric going to pull out there
>>> trump card again and contribute there lwip port? 
>> Well well, I almost saw that coming :/
> 
> Would eCosCentric like to make a comment regarding this subject?

We have no plans to contribute our lwIP work. Developing the eCos public
version based on the very latest sources seems the appropriate way to go
long term.

Paul.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-05-18  9:39         ` Paul Beskeen
@ 2009-05-18  9:55           ` Simon Kallweit
  0 siblings, 0 replies; 20+ messages in thread
From: Simon Kallweit @ 2009-05-18  9:55 UTC (permalink / raw)
  To: Paul Beskeen; +Cc: Andrew Lunn, ecos-maintainers

Paul Beskeen wrote:
>> Would eCosCentric like to make a comment regarding this subject?
> 
> We have no plans to contribute our lwIP work. Developing the eCos public
> version based on the very latest sources seems the appropriate way to go
> long term.

Well, that's good to hear. Still, does Jonathan Larmour care to 
elaborate a bit on his improvements over the original port from Jani? I 
think this could improve performance & stability for the sequential 
support of the new community port.

Simon

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-05-18  7:13     ` Andrew Lunn
@ 2009-05-18 10:42       ` Rutger Hofman
  2009-06-02 18:18       ` John Dallaway
  1 sibling, 0 replies; 20+ messages in thread
From: Rutger Hofman @ 2009-05-18 10:42 UTC (permalink / raw)
  To: ecos-maintainers; +Cc: Simon Kallweit, Simon Kallweit, Sergei Gavrikov

My NAND flash package currently has no synthetic target support. I 
commit to making one (possibly based on work started by Simon Kallweit, 
if he is willing to share that with me) in the shortest possible time if 
my package will be accepted into eCos.

In the meanwhile, Televic.be, who wrote a NAND controller driver for my 
NAND package for their board (Atmel ARM9: AT91SAM9260), have privately 
told me that they are willing to publish their driver source.

Rutger Hofman
VU Amsterdam


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  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
  1 sibling, 1 reply; 20+ messages in thread
From: John Dallaway @ 2009-06-02 18:18 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: eCos Maintainers

Hi Andrew

Andrew Lunn wrote:

> An FYI for some of the newbies who are maybe not subscribed to all the
> ecos-mailing lists:
> 
> After checking with Ross and Paul, i've taken the technical discussion
> about eCosCentrics's NAND implementation over to ecos-devel.

Have you been able to form a view on the relative merits of the VU
Amsterdam and eCosCentric implementations so far? Just wanting to ensure
that this process is not stalled for any reason...

John Dallaway

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
  2009-06-02 18:18       ` John Dallaway
@ 2009-06-03  6:55         ` Andrew Lunn
  0 siblings, 0 replies; 20+ messages in thread
From: Andrew Lunn @ 2009-06-03  6:55 UTC (permalink / raw)
  To: John Dallaway; +Cc: eCos Maintainers

On Tue, Jun 02, 2009 at 07:17:58PM +0100, John Dallaway wrote:
> Hi Andrew
> 
> Andrew Lunn wrote:
> 
> > An FYI for some of the newbies who are maybe not subscribed to all the
> > ecos-mailing lists:
> > 
> > After checking with Ross and Paul, i've taken the technical discussion
> > about eCosCentrics's NAND implementation over to ecos-devel.
> 
> Have you been able to form a view on the relative merits of the VU
> Amsterdam and eCosCentric implementations so far? Just wanting to ensure
> that this process is not stalled for any reason...

I have some first impressions, looking at the documentation. However
the discussions should really be on ecos-devel, not this semi private list.

    Andrew

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: NAND & YAFFS
@ 2009-05-15  6:44 cetoni GmbH - Uwe Kindler
  0 siblings, 0 replies; 20+ messages in thread
From: cetoni GmbH - Uwe Kindler @ 2009-05-15  6:44 UTC (permalink / raw)
  To: ecos-maintainers; +Cc: rutger

Hi,

I completely agree with Rutgers opinion about his development of eCos 
NAND support. 
(http://ecos.sourceware.org/ml/ecos-maintainers/2009-05/msg00011.html).
I think the situation is very disappointing for him.

He invested a lot of work and time, he made his project public very 
early and he carefully designed the NAND flash IO and device layers. 
Because his work was public from the beginning, anyone could contribute, 
criticize or help. At the moment his implementation is the only one I 
know in detail and the only one that is public accessible. Furthermore 
its NAND framework is already used and known by other eCos community 
members. So at the moment I tend to say, Rutgers implementation is the 
current eCos NAND framework.

I think before we decide if some parts of eCosCentrics NAND 
implementation can be used, we should carefully check both 
implementations and discuss pros and cons. To do this we would need 
public access to the eCosCentric NAND implementation as soon as possible.

Furthermore I would like to know from eCosCentric in some short words, 
why their NAND implementation/design is better than Rutgers 
implementation. If this is not relizable within some days, we should 
stay with Rutgers implementation to get working NAND support as fast as 
possible.


Kind regards,

Dipl. Inf. (FH)
Uwe Kindler
Software Engineering

--

cetoni GmbH
Am Wiesenring 6
D-07554 Korbussen

Tel.: +49 (0) 36602 338 28
Fax:  +49 (0) 36602 338 11
uwe.kindler@cetoni.de
http://www.cetoni.de

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2009-06-03  6:55 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-13 13:59 NAND & YAFFS Ross Younger
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

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).