Re: [ECOS] Legacy Flash implementation

[Andrew Lunn <andrew@lunn.ch>]

On Mon, Jul 09, 2007 at 01:09:22PM +0200, Rutger Hofman wrote:
> Rutger Hofman wrote:
>> Ahum. I guess I had forgotten this now, but it appears that Flash v2 
>> (including legacy API) requires CVS branch flash_v2 in the checkout. 
>> Having a different branch is entirely consistent with my problems.
>
> OK, it's trivial to get -r flash_v2_tag. But this effectively gives me an 
> eCos CVS snapshot from 2004, with patches *only* to the flash modules. I 
> would very much prefer to be in sync with the main eCos CVS trunk and still 
> have flash_v2 -- I want the newer i2c, for example.
>
> I think there are a number of different solutions to this:
>
> 1) eCos maintainers merge the flash v2 branch into the main trunk. This 
> would be perfect.

A long, long time ago, it was planned to merge the flash_v2 branch
into the trunk when eCos 3.0 was released. Changes to flash can
introduce big problems. eg turn a device into a brick if it does not
work correctly. So it was planned to do quite a bit of testing first,
which is normal for a major release.

However the plan for the 3.0 release was to wait until eCos could be
signed over to the FSF. This has taken years and years to get the
copyright issues sorted out. I beleave all but eCosCentric originated
code can now be assigned to FSF, but since eCosCentric are the big
drivers for making 3.0 happen, not much has happened. 

If 3.0 is not going to happen real soon now we could merge the
flash_v2 branch in. eCosCentrics private tree already uses
flash_v2. So they have obviously done lots of testing of the generic
parts, plus the device drivers there customers use. So if eCosCentric
could contribute any patches they have we could do a merge and be
reasonable sure we are not going to brick anybodies device.

           Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss