--- /dev/null
+<!-- Copyright (C) 2003 Red Hat, Inc. -->
+<!-- This material may be distributed only subject to the terms -->
+<!-- and conditions set forth in the Open Publication License, v1.0 -->
+<!-- or later (the latest version is presently available at -->
+<!-- http://www.opencontent.org/openpub/). -->
+<!-- Distribution of the work or derivative of the work in any -->
+<!-- standard (paper) book form is prohibited unless prior -->
+<!-- permission is obtained from the copyright holder. -->
+<HTML
+><HEAD
+><TITLE
+>Porting</TITLE
+><meta name="MSSmartTagsPreventParsing" content="TRUE">
+<META
+NAME="GENERATOR"
+CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
+"><LINK
+REL="HOME"
+TITLE="eCos Reference Manual"
+HREF="ecos-ref.html"><LINK
+REL="UP"
+TITLE="eCos Synthetic Target"
+HREF="hal-synth-arch.html"><LINK
+REL="PREVIOUS"
+TITLE="Writing New Devices - host"
+HREF="synth-new-host.html"><LINK
+REL="NEXT"
+TITLE="SA11X0 USB Device Driver"
+HREF="devs-usb-sa11x0-ref.html"></HEAD
+><BODY
+CLASS="REFENTRY"
+BGCOLOR="#FFFFFF"
+TEXT="#000000"
+LINK="#0000FF"
+VLINK="#840084"
+ALINK="#0000FF"
+><DIV
+CLASS="NAVHEADER"
+><TABLE
+SUMMARY="Header navigation table"
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TH
+COLSPAN="3"
+ALIGN="center"
+>eCos Reference Manual</TH
+></TR
+><TR
+><TD
+WIDTH="10%"
+ALIGN="left"
+VALIGN="bottom"
+><A
+HREF="synth-new-host.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="80%"
+ALIGN="center"
+VALIGN="bottom"
+></TD
+><TD
+WIDTH="10%"
+ALIGN="right"
+VALIGN="bottom"
+><A
+HREF="devs-usb-sa11x0-ref.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+></TABLE
+><HR
+ALIGN="LEFT"
+WIDTH="100%"></DIV
+><H1
+><A
+NAME="SYNTH-PORTING">Porting</H1
+><DIV
+CLASS="REFNAMEDIV"
+><A
+NAME="AEN18705"
+></A
+><H2
+>Name</H2
+>Porting -- Adding support for other hosts</DIV
+><DIV
+CLASS="REFSECT1"
+><A
+NAME="SYNTH-PORTING-DESCRIPTION"
+></A
+><H2
+>Description</H2
+><P
+>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 example 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.
+ </P
+></DIV
+><DIV
+CLASS="REFSECT1"
+><A
+NAME="SYNTH-PORTING-LINUX"
+></A
+><H2
+>Other Linux Platforms</H2
+><P
+>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 <TT
+CLASS="FILENAME"
+>i386linux</TT
+>
+directory tree in the <TT
+CLASS="FILENAME"
+>hal/synth</TT
+>
+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
+<TT
+CLASS="FILENAME"
+>basetype.h</TT
+> header file. It will also be necessary
+to update the toplevel <TT
+CLASS="FILENAME"
+>ecos.db</TT
+> database with an
+entry for the new HAL package, and a new target entry will be needed.
+ </P
+><P
+>Obviously a different processor will have different register sets and
+calling conventions, so the code for saving and restoring thread
+contexts and for implementing <TT
+CLASS="FUNCTION"
+>setjmp</TT
+> and
+<TT
+CLASS="FUNCTION"
+>longjmp</TT
+> 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
+<TT
+CLASS="LITERAL"
+>int 0x080</TT
+> 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
+<TT
+CLASS="FUNCTION"
+>linux_entry</TT
+> function provided by the
+architectural synthetic target HAL package.
+ </P
+><P
+>The header file <TT
+CLASS="FILENAME"
+>hal_io.h</TT
+> provided by the
+architectural HAL package provides various structure definitions,
+function 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.
+ </P
+><P
+>The synthetic target's memory map is defined in two files in the
+<TT
+CLASS="FILENAME"
+>include/pkgconf</TT
+> 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.
+ </P
+><P
+>Other HAL functionality such as interrupt handling, diagnostics, and
+the system clock are provided by the architectural 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.
+ </P
+><P
+>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. The GNU C library sources may also prove very
+useful: for a normal Linux application it is the C library that
+provides the startup code and the system call interface.
+ </P
+></DIV
+><DIV
+CLASS="REFSECT1"
+><A
+NAME="SYNTH-PORTING-UNIX"
+></A
+><H2
+>Other Unix Platforms</H2
+><P
+>Porting to a Unix or Unix-like operating system other than Linux would
+be somewhat more involved. The first requirement is toolchains: the
+GNU compilers, gcc and g++, must definitely be used; use of other GNU
+tools such as the linker may be needed as well, because eCos depends
+on functionality such as prioritizing C++ static constructors, and
+other linkers may not implement this or may implement it in a
+different and incompatible way. A closely related requirement is the
+use of ELF format for binary executables: if the operating system
+still uses an older format such as COFF then there are likely to be
+problems because they do not provide the flexibility required by eCos.
+ </P
+><P
+>In the architectural HAL there should be very little code that is
+specific to Linux. Instead the code should work on any operating
+system that provides a reasonable implementation of the POSIX
+standard. There may be some problems with program startup, but those
+could be handled at the architectural level. Some changes may also be
+required to the exception handling code. However one file which will
+present a problem is <TT
+CLASS="FILENAME"
+>hal_io.h</TT
+>, which contains
+various structure definitions and macros used with the system call
+interface. It is likely that many of these definitions will need
+changing, and it may well be appropriate to implement variant HAL
+packages for the different operating systems where this information
+can be separated out. Another possible problem is that the generic
+code assumes that system calls such as
+<TT
+CLASS="FUNCTION"
+>cyg_hal_sys_write</TT
+> are available. On an operating
+system other than Linux it is possible that some of these are not
+simple system calls, and instead wrapper functions will need to be
+implemented at the variant HAL level.
+ </P
+><P
+>The generic I/O auxiliary code should be fairly portable to other Unix
+platforms. However some of the device drivers may contain code that is
+specific to Linux, for example the <TT
+CLASS="LITERAL"
+>PF_PACKET</TT
+> socket
+address family and the ethertap virtual tunnelling interface. These
+may prove quite difficult to port.
+ </P
+><P
+>The remaining porting task is to implement one or more platform HAL
+packages, one per processor type that is supported. This should
+involve much the same work as a port to <A
+HREF="synth-porting.html#SYNTH-PORTING-LINUX"
+>another processor running Linux</A
+>.
+ </P
+><P
+>When using other Unix operating systems the kernel source code may not
+be available, which would make any porting effort more challenging.
+However there is still a good chance that the GNU C library will have
+been ported already, so its source code may contain much useful
+information.
+ </P
+></DIV
+><DIV
+CLASS="REFSECT1"
+><A
+NAME="SYNTH-PORTING-OTHER"
+></A
+><H2
+>Windows Platforms</H2
+><P
+>Porting the current synthetic target code to some version of Windows
+or to another non-Unix platform is likely to prove very difficult. The
+first hurdle that needs to be crossed is the file format for binary
+executables: current Windows implementations do not use ELF, instead
+they use their own format PE which is a variant of the rather old and
+limited COFF format. It may well prove easier to first write an ELF
+loader for Windows executables, rather than try to get eCos to work
+within the constraints of PE. Of course that introduces new problems,
+for example existing source-level debuggers will still expect
+executables to be in PE format.
+ </P
+><P
+>Under Linux a synthetic target application is not linked with the
+system's C library or any other standard system library. That would
+cause confusion, for example both eCos and the system's C library
+might try to define the <TT
+CLASS="FUNCTION"
+>printf</TT
+> function, and
+introduce complications such as working with shared libraries. For
+much the same reasons, a synthetic target application under Windows
+should not be linked with any Windows DLL's. If an ELF loader has been
+specially written then this may not be much of a problem.
+ </P
+><P
+>The next big problem is the system call interface. Under Windows
+system calls are generally made via DLL's, and it is not clear that
+the underlying trap mechanism is well-documented or consistent between
+different releases of Windows.
+ </P
+><P
+>The current code depends on the operating system providing an
+implementation of POSIX signal handling. This is used for I/O
+purposes, for example <TT
+CLASS="LITERAL"
+>SIGALRM</TT
+> is used for the
+system clock, and for exceptions. It is not known what equivalent
+functionality is available under Windows.
+ </P
+><P
+>Given the above problems a port of the synthetic target to Windows may
+or may not be technically feasible, but it would certainly require a
+very large amount of effort.
+ </P
+></DIV
+><DIV
+CLASS="NAVFOOTER"
+><HR
+ALIGN="LEFT"
+WIDTH="100%"><TABLE
+SUMMARY="Footer navigation table"
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+><A
+HREF="synth-new-host.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="ecos-ref.html"
+ACCESSKEY="H"
+>Home</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+><A
+HREF="devs-usb-sa11x0-ref.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+>Writing New Devices - host</TD
+><TD
+WIDTH="34%"
+ALIGN="center"
+VALIGN="top"
+><A
+HREF="hal-synth-arch.html"
+ACCESSKEY="U"
+>Up</A
+></TD
+><TD
+WIDTH="33%"
+ALIGN="right"
+VALIGN="top"
+>SA11X0 USB Device Driver</TD
+></TR
+></TABLE
+></DIV
+></BODY
+></HTML
+>
\ No newline at end of file
projects / karo-tx-redboot.git / blobdiff