Comtrol eCos - Manual (Page 785)

Porting
Name
Porting — Adding support for other hosts
Description
The initial development effort of the eCos synthetic target happened on x86 Linux machines. Porting to other
platforms involves addressing a number of different issues. Some ports should be fairly straightforward, for exam-
ple a port to Linux on a processor other than an x86. Porting to Unix or Unix-like operating systems other than
Linux may be possible, but would involve more effort. Porting to a completely different operating system such as
Windows would be very difficult. The text below complements the eCos Porting Guide.
Other Linux Platforms
Porting the synthetic target to a Linux platform that uses a processor other than x86 should be straightforward.
The simplest approach is to copy the existing
i386linux directory tree in the hal/synth hierarchy, then rename
and edit the ten or so files in this package. Most of the changes should be pretty obvious, for example on a 64-bit
processor some new data types will be needed in the
basetype.h header file. It will also be necessary to update
the toplevel ecos.db database with an entry for the new HAL package, and a new target entry will be needed.
Obviously a different processor will have different register sets and calling conventions, so the code for saving and
restoring thread contexts and for implementing
setjmp and longjmp will need to be updated. The exact way of
performing Linux system calls will vary: on x86 linux this usually involves pushing some registers on the stack
and then executing an
int 0x080 trap instruction, but on a different processor the arguments might be passed in
registers instead and certainly a different trap instruction will be used. The startup code is written in assembler, but
needs to do little more than extract the process’ argument and environment variables and then jump to the main
linux_entry function provided by the architectural synthetic target HAL package.
The header file hal_io.h provided by the architectural HAL package provides various structure definitions, func-
tion prototypes, and macros related to system calls. These are correct for x86 linux, but there may be problems on
other processors. For example a structure field that is currently defined as a 32-bit number may in fact may be a
64-bit number instead.
The synthetic target’s memory map is defined in two files in the include/pkgconf subdirectory. For x86 the
default memory map involves eight megabytes of read-only memory for the code at location 0x1000000 and another
eight megabytes for data at 0x2000000. These address ranges may be reserved for other purposes on the new
architecture, so may need changing. There may be some additional areas of memory allocated by the system for
other purposes, for example the startup stack and any environment variables, but usually eCos applications can and
should ignore those.
Other HAL functionality such as interrupt handling, diagnostics, and the system clock are provided by the architec-
tural HAL package and should work on different processors with few if any changes. There may be some problems
in the code that interacts with the I/O auxiliary because of lurking assumptions about endianness or the sizes of
various data types.
When porting to other processors, a number of sources of information are likely to prove useful. Obviously the
Linux kernel sources and header files constitute the ultimate authority on how things work at the system call level.
681