mirror of
https://gitlab.rtems.org/rtems/rtos/rtems.git
synced 2026-08-22 23:39:43 +08:00
2006-08-23 Joel Sherrill <joel@OARcorp.com>
* Makefile.am, configure.ac, index.html.in: FAQ should now be completely in the Wiki. * FAQ/.cvsignore, FAQ/FAQ.texi, FAQ/Makefile.am, FAQ/basic.t, FAQ/bsp.t, FAQ/build45.t, FAQ/concepts.t, FAQ/debug.t, FAQ/endoftime.t, FAQ/entry, FAQ/freesw.t, FAQ/hwdebugaids.t, FAQ/projects.t, FAQ/stamp-vti, FAQ/tools.t, FAQ/version.texi, common/timemac.texi, common/timetbl.t, common/timing.t: Removed.
This commit is contained in:
Joel Sherrill
@@ -1,3 +1,13 @@
|
||||
2006-08-23 Joel Sherrill <joel@OARcorp.com>
|
||||
|
||||
* Makefile.am, configure.ac, index.html.in: FAQ should now be
|
||||
completely in the Wiki.
|
||||
* FAQ/.cvsignore, FAQ/FAQ.texi, FAQ/Makefile.am, FAQ/basic.t,
|
||||
FAQ/bsp.t, FAQ/build45.t, FAQ/concepts.t, FAQ/debug.t,
|
||||
FAQ/endoftime.t, FAQ/entry, FAQ/freesw.t, FAQ/hwdebugaids.t,
|
||||
FAQ/projects.t, FAQ/stamp-vti, FAQ/tools.t, FAQ/version.texi,
|
||||
common/timemac.texi, common/timetbl.t, common/timing.t: Removed.
|
||||
|
||||
2006-08-23 Joel Sherrill <joel@OARcorp.com>
|
||||
|
||||
* Makefile.am, configure.ac, FAQ/stamp-vti, FAQ/version.texi,
|
||||
|
||||
@@ -1,23 +0,0 @@
|
||||
embeddedinfo.texi
|
||||
FAQ
|
||||
FAQ.aux
|
||||
FAQ.cp
|
||||
FAQ.dvi
|
||||
FAQ.fn
|
||||
FAQ*.html
|
||||
FAQ.ky
|
||||
FAQ.log
|
||||
FAQ.pdf
|
||||
FAQ.pg
|
||||
FAQ.ps
|
||||
FAQ.toc
|
||||
FAQ.tp
|
||||
FAQ.vr
|
||||
index.html
|
||||
Makefile
|
||||
Makefile.in
|
||||
mdate-sh
|
||||
rtems_footer.html
|
||||
rtems_header.html
|
||||
stamp-vti
|
||||
version.texi
|
||||
@@ -1,117 +0,0 @@
|
||||
\input texinfo @c -*-texinfo-*-
|
||||
@c %**start of header
|
||||
@setfilename FAQ.info
|
||||
@setcontentsaftertitlepage
|
||||
@syncodeindex vr fn
|
||||
@synindex ky cp
|
||||
@paragraphindent 0
|
||||
@c %**end of header
|
||||
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@c
|
||||
@c Master file for the RTEMS FAQ
|
||||
@c
|
||||
|
||||
@include version.texi
|
||||
@include common/setup.texi
|
||||
@include common/rtems.texi
|
||||
|
||||
@ifset use-ascii
|
||||
@dircategory RTEMS On-Line Manual
|
||||
@direntry
|
||||
* RTEMS FAQ: (FAQ). Frequently Asked Questions.
|
||||
@end direntry
|
||||
@end ifset
|
||||
|
||||
@c
|
||||
@c Title Page Stuff
|
||||
@c
|
||||
|
||||
@c
|
||||
@c I don't really like having a short title page. --joel
|
||||
@c
|
||||
@c @shorttitlepage RTEMS Frequently Asked Questions
|
||||
|
||||
@setchapternewpage odd
|
||||
@settitle RTEMS Frequently Asked Questions
|
||||
@titlepage
|
||||
@finalout
|
||||
|
||||
@title RTEMS Frequently Asked Questions
|
||||
@subtitle Edition @value{EDITION}, for @value{VERSION}
|
||||
@sp 1
|
||||
@subtitle @value{UPDATED}
|
||||
@author On-Line Applications Research Corporation
|
||||
@page
|
||||
@include common/cpright.texi
|
||||
@end titlepage
|
||||
|
||||
@c This prevents a black box from being printed on "overflow" lines.
|
||||
@c The alternative is to rework a sentence to avoid this problem.
|
||||
|
||||
@include basic.texi
|
||||
@include tools.texi
|
||||
@include concepts.texi
|
||||
@include build45.texi
|
||||
@include bsp.texi
|
||||
@include debug.texi
|
||||
@include freesw.texi
|
||||
@include hwdebugaids.texi
|
||||
@include projects.texi
|
||||
@include endoftime.texi
|
||||
|
||||
@ifinfo
|
||||
@node Top, Basic Information, (dir), (dir)
|
||||
@top FAQ
|
||||
|
||||
This document is the RTEMS FAQ. FAQ is an acronym for Frequently
|
||||
Asked Questions and we sincerely hope that this contains the answers
|
||||
to some of the questions most frequently asked about RTEMS.
|
||||
|
||||
Common questions have been divided into the following categories.
|
||||
|
||||
|
||||
@menu
|
||||
* Basic Information::
|
||||
* General Development Tool Hints::
|
||||
* RTEMS Concepts::
|
||||
* Building RTEMS::
|
||||
* BSP Questions::
|
||||
* Debugging Hints::
|
||||
* Free Software that Works with RTEMS::
|
||||
* Hardware to Ease Debugging::
|
||||
* RTEMS Projects::
|
||||
* Date/Time Issues in Systems Using RTEMS::
|
||||
@end menu
|
||||
|
||||
@c * Command and Variable Index::
|
||||
@c * Concept Index::
|
||||
@end ifinfo
|
||||
@c
|
||||
@c
|
||||
@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here
|
||||
@c
|
||||
|
||||
@c @node Command and Variable Index, Concept Index, Installing GCC AND NEWLIB, Top
|
||||
@c @unnumbered Command and Variable Index
|
||||
|
||||
@c There are currently no Command and Variable Index entries.
|
||||
|
||||
@c @printindex fn
|
||||
|
||||
@c @node Concept Index, , Command and Variable Index, Top
|
||||
@c @unnumbered Concept Index
|
||||
|
||||
@c There are currently no Concept Index entries.
|
||||
@c @printindex cp
|
||||
|
||||
@contents
|
||||
@bye
|
||||
|
||||
@@ -1,82 +0,0 @@
|
||||
#
|
||||
# COPYRIGHT (c) 1988-2002.
|
||||
# On-Line Applications Research Corporation (OAR).
|
||||
# All rights reserved.
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
PROJECT = FAQ
|
||||
EDITION = 1
|
||||
|
||||
include $(top_srcdir)/project.am
|
||||
include $(top_srcdir)/main.am
|
||||
|
||||
GENERATED_FILES = basic.texi tools.texi concepts.texi build45.texi bsp.texi \
|
||||
debug.texi freesw.texi hwdebugaids.texi projects.texi endoftime.texi
|
||||
|
||||
COMMON_FILES += $(top_srcdir)/common/cpright.texi
|
||||
|
||||
FILES =
|
||||
|
||||
info_TEXINFOS = FAQ.texi
|
||||
FAQ_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
|
||||
|
||||
#
|
||||
# Process Automatically Generated Files
|
||||
#
|
||||
|
||||
basic.texi: basic.t
|
||||
$(BMENU2) -c -p "Top" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
tools.texi: tools.t
|
||||
$(BMENU2) -c -p "Top" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
concepts.texi: concepts.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
build45.texi: build45.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
bsp.texi: bsp.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
debug.texi: debug.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
freesw.texi: freesw.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
hwdebugaids.texi: hwdebugaids.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
projects.texi: projects.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
endoftime.texi: endoftime.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
CLEANFILES += FAQ.info FAQ.info-?
|
||||
|
||||
EXTRA_DIST = entry basic.t bsp.t build45.t concepts.t debug.t endoftime.t \
|
||||
freesw.t hwdebugaids.t projects.t tools.t
|
||||
-196
@@ -1,196 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Basic Information
|
||||
|
||||
The questions in this category are basic questions about RTEMS. Where
|
||||
did it come from, why is it, what is it, when should you use it, etc.?
|
||||
|
||||
@section What does RTEMS stand for?
|
||||
|
||||
RTEMS is an an acronym for the Real-Time Executive for Multiprocessor
|
||||
Systems.
|
||||
|
||||
Initially RTEMS stood for the Real-Time Executive for Missile Systems
|
||||
but as it became clear that the application domains that could use
|
||||
RTEMS extended far beyond missiles, the "M" changed to mean Military.
|
||||
At one point, there were both Ada and C implementations of RTEMS. The
|
||||
C version changed the "M" to mean Multiprocessor while the Ada version
|
||||
remained with the "M" meaning Military.
|
||||
|
||||
@section What is RTEMS?
|
||||
|
||||
RTEMS is a real-time executive which provides a high performance
|
||||
environment for embedded military applications including many
|
||||
features. The following is just a short list of the features
|
||||
available in RTEMS. If you are interested in something that
|
||||
is not on this list, please contact the RTEMS Team. Features
|
||||
are being added continuously.
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item Standards Compliant
|
||||
@itemize @bullet
|
||||
@item POSIX 1003.1b API including threads
|
||||
@item RTEID/ORKID based Classic API
|
||||
@end itemize
|
||||
|
||||
@item TCP/IP Stack
|
||||
@itemize @bullet
|
||||
@item high performance port of FreeBSD TCP/IP stack
|
||||
@item UDP, TCP
|
||||
@item ICMP, DHCP, RARP
|
||||
@item TFTP
|
||||
@item RPC
|
||||
@item FTPD
|
||||
@item HTTPD
|
||||
@item CORBA
|
||||
@end itemize
|
||||
|
||||
@item Debugging
|
||||
@itemize @bullet
|
||||
@item GNU debugger (gdb)
|
||||
@item DDD GUI interface to GDB
|
||||
@item thread aware
|
||||
@item debug over Ethernet
|
||||
@item debug over Serial Port
|
||||
@end itemize
|
||||
|
||||
@item Filesystem Support
|
||||
@itemize @bullet
|
||||
@item In-Memory Filesystem (IMFS)
|
||||
@item TFTP Client Filesystem
|
||||
@end itemize
|
||||
|
||||
@item Basic Kernel Features
|
||||
@itemize @bullet
|
||||
@item multitasking capabilities
|
||||
@item homogeneous and heterogeneous multiprocessor systems
|
||||
@item event-driven, priority-based, preemptive scheduling
|
||||
@item optional rate monotonic scheduling
|
||||
@item intertask communication and synchronization
|
||||
@item priority inheritance
|
||||
@item responsive interrupt management
|
||||
@item dynamic memory allocation
|
||||
@item high level of user configurability
|
||||
@end itemize
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
@section What standards does RTEMS support?
|
||||
|
||||
The original "Classic" RTEMS API is based on the Real-Time Executive
|
||||
Interface Definition (RTEID) and the Open Real-Time Kernel Interface
|
||||
Definition (ORKID). RTEMS also includes support for POSIX threads
|
||||
and real-time extensions.
|
||||
|
||||
With the addition of file system infrastructure, RTEMS supports
|
||||
about 70% of the POSIX 1003.1b-1996 standard. This standard
|
||||
defines the programming interfaces of standard UNIX. This means
|
||||
that much source code that works on UNIX, also works on RTEMS.
|
||||
|
||||
@section What processors is RTEMS available for?
|
||||
|
||||
RTEMS is available for the following processor families:
|
||||
|
||||
@itemize @bullet
|
||||
@item Motorola MC68xxx
|
||||
@item Motorola MC683xx
|
||||
@item Motorola ColdFire
|
||||
@item ARM
|
||||
@item Hitachi H8/300
|
||||
@item Hitachi SH
|
||||
@item Intel i386
|
||||
@item MIPS
|
||||
@item PowerPC
|
||||
@item SPARC
|
||||
@item Texas Instruments C3x/C4x
|
||||
@item OpenCores OR32
|
||||
@end itemize
|
||||
|
||||
In addition, there is a port to UNIX which can be used as a prototyping
|
||||
and simulation environment.
|
||||
|
||||
@section Executive vs. Kernel vs. Operating System (RTOS)
|
||||
|
||||
The developers of RTEMS developers use the terms executive and kernel
|
||||
interchangeably. In the embedded system community, the terms executive
|
||||
or kernel are generally used to refer to small operating systems.
|
||||
So we consider it proper to refer to RTEMS as an executive, a kernel,
|
||||
or an operating system.
|
||||
|
||||
@section Where/why was it developed?
|
||||
|
||||
RTEMS was developed by On-Line Applications Research Corporation (OAR)
|
||||
for the U.S. Army Missile Command prior to that organizations merger
|
||||
with the Aviation Command that resulted in the new command, U. S. Army
|
||||
Aviation and Missile command (AMCOM). The original goal of RTEMS was
|
||||
to provide a portable, standards-based real-time executive for which
|
||||
source code was available and royalties were paid.
|
||||
|
||||
In other words, RTEMS was open source before open source was cool.
|
||||
|
||||
Since the initial release to the world, the RTEMS Community has
|
||||
grown enormously and contributed significantly to RTEMS. Important
|
||||
additions such as the TCP/IP stack, FAT filesystem, multiple ports,
|
||||
device drivers, and most BSPs have come from users like yourself.
|
||||
|
||||
@section Are there no similar commercial products?
|
||||
|
||||
Yes, but not all are based on standards and the open source philosophy.
|
||||
|
||||
@section How can I get RTEMS?
|
||||
|
||||
RTEMS is distributed from @uref{@value{RTEMSHTTPURL},@value{RTEMSHTTPURL}}.
|
||||
This is a server dedicated to the RTEMS Project which was donated by and
|
||||
hosted by @uref{http://www.oarcorp.com,OAR Corporation} to provide
|
||||
a focal point for all RTEMS activities. Point your
|
||||
favorite browser at the following URL and following the link:
|
||||
|
||||
@uref{@value{RTEMSHTTPURL},@value{RTEMSHTTPURL}}
|
||||
|
||||
But if you are already reading this, you probably already found it. :)
|
||||
|
||||
@section What about support?
|
||||
|
||||
RTEMS development and support services are available from a number
|
||||
of firms. See
|
||||
@uref{@value{RTEMSHTTPURL}/support.html,@value{RTEMSHTTPURL}/support.html}
|
||||
for the current list of RTEMS service providers.
|
||||
|
||||
Remember that RTEMS maintenance is funded by users. If you are
|
||||
using RTEMS on a commercial project, please get support.
|
||||
|
||||
@section Are there any mailing lists?
|
||||
|
||||
The primary RTEMS mailing list is @code{@value{RTEMSUSERS}}. This
|
||||
list is for general RTEMS discussions, questions, design help, advice,
|
||||
etc.. Subscribe by sending an empty mail
|
||||
message to @code{@value{RTEMSUSERSSUBSCRIBE}}. This
|
||||
mailing list is archived at:
|
||||
|
||||
@example
|
||||
http://www.rtems.com/ml/rtems-users
|
||||
@end example
|
||||
|
||||
@section Are there any license restrictions?
|
||||
|
||||
RTEMS is licensed under a modified version of the GNU General Public License
|
||||
(GPL). The modification places no restrictions on the applications which
|
||||
use RTEMS but protects the interests of those who work on RTEMS.
|
||||
|
||||
The TCP/IP network stack included with RTEMS is a port of the FreeBSD
|
||||
network stack and is licensed under different terms that also do not
|
||||
place restrictions on the application.
|
||||
|
||||
@section Are there any export restrictions?
|
||||
|
||||
No.
|
||||
|
||||
|
||||
@@ -1,35 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter BSP Questions
|
||||
|
||||
The items in this category provide answers to questions
|
||||
commonly asked about BSPs.
|
||||
|
||||
@section What is a BSP?
|
||||
|
||||
BSP is an acronym for Board Support Package.
|
||||
|
||||
A BSP is a collection of device drivers, startup code, linker scripts,
|
||||
and compiler support files (specs files) that tailor RTEMS for a
|
||||
particular target hardware environment.
|
||||
|
||||
@section What has to be in a BSP?
|
||||
|
||||
The basic set of items is the linker script, bsp_specs, and startup code.
|
||||
If you want standard IO, then you need a console driver. This is needed
|
||||
to run any of the RTEMS tests. If you want to measure passage of time,
|
||||
you need a clock tick driver. This driver is needed for all RTEMS tests
|
||||
EXCEPT hello world and the timing tests. The timer driver is a benchmark
|
||||
timer and is needed for the tmtests (timing tests). Sometimes you will
|
||||
see a shmsupp directory which is for shared memory multiprocessing
|
||||
systems. The network driver and real-time clock drivers are optional
|
||||
and not required by any RTEMS tests.
|
||||
|
||||
|
||||
|
||||
@@ -1,419 +0,0 @@
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Building RTEMS
|
||||
|
||||
Building any package in a cross-compilation fashion can be difficult,
|
||||
but configuring and building a real-time operating system that
|
||||
supports many CPU families and target boards can be confusing. The
|
||||
RTEMS development team has made every effort to make this process as
|
||||
straight forward as possible but there are going to be questions.
|
||||
|
||||
Moreover, between RTEMS 4.0 and 4.5, the configure and Makefile system in RTEMS
|
||||
was changed to be more compatible with GNU standards. This transition
|
||||
has lead to a number of subtle differences.
|
||||
|
||||
This section of the FAQ tries to address the more frequently asked
|
||||
questions about building RTEMS. Thanks to Ralf Corsepius for
|
||||
compiling this section from excerpts from various postings to the
|
||||
rtems-users mailing list.
|
||||
|
||||
@section Required Tools
|
||||
|
||||
@subsection Which tools are required to build RTEMS?
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item A native C-Toolchain, gcc prefered
|
||||
@item GNU-Bash and shell utils
|
||||
@item GNU-make.
|
||||
@item A target (typically cross) C- and (optional) C++-Toolchain.
|
||||
@item autoconf/automake (optional, recommended)
|
||||
@item Perl (optional, recommended, needed by automake and some tools within RTEMS)
|
||||
@item GNU-m4
|
||||
|
||||
@end itemize
|
||||
|
||||
@subsection Do I need autoconf and automake to build RTEMS?
|
||||
|
||||
No, you don't. Or to be more accurate, you won't need them until you
|
||||
modify something in RTEMS's Makefile.ams/configure.acs or start to develop
|
||||
with RTEMS.
|
||||
|
||||
I.e. you won't need them to get started, but you will need them when getting
|
||||
serious.
|
||||
|
||||
@subsection Do I need a native gcc on my host?
|
||||
|
||||
No, you should be able to use any native, ansi-compliant C-compiler, but
|
||||
using a native gcc is highly recommended.
|
||||
|
||||
@subsection Can I use a non-gcc cross-toolchain?
|
||||
|
||||
Generally speaking, it should be possible.
|
||||
However, most RTEMS development has taken place using gcc, therefore
|
||||
getting it working may not be easy.
|
||||
|
||||
@subsection Do I need gcc-2.9x for cross compilation?
|
||||
|
||||
[FIXME: Partially obsolete]
|
||||
|
||||
Not necessarily, but gcc-2.9x is highly recommended, because most development
|
||||
has taken place using gcc-2.9x and previous versions of gcc are not actively
|
||||
supported in RTEMS anymore (@ref{Can I use a non-gcc cross-toolchain?}).
|
||||
|
||||
@subsection Where to get autoconf automake ld gcc etc.?
|
||||
|
||||
The sources of all gnutools are available at any
|
||||
@uref{ftp://ftp.gnu.org,GNU} mirror.
|
||||
Native Linux binaries should come with any Linux distribution.
|
||||
Native Cygwin binaries should be available at @uref{http://www.cygwin.com}.
|
||||
|
||||
GNU-Toolchain binaries (gcc, binutils etc.) for Linux and patches required
|
||||
to build them from source are available from
|
||||
@uref{@value{RTEMSFTPURL},the RTEMS ftp site}.
|
||||
|
||||
|
||||
@section Issues when building RTEMS
|
||||
|
||||
@subsection When running ./configure weird thing start to happen
|
||||
|
||||
You are probably trying to build within the source-tree.
|
||||
RTEMS requires a separate build directory. I.e. if the
|
||||
sources are located at @code{/usr/local/src/rtems-@value{VERSION}},
|
||||
use something similar to this to configure RTEMS:
|
||||
|
||||
@example
|
||||
cd somewhere
|
||||
mkdir build
|
||||
cd build
|
||||
/usr/local/src/rtems-@value{VERSION}/configure [options]
|
||||
@end example
|
||||
|
||||
@subsection When running bootstrap weird thing start to happen
|
||||
|
||||
Many possibile causes: Most likely one of these:
|
||||
@itemize @bullet
|
||||
@item You are trying to build RTEMS with insufficient or incompatible
|
||||
versions of autoconf and automake.
|
||||
@item The autotools can't be found because your $PATH might not be set up
|
||||
correctly (Cf. @ref{How to set up $PATH?})
|
||||
@item You have used configure-script options which interfer with RTEMS
|
||||
configuration (Cf. @ref{configure --program-[prefix|suffix|transform-name]})
|
||||
@item You have tripped over a bug in RTEMS ;)
|
||||
@end itemize
|
||||
|
||||
@subsection configure xxx cannot create executables
|
||||
|
||||
While running a configure script, you see a message like this:
|
||||
@example
|
||||
checking for m68k-rtems-gcc... (cached) m68k-rtems-gcc
|
||||
checking for C compiler default output... configure: error: C compiler
|
||||
cannot create executables
|
||||
configure: error: /bin/sh '../../../../rtems-ss-@value{VERSION}/c/make/configure'
|
||||
failed for c/make
|
||||
@end example
|
||||
This kind of error message typically indicates a broken toolchain, broken
|
||||
toolchain installation or broken user environment.
|
||||
|
||||
Examinating the @code{config.log} corresponding to the the failing
|
||||
configure script should provide further information of what
|
||||
actually goes wrong (In the example above: @code{<target>/c/<BSP>/make/config.log})
|
||||
|
||||
@subsection Why can I not build RTEMS inside of the source tree?
|
||||
|
||||
The build-directory hierarchy is setup dynamically at configuration time.
|
||||
|
||||
Configuring inside of the source tree would prevent being able to configure
|
||||
for multiple targets simultaneously.
|
||||
|
||||
Using a separate build-tree simplifies Makefiles and configure scripts
|
||||
significantly.
|
||||
|
||||
Adaptation to GNU/Cygnus conventions.
|
||||
|
||||
@subsection Which environment variables to set?
|
||||
|
||||
None. Unlike for previous releases, it is not recommended anymore to set any
|
||||
RTEMS related environment variable (Exception: $PATH, cf.
|
||||
@ref{How to set up $PATH?}).
|
||||
|
||||
|
||||
@subsection Compiler /Assembler /Linker report errors
|
||||
|
||||
If you see a bunch of the error messages related to invalid instructions
|
||||
or similar, then probably your @code{$PATH} environment variable is not
|
||||
set up correctly (cf. @ref{How to set up $PATH?}). Otherwise you might
|
||||
have found a bug either in RTEMS or parts of the toolchain.
|
||||
|
||||
@subsection How to set up $PATH?
|
||||
|
||||
All target tools are supposed to be prefixed with a target-canonicalization
|
||||
prefix, eg. i386-rtems-gcc, m68k-rtems-ld are target tools.
|
||||
|
||||
Host tools are supposed not to be prefixed.
|
||||
e.g.: cc, ld, gcc, autoconf, automake, aclocal etc.
|
||||
|
||||
If using the pre-built tool binaries provided by the RTEMS project,
|
||||
simply prepend @code{@value{RTEMSPREFIX}}/bin to @code{$PATH}.
|
||||
|
||||
@subsection Can I build RTEMS Canadian Cross?
|
||||
|
||||
RTEMS >= 4.6.0 configuration is prepared for building RTEMS Canadian Cross,
|
||||
however building RTEMS Canadian Cross is known to be in its infancy, so
|
||||
your mileage may vary (See @code{README.cdn-X} in the toplevel directory of
|
||||
RTEMS's source tree for details.)
|
||||
|
||||
@subsection Building RTEMS is slow
|
||||
|
||||
RTEMS has become fairly large :).
|
||||
|
||||
In comparison to building previous versions, building RTEMS is slow,
|
||||
but that's the tradeoff to pay for simplier and safer configuration.
|
||||
|
||||
If using Cygwin, remember that Cygwin is emulating one OS ontop of another
|
||||
-- this necessarily must be significantly slower than using U*nix on the
|
||||
same hardware.
|
||||
|
||||
@subsection Building my pre-4.5.x BSPs does not work anymore
|
||||
|
||||
See @ref{How to merge pre-RTEMS-4.5.0 BSPs into RTEMS-4.5.0?}.
|
||||
|
||||
@subsection make debug_install / make profile_install
|
||||
|
||||
[FIXME:Partially obsolete]
|
||||
|
||||
These make targets are not supported anymore. Instead, use:
|
||||
|
||||
@example
|
||||
make VARIANT=DEBUG install
|
||||
make VARIANT=PROFILE install
|
||||
@end example
|
||||
|
||||
@subsection make debug / make profile
|
||||
|
||||
[FIXME:Partially obsolete]
|
||||
|
||||
These make targets are not supported anymore.
|
||||
Instead, use:
|
||||
|
||||
@example
|
||||
make VARIANT=DEBUG all
|
||||
make VARIANT=PROFILE all
|
||||
@end example
|
||||
|
||||
|
||||
@subsection Building RTEMS does not honor XXX_FOR_TARGET
|
||||
|
||||
RTEMS < 4.6.0 did not support passing flags from the environment.
|
||||
If using RTEMS < 4.6.0, editing your BSP's @code{make/custom/mybsp.cfg} and
|
||||
setting appropriate flags there is required.
|
||||
|
||||
RTEMS >= 4.6.0 honors several XXX_FOR_TARGET environment variables.
|
||||
Run @code{<path-to-rtems>/configure --help} for a full list of supported variables.
|
||||
|
||||
@subsection Editing Makefile.in Makefile configure
|
||||
|
||||
These files are generated by auto* tools, cf.
|
||||
@ref{Editing auto* generated files}).
|
||||
|
||||
@subsection Editing auto* generated files
|
||||
|
||||
RTEMS uses automake, therefore @b{never}, @b{ever}, @b{ever}
|
||||
edit Makefile.ins, Makefiles, configure or other auto* generated files.
|
||||
Changes to them will be swapped away soon and will get lost.
|
||||
|
||||
Instead edit the sources (eg.: Makefile.ams, configure.acs) auto* generated
|
||||
files are generated from directly.
|
||||
|
||||
If sending patches always send Makefile.ams and configure.acs.
|
||||
Sending Makefile.ins, Makefiles and configure scripts is pretty much useless.
|
||||
If sending larger patches, consider removing all auto* generated files
|
||||
by running @code{bootstrap -c} (cf. See @ref{./bootstrap})
|
||||
before running diff to cut a patch.
|
||||
|
||||
If you don't understand what this is all about, try start getting familiar
|
||||
with auto* tools by reading autoconf.info and automake.info, or feel free
|
||||
to ask for assistance on the RTEMS Mailing List
|
||||
(See @ref{Are there any mailing lists?}.
|
||||
|
||||
@section Host Operating Systems and RTEMS
|
||||
|
||||
@subsection Can I use Windows or DOS?
|
||||
|
||||
|
||||
No, plain DOS and plain Win will not work, but Cygwin should.
|
||||
Other U*nix emulations, such as Mingw and DJGPP are not supported and very
|
||||
likely will not work.
|
||||
Cywin / WinNT is known to work, but at the time of writing this, there
|
||||
seem to persist non-RTEMS related issues with Cygwin under Win9x which
|
||||
seem to prevent success on those systems.
|
||||
|
||||
@subsection Do I need Linux?
|
||||
|
||||
|
||||
No, you should be able to build RTEMS on any U*ix OS and under Cygwin/NT
|
||||
(cf. @ref{Can I use Windows or DOS?}).
|
||||
|
||||
@subsection Which Linux distribution is recommended?
|
||||
|
||||
None, any recent U*nix should work, i.e.
|
||||
any recent Linux distribution should work, too.
|
||||
|
||||
@section Development related questions
|
||||
|
||||
@subsection How to merge pre-RTEMS-4.5.0 BSPs into RTEMS-4.5.0?
|
||||
|
||||
[FIXME:Partially obsolete]
|
||||
|
||||
The simple answer is that between 4.0 and 4.5.0, RTEMS has moved to automake
|
||||
and greater compliance with GNU conventions.
|
||||
In 4.0, there was a single configure script at the top of the tree.
|
||||
Now RTEMS is configured more like other GNU tools -- as a collection of
|
||||
configurable entities.
|
||||
|
||||
Each BSP now has its own configure script.
|
||||
I highly recommend you look at the Makefile.am's, configure.ac, of a similar
|
||||
BSP. You might even want to consider running "bootstrap -c" from the top of
|
||||
the tree and looking at what is left. bootstrap (cf. @ref{./bootstrap})
|
||||
generates/removes all automatically generated files.
|
||||
|
||||
@subsection What is no_bsp / no_cpu?
|
||||
|
||||
@code{no_bsp} is a fictional BSP for a fictional CPU of type
|
||||
@code{no_cpu}. @code{no_cpu/no_bsp} support files in RTEMS can be used as
|
||||
templates when implementing BSPs or porting RTEMS to new CPUs.
|
||||
|
||||
@subsection What is the bare-BSP?
|
||||
|
||||
At the time being RTEMS is build per BSP, with all support files being build
|
||||
separately for each BSP. This can become unhandy when using several similar
|
||||
but not identical boards (e.g. a PC with different peripherial cards plugged
|
||||
in), because this in general requires to implement a BSP for each setup.
|
||||
The bare BSP is a general, setup independent BSP which can be used when
|
||||
keeping all BSP specific parts external from RTEMS.
|
||||
|
||||
At present time the bare BSP is in its infancy.
|
||||
It is known that it can be build for most CPUs RTEMS supports.
|
||||
It is also known to work in individual cases, but your mileage may vary.
|
||||
|
||||
@subsection What is the cpukit?
|
||||
|
||||
[FIXME:To be extended]
|
||||
|
||||
One major change having been introduced to RTEMS-4.6.0 is the cpukit,
|
||||
located below the directory @code{cpukit/} in RTEMS's toplevel directory.
|
||||
|
||||
@subsection Multilib vs. RTEMS CPU-variants
|
||||
|
||||
The GNU toolchain applies a specific classification of similar CPUs into
|
||||
CPU variants (eg. SH1, SH2 etc.) to provide better support for each CPU variant.
|
||||
|
||||
RTEMS uses a different classification because it internally requires more
|
||||
details about a specific CPU than the GNU toolchain's multilib classification
|
||||
provides.
|
||||
|
||||
@subsection Keeping auto* generated files in CVS
|
||||
|
||||
When using CVS to archive source code, problems arise from keeping generated
|
||||
files in CVS. In general, two possible solutions exist:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item Find a way to get correct timestamps after checking out the sources
|
||||
from CVS. Some people try to achieve this by
|
||||
|
||||
@itemize @bullet
|
||||
@item carefully checking in files into CVS in appropriate order
|
||||
@item applying scripts to fix timestamps accordingling (eg. by applying
|
||||
@code{touch} and @code{find}).
|
||||
@end itemize
|
||||
|
||||
@item Not keeping generated files in CVS, but regenerate them after
|
||||
having checked them out from CVS.
|
||||
|
||||
@end itemize
|
||||
|
||||
RTEMS favors the the latter variant, because it appears to be less error-prone
|
||||
and easier to handle (cf. @ref{./bootstrap} for details).
|
||||
|
||||
@subsection Importing RTEMS into CVS/RCS
|
||||
|
||||
When importing RTEMS into CVS/RCS or similar, we recommend not to import
|
||||
auto* generated files (cf. @ref{Keeping auto* generated files in CVS}).
|
||||
|
||||
To remove them before importing, run
|
||||
|
||||
@example
|
||||
./bootstrap -c
|
||||
@end example
|
||||
|
||||
from the toplevel directory of the source tree (cf. @ref{./bootstrap}).
|
||||
|
||||
@subsection ./bootstrap
|
||||
|
||||
|
||||
@code{bootstrap} is a simple shell script which automatically generates all
|
||||
auto* generated files within RTEMS's source tree (Other packages use the name
|
||||
@code{autogen.sh} for similar scripts). You will need to have autoconf,
|
||||
automake and further underlying packages installed to apply it.
|
||||
|
||||
It typically should be applied when having:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item checked out RTEMS sources from a CVS repository which does
|
||||
not contain generated files.
|
||||
|
||||
@item added new automake / autoconf files to the source tree (eg.
|
||||
having added a new BSP), and when not being sure about what needs to be
|
||||
updated.
|
||||
|
||||
@end itemize
|
||||
|
||||
Once all autoconf/automake generated files are present, you will rarely
|
||||
need to run @code{bootstrap}, because automake automatically updates
|
||||
generated files when it detects some files need to be updated (Cf.
|
||||
@ref{configure --enable-maintainer-mode}).
|
||||
|
||||
@subsection configure --enable-maintainer-mode
|
||||
|
||||
When working within the source-tree, consider to append
|
||||
@code{--enable-maintainer-mode} to the options passed to configure RTEMS.
|
||||
|
||||
@example
|
||||
<path>/rtems-@value{VERSION}/configure <options> --enable-maintainer-mode
|
||||
@end example
|
||||
|
||||
This will enable the maintainer-mode in automake generated Makefiles, which
|
||||
will let automake take care about dependencies between auto* generated
|
||||
files. I.e. auto* generated files will get automatically updated.
|
||||
|
||||
Configuring RTEMS in maintainer-mode will require to have autoconf, automake
|
||||
and underlying tools installed (Cf. @ref{Required Tools}).
|
||||
|
||||
@subsection configure --program-[prefix|suffix|transform-name]
|
||||
|
||||
These are generic configure script options automatically added by autoconf.
|
||||
RTEMS configuration does not support these, worse, they interfer with
|
||||
RTEMS's configuration -- i.e. @b{do not use them}.
|
||||
|
||||
@subsection configure.ac vs. configure.in
|
||||
|
||||
autoconf < 2.50 used the name @code{configure.in} for it's input files.
|
||||
autoconf >= 2.50 recommends using the name @code{configure.ac}, instead.
|
||||
|
||||
RTEMS > 4.5.0 applies autoconf >= 2.50, therefore all former RTEMS's
|
||||
@code{configure.in}'s have been renamed into @code{configure.ac} and
|
||||
have been adapted to autoconf >= 2.50 demands.
|
||||
|
||||
@subsection Reporting bugs
|
||||
|
||||
Several possibilities (In decreasing preference):
|
||||
@itemize @bullet
|
||||
@item File a bug report at @uref{@value{RTEMSGNATS},RTEMS's GNATS}
|
||||
@item Send an email to @uref{mailto:@value{RTEMSBUGS},@value{RTEMSBUGS}}
|
||||
@item Report your problem to one of the RTEMS mailing lists
|
||||
(Cf. @ref{Are there any mailing lists?}).
|
||||
@end itemize
|
||||
@@ -1,19 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter RTEMS Concepts
|
||||
|
||||
The questions in this category are hints that help basic understanding.
|
||||
|
||||
@section RTEMS Workspace versus Program Heap
|
||||
|
||||
The RTEMS Workspace is used to allocate space for objects created
|
||||
by RTEMS such as tasks, semaphores, message queues, etc.. It is
|
||||
primarily used during system initialization although task stacks
|
||||
and message buffer areas are also allocated from here.
|
||||
@ref{How do I determine how much memory is left?}.
|
||||
-158
@@ -1,158 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Debugging Hints
|
||||
|
||||
The questions in this category are hints that can ease debugging.
|
||||
|
||||
@section Executable Size
|
||||
|
||||
@subsection Why is my executable so big?
|
||||
|
||||
There are two primary causes for this. The most common is that
|
||||
you are doing an @code{ls -l} and looking at the actual file
|
||||
size -- not the size of the code in the target image. This
|
||||
file could be in an object format such as ELF or COFF and
|
||||
contain debug information. If this is the case, it could
|
||||
be an order of magnitude larger than the required code space.
|
||||
Use the strip command in your cross toolset to remove debugging
|
||||
information.
|
||||
|
||||
The following example was done using the i386-rtems cross toolset
|
||||
and the pc386 BSP. Notice that with symbolic information included
|
||||
the file @code{hello.exe} is almost a megabyte and would barely fit
|
||||
on a boot floppy. But there is actually only about 93K of code
|
||||
and initialized data. The other 800K is symbolic information
|
||||
which is not required to execute the application.
|
||||
|
||||
@example
|
||||
$ ls -l hello.exe
|
||||
-rwxrwxr-x 1 joel users 930515 May 2 09:50 hello.exe
|
||||
$ i386-rtems-size hello.exe
|
||||
text data bss dec hex filename
|
||||
88605 3591 11980 104176 196f0 hello.exe
|
||||
$ i386-rtems-strip hello.exe
|
||||
$ ls -l hello.exe
|
||||
-rwxrwxr-x 1 joel users 106732 May 2 10:02 hello.exe
|
||||
$ i386-rtems-size hello.exe
|
||||
text data bss dec hex filename
|
||||
88605 3591 11980 104176 196f0 hello.exe
|
||||
@end example
|
||||
|
||||
Another alternative is that the executable file is in an ASCII
|
||||
format such as Motorola Srecords. In this case, there is
|
||||
no debug information in the file but each byte in the target
|
||||
image requires two bytes to represent. On top of that, there
|
||||
is some overhead required to specify the addresses where the image
|
||||
is to be placed in target memory as well as checksum information.
|
||||
In this case, it is not uncommon to see executable files
|
||||
that are between two and three times larger than the actual
|
||||
space required in target memory.
|
||||
|
||||
Remember, the debugging information is required to do symbolic
|
||||
debugging with gdb. Normally gdb obtains its symbolic information
|
||||
from the same file that it gets the executable image from. However,
|
||||
gdb does not require that the executable image and symbolic
|
||||
information be obtained from the same file. So you might
|
||||
want to create a @code{hello_with_symbols.exe}, copy that
|
||||
file to @code{hello_without_symbols.exe}, and strip
|
||||
@code{hello_without_symbols.exe}. Then gdb would have to
|
||||
be told to read symbol information from @code{hello_with_symbols.exe}.
|
||||
The gdb command line option @code{-symbols} or command
|
||||
@code{symbol-file} may be used to specify the file read
|
||||
for symbolic information.
|
||||
|
||||
|
||||
@section Malloc
|
||||
|
||||
@subsection Is malloc reentrant?
|
||||
|
||||
Yes. The RTEMS Malloc implementation is reentrant. It is
|
||||
implemented as calls to the Region Manager in the Classic API.
|
||||
|
||||
@subsection When is malloc initialized?
|
||||
|
||||
During BSP initialization, the @code{bsp_libc_init} routine
|
||||
is called. This routine initializes the heap as well as
|
||||
the RTEMS system call layer (open, read, write, etc.) and
|
||||
the RTEMS reentrancy support for the Cygnus newlib Standard C
|
||||
Library.
|
||||
|
||||
The @code{bsp_libc_init} routine is passed the size and starting
|
||||
address of the memory area to be used for the program heap as well
|
||||
as the amount of memory to ask @code{sbrk} for when the heap is
|
||||
exhausted. For most BSPs, all memory available is placed in the
|
||||
program heap thus it can not be extended dynamically by calls to
|
||||
@code{sbrk}.
|
||||
|
||||
@section How do I determine how much memory is left?
|
||||
|
||||
First there are two types of memory: RTEMS Workspace and Program Heap.
|
||||
The RTEMS Workspace is the memory used by RTEMS to allocate control
|
||||
structures for system objects like tasks and semaphores, task
|
||||
stacks, and some system data structures like the ready chains.
|
||||
The Program Heap is where "malloc'ed" memory comes from.
|
||||
|
||||
Both are essentially managed as heaps based on the Heap Manager
|
||||
in the RTEMS SuperCore. The RTEMS Workspace uses the Heap Manager
|
||||
directly while the Program Heap is actually based on an RTEMS Region
|
||||
from the Classic API. RTEMS Regions are in turn based on the Heap
|
||||
Manager in the SuperCore.
|
||||
|
||||
@subsection How much memory is left in the RTEMS Workspace?
|
||||
|
||||
An executive workspace overage can be fairly easily spotted with a
|
||||
debugger. Look at _Workspace_Area. If first == last, then there is only
|
||||
one free block of memory in the workspace (very likely if no task
|
||||
deletions). Then do this:
|
||||
|
||||
(gdb) p *(Heap_Block *)_Workspace_Area->first
|
||||
$3 = @{back_flag = 1, front_flag = 68552, next = 0x1e260, previous = 0x1e25c@}
|
||||
|
||||
In this case, I had 68552 bytes left in the workspace.
|
||||
|
||||
@subsection How much memory is left in the Heap?
|
||||
|
||||
The C heap is a region so this should work:
|
||||
|
||||
(gdb) p *((Region_Control *)_Region_Information->local_table[1])->Memory->first
|
||||
$9 = @{back_flag = 1, front_flag = 8058280, next = 0x7ea5b4,
|
||||
previous = 0x7ea5b0@}
|
||||
|
||||
In this case, the first block on the C Heap has 8,058,280 bytes left.
|
||||
|
||||
@section How do I convert an executable to IEEE-695?
|
||||
|
||||
This section is based on an email from Andrew Bythell
|
||||
<abythell@@nortelnetworks.com> in July 1999.
|
||||
|
||||
Using Objcopy to convert m68k-coff to IEEE did not work. The new IEEE
|
||||
object could not be read by tools like the XRay BDM Debugger.
|
||||
|
||||
The exact nature of this problem is beyond me, but I did narrow it down to a
|
||||
problem with objcopy in binutils 2-9.1. To no surprise, others have
|
||||
discovered this problem as well, as it has been fixed in later releases.
|
||||
|
||||
I compiled a snapshot of the development sources from 07/26/99 and
|
||||
everything now works as it should. The development sources are at
|
||||
@uref{http://sourceware.cygnus.com/binutils} (thanks Ian!)
|
||||
|
||||
Additional notes on converting an m68k-coff object for use with XRay (and
|
||||
others):
|
||||
|
||||
@enumerate
|
||||
|
||||
|
||||
@item The m68k-coff object must be built with the -gstabs+ flag. The -g flag
|
||||
alone didn't work for me.
|
||||
|
||||
@item Run Objcopy with the --debugging flag to copy debugging information.
|
||||
|
||||
@end enumerate
|
||||
|
||||
|
||||
@@ -1,111 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Date/Time Issues in Systems Using RTEMS
|
||||
|
||||
This section provides technical information regarding
|
||||
date/time representation issues and RTEMS. The Y2K problem has
|
||||
lead numerous people to ask these questions. The answer to
|
||||
these questions are actually more complicated than most
|
||||
people asking the question expect. RTEMS supports multiple
|
||||
standards and each of these standards has its own epoch and
|
||||
time representation. These standards include both programming
|
||||
API and programming language standards.
|
||||
|
||||
In addition to the issues inside RTEMS
|
||||
itself, there is the complicating factor that the Board
|
||||
Support Package or application itself may interface with hardware
|
||||
or software that has its own set of date/time representation
|
||||
issues.
|
||||
|
||||
In conclusion, viewing date/time representation as "the Y2K problem"
|
||||
is very short-sighted. Date/time representation should be viewed as
|
||||
a systems level issue for the system you are building. Each software
|
||||
and hardware component in the system as well as the systems being
|
||||
connected to is a factor in the equation.
|
||||
|
||||
@section Hardware Issues
|
||||
|
||||
Numerous Real-Time Clock (RTC) controllers provide only a two-digit
|
||||
Binary Coded Decimal (BCD) representation for the current year. Without
|
||||
software correction, these chips are a classic example of the Y2K problem.
|
||||
When the RTC rolls the year register over from 99 to 00, the device
|
||||
has no idea whether the year is 1900 or 2000. It is the responsibility
|
||||
of the device driver to recognize this condition and correct for it.
|
||||
The most common technique used is to assume that all years prior
|
||||
to either the existence of the board or RTEMS are past 2000. The
|
||||
starting year (epoch) for RTEMS is 1988. Thus,
|
||||
|
||||
@itemize @bullet
|
||||
@item Chip year values 88-99 are interpreted as years 1988-2002.
|
||||
@item Chip year values 00-87 are interpreted as years 2000-2087.
|
||||
@end itemize
|
||||
|
||||
Using this technique, a RTC using a
|
||||
two-digit BCD representation of the current year will overflow on
|
||||
January 1, 2088.
|
||||
|
||||
@section RTEMS Specific Issues
|
||||
|
||||
Internally, RTEMS uses an unsigned thirty-two bit integer to represent the
|
||||
number of seconds since midnight January 1, 1988. This counter will
|
||||
overflow on February 5, 2124.
|
||||
|
||||
The time/date services in the Classic API will overflow when the
|
||||
RTEMS internal date/time representation overflows.
|
||||
|
||||
The POSIX API uses the type @i{time_t} to represent the number of
|
||||
seconds since January 1, 1970. Many traditional UNIX systems as
|
||||
well as RTEMS define @i{time_t} as a signed thirty-two bit integer.
|
||||
This representation overflows on January 18, 2038. The solution
|
||||
usually proposed is to define @i{time_t} as a sixty-four bit
|
||||
integer. This solution is appropriate for for UNIX workstations
|
||||
as many of them already support sixty-four bit integers natively.
|
||||
At this time, this imposes a burden on embedded systems which are
|
||||
still primarily using processors with native integers of thirty-two
|
||||
bits or less.
|
||||
|
||||
@section Language Specific Issues
|
||||
|
||||
The Ada95 Language Reference Manual requires that the @i{Ada.Calendar}
|
||||
package support years through the year 2099. However, just as the
|
||||
hardware is layered on top of hardware and may inherit its limits,
|
||||
the Ada tasking and run-time support is layered on top of an operating
|
||||
system. Thus, if the operating system or underlying hardware fail
|
||||
to correctly report dates after 2099, then it is possible for the
|
||||
@i{Ada.Calendar} package to fail prior to 2099.
|
||||
|
||||
@section Date/Time Conclusion
|
||||
|
||||
Each embedded system could be impacted by a variety of date/time
|
||||
representation issues. Even whether a particular date/time
|
||||
representation issue impacts a system is questionable. A system
|
||||
using only the RTEMS Classic API is not impacted by the
|
||||
date/time representation issues in POSIX. A system not using
|
||||
date/time at all is not impacted by any of these issues. Also
|
||||
the planned end of life for a system may make these issues
|
||||
moot.
|
||||
|
||||
The following is a timeline of the date/time representation
|
||||
issues presented in this section:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item 2000 - Two BCD Digit Real-Time Clock Rollover
|
||||
|
||||
@item 2038 - POSIX @i{time_t} Rollover
|
||||
|
||||
@item 2088 - Correction for Two BCD Digit Real-Time Clock Rollover
|
||||
|
||||
@item 2099 - Ada95 @i{Ada.Calendar} Rollover
|
||||
|
||||
@item 2124 - RTEMS Internal Seconds Counter Rollover
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
@@ -1,60 +0,0 @@
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
This is the RTEMS entry in the Crossgcc FAQ at @uref{http://www.objsw.com}.
|
||||
As of 8/19/99, it has been submitted twice and the FAQ not updated.
|
||||
|
||||
RTEMS is a freely available, royalty free real-time executive with
|
||||
multiprocessor capabilities. RTEMS' design provides performance and
|
||||
capabilities are comparable to those of the best commercial executives.
|
||||
The directive execution times and other critical performance measures such
|
||||
as interrupt latency are best of class. RTEMS was developed by On-Line
|
||||
Applications Research Corporation (OAR) under contract to the U.S. Army
|
||||
Missile Command.
|
||||
|
||||
|
||||
RTEMS includes support for multiple APIs. Currently RTEMS supports a
|
||||
POSIX threads API, and an RTEID based API which is similar to pSOS+.
|
||||
RTEMS includes a number of advanced real-time features including optional
|
||||
rate monotonic scheduling support, binary semapahores with priority
|
||||
inheritance, and watchdog timer functions.
|
||||
|
||||
RTEMS includes a port of the FreeBSD TCP/IP stack that has high
|
||||
performance on very modest hardware. A remote debug server is supported
|
||||
on some targets that allows debugging across the network.
|
||||
|
||||
RTEMS provides a rich run-time environment with a reentrant C library,
|
||||
POSIX 1003.1b support, and file system support. It also includes optional
|
||||
debug aids like stack overflow and heap integrity checking.
|
||||
|
||||
RTEMS is built using GNU autoconf and can be built on any host supporting
|
||||
the GNU tools including GNU/Linux, FreeBSD, NetBSD, Solaris, and MS-Windows
|
||||
to name but a few. The current RTEMS release supports the following CPU
|
||||
families:
|
||||
|
||||
Motorola m680x0, m683xx, and ColdFire
|
||||
Motorola and IBM PowerPC (4xx, 5xx, 6xx, 7xx, 8xx, and 84xx)
|
||||
Hitachi SH-1, SH-2, SH-4
|
||||
Hitachi H8
|
||||
ARM
|
||||
Intel i386, i486, and Pentium
|
||||
SPARC
|
||||
MIPS
|
||||
Texas Instruments C3x/C4x
|
||||
OpenCores OR32
|
||||
|
||||
There are over 35 Board Support Packages included with RTEMS including
|
||||
BSPs for a standard PC as well as the SPARC, MIPS, PowerPC simulators
|
||||
included with gdb. There are numerous BSPs for CPUs targetting the
|
||||
embedded market such as the Motorola m683xx, ppc4xx, and mpc8xx series
|
||||
which support the on-CPU peripherals.
|
||||
|
||||
WWW:
|
||||
|
||||
@uref{http://www.rtems.com}
|
||||
|
||||
E-mail:
|
||||
|
||||
@code{rtems-info@@OARcorp.com}
|
||||
|
||||
@@ -1,169 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Free Software that Works with RTEMS
|
||||
|
||||
This section describes other free software packages that are known to work
|
||||
with RTEMS.
|
||||
|
||||
@section Development Tools
|
||||
|
||||
@subsection Basic Development Environment
|
||||
|
||||
The standard RTEMS development environment consists of the following GNU
|
||||
components:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item gcc
|
||||
@item binutils
|
||||
@item gdb
|
||||
|
||||
@end itemize
|
||||
|
||||
Although not from the Free Software Foundation, the Cygnus newlib C
|
||||
library integrates well with the GNU tools and is a standard part of the
|
||||
RTEMS development environment.
|
||||
|
||||
@subsection GNU Ada
|
||||
|
||||
For those interested in using the Ada95 programming language, the GNU Ada
|
||||
compiler (GNAT) is available and has excellent support for RTEMS.
|
||||
|
||||
@subsection DDD - Data Display Debugger
|
||||
|
||||
By far the easiest way to use DDD if you are on a Redhat or SuSE Linux system
|
||||
is to retrieve the RPM package for your OS version. In general, it is
|
||||
easier to install a static binary since doing so avoids all problems
|
||||
with dynamic library versions.
|
||||
|
||||
Some versions of DDD have had trouble with Lesstif. If you
|
||||
are using Lesstif, you will need version 0.88 or newer. It
|
||||
is also available as an RPM at the popular sites. Another Motif
|
||||
clone is Motive and versions 1.2 and newer known to work with DDD
|
||||
on popular distributions of Linux including RedHat and Slackware.
|
||||
|
||||
Installed as RPMs, DDD in conjunction with either Lesstif or Motive
|
||||
should work out-of-the-box.
|
||||
|
||||
User comments indicate that both Lesstif and DDD can be built
|
||||
from scratch without any problems. Instructions on installing DDD
|
||||
are at @uref{http://www.cs.tu-bs.de/softech/ddd/}. They
|
||||
indicate that
|
||||
|
||||
@itemize @bullet
|
||||
LessTif should be used in (default) Motif 1.2 compatibility mode.
|
||||
|
||||
The Motif 2.0 compatibility mode of LessTif is still incomplete.
|
||||
@end itemize
|
||||
|
||||
So configure lesstif with --enable-default-12.
|
||||
|
||||
The configure script is broken (see www.lesstif.org --> known problems)
|
||||
for 0.88.1. I didn't fix the script as they show, so I just have links
|
||||
in /usr/local/lib (also shown).
|
||||
|
||||
Watch out: Lesstif installs its libraries in /usr/local/Lesstif. You
|
||||
will need to update /etc/ld.so.conf and regenerate the cache of shared
|
||||
library paths to point to the Motif 1.2 library.
|
||||
|
||||
The following notes are from an RTEMS user who uses DDD in conjunction
|
||||
with Lesstif. Configure DDD "--with-motif-libraries=/usr/local/lib
|
||||
--with-motif-includes=/usr/local/include" DDD needs gnuplot 3.7.
|
||||
@uref{ftp://ftp.dartmouth.edu/pub/gnuplot/gnuplot-3.7.tar.gz}. Build and
|
||||
install from scratch.
|
||||
|
||||
DDD can be started from a script that specifies the cross debugger.
|
||||
This simplifies the invocation. The following example shows what
|
||||
a script doing this looks like.
|
||||
|
||||
@example
|
||||
#!/bin/bash
|
||||
ddd --debugger m68k-elf-gdb $1
|
||||
@end example
|
||||
|
||||
Under many flavors of UNIX, you will likely have to relax permissions.
|
||||
|
||||
On Linux, to get gdb to use the serial ports while running as a
|
||||
normal user, edit /etc/security/console.perms, and create a <serial>
|
||||
class (call it whatever you want).
|
||||
|
||||
@example
|
||||
<serial>=/dev/ttyS* /dev/cua*
|
||||
@end example
|
||||
|
||||
Now enable the change of ownership of these devices when users log in
|
||||
from the console:
|
||||
|
||||
@example
|
||||
<console> 0600 <serial> 0600 root
|
||||
@end example
|
||||
|
||||
Users report using minicom to communicate with the target to initiate a TFTP
|
||||
download. They then suspend minicom, launch DDD, and begin debugging.
|
||||
|
||||
The procedure should be the same on other platforms, modulo the choice
|
||||
of terminal emulator program and the scheme used to access the serial
|
||||
ports. From problem reports on the cygwin mailing list, it appears that
|
||||
GDB has some problems communicating over serial lines on that platform.
|
||||
|
||||
NOTE: GDB does not like getting lots of input from the program under test
|
||||
over the serial line. Actually, it does not care, but it looses
|
||||
characters. It would appear that flow control is not re-enabled when it
|
||||
resumes program execution. At times, it looked like the test were
|
||||
failing, but everything was OK. We modified the MVME167 serial driver to
|
||||
send test output to another serial port. Using two serial ports is
|
||||
usually the easiest way to get test output while retaining a reliable debug
|
||||
connection regardless of the debugger/target combination.
|
||||
|
||||
NOTE: Enabling gdb's remote cache might prevent this (Observed with SH1
|
||||
boards, but may also be valid for targets):
|
||||
@example
|
||||
gdb > set remotecache
|
||||
@end example
|
||||
|
||||
Information provided by Charles-Antoine Gauthier (charles.gauthier@@iit.nrc.ca)
|
||||
Jiri Gaisler (jgais@@ws.estec.esa.nl) and Ralf Cors@'epius
|
||||
(corsepiu@@faw.uni-ulm.de)
|
||||
|
||||
|
||||
@section omniORB
|
||||
|
||||
omniORB is a GPL'ed CORBA which has been ported to RTEMS. It is
|
||||
available from
|
||||
(@uref{http://www.uk.research.att.com/omniORB/omniORB.html,http://www.uk.research.att.com/omniORB/omniORB.html})
|
||||
.
|
||||
|
||||
For information on the RTEMS port of omniORB to RTEMS, see the following
|
||||
URL
|
||||
(@uref{http://www.connecttel.com/corba/rtems_omni.html,http://www.connecttel.com/corba/rtems_omni.html}).
|
||||
|
||||
C++ exceptions must work properly on your target for omniORB to work.
|
||||
|
||||
The port of omniORB to RTEMS was done by Rosimildo DaSilva
|
||||
<rdasilva@@connecttel.com>.
|
||||
|
||||
@section TCL
|
||||
|
||||
Tool Command Language.
|
||||
|
||||
ditto
|
||||
|
||||
@section ncurses
|
||||
|
||||
Free version of curses.
|
||||
|
||||
ditto
|
||||
|
||||
|
||||
@section zlib
|
||||
|
||||
Free compression/decompression library.
|
||||
|
||||
ditto
|
||||
|
||||
@@ -1,110 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Hardware to Ease Debugging
|
||||
|
||||
The items in this category provide information on various hardware
|
||||
debugging assistants that are available.
|
||||
|
||||
@section MC683xx BDM Support for GDB
|
||||
|
||||
Eric Norum (eric@@skatter.usask.ca) has a driver for a parallel
|
||||
port interface to a BDM module. This driver has a long history
|
||||
and is based on a driver by Gunter Magin (magin@@skil.camelot.de)
|
||||
which in turn was based on BD32 for DOS by Scott Howard. Eric Norum
|
||||
and Chris Johns (ccj@@acm.org) have put together a package containing
|
||||
everything you need to use this BDM driver including software, PCB layouts,
|
||||
and machining drawings. From the README:
|
||||
|
||||
"This package contains everything you need to be able to run GDB on
|
||||
Linux and control a Motorola CPU32+ (68360) or Coldfire (5206, 5206e, or
|
||||
5207) target through a standard PC parallel port."
|
||||
|
||||
Information on this BDM driver is available at the following URL:
|
||||
|
||||
@example
|
||||
http://www.calm.hw.ac.uk/davidf/coldfire/gdb-bdm-linux.htm
|
||||
@end example
|
||||
|
||||
The package is officially hosted at Eric Norum's ftp site:
|
||||
|
||||
@example
|
||||
ftp://skatter.usask.ca/pub/eric/BDM-Linux-gdb/
|
||||
@end example
|
||||
|
||||
Peter Shoebridge (peter@@zeecube.com) has ported the Linux
|
||||
parallel port BDM driver from Eric Norum to Windows NT. It is
|
||||
available at http://www.zeecube.com/bdm.
|
||||
|
||||
The efi332 project has a home-built BDM module and gdb backend for
|
||||
Linux. See http://efi332.eng.ohio-state.edu/efi332/hardware.html)
|
||||
for details. The device driver and gdb backend are based on those
|
||||
by Gunter Magin (magin@@skil.camelot.de) available from
|
||||
ftp.lpr.e-technik.tu-muenchen.de.
|
||||
|
||||
Pavel Pisa (pisa@@cmp.felk.cvut.cz) has one available at
|
||||
http://cmp.felk.cvut.cz/~pisa/m683xx/bdm_driver.html.
|
||||
|
||||
Huntsville Microsystems (HMI) has GDB support for their BDM module
|
||||
available upon request. It is also available from their ftp site:
|
||||
ftp://ftp.hmi.com/pub/gdb
|
||||
|
||||
The Macraigor OCD BDM module has a driver for Linux
|
||||
written by Gunter Magin (magin@@skil.camelot.de).
|
||||
No URLs yet.
|
||||
|
||||
Finally, there is a overview of BDM at the following URL:
|
||||
http://cmp.felk.cvut.cz/~pisa/m683xx/bdm_driver.html.
|
||||
|
||||
Information in this section from:
|
||||
|
||||
@itemize @bullet
|
||||
@item Brendan Simon <brendan@@dgs.monash.edu.au>
|
||||
@item W Gerald Hicks <wghicks@@bellsouth.net>
|
||||
@item Chris Johns <ccj@@acm.org>
|
||||
@item Eric Norum <eric@@skatter.usask.ca>
|
||||
@item Gunter Magin <magin@@skil.camelot.de>
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
@section MPC8xx BDM Support for GDB
|
||||
|
||||
@c "Adrian Bocaniciu" <a.bocaniciu@computer.org> has a driver
|
||||
@c for NT and is willing to share it but he needs to be emailed
|
||||
@c privately since he needs to explain somethings about it.
|
||||
@c It has been used for over a year as of 08/18/99.
|
||||
|
||||
Christian Haan <chn@@intego.de> has written a driver for FreeBSD
|
||||
based for"a slightly changed ICD BDM module (because of changes
|
||||
in the BDM interface on the PowerPC)" that "probably will work with
|
||||
the PD module too." His work is based on the M68K BDM work by
|
||||
Gunter Magin (Gunter.Magin@@skil.camelot.de) and
|
||||
the PPC BDM for Linux work by Sergey Drazhnikov (swd@@agua.comptek.ru).
|
||||
This is not yet publicly available.
|
||||
|
||||
Sergey Drazhnikov (swd@@agua.comptek.ru) has written a PPC BDM driver for
|
||||
Linux. Information is available at http://cyclone.parad.ru/ppcbdm.
|
||||
|
||||
Huntsville Microsystems (HMI) has GDB support for their BDM module
|
||||
available upon request. It is also available from their ftp site:
|
||||
ftp://ftp.hmi.com/pub/gdb
|
||||
|
||||
GDB includes support for a set of primitives to support the Macraigor
|
||||
Wiggler (OCD BDM). Unfortunately, this requires the use of a
|
||||
proprietary interface and is supported only on Windows. This forces
|
||||
one to use CYGWIN. Reports are that this results in a slow
|
||||
interface. Scott Howard (http://www.objsw.com) has announced
|
||||
that support for the gdb+wiggler combination under DJGPP which should
|
||||
run significantly faster.
|
||||
|
||||
@itemize @bullet
|
||||
@item Leon Pollak <leonp@@plris.com>
|
||||
@item Christian Haan <chn@@intego.de>
|
||||
@end itemize
|
||||
|
||||
@@ -1,113 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter RTEMS Projects
|
||||
|
||||
The questions in this category are regarding things that people
|
||||
are working on or that the RTEMS community would like to see work on.
|
||||
|
||||
There are multiple ways to support the RTEMS Project. Financial support
|
||||
is always welcomed. This can be via sponsorship of a specific project
|
||||
such as one of the ones listed here or via volunteering in some
|
||||
capacity.
|
||||
|
||||
@section Other Filesystems
|
||||
|
||||
This is a list of the filesystems that would be nice to have support
|
||||
for in RTEMS. For each filsystem, status and contact information is
|
||||
provided for those who have expressed interest in helping out or are actively
|
||||
working on it.
|
||||
|
||||
@itemize @bullet
|
||||
@item TFTP client - read only, no write capability
|
||||
@itemize @bullet
|
||||
@item No Contact
|
||||
@end itemize
|
||||
|
||||
@item DOS Filesystem - ???
|
||||
@itemize @bullet
|
||||
@item Peter Shoebridge <peter@@zeecube.com>
|
||||
@item Victor V. Vengerov <vvv@@tepkom.ru>
|
||||
@end itemize
|
||||
|
||||
@item CD-ROM Filesystem - ???
|
||||
@itemize @bullet
|
||||
@item Peter Shoebridge <peter@@zeecube.com>
|
||||
@end itemize
|
||||
|
||||
@item Flash Filesystem(s) - ???
|
||||
@itemize @bullet
|
||||
@item Rod Barman <rodb@@ieee.org>
|
||||
@item Victor V. Vengerov <vvv@@tepkom.ru>
|
||||
@end itemize
|
||||
|
||||
@item Remote Host Filesystem - ???
|
||||
@itemize @bullet
|
||||
@item Wayne Bullaughey <wayne@@wmi.com>
|
||||
@end itemize
|
||||
|
||||
@item NFS client - ???
|
||||
@itemize @bullet
|
||||
@item No Contact
|
||||
@end itemize
|
||||
|
||||
@end itemize
|
||||
|
||||
@section Java
|
||||
|
||||
@subsection Kaffe
|
||||
|
||||
This porting effort is underway and active.
|
||||
|
||||
@itemize @bullet
|
||||
@item Jiri Gaisler <jgais@@ws.estec.esa.nl>
|
||||
@item Oscar Martinez de la Torre <omt@@wm.estec.esa.nl>
|
||||
@end itemize
|
||||
|
||||
NOTE: An older version of Kaffe was ported to a pre-4.0 version of RTEMS.
|
||||
The network support in RTEMS was immature at that port and Kaffe had
|
||||
portability problems. Together these resulted in an unclean port which
|
||||
was never merged.
|
||||
|
||||
@subsection GNU Java Compiler (gjc)
|
||||
|
||||
This porting effort is underway and active.
|
||||
|
||||
@itemize @bullet
|
||||
@item Charles-Antoine Gauthier <charles.gauthier@@iit.nrc.ca>
|
||||
@end itemize
|
||||
|
||||
@section CORBA
|
||||
|
||||
@subsection TAO
|
||||
|
||||
This porting effort is pending testing. Erik ported the code but then
|
||||
discovered that his target board did not have enough memory to run
|
||||
any TAO tests.
|
||||
|
||||
@itemize @bullet
|
||||
@item Erik Ivanenko <erik.ivanenko@@utoronto.ca>
|
||||
@end itemize
|
||||
|
||||
@section APIs
|
||||
|
||||
@subsection POSIX 1003.1b
|
||||
|
||||
Support for POSIX 1003.1b is mature but there are a few remaining
|
||||
items including a handful of services, performance tests, and
|
||||
documentation. Please refer to the Status chapter of the
|
||||
@i{POSIX API User's Guide} for more details.
|
||||
|
||||
@subsection ITRON 3.0
|
||||
|
||||
Support for ITRON 3.0 is in its beginning stages. There are
|
||||
numerous managers left to implement, both functional and
|
||||
performance tests to write, and much documentation remaining.
|
||||
Please refer to the Status chapter of the @i{ITRON 3.0 API User's Guide}
|
||||
for specific details.
|
||||
|
||||
@@ -1,4 +0,0 @@
|
||||
@set UPDATED 5 March 2004
|
||||
@set UPDATED-MONTH March 2004
|
||||
@set EDITION 4.6.99.3
|
||||
@set VERSION 4.6.99.3
|
||||
@@ -1,71 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter General Development Tool Hints
|
||||
|
||||
The questions in this category are related to the GNU development tools
|
||||
in a non-language specific way.
|
||||
|
||||
@section What is GNU?
|
||||
|
||||
Take a look at @uref{http://www.gnu.org,http://www.gnu.org} for information on the GNU Project.
|
||||
|
||||
@section How do I generate a patch?
|
||||
|
||||
The RTEMS patches to the development tools are generated using a
|
||||
command like this
|
||||
|
||||
@example
|
||||
diff -N -P -r -c TOOL-original-image TOOL-with-changes >PATCHFILE
|
||||
@end example
|
||||
|
||||
where the options are:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item -N and -P take care of adding and removing files (be careful not to
|
||||
include junk files like file.mybackup)
|
||||
|
||||
@item -r tells diff to recurse through subdirectories
|
||||
|
||||
@item -c is a context diff (easy to read for humans)
|
||||
|
||||
@end itemize
|
||||
|
||||
Please look at the generated PATCHFILE and make sure it does not
|
||||
contain anything you did not intend to send to the maintainers.
|
||||
It is easy to accidentally leave a backup file in the modified
|
||||
source tree or have a spurious change that should not be
|
||||
in the PATCHFILE.
|
||||
|
||||
If you end up with the entire contents of a file in the patch
|
||||
and can't figure out why, you may have different CR/LF scheme
|
||||
in the two source files. The GNU open-source packages usually have
|
||||
UNIX style CR/LF. If you edit on a Windows platform, the line
|
||||
terminators may have been transformed by the editor into Windows
|
||||
style.
|
||||
|
||||
@section How do I apply a patch?
|
||||
|
||||
Patches generated with the @code{diff} program are fed into the
|
||||
@code{patch} program as follows:
|
||||
|
||||
@example
|
||||
patch -p1 <PATCHFILE
|
||||
@end example
|
||||
|
||||
where the options are:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item -pNUM tells @code{patch} to strip off NUM slashes from the
|
||||
pathname.
|
||||
|
||||
@end itemize
|
||||
|
||||
If @code{patch} prompts for a file to patch, you may need to adjust NUM.
|
||||
@@ -1,4 +0,0 @@
|
||||
@set UPDATED 5 March 2004
|
||||
@set UPDATED-MONTH March 2004
|
||||
@set EDITION 4.6.99.3
|
||||
@set VERSION 4.6.99.3
|
||||
+3
-4
@@ -7,7 +7,7 @@ ACLOCAL_AMFLAGS = -I ../aclocal
|
||||
# NOTE: The order of the directories is essential.
|
||||
# + tools, common and images are shared across many documents
|
||||
|
||||
SUBDIRS = tools FAQ started user bsp_howto porting develenv posix_users \
|
||||
SUBDIRS = tools started user bsp_howto porting develenv posix_users \
|
||||
posix1003.1 filesystem itron3.0 networking ada_user started_ada \
|
||||
rtems_gdb rgdb_specs new_chapters relnotes cpu_supplement gnu_docs
|
||||
|
||||
@@ -17,9 +17,8 @@ endif
|
||||
|
||||
EXTRA_DIST = HELP.html rtems_header.html.in rtems_footer.html.in
|
||||
|
||||
EXTRA_DIST += common/cpright.texi common/setup.texi common/timemac.texi \
|
||||
common/timetbl.t common/treedef.tex common/wksheets.t common/timing.t \
|
||||
common/rtems.texi.in
|
||||
EXTRA_DIST += common/cpright.texi common/setup.texi \
|
||||
common/treedef.tex common/rtems.texi.in
|
||||
|
||||
html_imagesdir = $(htmldir)/images
|
||||
|
||||
|
||||
@@ -1,36 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
@c
|
||||
@c Macros to help with the tables in this file
|
||||
@c
|
||||
|
||||
@tex
|
||||
\global\advance \smallskipamount by -4pt
|
||||
|
||||
\global\def\rtemstimetable{
|
||||
\vrule\strut##&
|
||||
\hbox to 3.0in{\enskip##\hfil}&
|
||||
\hbox to 0.75in{\enskip##\hfil}&
|
||||
\vrule##\cr
|
||||
\noalign{\hrule}
|
||||
}
|
||||
|
||||
\global\def\rtemsendtimetable{}
|
||||
\global\def\rtemsonecase#1#2{
|
||||
& \bf #1\hfil& #2 & \cr\noalign{\hrule}
|
||||
}
|
||||
|
||||
\global\def\rtemsdirective#1{
|
||||
& \bf #1 \hfil& & \cr\noalign{\hrule}
|
||||
}
|
||||
|
||||
\global\def\rtemscase#1#2{
|
||||
& \hskip 0.3in #1\hfil& #2 & \cr\noalign{\hrule}
|
||||
}
|
||||
|
||||
@end tex
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,396 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Timing Specification
|
||||
|
||||
@section Introduction
|
||||
|
||||
This chapter provides information pertaining to the
|
||||
measurement of the performance of RTEMS, the methods of
|
||||
gathering the timing data, and the usefulness of the data. Also
|
||||
discussed are other time critical aspects of RTEMS that affect
|
||||
an applications design and ultimate throughput. These aspects
|
||||
include determinancy, interrupt latency and context switch times.
|
||||
|
||||
@section Philosophy
|
||||
|
||||
Benchmarks are commonly used to evaluate the
|
||||
performance of software and hardware. Benchmarks can be an
|
||||
effective tool when comparing systems. Unfortunately,
|
||||
benchmarks can also be manipulated to justify virtually any
|
||||
claim. Benchmarks of real-time executives are difficult to
|
||||
evaluate for a variety of reasons. Executives vary in the
|
||||
robustness of features and options provided. Even when
|
||||
executives compare favorably in functionality, it is quite
|
||||
likely that different methodologies were used to obtain the
|
||||
timing data. Another problem is that some executives provide
|
||||
times for only a small subset of directives, This is typically
|
||||
justified by claiming that these are the only time-critical
|
||||
directives. The performance of some executives is also very
|
||||
sensitive to the number of objects in the system. To obtain any
|
||||
measure of usefulness, the performance information provided for
|
||||
an executive should address each of these issues.
|
||||
|
||||
When evaluating the performance of a real-time
|
||||
executive, one typically considers the following areas:
|
||||
determinancy, directive times, worst case interrupt latency, and
|
||||
context switch time. Unfortunately, these areas do not have
|
||||
standard measurement methodologies. This allows vendors to
|
||||
manipulate the results such that their product is favorably
|
||||
represented. We have attempted to provide useful and meaningful
|
||||
timing information for RTEMS. To insure the usefulness of our
|
||||
data, the methodology and definitions used to obtain and
|
||||
describe the data are also documented.
|
||||
|
||||
@subsection Determinancy
|
||||
|
||||
The correctness of data in a real-time system must
|
||||
always be judged by its timeliness. In many real-time systems,
|
||||
obtaining the correct answer does not necessarily solve the
|
||||
problem. For example, in a nuclear reactor it is not enough to
|
||||
determine that the core is overheating. This situation must be
|
||||
detected and acknowledged early enough that corrective action
|
||||
can be taken and a meltdown avoided.
|
||||
|
||||
Consequently, a system designer must be able to
|
||||
predict the worst-case behavior of the application running under
|
||||
the selected executive. In this light, it is important that a
|
||||
real-time system perform consistently regardless of the number
|
||||
of tasks, semaphores, or other resources allocated. An
|
||||
important design goal of a real-time executive is that all
|
||||
internal algorithms be fixed-cost. Unfortunately, this goal is
|
||||
difficult to completely meet without sacrificing the robustness
|
||||
of the executive's feature set.
|
||||
|
||||
Many executives use the term deterministic to mean
|
||||
that the execution times of their services can be predicted.
|
||||
However, they often provide formulas to modify execution times
|
||||
based upon the number of objects in the system. This usage is
|
||||
in sharp contrast to the notion of deterministic meaning fixed
|
||||
cost.
|
||||
|
||||
Almost all RTEMS directives execute in a fixed amount
|
||||
of time regardless of the number of objects present in the
|
||||
system. The primary exception occurs when a task blocks while
|
||||
acquiring a resource and specifies a non-zero timeout interval.
|
||||
|
||||
Other exceptions are message queue broadcast,
|
||||
obtaining a variable length memory block, object name to ID
|
||||
translation, and deleting a resource upon which tasks are
|
||||
waiting. In addition, the time required to service a clock tick
|
||||
interrupt is based upon the number of timeouts and other
|
||||
"events" which must be processed at that tick. This second
|
||||
group is composed primarily of capabilities which are inherently
|
||||
non-deterministic but are infrequently used in time critical
|
||||
situations. The major exception is that of servicing a clock
|
||||
tick. However, most applications have a very small number of
|
||||
timeouts which expire at exactly the same millisecond (usually
|
||||
none, but occasionally two or three).
|
||||
|
||||
@subsection Interrupt Latency
|
||||
|
||||
Interrupt latency is the delay between the CPU's
|
||||
receipt of an interrupt request and the execution of the first
|
||||
application-specific instruction in an interrupt service
|
||||
routine. Interrupts are a critical component of most real-time
|
||||
applications and it is critical that they be acted upon as
|
||||
quickly as possible.
|
||||
|
||||
Knowledge of the worst case interrupt latency of an
|
||||
executive aids the application designer in determining the
|
||||
maximum period of time between the generation of an interrupt
|
||||
and an interrupt handler responding to that interrupt. The
|
||||
interrupt latency of an system is the greater of the executive's
|
||||
and the applications's interrupt latency. If the application
|
||||
disables interrupts longer than the executive, then the
|
||||
application's interrupt latency is the system's worst case
|
||||
interrupt disable period.
|
||||
|
||||
The worst case interrupt latency for a real-time
|
||||
executive is based upon the following components:
|
||||
|
||||
@itemize @bullet
|
||||
@item the longest period of time interrupts are disabled
|
||||
by the executive,
|
||||
|
||||
@item the overhead required by the executive at the
|
||||
beginning of each ISR,
|
||||
|
||||
@item the time required for the CPU to vector the
|
||||
interrupt, and
|
||||
|
||||
@item for some microprocessors, the length of the longest
|
||||
instruction.
|
||||
@end itemize
|
||||
|
||||
The first component is irrelevant if an interrupt
|
||||
occurs when interrupts are enabled, although it must be included
|
||||
in a worst case analysis. The third and fourth components are
|
||||
particular to a CPU implementation and are not dependent on the
|
||||
executive. The fourth component is ignored by this document
|
||||
because most applications use only a subset of a
|
||||
microprocessor's instruction set. Because of this the longest
|
||||
instruction actually executed is application dependent. The
|
||||
worst case interrupt latency of an executive is typically
|
||||
defined as the sum of components (1) and (2). The second
|
||||
component includes the time necessry for RTEMS to save registers
|
||||
and vector to the user-defined handler. RTEMS includes the
|
||||
third component, the time required for the CPU to vector the
|
||||
interrupt, because it is a required part of any interrupt.
|
||||
|
||||
Many executives report the maximum interrupt disable
|
||||
period as their interrupt latency and ignore the other
|
||||
components. This results in very low worst-case interrupt
|
||||
latency times which are not indicative of actual application
|
||||
performance. The definition used by RTEMS results in a higher
|
||||
interrupt latency being reported, but accurately reflects the
|
||||
longest delay between the CPU's receipt of an interrupt request
|
||||
and the execution of the first application-specific instruction
|
||||
in an interrupt service routine.
|
||||
|
||||
The actual interrupt latency times are reported in
|
||||
the Timing Data chapter of this supplement.
|
||||
|
||||
@subsection Context Switch Time
|
||||
|
||||
An RTEMS context switch is defined as the act of
|
||||
taking the CPU from the currently executing task and giving it
|
||||
to another task. This process involves the following components:
|
||||
|
||||
@itemize @bullet
|
||||
@item Saving the hardware state of the current task.
|
||||
|
||||
@item Optionally, invoking the TASK_SWITCH user extension.
|
||||
|
||||
@item Restoring the hardware state of the new task.
|
||||
@end itemize
|
||||
|
||||
RTEMS defines the hardware state of a task to include
|
||||
the CPU's data registers, address registers, and, optionally,
|
||||
floating point registers.
|
||||
|
||||
Context switch time is often touted as a performance
|
||||
measure of real-time executives. However, a context switch is
|
||||
performed as part of a directive's actions and should be viewed
|
||||
as such when designing an application. For example, if a task
|
||||
is unable to acquire a semaphore and blocks, a context switch is
|
||||
required to transfer control from the blocking task to a new
|
||||
task. From the application's perspective, the context switch is
|
||||
a direct result of not acquiring the semaphore. In this light,
|
||||
the context switch time is no more relevant than the performance
|
||||
of any other of the executive's subroutines which are not
|
||||
directly accessible by the application.
|
||||
|
||||
In spite of the inappropriateness of using the
|
||||
context switch time as a performance metric, RTEMS context
|
||||
switch times for floating point and non-floating points tasks
|
||||
are provided for comparison purposes. Of the executives which
|
||||
actually support floating point operations, many do not report
|
||||
context switch times for floating point context switch time.
|
||||
This results in a reported context switch time which is
|
||||
meaningless for an application with floating point tasks.
|
||||
|
||||
The actual context switch times are reported in the
|
||||
Timing Data chapter of this supplement.
|
||||
|
||||
@subsection Directive Times
|
||||
|
||||
Directives are the application's interface to the
|
||||
executive, and as such their execution times are critical in
|
||||
determining the performance of the application. For example, an
|
||||
application using a semaphore to protect a critical data
|
||||
structure should be aware of the time required to acquire and
|
||||
release a semaphore. In addition, the application designer can
|
||||
utilize the directive execution times to evaluate the
|
||||
performance of different synchronization and communication
|
||||
mechanisms.
|
||||
|
||||
The actual directive execution times are reported in
|
||||
the Timing Data chapter of this supplement.
|
||||
|
||||
@section Methodology
|
||||
|
||||
@subsection Software Platform
|
||||
|
||||
The RTEMS timing suite is written in C. The overhead
|
||||
of passing arguments to RTEMS by C is not timed. The times
|
||||
reported represent the amount of time from entering to exiting
|
||||
RTEMS.
|
||||
|
||||
The tests are based upon one of two execution models:
|
||||
(1) single invocation times, and (2) average times of repeated
|
||||
invocations. Single invocation times are provided for
|
||||
directives which cannot easily be invoked multiple times in the
|
||||
same scenario. For example, the times reported for entering and
|
||||
exiting an interrupt service routine are single invocation
|
||||
times. The second model is used for directives which can easily
|
||||
be invoked multiple times in the same scenario. For example,
|
||||
the times reported for semaphore obtain and semaphore release
|
||||
are averages of multiple invocations. At least 100 invocations
|
||||
are used to obtain the average.
|
||||
|
||||
@subsection Hardware Platform
|
||||
|
||||
Since RTEMS supports a variety of processors, the
|
||||
hardware platform used to gather the benchmark times must also
|
||||
vary. Therefore, for each processor supported the hardware
|
||||
platform must be defined. Each definition will include a brief
|
||||
description of the target hardware platform including the clock
|
||||
speed, memory wait states encountered, and any other pertinent
|
||||
information. This definition may be found in the processor
|
||||
dependent timing data chapter within this supplement.
|
||||
|
||||
@subsection What is measured?
|
||||
|
||||
An effort was made to provide execution times for a
|
||||
large portion of RTEMS. Times were provided for most directives
|
||||
regardless of whether or not they are typically used in time
|
||||
critical code. For example, execution times are provided for
|
||||
all object create and delete directives, even though these are
|
||||
typically part of application initialization.
|
||||
|
||||
The times include all RTEMS actions necessary in a
|
||||
particular scenario. For example, all times for blocking
|
||||
directives include the context switch necessary to transfer
|
||||
control to a new task. Under no circumstances is it necessary
|
||||
to add context switch time to the reported times.
|
||||
|
||||
The following list describes the objects created by
|
||||
the timing suite:
|
||||
|
||||
@itemize @bullet
|
||||
@item All tasks are non-floating point.
|
||||
|
||||
@item All tasks are created as local objects.
|
||||
|
||||
@item No timeouts are used on blocking directives.
|
||||
|
||||
@item All tasks wait for objects in FIFO order.
|
||||
|
||||
@end itemize
|
||||
|
||||
In addition, no user extensions are configured.
|
||||
|
||||
@subsection What is not measured?
|
||||
|
||||
The times presented in this document are not intended
|
||||
to represent best or worst case times, nor are all directives
|
||||
included. For example, no times are provided for the initialize
|
||||
executive and fatal_error_occurred directives. Other than the
|
||||
exceptions detailed in the Determinancy section, all directives
|
||||
will execute in the fixed length of time given.
|
||||
|
||||
Other than entering and exiting an interrupt service
|
||||
routine, all directives were executed from tasks and not from
|
||||
interrupt service routines. Directives invoked from ISRs, when
|
||||
allowable, will execute in slightly less time than when invoked
|
||||
from a task because rescheduling is delayed until the interrupt
|
||||
exits.
|
||||
|
||||
@subsection Terminology
|
||||
|
||||
The following is a list of phrases which are used to
|
||||
distinguish individual execution paths of the directives taken
|
||||
during the RTEMS performance analysis:
|
||||
|
||||
@table @b
|
||||
@item another task
|
||||
The directive was performed
|
||||
on a task other than the calling task.
|
||||
|
||||
@item available
|
||||
A task attempted to obtain a resource and
|
||||
immediately acquired it.
|
||||
|
||||
@item blocked task
|
||||
The task operated upon by the
|
||||
directive was blocked waiting for a resource.
|
||||
|
||||
@item caller blocks
|
||||
The requested resoure was not
|
||||
immediately available and the calling task chose to wait.
|
||||
|
||||
@item calling task
|
||||
The task invoking the directive.
|
||||
|
||||
@item messages flushed
|
||||
One or more messages was flushed
|
||||
from the message queue.
|
||||
|
||||
@item no messages flushed
|
||||
No messages were flushed from
|
||||
the message queue.
|
||||
|
||||
@item not available
|
||||
A task attempted to obtain a resource
|
||||
and could not immediately acquire it.
|
||||
|
||||
@item no reschedule
|
||||
The directive did not require a
|
||||
rescheduling operation.
|
||||
|
||||
@item NO_WAIT
|
||||
A resource was not available and the
|
||||
calling task chose to return immediately via the NO_WAIT option
|
||||
with an error.
|
||||
|
||||
@item obtain current
|
||||
The current value of something was
|
||||
requested by the calling task.
|
||||
|
||||
@item preempts caller
|
||||
The release of a resource caused a
|
||||
task of higher priority than the calling to be readied and it
|
||||
became the executing task.
|
||||
|
||||
@item ready task
|
||||
The task operated upon by the directive
|
||||
was in the ready state.
|
||||
|
||||
@item reschedule
|
||||
The actions of the directive
|
||||
necessitated a rescheduling operation.
|
||||
|
||||
@item returns to caller
|
||||
The directive succeeded and
|
||||
immediately returned to the calling task.
|
||||
|
||||
@item returns to interrupted task
|
||||
The instructions
|
||||
executed immediately following this interrupt will be in the
|
||||
interrupted task.
|
||||
|
||||
@item returns to nested interrupt
|
||||
The instructions
|
||||
executed immediately following this interrupt will be in a
|
||||
previously interrupted ISR.
|
||||
|
||||
@item returns to preempting task
|
||||
The instructions
|
||||
executed immediately following this interrupt or signal handler
|
||||
will be in a task other than the interrupted task.
|
||||
|
||||
@item signal to self
|
||||
The signal set was sent to the
|
||||
calling task and signal processing was enabled.
|
||||
|
||||
@item suspended task
|
||||
The task operated upon by the
|
||||
directive was in the suspended state.
|
||||
|
||||
@item task readied
|
||||
The release of a resource caused a
|
||||
task of lower or equal priority to be readied and the calling
|
||||
task remained the executing task.
|
||||
|
||||
@item yield
|
||||
The act of attempting to voluntarily release
|
||||
the CPU.
|
||||
|
||||
@end table
|
||||
|
||||
@@ -177,7 +177,6 @@ _RTEMS_UPDATE_CONDITIONAL([common/rtems.sed],[common/rtems.sed~])
|
||||
|
||||
AC_CONFIG_FILES([
|
||||
index.html
|
||||
FAQ/Makefile
|
||||
develenv/Makefile
|
||||
user/Makefile
|
||||
bsp_howto/Makefile])
|
||||
|
||||
+13
-111
@@ -7,15 +7,7 @@
|
||||
<HR>
|
||||
<BODY>
|
||||
<MENU>
|
||||
<LI>
|
||||
<A HREF="../pdf/FAQ.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/FAQ.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/FAQ.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="FAQ/index.html">RTEMS FAQ</A>
|
||||
</LI>
|
||||
<LI><A HREF="http://www.rtems.org/wiki">RTEMS Wiki</A></LI>
|
||||
<LI>C/C++ Manuals</LI>
|
||||
<MENU>
|
||||
<LI><A HREF="../pdf/started.pdf">
|
||||
@@ -82,6 +74,16 @@
|
||||
</MENU>
|
||||
<LI>Miscellaneous Manuals</LI>
|
||||
<MENU>
|
||||
<LI><A HREF="../pdf/cpu_supplement.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/cpu_supplement.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/cpu_supplement.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="cpu_supplement/index.html">
|
||||
RTEMS CPU Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="../pdf/develenv.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/develenv.ps">
|
||||
@@ -153,109 +155,9 @@
|
||||
</LI>
|
||||
</MENU>
|
||||
|
||||
|
||||
<LI>CPU Supplements for Primary Ports
|
||||
|
||||
<MENU>
|
||||
|
||||
<LI><A HREF="HELP.html">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="HELP.html">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="HELP.html">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="HELP.html">
|
||||
RTEMS Hitachi H8/300 Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="../pdf/i386.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/i386.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/i386.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="supplements/i386/index.html">
|
||||
RTEMS Intel i386 Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="../pdf/m68k.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/m68k.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/m68k.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="supplements/m68k/index.html">
|
||||
RTEMS Motorola MC68xxx Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="../pdf/mips.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/mips.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/mips.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="supplements/mips/index.html">
|
||||
RTEMS MIPS Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="../pdf/powerpc.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/powerpc.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/powerpc.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="supplements/powerpc/index.html">
|
||||
RTEMS PowerPC Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="../pdf/sh.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/sh.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/sh.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="supplements/sh/index.html">
|
||||
RTEMS Hitachi SH Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="../pdf/sparc.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/sparc.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/sparc.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="supplements/sparc/index.html">
|
||||
RTEMS SPARC Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="HELP.html">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="HELP.html">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="HELP.html">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="HELP.html">
|
||||
RTEMS UNIX Port Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
</MENU>
|
||||
|
||||
<LI>CPU Supplements for Secondary Ports
|
||||
|
||||
<MENU>
|
||||
<LI><A HREF="../pdf/c4x.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/c4x.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/c4x.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="supplements/c4x/index.html">
|
||||
RTEMS Texas Instruments C3x/C4x Applications Supplement</A>
|
||||
</LI>
|
||||
</MENU>
|
||||
</LI>
|
||||
</li>
|
||||
|
||||
</MENU>
|
||||
<HR>
|
||||
Copyright © 1988-2004 <A HREF="http://www.oarcorp.com" target="Text Frame">OAR Corporation</A>
|
||||
Copyright © 1988-2006 <A HREF="http://www.oarcorp.com" target="Text Frame">OAR Corporation</A>
|
||||
</BODY></HTML>
|
||||
|
||||
Reference in New Issue
Block a user