OpenCores
URL https://opencores.org/ocsvn/openrisc_2011-10-31/openrisc_2011-10-31/trunk

Subversion Repositories openrisc_2011-10-31

[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [ref/] [synth.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
>Overview</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="eCos Synthetic Target"
26
HREF="hal-synth-arch.html"><LINK
27
REL="NEXT"
28
TITLE="Installation"
29
HREF="synth-install.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="hal-synth-arch.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="synth-install.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">Overview</H1
83
><DIV
84
CLASS="REFNAMEDIV"
85
><A
86
NAME="AEN17662"
87
></A
88
><H2
89
>Name</H2
90
>The eCos synthetic target&nbsp;--&nbsp;Overview</DIV
91
><DIV
92
CLASS="REFSECT1"
93
><A
94
NAME="SYNTH-DESCRIPTION"
95
></A
96
><H2
97
>Description</H2
98
><P
99
>Usually eCos runs on either a custom piece of hardware, specially
100
designed to meet the needs of a specific application, or on a
101
development board of some sort that is available before the final
102
hardware. Such boards have a number of things in common:
103
    </P
104
><P
105
></P
106
><OL
107
TYPE="1"
108
><LI
109
><P
110
>Obviously there has to be at least one processor to do the work. Often
111
this will be a 32-bit processor, but it can be smaller or larger.
112
Processor speed will vary widely, depending on the expected needs of
113
the application. However the exact processor being used tends not to
114
matter very much for most of the development process: the use of
115
languages such as C or C++ means that the compiler will handle those
116
details.
117
      </P
118
></LI
119
><LI
120
><P
121
>There needs to be memory for code and for data. A typical system will
122
have two different types of memory. There will be some non-volatile
123
memory such as flash, EPROM or masked ROM. There will also be some
124
volatile memory such as DRAM or SRAM. Often the code for the final
125
application will reside in the non-volatile memory and all of the RAM
126
will be available for data. However updating non-volatile memory
127
requires a non-trivial amount of effort, so for much of the
128
development process it is more convenient to burn suitable firmware,
129
for example RedBoot, into the non-volatile memory and then use that to
130
load the application being debugged into RAM, alongside the
131
application data and a small area reserved for use by the firmware.
132
      </P
133
></LI
134
><LI
135
><P
136
>The platform must provide certain mimimal I/O facilities. Most eCos
137
configurations require a clock signal of some sort. There must also be
138
some way of outputting diagnostics to the user, often but not always
139
via a serial port. Unless special debug hardware is being used, source
140
level debugging will require bidirectional communication between a
141
host machine and the target hardware, usually via a serial port or an
142
ethernet device.
143
      </P
144
></LI
145
><LI
146
><P
147
>All the above is not actually very useful yet because there is no way
148
for the embedded device to interact with the rest of the world, except
149
by generating diagnostics. Therefore an embedded device will have
150
additional I/O hardware. This may be fairly standard hardware such as
151
an ethernet or USB interface, or special hardware designed
152
specifically for the intended application, or quite often some
153
combination. Standard hardware such as ethernet or USB may be
154
supported by eCos device drivers and protocol stacks, whereas the
155
special hardware will be driven directly by application code.
156
      </P
157
></LI
158
></OL
159
><P
160
>Much of the above can be emulated on a typical PC running Linux.
161
Instead of running the embedded application being developed on a
162
target board of some sort, it can be run as a Linux process. The
163
processor will be the PC's own processor, for example an x86, and the
164
memory will be the process' address space. Some I/O facilities can be
165
emulated directly through system calls. For example clock hardware can
166
be emulated by setting up a <TT
167
CLASS="LITERAL"
168
>SIGALRM</TT
169
> signal, which
170
will cause the process to be interrupted at regular intervals. This
171
emulation of real hardware will not be particularly accurate, the
172
number of cpu cycles available to the eCos application between clock
173
ticks will vary widely depending on what else is running on the PC,
174
but for much development work it will be good enough.
175
    </P
176
><P
177
>Other I/O facilities are provided through an I/O auxiliary process,
178
ecosynth, that gets spawned by the eCos application during startup.
179
When an eCos device driver wants to perform some I/O operation, for
180
example send out an ethernet packet, it sends a request to the I/O
181
auxiliary. That is an ordinary Linux application so it has ready
182
access to all normal Linux I/O facilities. To emulate a device
183
interrupt the I/O auxiliary can raise a <TT
184
CLASS="LITERAL"
185
>SIGIO</TT
186
>
187
signal within the eCos application. The HAL's interrupt subsystem
188
installs a signal handler for this, which will then invoke the
189
standard eCos ISR/DSR mechanisms. The I/O auxiliary is based around
190
Tcl scripting, making it easy to extend and customize. It should be
191
possible to configure the synthetic target so that its I/O
192
functionality is similar to what will be available on the final target
193
hardware for the application being developed.
194
    </P
195
><DIV
196
CLASS="INFORMALFIGURE"
197
><A
198
NAME="AEN17681"><P
199
></P
200
><DIV
201
CLASS="MEDIAOBJECT"
202
><P
203
><IMG
204
SRC="synth-io-overview.png"
205
ALIGN="CENTER"></P
206
></DIV
207
><P
208
></P
209
></DIV
210
><P
211
>A key requirement for synthetic target code is that the embedded
212
application must not be linked with any of the standard Linux
213
libraries such as the GNU C library: that would lead to a confusing
214
situation where both eCos and the Linux libraries attempted to provide
215
functions such as <TT
216
CLASS="FUNCTION"
217
>printf</TT
218
>. Instead the synthetic
219
target support must be implemented directly on top of the Linux
220
kernels' system call interface. For example, the kernel provides a
221
system call for write operations. The actual function
222
<TT
223
CLASS="FUNCTION"
224
>write</TT
225
> is implemented in the system's C library,
226
but all it does is move its arguments on to the stack or into certain
227
registers and then execute a special trap instruction such as
228
<TT
229
CLASS="LITERAL"
230
>int&nbsp;0x80</TT
231
>. When this instruction is executed
232
control transfers into the kernel, which will validate the arguments
233
and perform the appropriate operation. Now, a synthetic target
234
application cannot be linked with the system's C library. Instead it
235
contains a function <TT
236
CLASS="FUNCTION"
237
>cyg_hal_sys_write</TT
238
> which, like
239
the C library's <TT
240
CLASS="FUNCTION"
241
>write</TT
242
> function, pushes its
243
arguments on to the stack and executes the trap instruction. The Linux
244
kernel cannot tell the difference, so it will perform the I/O
245
operation requested by the synthetic target. With appropriate
246
knowledge of what system calls are available, this makes it possible
247
to emulate the required I/O facilities. For example, spawning the
248
ecosynth I/O auxiliary involves system calls
249
<TT
250
CLASS="FUNCTION"
251
>cyg_hal_sys_fork</TT
252
> and
253
<TT
254
CLASS="FUNCTION"
255
>cyg_hal_sys_execve</TT
256
>, and sending a request to the
257
auxiliary uses <TT
258
CLASS="FUNCTION"
259
>cyg_hal_sys_write</TT
260
>.
261
    </P
262
><P
263
>In many ways developing for the synthetic target is no different from
264
developing for real embedded targets. eCos must be configured
265
appropriately: selecting a suitable target such as
266
<TT
267
CLASS="USERINPUT"
268
><B
269
>i386linux</B
270
></TT
271
> will cause the configuration system
272
to load the appropriate packages for this hardware; this includes an
273
architectural HAL package and a platform-specific package; the
274
architectural package contains generic code applicable to all Linux
275
platforms, whereas the platform package is for specific Linux
276
implementations such as the x86 version and contains any
277
processor-specific code. Selecting this target will also bring in some
278
device driver packages. Other aspects of the configuration such as
279
which API's are supported are determined by the template, by adding
280
and removing packages, and by fine-grained configuration.
281
    </P
282
><P
283
>In other ways developing for the synthetic target can be much easier
284
than developing for a real embedded target. For example there is no
285
need to worry about building and installing suitable firmware on the
286
target hardware, and then downloading and debugging the actual
287
application over a serial line or a similar connection. Instead an
288
eCos application built for the synthetic target is mostly
289
indistinguishable from an ordinary Linux program. It can be run simply
290
by typing the name of the executable file at a shell prompt.
291
Alternatively you can debug the application using whichever version of
292
gdb is provided by your Linux distribution. There is no need to build
293
or install special toolchains. Essentially using the synthetic target
294
means that the various problems associated with real embedded hardware
295
can be bypassed for much of the development process.
296
    </P
297
><P
298
>The eCos synthetic target provides emulation, not simulation. It is
299
possible to run eCos in suitable architectural simulators but that
300
involves a rather different approach to software development. For
301
example, when running eCos on the psim PowerPC simulator you need
302
appropriate cross-compilation tools that allow you to build PowerPC
303
executables. These are then loaded into the simulator which interprets
304
every instruction and attempts to simulate what would happen if the
305
application were running on real hardware. This involves a lot of
306
processing overhead, but depending on the functionality provided by
307
the simulator it can give very accurate results. When developing for
308
the synthetic target the executable is compiled for the PC's own
309
processor and will be executed at full speed, with no need for a
310
simulator or special tools. This will be much faster and somewhat
311
simpler than using an architectural simulator, but no attempt is made
312
to accurately match the behaviour of a real embedded target.
313
    </P
314
></DIV
315
><DIV
316
CLASS="NAVFOOTER"
317
><HR
318
ALIGN="LEFT"
319
WIDTH="100%"><TABLE
320
SUMMARY="Footer navigation table"
321
WIDTH="100%"
322
BORDER="0"
323
CELLPADDING="0"
324
CELLSPACING="0"
325
><TR
326
><TD
327
WIDTH="33%"
328
ALIGN="left"
329
VALIGN="top"
330
><A
331
HREF="hal-synth-arch.html"
332
ACCESSKEY="P"
333
>Prev</A
334
></TD
335
><TD
336
WIDTH="34%"
337
ALIGN="center"
338
VALIGN="top"
339
><A
340
HREF="ecos-ref.html"
341
ACCESSKEY="H"
342
>Home</A
343
></TD
344
><TD
345
WIDTH="33%"
346
ALIGN="right"
347
VALIGN="top"
348
><A
349
HREF="synth-install.html"
350
ACCESSKEY="N"
351
>Next</A
352
></TD
353
></TR
354
><TR
355
><TD
356
WIDTH="33%"
357
ALIGN="left"
358
VALIGN="top"
359
>eCos Synthetic Target</TD
360
><TD
361
WIDTH="34%"
362
ALIGN="center"
363
VALIGN="top"
364
><A
365
HREF="hal-synth-arch.html"
366
ACCESSKEY="U"
367
>Up</A
368
></TD
369
><TD
370
WIDTH="33%"
371
ALIGN="right"
372
VALIGN="top"
373
>Installation</TD
374
></TR
375
></TABLE
376
></DIV
377
></BODY
378
></HTML
379
>

powered by: WebSVN 2.1.0

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