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.