OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [ref/] [synth-porting.html] - Blame information for rev 174

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 28 unneback
<!-- Copyright (C) 2003 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.               -->
9
<HTML
10
><HEAD
11
><TITLE
12
>Porting</TITLE
13
><meta name="MSSmartTagsPreventParsing" content="TRUE">
14
<META
15
NAME="GENERATOR"
16
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
17
"><LINK
18
REL="HOME"
19
TITLE="eCos Reference Manual"
20
HREF="ecos-ref.html"><LINK
21
REL="UP"
22
TITLE="eCos Synthetic Target"
23
HREF="hal-synth-arch.html"><LINK
24
REL="PREVIOUS"
25
TITLE="Writing New Devices - host"
26
HREF="synth-new-host.html"><LINK
27
REL="NEXT"
28
TITLE="SA11X0 USB Device Driver"
29
HREF="devs-usb-sa11x0-ref.html"></HEAD
30
><BODY
31
CLASS="REFENTRY"
32
BGCOLOR="#FFFFFF"
33
TEXT="#000000"
34
LINK="#0000FF"
35
VLINK="#840084"
36
ALINK="#0000FF"
37
><DIV
38
CLASS="NAVHEADER"
39
><TABLE
40
SUMMARY="Header navigation table"
41
WIDTH="100%"
42
BORDER="0"
43
CELLPADDING="0"
44
CELLSPACING="0"
45
><TR
46
><TH
47
COLSPAN="3"
48
ALIGN="center"
49
>eCos Reference Manual</TH
50
></TR
51
><TR
52
><TD
53
WIDTH="10%"
54
ALIGN="left"
55
VALIGN="bottom"
56
><A
57
HREF="synth-new-host.html"
58
ACCESSKEY="P"
59
>Prev</A
60
></TD
61
><TD
62
WIDTH="80%"
63
ALIGN="center"
64
VALIGN="bottom"
65
></TD
66
><TD
67
WIDTH="10%"
68
ALIGN="right"
69
VALIGN="bottom"
70
><A
71
HREF="devs-usb-sa11x0-ref.html"
72
ACCESSKEY="N"
73
>Next</A
74
></TD
75
></TR
76
></TABLE
77
><HR
78
ALIGN="LEFT"
79
WIDTH="100%"></DIV
80
><H1
81
><A
82
NAME="SYNTH-PORTING">Porting</H1
83
><DIV
84
CLASS="REFNAMEDIV"
85
><A
86
NAME="AEN18705"
87
></A
88
><H2
89
>Name</H2
90
>Porting&nbsp;--&nbsp;Adding support for other hosts</DIV
91
><DIV
92
CLASS="REFSECT1"
93
><A
94
NAME="SYNTH-PORTING-DESCRIPTION"
95
></A
96
><H2
97
>Description</H2
98
><P
99
>The initial development effort of the eCos synthetic target happened
100
on x86 Linux machines. Porting to other platforms involves addressing
101
a number of different issues. Some ports should be fairly
102
straightforward, for example a port to Linux on a processor other than
103
an x86. Porting to Unix or Unix-like operating systems other than
104
Linux may be possible, but would involve more effort. Porting to a
105
completely different operating system such as Windows would be very
106
difficult. The text below complements the eCos Porting Guide.
107
    </P
108
></DIV
109
><DIV
110
CLASS="REFSECT1"
111
><A
112
NAME="SYNTH-PORTING-LINUX"
113
></A
114
><H2
115
>Other Linux Platforms</H2
116
><P
117
>Porting the synthetic target to a Linux platform that uses a processor
118
other than x86 should be straightforward. The simplest approach is to
119
copy the existing <TT
120
CLASS="FILENAME"
121
>i386linux</TT
122
>
123
directory tree in the <TT
124
CLASS="FILENAME"
125
>hal/synth</TT
126
>
127
hierarchy, then rename and edit the ten or so files in this package.
128
Most of the changes should be pretty obvious, for example on a 64-bit
129
processor some new data types will be needed in the
130
<TT
131
CLASS="FILENAME"
132
>basetype.h</TT
133
> header file. It will also be necessary
134
to update the toplevel <TT
135
CLASS="FILENAME"
136
>ecos.db</TT
137
> database with an
138
entry for the new HAL package, and a new target entry will be needed.
139
    </P
140
><P
141
>Obviously a different processor will have different register sets and
142
calling conventions, so the code for saving and restoring thread
143
contexts and for implementing <TT
144
CLASS="FUNCTION"
145
>setjmp</TT
146
> and
147
<TT
148
CLASS="FUNCTION"
149
>longjmp</TT
150
> will need to be updated. The exact way of
151
performing Linux system calls will vary: on x86 linux this usually
152
involves pushing some registers on the stack and then executing an
153
<TT
154
CLASS="LITERAL"
155
>int&nbsp;0x080</TT
156
> trap instruction, but on a different
157
processor the arguments might be passed in registers instead and
158
certainly a different trap instruction will be used. The startup code
159
is written in assembler, but needs to do little more than extract the
160
process' argument and environment variables and then jump to the main
161
<TT
162
CLASS="FUNCTION"
163
>linux_entry</TT
164
> function provided by the
165
architectural synthetic target HAL package.
166
    </P
167
><P
168
>The header file <TT
169
CLASS="FILENAME"
170
>hal_io.h</TT
171
> provided by the
172
architectural HAL package provides various structure definitions,
173
function prototypes, and macros related to system calls. These are
174
correct for x86 linux, but there may be problems on other processors.
175
For example a structure field that is currently defined as a 32-bit
176
number may in fact may be a 64-bit number instead.
177
    </P
178
><P
179
>The synthetic target's memory map is defined in two files in the
180
<TT
181
CLASS="FILENAME"
182
>include/pkgconf</TT
183
> subdirectory.
184
For x86 the default memory map involves eight megabytes of read-only
185
memory for the code at location 0x1000000 and another eight megabytes
186
for data at 0x2000000. These address ranges may be reserved for other
187
purposes on the new architecture, so may need changing. There may be
188
some additional areas of memory allocated by the system for other
189
purposes, for example the startup stack and any environment variables,
190
but usually eCos applications can and should ignore those.
191
    </P
192
><P
193
>Other HAL functionality such as interrupt handling, diagnostics, and
194
the system clock are provided by the architectural HAL package and
195
should work on different processors with few if any changes. There may
196
be some problems in the code that interacts with the I/O auxiliary
197
because of lurking assumptions about endianness or the sizes of
198
various data types.
199
    </P
200
><P
201
>When porting to other processors, a number of sources of information
202
are likely to prove useful. Obviously the Linux kernel sources and
203
header files constitute the ultimate authority on how things work at
204
the system call level. The GNU C library sources may also prove very
205
useful: for a normal Linux application it is the C library that
206
provides the startup code and the system call interface.
207
    </P
208
></DIV
209
><DIV
210
CLASS="REFSECT1"
211
><A
212
NAME="SYNTH-PORTING-UNIX"
213
></A
214
><H2
215
>Other Unix Platforms</H2
216
><P
217
>Porting to a Unix or Unix-like operating system other than Linux would
218
be somewhat more involved. The first requirement is toolchains: the
219
GNU compilers, gcc and g++, must definitely be used; use of other GNU
220
tools such as the linker may be needed as well, because eCos depends
221
on functionality such as prioritizing C++ static constructors, and
222
other linkers may not implement this or may implement it in a
223
different and incompatible way. A closely related requirement is the
224
use of ELF format for binary executables: if the operating system
225
still uses an older format such as COFF then there are likely to be
226
problems because they do not provide the flexibility required by eCos.
227
    </P
228
><P
229
>In the architectural HAL there should be very little code that is
230
specific to Linux. Instead the code should work on any operating
231
system that provides a reasonable implementation of the POSIX
232
standard. There may be some problems with program startup, but those
233
could be handled at the architectural level. Some changes may also be
234
required to the exception handling code. However one file which will
235
present a problem is <TT
236
CLASS="FILENAME"
237
>hal_io.h</TT
238
>, which contains
239
various structure definitions and macros used with the system call
240
interface. It is likely that many of these definitions will need
241
changing, and it may well be appropriate to implement variant HAL
242
packages for the different operating systems where this information
243
can be separated out. Another possible problem is that the generic
244
code assumes that system calls such as
245
<TT
246
CLASS="FUNCTION"
247
>cyg_hal_sys_write</TT
248
> are available. On an operating
249
system other than Linux it is possible that some of these are not
250
simple system calls, and instead wrapper functions will need to be
251
implemented at the variant HAL level.
252
    </P
253
><P
254
>The generic I/O auxiliary code should be fairly portable to other Unix
255
platforms. However some of the device drivers may contain code that is
256
specific to Linux, for example the <TT
257
CLASS="LITERAL"
258
>PF_PACKET</TT
259
> socket
260
address family and the ethertap virtual tunnelling interface. These
261
may prove quite difficult to port.
262
    </P
263
><P
264
>The remaining porting task is to implement one or more platform HAL
265
packages, one per processor type that is supported. This should
266
involve much the same work as a port to <A
267
HREF="synth-porting.html#SYNTH-PORTING-LINUX"
268
>another processor running Linux</A
269
>.
270
    </P
271
><P
272
>When using other Unix operating systems the kernel source code may not
273
be available, which would make any porting effort more challenging.
274
However there is still a good chance that the GNU C library will have
275
been ported already, so its source code may contain much useful
276
information.
277
    </P
278
></DIV
279
><DIV
280
CLASS="REFSECT1"
281
><A
282
NAME="SYNTH-PORTING-OTHER"
283
></A
284
><H2
285
>Windows Platforms</H2
286
><P
287
>Porting the current synthetic target code to some version of Windows
288
or to another non-Unix platform is likely to prove very difficult. The
289
first hurdle that needs to be crossed is the file format for binary
290
executables: current Windows implementations do not use ELF, instead
291
they use their own format PE which is a variant of the rather old and
292
limited COFF format. It may well prove easier to first write an ELF
293
loader for Windows executables, rather than try to get eCos to work
294
within the constraints of PE. Of course that introduces new problems,
295
for example existing source-level debuggers will still expect
296
executables to be in PE format.
297
    </P
298
><P
299
>Under Linux a synthetic target application is not linked with the
300
system's C library or any other standard system library. That would
301
cause confusion, for example both eCos and the system's C library
302
might try to define the <TT
303
CLASS="FUNCTION"
304
>printf</TT
305
> function, and
306
introduce complications such as working with shared libraries. For
307
much the same reasons, a synthetic target application under Windows
308
should not be linked with any Windows DLL's. If an ELF loader has been
309
specially written then this may not be much of a problem.
310
    </P
311
><P
312
>The next big problem is the system call interface. Under Windows
313
system calls are generally made via DLL's, and it is not clear that
314
the underlying trap mechanism is well-documented or consistent between
315
different releases of Windows.
316
    </P
317
><P
318
>The current code depends on the operating system providing an
319
implementation of POSIX signal handling. This is used for I/O
320
purposes, for example <TT
321
CLASS="LITERAL"
322
>SIGALRM</TT
323
> is used for the
324
system clock, and for exceptions. It is not known what equivalent
325
functionality is available under Windows.
326
    </P
327
><P
328
>Given the above problems a port of the synthetic target to Windows may
329
or may not be technically feasible, but it would certainly require a
330
very large amount of effort.
331
    </P
332
></DIV
333
><DIV
334
CLASS="NAVFOOTER"
335
><HR
336
ALIGN="LEFT"
337
WIDTH="100%"><TABLE
338
SUMMARY="Footer navigation table"
339
WIDTH="100%"
340
BORDER="0"
341
CELLPADDING="0"
342
CELLSPACING="0"
343
><TR
344
><TD
345
WIDTH="33%"
346
ALIGN="left"
347
VALIGN="top"
348
><A
349
HREF="synth-new-host.html"
350
ACCESSKEY="P"
351
>Prev</A
352
></TD
353
><TD
354
WIDTH="34%"
355
ALIGN="center"
356
VALIGN="top"
357
><A
358
HREF="ecos-ref.html"
359
ACCESSKEY="H"
360
>Home</A
361
></TD
362
><TD
363
WIDTH="33%"
364
ALIGN="right"
365
VALIGN="top"
366
><A
367
HREF="devs-usb-sa11x0-ref.html"
368
ACCESSKEY="N"
369
>Next</A
370
></TD
371
></TR
372
><TR
373
><TD
374
WIDTH="33%"
375
ALIGN="left"
376
VALIGN="top"
377
>Writing New Devices - host</TD
378
><TD
379
WIDTH="34%"
380
ALIGN="center"
381
VALIGN="top"
382
><A
383
HREF="hal-synth-arch.html"
384
ACCESSKEY="U"
385
>Up</A
386
></TD
387
><TD
388
WIDTH="33%"
389
ALIGN="right"
390
VALIGN="top"
391
>SA11X0 USB Device Driver</TD
392
></TR
393
></TABLE
394
></DIV
395
></BODY
396
></HTML
397
>

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.