1 <!-- Copyright (C) 2002 Red Hat, Inc. -->
2 <!-- This material may be distributed only subject to the terms -->
3 <!-- and conditions set forth in the Open Publication License, v1.0 -->
4 <!-- or later (the latest version is presently available at -->
5 <!-- http://www.opencontent.org/openpub/). -->
6 <!-- Distribution of the work or derivative of the work in any -->
7 <!-- standard (paper) book form is prohibited unless prior -->
8 <!-- permission is obtained from the copyright holder. -->
13 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
16 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
19 TITLE="eCos Synthetic Target"
20 HREF="hal-synth-arch.html"><LINK
22 TITLE="Writing New Devices - host"
23 HREF="synth-new-host.html"></HEAD
34 SUMMARY="Header navigation table"
43 >eCos Synthetic Target</TH
51 HREF="synth-new-host.html"
72 NAME="SYNTH-PORTING">Porting</H1
80 >Porting -- Adding support for other hosts</DIV
84 NAME="SYNTH-PORTING-DESCRIPTION"
89 >The initial development effort of the eCos synthetic target happened
90 on x86 Linux machines. Porting to other platforms involves addressing
91 a number of different issues. Some ports should be fairly
92 straightforward, for example a port to Linux on a processor other than
93 an x86. Porting to Unix or Unix-like operating systems other than
94 Linux may be possible, but would involve more effort. Porting to a
95 completely different operating system such as Windows would be very
96 difficult. The text below complements the eCos Porting Guide.
102 NAME="SYNTH-PORTING-LINUX"
105 >Other Linux Platforms</H2
107 >Porting the synthetic target to a Linux platform that uses a processor
108 other than x86 should be straightforward. The simplest approach is to
109 copy the existing <TT
113 directory tree in the <TT
117 hierarchy, then rename and edit the ten or so files in this package.
118 Most of the changes should be pretty obvious, for example on a 64-bit
119 processor some new data types will be needed in the
123 > header file. It will also be necessary
124 to update the toplevel <TT
128 entry for the new HAL package, and a new target entry will be needed.
131 >Obviously a different processor will have different register sets and
132 calling conventions, so the code for saving and restoring thread
133 contexts and for implementing <TT
140 > will need to be updated. The exact way of
141 performing Linux system calls will vary: on x86 linux this usually
142 involves pushing some registers on the stack and then executing an
146 > trap instruction, but on a different
147 processor the arguments might be passed in registers instead and
148 certainly a different trap instruction will be used. The startup code
149 is written in assembler, but needs to do little more than extract the
150 process' argument and environment variables and then jump to the main
154 > function provided by the
155 architectural synthetic target HAL package.
162 architectural HAL package provides various structure definitions,
163 function prototypes, and macros related to system calls. These are
164 correct for x86 linux, but there may be problems on other processors.
165 For example a structure field that is currently defined as a 32-bit
166 number may in fact may be a 64-bit number instead.
169 >The synthetic target's memory map is defined in two files in the
174 For x86 the default memory map involves eight megabytes of read-only
175 memory for the code at location 0x1000000 and another eight megabytes
176 for data at 0x2000000. These address ranges may be reserved for other
177 purposes on the new architecture, so may need changing. There may be
178 some additional areas of memory allocated by the system for other
179 purposes, for example the startup stack and any environment variables,
180 but usually eCos applications can and should ignore those.
183 >Other HAL functionality such as interrupt handling, diagnostics, and
184 the system clock are provided by the architectural HAL package and
185 should work on different processors with few if any changes. There may
186 be some problems in the code that interacts with the I/O auxiliary
187 because of lurking assumptions about endianness or the sizes of
191 >When porting to other processors, a number of sources of information
192 are likely to prove useful. Obviously the Linux kernel sources and
193 header files constitute the ultimate authority on how things work at
194 the system call level. The GNU C library sources may also prove very
195 useful: for a normal Linux application it is the C library that
196 provides the startup code and the system call interface.
202 NAME="SYNTH-PORTING-UNIX"
205 >Other Unix Platforms</H2
207 >Porting to a Unix or Unix-like operating system other than Linux would
208 be somewhat more involved. The first requirement is toolchains: the
209 GNU compilers, gcc and g++, must definitely be used; use of other GNU
210 tools such as the linker may be needed as well, because eCos depends
211 on functionality such as prioritizing C++ static constructors, and
212 other linkers may not implement this or may implement it in a
213 different and incompatible way. A closely related requirement is the
214 use of ELF format for binary executables: if the operating system
215 still uses an older format such as COFF then there are likely to be
216 problems because they do not provide the flexibility required by eCos.
219 >In the architectural HAL there should be very little code that is
220 specific to Linux. Instead the code should work on any operating
221 system that provides a reasonable implementation of the POSIX
222 standard. There may be some problems with program startup, but those
223 could be handled at the architectural level. Some changes may also be
224 required to the exception handling code. However one file which will
225 present a problem is <TT
229 various structure definitions and macros used with the system call
230 interface. It is likely that many of these definitions will need
231 changing, and it may well be appropriate to implement variant HAL
232 packages for the different operating systems where this information
233 can be separated out. Another possible problem is that the generic
234 code assumes that system calls such as
237 >cyg_hal_sys_write</TT
238 > are available. On an operating
239 system other than Linux it is possible that some of these are not
240 simple system calls, and instead wrapper functions will need to be
241 implemented at the variant HAL level.
244 >The generic I/O auxiliary code should be fairly portable to other Unix
245 platforms. However some of the device drivers may contain code that is
246 specific to Linux, for example the <TT
250 address family and the ethertap virtual tunnelling interface. These
251 may prove quite difficult to port.
254 >The remaining porting task is to implement one or more platform HAL
255 packages, one per processor type that is supported. This should
256 involve much the same work as a port to <A
257 HREF="synth-porting.html#SYNTH-PORTING-LINUX"
258 >another processor running Linux</A
262 >When using other Unix operating systems the kernel source code may not
263 be available, which would make any porting effort more challenging.
264 However there is still a good chance that the GNU C library will have
265 been ported already, so its source code may contain much useful
272 NAME="SYNTH-PORTING-OTHER"
275 >Windows Platforms</H2
277 >Porting the current synthetic target code to some version of Windows
278 or to another non-Unix platform is likely to prove very difficult. The
279 first hurdle that needs to be crossed is the file format for binary
280 executables: current Windows implementations do not use ELF, instead
281 they use their own format PE which is a variant of the rather old and
282 limited COFF format. It may well prove easier to first write an ELF
283 loader for Windows executables, rather than try to get eCos to work
284 within the constraints of PE. Of course that introduces new problems,
285 for example existing source-level debuggers will still expect
286 executables to be in PE format.
289 >Under Linux a synthetic target application is not linked with the
290 system's C library or any other standard system library. That would
291 cause confusion, for example both eCos and the system's C library
292 might try to define the <TT
296 introduce complications such as working with shared libraries. For
297 much the same reasons, a synthetic target application under Windows
298 should not be linked with any Windows DLL's. If an ELF loader has been
299 specially written then this may not be much of a problem.
302 >The next big problem is the system call interface. Under Windows
303 system calls are generally made via DLL's, and it is not clear that
304 the underlying trap mechanism is well-documented or consistent between
305 different releases of Windows.
308 >The current code depends on the operating system providing an
309 implementation of POSIX signal handling. This is used for I/O
310 purposes, for example <TT
314 system clock, and for exceptions. It is not known what equivalent
315 functionality is available under Windows.
318 >Given the above problems a port of the synthetic target to Windows may
319 or may not be technically feasible, but it would certainly require a
320 very large amount of effort.
328 SUMMARY="Footer navigation table"
339 HREF="synth-new-host.html"
348 HREF="hal-synth-arch.html"
363 >Writing New Devices - host</TD
projects / karo-tx-redboot.git / blob