doc/html/ref/synth-porting.html

   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.               -->
   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 >