Re: Getting Atmel AT91SAM9 into eCos

Re: Getting Atmel AT91SAM9 into eCos

[John Dallaway]

Hi Daniel, Evgeniy and eCos maintainers

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

    http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000819

John Dallaway
eCos maintainer

Re: Getting Atmel AT91SAM9 into eCos

[Evgeniy Dushistov]

On Tue, Feb 23, 2010 at 09:26:15AM +0000, John Dallaway wrote:
> Hi Daniel, Evgeniy and eCos maintainers
> 
> 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.
> 

Actually, I and Filip Navara implemented AT91SAM7X and at91sam9263
support for qemu, one of the most recent version can be found here:
git://github.com/Dushistov/qemu_at91sam9263.git
It can run linux, freertos, ecos.

So if there is interest, I can create binaries of qemu for linux OS,
so maintainers who have sam7 hardware, but have no sam9, or 
vice versa, or completly have no development boards can run
and test eCos.


-- 
/Evgeniy

Re: Getting Atmel AT91SAM9 into eCos

[Gary Thomas]

On 02/23/2010 03:01 AM, Evgeniy Dushistov wrote:
> On Tue, Feb 23, 2010 at 09:26:15AM +0000, John Dallaway wrote:
>> Hi Daniel, Evgeniy and eCos maintainers
>>
>> 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.
>>
>
> Actually, I and Filip Navara implemented AT91SAM7X and at91sam9263
> support for qemu, one of the most recent version can be found here:
> git://github.com/Dushistov/qemu_at91sam9263.git
> It can run linux, freertos, ecos.
>
> So if there is interest, I can create binaries of qemu for linux OS,
> so maintainers who have sam7 hardware, but have no sam9, or
> vice versa, or completly have no development boards can run
> and test eCos.

How do you configure Qemu to run eCos on these platforms?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Getting Atmel AT91SAM9 into eCos

[Evgeniy Dushistov]

On Tue, Feb 23, 2010 at 09:53:28AM -0700, Gary Thomas wrote:
> On 02/23/2010 03:01 AM, Evgeniy Dushistov wrote:
> > On Tue, Feb 23, 2010 at 09:26:15AM +0000, John Dallaway wrote:
> >> Hi Daniel, Evgeniy and eCos maintainers
> >>
> >> 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.
> >>
> >
> > Actually, I and Filip Navara implemented AT91SAM7X and at91sam9263
> > support for qemu, one of the most recent version can be found here:
> > git://github.com/Dushistov/qemu_at91sam9263.git
> > It can run linux, freertos, ecos.
> >
> > So if there is interest, I can create binaries of qemu for linux OS,
> > so maintainers who have sam7 hardware, but have no sam9, or
> > vice versa, or completly have no development boards can run
> > and test eCos.
> 
> How do you configure Qemu to run eCos on these platforms?
> 
Get sources of qemu from git url above, then
./configure --target-list="arm-softmmu arm-linux-user armeb-linux-user"
&& make

To run eCos on at91sam9263, you need something like
./arm-softmmu/qemu-system-arm  -serial tcp::4445,server -M at91sam9263ek
-pflash ../pflash-redboot.img &
#to get access to dbgu port
telnet localhost 4445 

pflash-redboot.img is image 8M nor flash, it can be created by:
qemu-img create pflash-redboot.img 8M
dd if=redboot.bin of=pflash-redboot.img ...

For at91sam7x things little simplier, you need something like:
./arm-softmmu/qemu-system-arm  -serial tcp::4445,server -M at91pes
-kernel <name>.elf

you can run qemu with "-s -S" and connect to it using arm-eabi-gdb to 
port 1234.

-- 
/Evgeniy

Re: Getting Atmel AT91SAM9 into eCos

[John Dallaway]

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?

John Dallaway
eCos maintainer

Re: Getting Atmel AT91SAM9 into eCos

[Jonathan Larmour]

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. To 
do that, I need to go through the past discussion in the community and 
summarise what people have already said, then reopen discussion in the 
community. I'll try and do something this week. Although I'll be away next 
week.

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

Jifl
-- 
------["The best things in life aren't things."]------      Opinions==mine

Re: Getting Atmel AT91SAM9 into eCos

[John Dallaway]

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

Re: Getting Atmel AT91SAM9 into eCos

[Sergei Gavrikov]

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

Re: Getting Atmel AT91SAM9 into eCos

[Jonathan Larmour]

[ snip good stuff from Sergei ]

On 09/03/10 02:00, Sergei Gavrikov wrote:
> 
> 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.

One of the main difficulties there was directly because of CVS. The
trunk had moved on (particularly in RedBoot's flash support), so there
was a lot of overhead to merging.

These merge headaches would be much less with a modern VCS, so it won't
be as scary to merge. Which is a big reason why people kept putting it off.

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

Clearly you're keen on distributed :-). I agree, but we'll discuss
elsewhere. I'll try and get a mail out today.

Jifl

Re: Getting Atmel AT91SAM9 into eCos

[Jonathan Larmour]

On 08/03/10 15:59, John Dallaway wrote:
> Jonathan Larmour wrote:
>>
>> 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 know it's not ideal, hence my comment about it not feeling right, but
this patch in particular may justify it.

> 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's not to do with hard graft using CVS. It's to do with proper
configuration management, and tracking changes, and sensible merges.
This patch moves a lot of stuff around between files.

The right process for getting this support in (in a new VCS) is to
create a branch, apply the patch, then make further changes and test in
the branch, then merge to trunk. Of course once in the branch, anyone
can start using it if they really want to.

And as Sergei says I think the time is right to bring the VCS discussion
to a close without it needing to drag out too long.

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

Yes but there are quite a few of those and they are popular. All sorts
of people out there will have made their own ports. With things moving
around, those ports break. It's not just a case of keeping the ports
checked in to CVS working.

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

We have to consider people's ports out there. People don't ship product
based on an eval board - they have their own ports for their own
hardware. Breakage should not be done lightly; it may well be necessary,
but in that case we really have to be sure the abstractions are right to
prevent having to break it again. (And having a VCS which can manage
change sets will also make it a lot clearer to see what changes are
required specifically to replicate the changes needed).

> Jifl, should we think in terms of a ARM9 v2 variant package (like flash
> v2) to mitigate the risk?

Indeed I am advocating something like "flash v2" (which FAOD was always
an informal name), which means development takes place on a branch and
gets merged to trunk when we're happy with it, replacing what's there.
FAOD it would be bad to have a new ARM9v2 package in the trunk. For the
same reasons of avoiding unnecessary breakage of ports above, we'd have
to keep it round forever.

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

No, much more. From my own quick view of the sources, the idea looks
roughly right, but the detail needs refinement.

Jifl