Re: Getting Atmel AT91SAM9 into eCos

[Sergei Gavrikov <sergei dot gavrikov at gmail dot com>]

Hi all

[ snip nothing ]

John Dallaway wrote:

> Hi Jifl and all
>
> Jonathan Larmour wrote:
>
> > John Dallaway wrote:
> >
> > > eCos maintainers
> > >
> > > John Dallaway wrote:
> > >
> > > > Daniel Helgason wrote:
> > > >
> > > > > I have seen many messages on the eCos mailing lists about getting 
> > > > > AT91SAM9 support into eCos. I'm writing directly to you in hopes of 
> > > > > getting some movement on this. I know this is off the mailing list 
> > > > > but I wanted to get initial input directly from people whose 
> > > > > opinions I have come to respect before I add yet another message to 
> > > > > the mailing list about this subject.
> > > >
> > > > [ snip ]
> > > >
> > > > > If there was ever a time to consider pushing the AT91SAM9 devices 
> > > > > into eCos, this could be it! I am asking you for your thoughts on 
> > > > > how to proceed from here. Thanks!
> > > >
> > > > I am not an expert on ARM7/ARM9 differences but there are several 
> > > > eCos maintainers who have experience with multiple ARM variants and 
> > > > are well positioned to review the AT91SAM9 patch. I do not think 
> > > > motivation should be an issue here. We all wish to see eCos move 
> > > > forward and AT91SAM9 support is clearly very good for the project.
> > > >
> > > > My main concern is that we don't break eCos support for older ARM 
> > > > platforms in the process of improving the hardware abstraction for 
> > > > future platform ports.
> > > >
> > > > Is there an eCos maintainer with the necessary ARM expertise who can 
> > > > volunteer for the review of this contribution?
> > >
> > > There has been no response to this.
> > >
> > > The review of Evgeniy's patch is particularly important at present to 
> > > avoid merging issues for various new and planned platform ports on 
> > > ARM7/9. It is also important that the variant abstraction re-work is 
> > > reviewed by someone with real expertise in the area.
> > >
> > > What do you suggest? Should we ask for a volunteer from the wider eCos 
> > > community to review the patch in this instance?
> >
> > In truth, the main reason I (and probably others) have been studiously 
> > ignoring this is because the patch is far-reaching. That doesn't make 
> > it bad, but there's a lot of risk (and effort) here, with potential 
> > knock-on for ports we can't retest easily, and effects for any eCos 
> > user's own ports we don't have in our repo.
> >
> > It would also be hard to apply such a patch while using CVS, due to its 
> > problems with moving things around. I will kick off a discussion about 
> > VCS's because w.r.t this patch or otherwise, it needs to be resolved.
>
> I agree that the VCS debate needs to happen, but it seems dangerous to 
> link patch review with VCS changes in the sense that it introduces 
> further (unquantified) delay to the review of patches which have already 
> been pending for many months.

By other hand we had gone almost whole circle of such debates. AFAIR, the 
community in the most agreed with that any distributed VC system will help 
us to move things more quickly. The question was: Git or HG. We know that 
what eCosCentric chose. It seems we have not to debate during a few months 
again. There were a few summaries on the list.

> I am happy to volunteer for the hard graft of working with CVS if it 
> will help to get things moving on the ARM7/ARM9 front.

to be or to call for?

> > It doesn't feel right saying that we can't do something with the patch 
> > till we've switched VCS, but the practicalities do mean that there may 
> > be reasons to wait.

Switching to new VCS is good time to think about ARM7/9 sorting in a 
background, again and again.

I do not think that we can be the experts with all nowadays and future 
*smart* lines either from Atmel or from other vendors. Atmel named SAM 
line *Smart* (http://en.wikipedia.org/wiki/AT91SAM) to "encode" 3 CPU 
cores in SAM line: ARM7DTMI, ARM926, Cortex-M3.  We know about the same 
"smart" lines from NXP, for example, etc. The next lines (=targets) will 
come soon.  And do you think that reorganizing an existing arm/* branch 
can give us some kind of "AT91-centric" ARM7 package?

> > It's likely this work would need to be committed initially on a branch. 
> > But again a reason for a new VCS is that merging from branch to trunk 
> > is much much much saner than with CVS, especially with moved files, 
> > renames, etc. (assuming the branch was made from the new VCS).

The arrived AT91SAM9 port is the first bird. So, I would agree with 
Jonathan that distributed VCS would help us to do smart things with the 
sources likes CPU vendors do smart things with the ARM cores.

I'm sorry, I have no answer on the John's "far-reaching" question the 
below, but, IMO "ARM9 v2" branch under CVS control can take the same long 
period as "FLASH v2" took the time under CVS before that was merged with 
mainstream. Let's get even first experimental trunk of eCos under DVCS. 
It is important that with distributed VCS of eCos we would collaborate 
with contributors more effectively. Well, this is my look/feel only.

Sergei

> Having just had a more detailed look, it appears that the new ARM7 
> package is only used by the ARM7 AT91 platforms as the patch stands 
> today. It is less invasive than I had imagined. The other ARM7 platforms 
> are untouched. So I think we could phase in use of the new ARM7 package 
> for new ports only. The changes to the ARM9 variant package are more of 
> an all-or-nothing proposition but we have several ports to ARM9 
> platforms in progress within the eCos community so the changes will 
> certainly get tested. However, some of the ARM9 platforms supported 
> within the eCos repository are obsolete and are likely to never be 
> tested again so if we break such platform support it will probably stay 
> broken forever.
>
> Jifl, should we think in terms of a ARM9 v2 variant package (like flash 
> v2) to mitigate the risk?
>
> If we can manage the risk and manage the CVS effort, the remaining major 
> obstacle to progress would be the verification that the abstractions are 
> correct. Perhaps an hour of effort for someone with the appropriate 
> experience?
>
> John Dallaway
> eCos maintainer