Re: Mapping of ARM Architecture to Repository

[John Dallaway <john@dallaway.org.uk>]

Hi Richard

Richard Rauch wrote:

> First I proudly want to notify, that I was able to establish a collaboration
> between my company ITR GmbH and Atmel Corporation.
> Subject of this collaboration is, that my company will be responsible for
> Atmel's activities regarding realtime operation system eCos.

Congratulations! That is great news for the eCos community.

> First project within the scope of this collaboration is the porting of eCos
> to the Atmel AT91SAM9G45 microcontroller, which I have already announced to
> the community some time ago.

I know that you are intending to contribute the AT91SAM9G45 port to the
eCos project. Is your company also intending to contribute other ports
you will develop in the future? Any plans for an AT91SAM3 port?

> Because Atmel is interested in not only providing a port to this
> microcontroller, but also to provide ports to other ARM based product
> families, I want to start a discussion about the repository structure.
> 
> The problem is, that there is a large variety of ARM based microcontroller
> cores (ARM7,ARM9,... Cortex-M0,M3,...,Cortex A8,A9,....).
> This core families are subdivided also into some special core versions (e.g.
> 922, 926,...).
> Each of the core families and variants has more or less some differences.
> 
> So, in my opinion, the structure of the repository is not sufficient to map
> the core differences.

The existing repository structure is intended to be very flexible,
allowing for architecture, variant, processor and platforms HALs to be
used together in multiple combinations.

> In principle, is it possible to make changes in the structures? In the
> moment, there are subdirectories hal/arm/arch, hal/arm/arm9 and hal/arm/xxxx
> for different microcontrollers.

In principle, we can certainly add new directory hierarchies to
accommodate new HALs. As you know, the key point is to discuss
everything in advance on the ecos-devel list, justify your proposal and
obtain agreement from the eCos maintainers before you start.

We do tend to be cautious in re-organising existing code because it is
not always possible to test the changes.

John Dallaway
eCos maintainer