public inbox for
 help / color / mirror / Atom feed
From: John Dallaway <>
To: Jonathan Larmour <>
Cc: eCos Maintainers <>,
	        Evgeniy Dushistov <>,
	        Daniel Helgason <>
Subject: Re: Getting Atmel AT91SAM9 into eCos
Date: Mon, 08 Mar 2010 15:59:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

John Dallaway
eCos maintainer

  reply	other threads:[~2010-03-08 15:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1266877649.3024.105.camel@localhost.localdomain>
2010-02-23  9:26 ` John Dallaway
2010-02-23  9:58   ` Evgeniy Dushistov
2010-02-23 16:53     ` Gary Thomas
2010-02-23 17:50       ` Evgeniy Dushistov
2010-03-08 13:11   ` John Dallaway
2010-03-08 13:54     ` Jonathan Larmour
2010-03-08 15:59       ` John Dallaway [this message]
2010-03-09  2:00         ` Sergei Gavrikov
2010-03-09 16:30           ` Jonathan Larmour
2010-03-09 16:25         ` Jonathan Larmour

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:

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

  git send-email \ \ \ \ \ \ \

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