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 firstname.lastname@example.org
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
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
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.