Refer to the supported targets page for details of the supported architectures. If a particular processor is not listed there then support for that processor is not yet available.

As the eCos project relies on contributions from the net to do porting, a port will only happen if someone is prepared to develop it and contribute it back.

We hope that porters will announce their intentions to port to a specific processor. If someone has done so, search the ecos-discuss list archives to see if one is in the process of development. Alternatively ask on the ecos-discuss list to check.

A sensible first step for this, as for any other non-trivial project involving eCos, would be to find out whether or not anybody else is already working on something similar. One way of doing this is to post a message to the ecos-discuss@sources.redhat.com mailing list. We aim to keep track of every ongoing eCos project that we know about, to avoid duplication of effort.

The next step is to make sure that you have a toolchain that is suitable for your target hardware. This means the compilers gcc and g++, the assembler gas, the linker, and the various binutils such as ar. It will also be necessary to have some way of actually running an executable on the target hardware, an operation which is inherently hardware dependent. On many targets this will already be possible via the debugger gdb, but on other targets it may be necessary to get gdb to work with the board first or to use some other technique.

It should be noted that eCos uses a number of relatively new extensions to the GNU tools, and you may well run into problems if you try to use some other release of the tools. The most important extension is constructor priority ordering, which allows us to control the order in which static C++ objects get constructed. For example it is possible to specify that a scheduler object gets created before any thread objects. This extension is likely to work with any processor that uses the ELF object format, but there will be problems with other object formats: please contact the eCos maintainers if you need more information about this. Another new extension is selective linking, which will result in smaller executables but which is not absolutely required for a working eCos port. This extension requires modifications to the toolchain for each architecture, and is not yet available except for the supported architectures. Work is in progress to make sure that these extensions work correctly for all architectures that use ELF object format, and to make the extensions available as part of the main net releases for the various tools.

Assuming a working toolchain, porting to a new processor mainly involves implementing a new architectural HAL package. There are existing packages for those architectures which are already supported, and these can be used as a starting point. The current specification of the eCos HAL is available online in the eCos Reference Manual. As you might expect, the work involved in porting eCos is very similar to the work involved in porting any embedded operating system: hardware initialization, interrupt handling, processor exceptions, context switching, etc.

In addition to the architectural HAL package it will be necessary to do a platform HAL package, in other words to provide the support for an actual development board. This involves issues such as board initialization, diagnostics, possibly gdb support, and linker scripts. There are existing platform HAL packages for the supported boards, and for various simulators.

See the eCos Porting Guide for more specific details on the porting process.

If somebody produces a port to a new processor but does not wish to maintain it indefinitely then the eCos maintainers may be willing to adopt this port. This involves quite possibly code clean-ups so that it satisfies the coding standards, possibly new documentation, and if hardware is available, testing. In addition we will maintain the port, upgrading it as the HAL specification evolves. The effort involved is considerable, and over time it will be significantly larger than the initial port. Usually the eCos maintainers will only be able to afford to do so if there are likely to be sufficient long-term interest. Also, we would need a ready source of suitable hardware that can be used for the testing, and we would need a copyright assignment for such ports.

However a port does not have to be supported for it to be useful to somebody. If a port (or any other eCos package) does not have an active maintainer then it can still be made available as unsupported software, provided space on our ftp server and suitable links in the web pages. This allows people to download and use such ports. If there are enough users for an unsupported port then perhaps somebody else will take over the maintainership. The same is of course true for any piece of contributed software.

As with a processor port, usually the first step is to publicize your intention and make sure that nobody else is already doing this. The second step is to make sure that you have the necessary tools, in particular some way of running an executable on the target board. It is possible that gdb already provides support for that board. Alternatively it may be necessary to add the necessary support to gdb, or to use some other means of running programs.

Assuming a working toolchain, the work involved on the eCos side is to implement a new platform HAL package. This involves issues such as board initialization, diagnostics, possibly gdb support, and linker scripts. There are existing platform HAL packages for the supported boards, and any of these can be used as starting points.

eCos depends heavily on a number of language extensions provided by the gcc and g++ compilers. In fact a number of these extensions were added to these compilers specifically to support eCos (although they have wider applications as well). The first such extension is C++ constructor priority ordering. When you define several C++ static objects the language does not define the order in which these objects get constructed. g++ now allows static objects to be ordered using the __attribute__ mechanism, so for example it is possible to create a scheduler object before any thread objects. The second extension is selective linking. Traditionally linkers worked in terms of compilation units, in other words entire files: if an application needed a particular function from a library then all other library functions which happened to be in the same source file would become part of the application's executable. Instead the linker will now work at the finer granularity of individual functions or variables.

Other extensions provided by gcc and g++ are used wherever appropriate. For example attributes are used to define some functions with weak linkage and to provide aliases for some functions. Inline assembler is used to establish memory barriers and prevent the compiler from optimizing in places where this would be undesirable, for example in context switch code. Computed goto's may be used during exception handling.

The use of these extensions makes it very difficult to use compilers other than gcc and g++ to build eCos. In addition it is possible that other extensions will be used in future if they prove to be appropriate for the problem at hand. Therefore we recommend against attempting to use any other compiler technology for eCos development.