📄 synth-porting.html
字号:
<!-- Copyright (C) 2003 Red Hat, Inc. --><!-- This material may be distributed only subject to the terms --><!-- and conditions set forth in the Open Publication License, v1.0 --><!-- or later (the latest version is presently available at --><!-- http://www.opencontent.org/openpub/). --><!-- Distribution of the work or derivative of the work in any --><!-- standard (paper) book form is prohibited unless prior --><!-- permission is obtained from the copyright holder. --><HTML><HEAD><TITLE>Porting</TITLE><meta name="MSSmartTagsPreventParsing" content="TRUE"><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+"><LINKREL="HOME"TITLE="eCos Reference Manual"HREF="ecos-ref.html"><LINKREL="UP"TITLE="eCos Synthetic Target"HREF="hal-synth-arch.html"><LINKREL="PREVIOUS"TITLE="Writing New Devices - host"HREF="synth-new-host.html"><LINKREL="NEXT"TITLE="SA11X0 USB Device Driver"HREF="devs-usb-sa11x0-ref.html"></HEAD><BODYCLASS="REFENTRY"BGCOLOR="#FFFFFF"TEXT="#000000"LINK="#0000FF"VLINK="#840084"ALINK="#0000FF"><DIVCLASS="NAVHEADER"><TABLESUMMARY="Header navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">eCos Reference Manual</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="synth-new-host.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom"></TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="devs-usb-sa11x0-ref.html"ACCESSKEY="N">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><H1><ANAME="SYNTH-PORTING">Porting</H1><DIVCLASS="REFNAMEDIV"><ANAME="AEN18705"></A><H2>Name</H2>Porting -- Adding support for other hosts</DIV><DIVCLASS="REFSECT1"><ANAME="SYNTH-PORTING-DESCRIPTION"></A><H2>Description</H2><P>The initial development effort of the eCos synthetic target happenedon x86 Linux machines. Porting to other platforms involves addressinga number of different issues. Some ports should be fairlystraightforward, for example a port to Linux on a processor other thanan x86. Porting to Unix or Unix-like operating systems other thanLinux may be possible, but would involve more effort. Porting to acompletely different operating system such as Windows would be verydifficult. The text below complements the eCos Porting Guide. </P></DIV><DIVCLASS="REFSECT1"><ANAME="SYNTH-PORTING-LINUX"></A><H2>Other Linux Platforms</H2><P>Porting the synthetic target to a Linux platform that uses a processorother than x86 should be straightforward. The simplest approach is tocopy the existing <TTCLASS="FILENAME">i386linux</TT>directory tree in the <TTCLASS="FILENAME">hal/synth</TT>hierarchy, then rename and edit the ten or so files in this package.Most of the changes should be pretty obvious, for example on a 64-bitprocessor some new data types will be needed in the<TTCLASS="FILENAME">basetype.h</TT> header file. It will also be necessaryto update the toplevel <TTCLASS="FILENAME">ecos.db</TT> database with anentry for the new HAL package, and a new target entry will be needed. </P><P>Obviously a different processor will have different register sets andcalling conventions, so the code for saving and restoring threadcontexts and for implementing <TTCLASS="FUNCTION">setjmp</TT> and<TTCLASS="FUNCTION">longjmp</TT> will need to be updated. The exact way ofperforming Linux system calls will vary: on x86 linux this usuallyinvolves pushing some registers on the stack and then executing an<TTCLASS="LITERAL">int 0x080</TT> trap instruction, but on a differentprocessor the arguments might be passed in registers instead andcertainly a different trap instruction will be used. The startup codeis written in assembler, but needs to do little more than extract theprocess' argument and environment variables and then jump to the main<TTCLASS="FUNCTION">linux_entry</TT> function provided by thearchitectural synthetic target HAL package. </P><P>The header file <TTCLASS="FILENAME">hal_io.h</TT> provided by thearchitectural HAL package provides various structure definitions,function prototypes, and macros related to system calls. These arecorrect for x86 linux, but there may be problems on other processors.For example a structure field that is currently defined as a 32-bitnumber may in fact may be a 64-bit number instead. </P><P>The synthetic target's memory map is defined in two files in the<TTCLASS="FILENAME">include/pkgconf</TT> subdirectory.For x86 the default memory map involves eight megabytes of read-onlymemory for the code at location 0x1000000 and another eight megabytesfor data at 0x2000000. These address ranges may be reserved for otherpurposes on the new architecture, so may need changing. There may besome additional areas of memory allocated by the system for otherpurposes, for example the startup stack and any environment variables,but usually eCos applications can and should ignore those. </P><P>Other HAL functionality such as interrupt handling, diagnostics, andthe system clock are provided by the architectural HAL package andshould work on different processors with few if any changes. There maybe some problems in the code that interacts with the I/O auxiliarybecause of lurking assumptions about endianness or the sizes ofvarious data types. </P><P>When porting to other processors, a number of sources of informationare likely to prove useful. Obviously the Linux kernel sources andheader files constitute the ultimate authority on how things work atthe system call level. The GNU C library sources may also prove veryuseful: for a normal Linux application it is the C library thatprovides the startup code and the system call interface. </P></DIV><DIVCLASS="REFSECT1"><ANAME="SYNTH-PORTING-UNIX"></A><H2>Other Unix Platforms</H2><P>Porting to a Unix or Unix-like operating system other than Linux wouldbe somewhat more involved. The first requirement is toolchains: theGNU compilers, gcc and g++, must definitely be used; use of other GNUtools such as the linker may be needed as well, because eCos dependson functionality such as prioritizing C++ static constructors, andother linkers may not implement this or may implement it in adifferent and incompatible way. A closely related requirement is theuse of ELF format for binary executables: if the operating systemstill uses an older format such as COFF then there are likely to beproblems because they do not provide the flexibility required by eCos. </P><P>In the architectural HAL there should be very little code that isspecific to Linux. Instead the code should work on any operatingsystem that provides a reasonable implementation of the POSIXstandard. There may be some problems with program startup, but thosecould be handled at the architectural level. Some changes may also berequired to the exception handling code. However one file which willpresent a problem is <TTCLASS="FILENAME">hal_io.h</TT>, which containsvarious structure definitions and macros used with the system callinterface. It is likely that many of these definitions will needchanging, and it may well be appropriate to implement variant HALpackages for the different operating systems where this informationcan be separated out. Another possible problem is that the genericcode assumes that system calls such as<TTCLASS="FUNCTION">cyg_hal_sys_write</TT> are available. On an operatingsystem other than Linux it is possible that some of these are notsimple system calls, and instead wrapper functions will need to beimplemented at the variant HAL level. </P><P>The generic I/O auxiliary code should be fairly portable to other Unixplatforms. However some of the device drivers may contain code that isspecific to Linux, for example the <TTCLASS="LITERAL">PF_PACKET</TT> socketaddress family and the ethertap virtual tunnelling interface. Thesemay prove quite difficult to port. </P><P>The remaining porting task is to implement one or more platform HALpackages, one per processor type that is supported. This shouldinvolve much the same work as a port to <AHREF="synth-porting.html#SYNTH-PORTING-LINUX">another processor running Linux</A>. </P><P>When using other Unix operating systems the kernel source code may notbe available, which would make any porting effort more challenging.However there is still a good chance that the GNU C library will havebeen ported already, so its source code may contain much usefulinformation. </P></DIV><DIVCLASS="REFSECT1"><ANAME="SYNTH-PORTING-OTHER"></A><H2>Windows Platforms</H2><P>Porting the current synthetic target code to some version of Windowsor to another non-Unix platform is likely to prove very difficult. Thefirst hurdle that needs to be crossed is the file format for binaryexecutables: current Windows implementations do not use ELF, insteadthey use their own format PE which is a variant of the rather old andlimited COFF format. It may well prove easier to first write an ELFloader for Windows executables, rather than try to get eCos to workwithin the constraints of PE. Of course that introduces new problems,for example existing source-level debuggers will still expectexecutables to be in PE format. </P><P>Under Linux a synthetic target application is not linked with thesystem's C library or any other standard system library. That wouldcause confusion, for example both eCos and the system's C librarymight try to define the <TTCLASS="FUNCTION">printf</TT> function, andintroduce complications such as working with shared libraries. Formuch the same reasons, a synthetic target application under Windowsshould not be linked with any Windows DLL's. If an ELF loader has beenspecially written then this may not be much of a problem. </P><P>The next big problem is the system call interface. Under Windowssystem calls are generally made via DLL's, and it is not clear thatthe underlying trap mechanism is well-documented or consistent betweendifferent releases of Windows. </P><P>The current code depends on the operating system providing animplementation of POSIX signal handling. This is used for I/Opurposes, for example <TTCLASS="LITERAL">SIGALRM</TT> is used for thesystem clock, and for exceptions. It is not known what equivalentfunctionality is available under Windows. </P><P>Given the above problems a port of the synthetic target to Windows mayor may not be technically feasible, but it would certainly require avery large amount of effort. </P></DIV><DIVCLASS="NAVFOOTER"><HRALIGN="LEFT"WIDTH="100%"><TABLESUMMARY="Footer navigation table"WIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top"><AHREF="synth-new-host.html"ACCESSKEY="P">Prev</A></TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="ecos-ref.html"ACCESSKEY="H">Home</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top"><AHREF="devs-usb-sa11x0-ref.html"ACCESSKEY="N">Next</A></TD></TR><TR><TDWIDTH="33%"ALIGN="left"VALIGN="top">Writing New Devices - host</TD><TDWIDTH="34%"ALIGN="center"VALIGN="top"><AHREF="hal-synth-arch.html"ACCESSKEY="U">Up</A></TD><TDWIDTH="33%"ALIGN="right"VALIGN="top">SA11X0 USB Device Driver</TD></TR></TABLE></DIV></BODY></HTML>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -