From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14478 invoked by alias); 8 Mar 2010 15:59:40 -0000 Received: (qmail 14469 invoked by uid 22791); 8 Mar 2010 15:59:38 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mtaout01-winn.ispmail.ntl.com (HELO mtaout01-winn.ispmail.ntl.com) (81.103.221.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 08 Mar 2010 15:59:33 +0000 Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100308155931.QMAR4204.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Mon, 8 Mar 2010 15:59:31 +0000 Received: from cog.dallaway.org.uk ([213.106.80.48]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20100308155931.GCVI13254.aamtaout01-winn.ispmail.ntl.com@cog.dallaway.org.uk>; Mon, 8 Mar 2010 15:59:31 +0000 Received: from cog.dallaway.org.uk (cog.dallaway.org.uk [127.0.0.1]) by cog.dallaway.org.uk (8.13.8/8.13.8) with ESMTP id o28FxSWl004522; Mon, 8 Mar 2010 15:59:28 GMT Message-ID: <4B951EE0.6020103@dallaway.org.uk> Date: Mon, 08 Mar 2010 15:59:00 -0000 From: John Dallaway User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: Jonathan Larmour CC: eCos Maintainers , Evgeniy Dushistov , Daniel Helgason Subject: Re: Getting Atmel AT91SAM9 into eCos References: <1266877649.3024.105.camel@localhost.localdomain> <4B839F37.50904@dallaway.org.uk> <4B94F776.1040707@dallaway.org.uk> <4B950183.7070004@jifvik.org> In-Reply-To: <4B950183.7070004@jifvik.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-maintainers-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@ecos.sourceware.org X-SW-Source: 2010-03/txt/msg00010.txt.bz2 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. 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. > 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. > > 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). 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