1 <!-- 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. -->
13 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
16 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
19 TITLE="eCos Reference Manual"
20 HREF="ecos-ref.html"><LINK
22 TITLE="eCos Synthetic Target"
23 HREF="hal-synth-arch.html"><LINK
25 TITLE="eCos Synthetic Target"
26 HREF="hal-synth-arch.html"><LINK
29 HREF="synth-install.html"></HEAD
40 SUMMARY="Header navigation table"
49 >eCos Reference Manual</TH
57 HREF="hal-synth-arch.html"
71 HREF="synth-install.html"
82 NAME="SYNTH">Overview</H1
90 >The eCos synthetic target -- Overview</DIV
94 NAME="SYNTH-DESCRIPTION"
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:
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
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.
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
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.
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
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.
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
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.
196 CLASS="INFORMALFIGURE"
204 SRC="synth-io-overview.png"
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
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
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
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
237 >cyg_hal_sys_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
251 >cyg_hal_sys_fork</TT
255 >cyg_hal_sys_execve</TT
256 >, and sending a request to the
259 >cyg_hal_sys_write</TT
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
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.
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.
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.
320 SUMMARY="Footer navigation table"
331 HREF="hal-synth-arch.html"
349 HREF="synth-install.html"
359 >eCos Synthetic Target</TD
365 HREF="hal-synth-arch.html"
projects / karo-tx-redboot.git / blob