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 email@example.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.