mirror of
https://gitlab.rtems.org/rtems/rtos/rtems.git
synced 2025-11-16 12:34:45 +00:00
2010-12-16 Joel Sherrill <joel.sherrilL@OARcorp.com>
* Makefile.am, configure.ac, develenv/direct.t: Remove Getting Started with GNAT/RTEMS. * started_ada/.cvsignore, started_ada/Makefile.am, started_ada/buildada.t, started_ada/gdb.t, started_ada/intro.t, started_ada/require.t, started_ada/sample.t, started_ada/started_ada.texi, started_ada/tversions.texi: Removed.
This commit is contained in:
Joel Sherrill
@@ -1,3 +1,12 @@
|
||||
2010-12-16 Joel Sherrill <joel.sherrilL@OARcorp.com>
|
||||
|
||||
* Makefile.am, configure.ac, develenv/direct.t: Remove Getting Started
|
||||
with GNAT/RTEMS.
|
||||
* started_ada/.cvsignore, started_ada/Makefile.am,
|
||||
started_ada/buildada.t, started_ada/gdb.t, started_ada/intro.t,
|
||||
started_ada/require.t, started_ada/sample.t,
|
||||
started_ada/started_ada.texi, started_ada/tversions.texi: Removed.
|
||||
|
||||
2010-11-11 Joel Sherrill <joel.sherrilL@OARcorp.com>
|
||||
|
||||
PR 1716/doc
|
||||
|
||||
@@ -8,7 +8,7 @@ ACLOCAL_AMFLAGS = -I ../aclocal
|
||||
# + tools, common and images are shared across many documents
|
||||
|
||||
SUBDIRS = tools started user bsp_howto porting develenv posix_users \
|
||||
posix1003.1 filesystem itron3.0 networking ada_user started_ada \
|
||||
posix1003.1 filesystem itron3.0 networking ada_user \
|
||||
new_chapters relnotes cpu_supplement shell
|
||||
|
||||
if USE_HTML
|
||||
|
||||
@@ -208,7 +208,6 @@ posix1003.1/Makefile
|
||||
filesystem/Makefile
|
||||
itron3.0/Makefile
|
||||
ada_user/Makefile
|
||||
started_ada/Makefile
|
||||
relnotes/Makefile
|
||||
new_chapters/Makefile
|
||||
cpu_supplement/Makefile
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1989-2007.
|
||||
@c COPYRIGHT (c) 1989-2010.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@@ -690,10 +690,6 @@ recent RTEMS releases.
|
||||
This directory contains the source code for the
|
||||
@cite{Getting Started with RTEMS for C/C++ Users} manual.
|
||||
|
||||
@item $@{RTEMS_ROOT@}/doc/started_ada/
|
||||
This directory contains the source code for the
|
||||
@cite{Getting Started with RTEMS for Ada Users} manual.
|
||||
|
||||
@item $@{RTEMS_ROOT@}/doc/tools/
|
||||
This directory contains the source code for the tools
|
||||
used on the development host to assist in producing the
|
||||
|
||||
@@ -1,29 +0,0 @@
|
||||
buildada.texi
|
||||
buildrt.texi
|
||||
gdb.texi
|
||||
index.html
|
||||
intro.texi
|
||||
Makefile
|
||||
Makefile.in
|
||||
mdate-sh
|
||||
require.texi
|
||||
rtems_footer.html
|
||||
rtems_header.html
|
||||
sample.texi
|
||||
stamp-vti
|
||||
started_ada
|
||||
started_ada.aux
|
||||
started_ada.cp
|
||||
started_ada.dvi
|
||||
started_ada.fn
|
||||
started_ada*.html
|
||||
started_ada.info
|
||||
started_ada.ky
|
||||
started_ada.log
|
||||
started_ada.pdf
|
||||
started_ada.pg
|
||||
started_ada.ps
|
||||
started_ada.toc
|
||||
started_ada.tp
|
||||
started_ada.vr
|
||||
version.texi
|
||||
@@ -1,56 +0,0 @@
|
||||
#
|
||||
# COPYRIGHT (c) 1988-2002.
|
||||
# On-Line Applications Research Corporation (OAR).
|
||||
# All rights reserved.
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
PROJECT = started_ada
|
||||
EDITION = 1
|
||||
|
||||
include $(top_srcdir)/project.am
|
||||
include $(top_srcdir)/main.am
|
||||
|
||||
GENERATED_FILES = buildada.texi buildrt.texi gdb.texi intro.texi \
|
||||
require.texi sample.texi
|
||||
|
||||
COMMON_FILES += $(top_srcdir)/common/cpright.texi
|
||||
|
||||
FILES = tversions.texi
|
||||
|
||||
info_TEXINFOS = started_ada.texi
|
||||
started_ada_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
|
||||
|
||||
intro.texi: intro.t tversions.texi
|
||||
$(BMENU2) -c -p "Top" \
|
||||
-u "Top" \
|
||||
-n "Requirements" < $< > $@
|
||||
|
||||
require.texi: require.t tversions.texi
|
||||
$(BMENU2) -c -p "GNAT Chat Mailing List" \
|
||||
-u "Top" \
|
||||
-n "Building the GNAT Cross Compiler Toolset" < $< > $@
|
||||
|
||||
buildada.texi: buildada.t tversions.texi
|
||||
$(BMENU2) -c -p "Insure GCC and GNAT Environment Variables Are Not Set" \
|
||||
-u "Top" \
|
||||
-n "Building RTEMS" < $< > $@
|
||||
|
||||
buildrt.texi: $(top_srcdir)/started/buildrt.t tversions.texi
|
||||
$(BMENU2) -c -p "Error Messages Indicating Configuration Problems" \
|
||||
-u "Top" \
|
||||
-n "Building the Sample Application" < $< > $@
|
||||
|
||||
sample.texi: sample.t tversions.texi
|
||||
$(BMENU2) -c -p "Using the RTEMS configure Script Directly" \
|
||||
-u "Top" \
|
||||
-n "Building the GNU Debugger" < $< > $@
|
||||
|
||||
gdb.texi: gdb.t tversions.texi
|
||||
$(BMENU2) -c -p "Application Executable" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
EXTRA_DIST = buildada.t gdb.t intro.t require.t sample.t
|
||||
CLEANFILES += started_ada.info
|
||||
@@ -1,698 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Building the GNAT Cross Compiler Toolset
|
||||
|
||||
This chapter describes the steps required to acquire the
|
||||
source code for a GNU cross compiler toolset, apply
|
||||
any required RTEMS specific patches, compile that
|
||||
toolset and install it.
|
||||
|
||||
@section Create the Archive and Build Directories
|
||||
|
||||
Start by making the @code{archive} directory to contain the downloaded
|
||||
source code and the @code{tools} directory to be used as a build
|
||||
directory. The command sequence to do this is shown
|
||||
below:
|
||||
|
||||
@example
|
||||
mkdir archive
|
||||
mkdir tools
|
||||
@end example
|
||||
|
||||
This will result in an initial directory structure similar to the
|
||||
one shown in the following figure:
|
||||
|
||||
@example
|
||||
@group
|
||||
/whatever/prefix/you/choose/
|
||||
archive/
|
||||
tools/
|
||||
|
||||
@end group
|
||||
@end example
|
||||
|
||||
@c @ifset use-html
|
||||
@c @html
|
||||
@c <IMG SRC="sfile12c.jpg" WIDTH=417 HEIGHT=178
|
||||
@c ALT="Starting Directory Organization">
|
||||
@c @end html
|
||||
@c @end ifset
|
||||
|
||||
@section Get All the Pieces
|
||||
|
||||
This section lists the components of an RTEMS cross development system.
|
||||
Included are the locations of each component as well as any required RTEMS
|
||||
specific patches.
|
||||
|
||||
@subheading @value{GCCVERSION}
|
||||
@example
|
||||
FTP Site: @value{GCCFTPSITE}
|
||||
Directory: @value{GCCFTPDIR}
|
||||
File: @value{GCCTAR}
|
||||
@ifset use-html
|
||||
@c URL: @uref{ftp://@value{GCCFTPSITE}@value{GCCFTPDIR}/@value{GCCTAR},Download @value{GCCVERSION}}
|
||||
URL: ftp://@value{GCCFTPSITE}@value{GCCFTPDIR}/@value{GCCTAR}
|
||||
@end ifset
|
||||
@end example
|
||||
|
||||
@subheading @value{GNAT-VERSION}
|
||||
@example
|
||||
FTP Site: @value{GNAT-FTPSITE}
|
||||
Directory: @value{GNAT-FTPDIR}
|
||||
File: @value{GNAT-TAR}
|
||||
@ifset use-html
|
||||
@c URL: @uref{ ftp://@value{GNAT-FTPSITE}@value{GNAT-FTPDIR}/@value{GNAT-TAR}, Download @value{GNAT-VERSION}}
|
||||
URL: ftp://@value{GNAT-FTPSITE}@value{GNAT-FTPDIR}/@value{GNAT-TAR}
|
||||
@end ifset
|
||||
@end example
|
||||
|
||||
@subheading @value{BINUTILSVERSION}
|
||||
@example
|
||||
FTP Site: @value{BINUTILSFTPSITE}
|
||||
Directory: @value{BINUTILSFTPDIR}
|
||||
File: @value{BINUTILSTAR}
|
||||
@ifset use-html
|
||||
@c URL: @uref{ftp://@value{BINUTILSFTPSITE}@value{BINUTILSFTPDIR}/@value{BINUTILSTAR}, Download @value{BINUTILSVERSION}}
|
||||
URL: ftp://@value{BINUTILSFTPSITE}@value{BINUTILSFTPDIR}/@value{BINUTILSTAR}
|
||||
@end ifset
|
||||
@end example
|
||||
|
||||
@subheading @value{NEWLIBVERSION}
|
||||
@example
|
||||
FTP Site: @value{NEWLIBFTPSITE}
|
||||
Directory: @value{NEWLIBFTPDIR}
|
||||
File: @value{NEWLIBTAR}
|
||||
@ifset use-html
|
||||
@c URL: @uref{ftp://@value{NEWLIBFTPSITE}@value{NEWLIBFTPDIR}/@value{NEWLIBTAR}, Download @value{NEWLIBVERSION}}
|
||||
URL: ftp://@value{NEWLIBFTPSITE}@value{NEWLIBFTPDIR}/@value{NEWLIBTAR}
|
||||
@end ifset
|
||||
@end example
|
||||
|
||||
@subheading @value{RTEMSVERSION}
|
||||
@example
|
||||
FTP Site: @value{RTEMSFTPSITE}
|
||||
Directory: @value{RTEMSFTPDIR}
|
||||
File: @value{RTEMSTAR}
|
||||
@ifset use-html
|
||||
@c URL: @uref{ftp://@value{RTEMSFTPSITE}@value{RTEMSFTPDIR}, Download RTEMS components}
|
||||
URL: ftp://@value{RTEMSFTPSITE}@value{RTEMSFTPDIR}
|
||||
@end ifset
|
||||
@end example
|
||||
|
||||
@subheading RTEMS Hello World
|
||||
@example
|
||||
FTP Site: @value{RTEMSFTPSITE}
|
||||
Directory: @value{RTEMSFTPDIR}
|
||||
File: hello_world_ada.tgz
|
||||
@ifset use-html
|
||||
@c URL: @uref{ftp://@value{RTEMSFTPSITE}@value{RTEMSFTPDIR}/ada_tools/hello_world_ada.tgz, Download RTEMS Hello World}
|
||||
URL: ftp://@value{RTEMSFTPSITE}@value{RTEMSFTPDIR}/ada_tools/hello_world_ada.tgz
|
||||
@end ifset
|
||||
@end example
|
||||
|
||||
@subheading RTEMS Specific Tool Patches and Scripts
|
||||
@example
|
||||
FTP Site: @value{RTEMSFTPSITE}
|
||||
Directory: @value{RTEMSFTPDIR}/ada_tools/source
|
||||
File: @value{BUILDTOOLSTAR}
|
||||
@ifset BINUTILSRTEMSPATCH
|
||||
File: @value{BINUTILSRTEMSPATCH}
|
||||
@end ifset
|
||||
@ifset NEWLIBRTEMSPATCH
|
||||
File: @value{NEWLIBRTEMSPATCH}
|
||||
@end ifset
|
||||
@ifset GCCRTEMSPATCH
|
||||
File: @value{GCCRTEMSPATCH}
|
||||
@end ifset
|
||||
@ifset GNAT-RTEMSPATCH
|
||||
File: @value{GNAT-RTEMSPATCH}
|
||||
@end ifset
|
||||
@ifset use-html
|
||||
@c URL: @uref{ftp://@value{RTEMSFTPSITE}@value{RTEMSFTPDIR}/ada_tools/source, Download RTEMS patches}
|
||||
URL: ftp://@value{RTEMSFTPSITE}@value{RTEMSFTPDIR}/ada_tools/source
|
||||
@end ifset
|
||||
@end example
|
||||
|
||||
@section Unarchiving the Tools
|
||||
|
||||
While in the @code{tools} directory, unpack the compressed
|
||||
tar files using the following command sequence:
|
||||
|
||||
@example
|
||||
cd tools
|
||||
tar xzf ../archive/@value{GCCTAR}
|
||||
tar xzf ../archive/@value{GNAT-TAR}
|
||||
tar xzf ../archive/@value{BINUTILSTAR}
|
||||
tar xzf ../archive/@value{NEWLIBTAR}
|
||||
tar xzf ../archive/@value{BUILDTOOLSTAR}
|
||||
@end example
|
||||
|
||||
After the compressed tar files have been unpacked, the following
|
||||
directories will have been created under tools.
|
||||
|
||||
@itemize @bullet
|
||||
@item @value{BINUTILSUNTAR}
|
||||
@item @value{GCCUNTAR}
|
||||
@item @value{GNAT-UNTAR}
|
||||
@item @value{NEWLIBUNTAR}
|
||||
@end itemize
|
||||
|
||||
There will also be a set of scripts in the current directory
|
||||
which aid in building the tools and RTEMS. They are:
|
||||
|
||||
@itemize @bullet
|
||||
@item bit_ada
|
||||
@item bit_gdb
|
||||
@item bit_rtems
|
||||
@item common.sh
|
||||
@item user.cfg
|
||||
@end itemize
|
||||
|
||||
When the @code{bit_ada} script is executed later in this process,
|
||||
it will automatically create two other subdirectories:
|
||||
|
||||
@itemize @bullet
|
||||
@item src
|
||||
@item build-$@{CPU@}-tools
|
||||
@end itemize
|
||||
|
||||
Similarly, the @code{bit_gdb} script will create the
|
||||
subdirectory @code{build-$@{CPU@}-gdb} and
|
||||
the @code{bit_rtems} script will create the
|
||||
subdirectory @code{build-$@{CPU@}-rtems}.
|
||||
|
||||
The directory tree should look something like the following figure:
|
||||
|
||||
@example
|
||||
@group
|
||||
/whatever/prefix/you/choose/
|
||||
archive/
|
||||
@value{GCCTAR}
|
||||
@value{GNAT-TAR}
|
||||
@value{BINUTILSTAR}
|
||||
@value{NEWLIBTAR}
|
||||
@value{RTEMSTAR}
|
||||
@value{BUILDTOOLSTAR}
|
||||
@ifset GCCRTEMSPATCH
|
||||
@value{GCCRTEMSPATCH}
|
||||
@end ifset
|
||||
@ifset BINUTILSRTEMSPATCH
|
||||
@value{BINUTILSRTEMSPATCH}
|
||||
@end ifset
|
||||
@ifset NEWLIBRTEMSPATCH
|
||||
@value{NEWLIBRTEMSPATCH}
|
||||
@end ifset
|
||||
@ifset GNAT-RTEMSPATCH
|
||||
@value{GNAT-RTEMSPATCH}
|
||||
@end ifset
|
||||
hello_world_ada.tgz
|
||||
bit_ada
|
||||
tools/
|
||||
@value{BINUTILSUNTAR}/
|
||||
@value{GCCUNTAR}/
|
||||
@value{GNAT-UNTAR}/
|
||||
@value{NEWLIBUNTAR}/
|
||||
bit_ada
|
||||
bit_gdb
|
||||
bit_rtems
|
||||
common.sh
|
||||
user.cfg
|
||||
@end group
|
||||
@end example
|
||||
|
||||
@c @ifset use-html
|
||||
@c @html
|
||||
@c <IMG SRC="bit_ada.jpg" WIDTH=816 HEIGHT=267 ALT="Directory Organization">
|
||||
@c @end html
|
||||
@c @end ifset
|
||||
|
||||
@c
|
||||
@c Host Specific Notes
|
||||
@c
|
||||
|
||||
@section Host Specific Notes
|
||||
|
||||
@subsection Solaris 2.x
|
||||
|
||||
The build scripts are written in "shell". The program @code{/bin/sh}
|
||||
on Solaris 2.x is not robust enough to execute these scripts. If you
|
||||
are on a Solaris 2.x host, then change the first line of the files
|
||||
@code{bit_ada}, @code{bit_gdb}, and @code{bit_rtems} to use the
|
||||
@code{/bin/ksh} shell instead.
|
||||
|
||||
@c
|
||||
@c Reading the Documentation
|
||||
@c
|
||||
|
||||
@section Reading the Tools Documentation
|
||||
|
||||
Each of the tools in the GNU development suite comes with documentation.
|
||||
It is in the reader's and tool maintainers' interest that one read the
|
||||
documentation before posting a problem to a mailing list or news group.
|
||||
|
||||
|
||||
@c
|
||||
@c GCC patches
|
||||
@c
|
||||
|
||||
@section Apply RTEMS Patch to GCC
|
||||
|
||||
@ifclear GCCRTEMSPATCH
|
||||
No RTEMS specific patches are required for @value{GCCVERSION} to
|
||||
support @value{RTEMSVERSION}.
|
||||
@end ifclear
|
||||
|
||||
@ifset GCCRTEMSPATCH
|
||||
|
||||
Apply the patch using the following command sequence:
|
||||
|
||||
@example
|
||||
cd tools/@value{GCCUNTAR}
|
||||
zcat ../../archive/@value{GCCRTEMSPATCH} | patch -p1
|
||||
@end example
|
||||
|
||||
Check to see if any of these patches have been rejected using the following
|
||||
sequence:
|
||||
|
||||
@example
|
||||
cd tools/@value{GCCUNTAR}
|
||||
find . -name "*.rej" -print
|
||||
@end example
|
||||
|
||||
If any files are found with the .rej extension, a patch has been rejected.
|
||||
This should not happen with a good patch file which is properly applied.
|
||||
|
||||
@end ifset
|
||||
|
||||
@c
|
||||
@c BINUTILS patches
|
||||
@c
|
||||
|
||||
@section Apply RTEMS Patch to binutils
|
||||
|
||||
@ifclear BINUTILSRTEMSPATCH
|
||||
No RTEMS specific patches are required for @value{BINUTILSVERSION} to
|
||||
support @value{RTEMSVERSION}.
|
||||
@end ifclear
|
||||
|
||||
@ifset BINUTILSRTEMSPATCH
|
||||
Apply the patch using the following command sequence:
|
||||
|
||||
@example
|
||||
cd tools/@value{BINUTILSUNTAR}
|
||||
zcat ../../archive/@value{BINUTILSRTEMSPATCH} | patch -p1
|
||||
@end example
|
||||
|
||||
Check to see if any of these patches have been rejected using the following
|
||||
sequence:
|
||||
|
||||
@example
|
||||
cd tools/@value{BINUTILSUNTAR}
|
||||
find . -name "*.rej" -print
|
||||
@end example
|
||||
|
||||
If any files are found with the .rej extension, a patch has been rejected.
|
||||
This should not happen with a good patch file which is properly applied.
|
||||
|
||||
@end ifset
|
||||
|
||||
@c
|
||||
@c Newlib patches
|
||||
@c
|
||||
|
||||
@section Apply RTEMS Patch to newlib
|
||||
|
||||
@ifclear NEWLIBRTEMSPATCH
|
||||
No RTEMS specific patches are required for @value{NEWLIBVERSION} to
|
||||
support @value{RTEMSVERSION}.
|
||||
@end ifclear
|
||||
|
||||
@ifset NEWLIBRTEMSPATCH
|
||||
|
||||
Apply the patch using the following command sequence:
|
||||
|
||||
@example
|
||||
cd tools/@value{NEWLIBUNTAR}
|
||||
zcat ../../archive/@value{NEWLIBRTEMSPATCH} | patch -p1
|
||||
@end example
|
||||
|
||||
Check to see if any of these patches have been rejected using the following
|
||||
sequence:
|
||||
|
||||
@example
|
||||
cd tools/@value{NEWLIBUNTAR}
|
||||
find . -name "*.rej" -print
|
||||
@end example
|
||||
|
||||
If any files are found with the .rej extension, a patch has been rejected.
|
||||
This should not happen with a good patch file which is properly applied.
|
||||
|
||||
@end ifset
|
||||
|
||||
@c
|
||||
@c GNAT patches
|
||||
@c
|
||||
|
||||
@section Apply RTEMS Patch to GNAT
|
||||
|
||||
@ifclear GNAT-RTEMSPATCH
|
||||
No RTEMS specific patches are required for @value{GNAT-VERSION} to
|
||||
support @value{RTEMSVERSION}.
|
||||
@end ifclear
|
||||
|
||||
@ifset GNAT-RTEMSPATCH
|
||||
|
||||
Apply the patch using the following command sequence:
|
||||
|
||||
@example
|
||||
cd tools/@value{GNAT-UNTAR}
|
||||
zcat ../../archive/@value{GNAT-RTEMSPATCH} | patch -p1
|
||||
@end example
|
||||
|
||||
Check to see if any of these patches have been rejected using the following
|
||||
sequence:
|
||||
|
||||
@example
|
||||
cd tools/@value{GNAT-UNTAR}
|
||||
find . -name "*.rej" -print
|
||||
@end example
|
||||
|
||||
If any files are found with the .rej extension, a patch has been rejected.
|
||||
This should not happen with a good patch file which is properly applied.
|
||||
|
||||
@end ifset
|
||||
|
||||
@c
|
||||
@c Copy the ada directory
|
||||
@c
|
||||
|
||||
|
||||
@section Copy the ada Subdirectory to the GCC Source Tree
|
||||
|
||||
Copy the ada subtree in the patched subtree of
|
||||
tools/@value{GNAT-UNTAR}/src to the
|
||||
tools/@value{GCCUNTAR} directory:
|
||||
|
||||
@example
|
||||
cd tools/@value{GNAT-UNTAR}/src
|
||||
cp -r ada ../../@value{GCCUNTAR}
|
||||
@end example
|
||||
|
||||
|
||||
@c
|
||||
@c Localizing the Configuration
|
||||
@c
|
||||
|
||||
@section Localizing the Configuration
|
||||
|
||||
Edit the @code{user.cfg} file to alter the settings of various
|
||||
variables which are used to tailor the build process.
|
||||
Each of the variables set in @code{user.cfg} may be modified
|
||||
as described below:
|
||||
|
||||
@table @code
|
||||
@item INSTALL_POINT
|
||||
is the location where you wish the GNU C/C++ cross compilation tools for
|
||||
RTEMS to be built. It is recommended that the directory chosen to receive
|
||||
these tools be named so that it is clear from which gcc distribution it
|
||||
was generated and for which target system the tools are to produce code for.
|
||||
|
||||
@b{WARNING}: The @code{INSTALL_POINT} should not be a subdirectory
|
||||
under the build directory. The build directory will be removed
|
||||
automatically upon successful completion of the build procedure.
|
||||
|
||||
@item BINUTILS
|
||||
is the directory under tools that contains @value{BINUTILSUNTAR}.
|
||||
For example:
|
||||
|
||||
@example
|
||||
BINUTILS=@value{BINUTILSUNTAR}
|
||||
@end example
|
||||
|
||||
@item GCC
|
||||
is the directory under tools that contains @value{GCCUNTAR}.
|
||||
For example,
|
||||
|
||||
@example
|
||||
GCC=@value{GCCUNTAR}
|
||||
@end example
|
||||
|
||||
Note that the gnat version is not needed because the gnat source
|
||||
is built as part of building gcc.
|
||||
|
||||
@item NEWLIB
|
||||
is the directory under tools that contains @value{NEWLIBUNTAR}.
|
||||
For example:
|
||||
|
||||
@example
|
||||
NEWLIB=@value{NEWLIBUNTAR}
|
||||
@end example
|
||||
|
||||
@item BUILD_DOCS
|
||||
is set to "yes" if you want to install documentation. This requires
|
||||
that tools supporting documentation production be installed. This
|
||||
currently is limited to the GNU texinfo package.
|
||||
For example:
|
||||
|
||||
@example
|
||||
BUILD_DOCS=yes
|
||||
@end example
|
||||
|
||||
@item BUILD_OTHER_LANGUAGES
|
||||
is set to "yes" if you want to build languages other than C and C++. At
|
||||
the current time, the set of alternative languages includes Java, Fortran,
|
||||
and Objective-C. These alternative languages do not always build cross.
|
||||
Hence this option defaults to "no".
|
||||
|
||||
For example:
|
||||
|
||||
@example
|
||||
BUILD_OTHER_LANGUAGES=yes
|
||||
@end example
|
||||
|
||||
@b{NOTE:} Based upon the version of the compiler being used, it may not
|
||||
be possible to build languages other than C and C++ cross. In many cases,
|
||||
the language run-time support libraries are not "multilib'ed". Thus the
|
||||
executable code in these libraries will be for the default compiler settings
|
||||
and not necessarily be correct for your CPU model.
|
||||
|
||||
@item RTEMS
|
||||
is the directory under tools that contails @value{RTEMSUNTAR}.
|
||||
|
||||
@item ENABLE_RTEMS_POSIX
|
||||
is set to "yes" if you want to enable the RTEMS POSIX API support.
|
||||
At this time, this feature is not supported by the UNIX ports of RTEMS
|
||||
and is forced to "no" for those targets. This corresponds to the
|
||||
@code{configure} option @code{--enable-posix}.
|
||||
|
||||
This must be enabled to support the GNAT/RTEMS run-time.
|
||||
|
||||
@item ENABLE_RTEMS_ITRON
|
||||
is set to "yes" if you want to enable the RTEMS ITRON API support.
|
||||
At this time, this feature is not supported by the UNIX ports of RTEMS
|
||||
and is forced to "no" for those targets. This corresponds to the
|
||||
@code{configure} option @code{--enable-itron}.
|
||||
|
||||
@item ENABLE_RTEMS_MP
|
||||
is set to "yes" if you want to enable the RTEMS multiprocessing
|
||||
support. This feature is not supported by all RTEMS BSPs and
|
||||
is automatically forced to "no" for those BSPs. This corresponds to the
|
||||
@code{configure} option @code{--enable-multiprocessing}.
|
||||
|
||||
@item ENABLE_RTEMS_CXX
|
||||
is set to "yes" if you want to build the RTEMS C++ support including
|
||||
the C++ Wrapper for the Classic API. This corresponds to the
|
||||
@code{configure} option @code{--enable-cxx}.
|
||||
|
||||
@item ENABLE_RTEMS_TESTS
|
||||
is set to "yes" if you want to build the RTEMS Test Suite. If this
|
||||
is set to "no", then only the Sample Tests will be built. Setting
|
||||
this option to "yes" significantly increases the amount of disk
|
||||
space required to build RTEMS.
|
||||
This corresponds to the @code{configure} option @code{--enable-tests}.
|
||||
|
||||
@item ENABLE_RTEMS_TCPIP
|
||||
is set to "yes" if you want to build the RTEMS TCP/IP Stack. If a
|
||||
particular BSP does not support TCP/IP, then this feature is automatically
|
||||
disabled. This corresponds to the @code{configure} option
|
||||
@code{--enable-tcpip}.
|
||||
|
||||
@item ENABLE_RTEMS_NONDEBUG
|
||||
is set to "yes" if you want to build RTEMS in a fully optimized
|
||||
state. This corresponds to executing @code{make} after configuring
|
||||
the source tree.
|
||||
|
||||
@item ENABLE_RTEMS_DEBUG
|
||||
is set to "yes" if you want to build RTEMS in a debug version.
|
||||
When built for debug, RTEMS will include run-time code to
|
||||
perform consistency checks such as heap consistency checks.
|
||||
Although the precise compilation arguments are BSP dependent,
|
||||
the debug version of RTEMS is usually built at a lower optimization
|
||||
level. This is usually done to reduce inlining which can make
|
||||
tracing code execution difficult. This corresponds to executing
|
||||
@code{make VARIANT=debug} after configuring
|
||||
the source tree.
|
||||
|
||||
@item INSTALL_RTEMS
|
||||
is set to "yes" if you want to install RTEMS after building it.
|
||||
This corresponds to executing @code{make install} after configuring
|
||||
and building the source tree.
|
||||
|
||||
@item ENABLE_RTEMS_MAINTAINER_MODE
|
||||
is set to "yes" if you want to enabled maintainer mode functionality
|
||||
in the RTEMS Makefile. This is disabled by default and it is not
|
||||
expected that most users will want to enable this. When this option
|
||||
is enabled, the build process may attempt to regenerate files that
|
||||
require tools not required when this option is disabled.
|
||||
This corresponds to the @code{configure} option
|
||||
@code{--enable-maintainer-mode}.
|
||||
|
||||
@end table
|
||||
|
||||
@section Running the bit_ada Script
|
||||
|
||||
After the @code{bit_ada} script has been modified to reflect the
|
||||
local installation, the modified @code{bit_ada} script is run
|
||||
using the following sequence:
|
||||
|
||||
@example
|
||||
cd tools
|
||||
./bit_ada <target configuration>
|
||||
@end example
|
||||
|
||||
Where <target configuration> is one of the following:
|
||||
|
||||
@itemize @bullet
|
||||
@item hppa1.1
|
||||
@item i386
|
||||
@item m68k
|
||||
@item powerpc
|
||||
@item sh
|
||||
@item sparc
|
||||
@end itemize
|
||||
|
||||
NOTE: The above list of target configurations is the list of RTEMS supported
|
||||
targets. Only a subset of these have been tested with GNAT/RTEMS. For more
|
||||
information, contact your GNAT/RTEMS representative.
|
||||
|
||||
The build process can take a while to complete. Many users find it
|
||||
handy to run the build process in the background, capture the output
|
||||
in a file, and monitor the output. This can be done as follows:
|
||||
|
||||
@example
|
||||
./bit_ada <target configuration> >bit.log 2>&1 &
|
||||
tail -f bit.log
|
||||
@end example
|
||||
|
||||
If no errors are encountered, the @code{bit_ada} script will conclude by
|
||||
printing messages similar to the following:
|
||||
|
||||
@example
|
||||
|
||||
The src and build-i386-tools subdirectory may now be removed.
|
||||
|
||||
Started: Fri Apr 10 10:14:07 CDT 1998
|
||||
Finished: Fri Apr 10 12:01:33 CDT 1998
|
||||
@end example
|
||||
|
||||
If the @code{bit_ada} script successfully completes, then the
|
||||
GNU C/C++ cross compilation tools are installed.
|
||||
|
||||
If the @code{bit_ada} script does not successfully complete, then investigation
|
||||
will be required to determine the source of the error.
|
||||
|
||||
@c
|
||||
@c Common Problems
|
||||
@c
|
||||
|
||||
@section Common Problems
|
||||
|
||||
@subsection Error Message Indicates Invalid Option to Assembler
|
||||
|
||||
If a message like this is printed then the new cross compiler
|
||||
is most likely using the native assembler instead of the cross
|
||||
assembler or vice-versa (native compiler using new cross assembler).
|
||||
This can occur for one of the following reasons:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item Binutils Patch Improperly Applied
|
||||
@item Binutils Not Built
|
||||
@item Current Directory is in Your PATH
|
||||
|
||||
@end itemize
|
||||
|
||||
If you are using binutils 2.9.1 or newer with certain older versions of
|
||||
gcc, they do not agree on what the name of the newly
|
||||
generated cross assembler is. Older binutils called it @code{as.new}
|
||||
which became @code{as.new.exe} under Windows. This is not a valid
|
||||
file name, so @code{as.new} is now called @code{as-new}. By using the latest
|
||||
released tool versions and RTEMS patches, this problem will be avoided.
|
||||
|
||||
If binutils did not successfully build the cross assembler, then
|
||||
the new cross gcc (@code{xgcc}) used to build the libraries can not
|
||||
find it. Make sure the build of the binutils succeeded.
|
||||
|
||||
If you include the current directory in your PATH, then there
|
||||
is a chance that the native compiler will accidentally use
|
||||
the new cross assembler instead of the native one. This usually
|
||||
indicates that "." is before the standard system directories
|
||||
in your PATH. As a general rule, including "." in your PATH
|
||||
is a security risk and should be avoided. Remove "." from
|
||||
your PATH.
|
||||
|
||||
NOTE: In some environments, it may be difficult to remove "."
|
||||
completely from your PATH. In this case, make sure that "."
|
||||
is after the system directories containing "as" and "ld".
|
||||
|
||||
@subsection Error Messages Indicating Configuration Problems
|
||||
|
||||
If you see error messages like the following,
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item cannot configure libiberty
|
||||
@item coff-emulation not found
|
||||
@item etc.
|
||||
|
||||
@end itemize
|
||||
|
||||
Then it is likely that one or more of your gnu tools is
|
||||
already configured locally in its source tree. You can check
|
||||
for this by searching for the @code{config.status} file
|
||||
in the various tool source trees. The following command
|
||||
does this for the binutils source:
|
||||
|
||||
@example
|
||||
find @value{BINUTILSUNTAR} -name config.status -print
|
||||
@end example
|
||||
|
||||
The solution for this is to execute the command
|
||||
@code{make distclean} in each of the GNU tools
|
||||
root source directory. This should remove all
|
||||
generated files including Makefiles.
|
||||
|
||||
This situation usually occurs when you have previously
|
||||
built the tool source for some non-RTEMS target. The
|
||||
generated configuration specific files are still in
|
||||
the source tree and the include path specified during
|
||||
the RTEMS build accidentally picks up the previous
|
||||
configuration. The include path used is something like
|
||||
this:
|
||||
|
||||
@example
|
||||
-I../../@value{BINUTILSUNTAR}/gcc -I/@value{BINUTILSUNTAR}/gcc/include -I.
|
||||
@end example
|
||||
|
||||
Note that the tool source directory is searched before the
|
||||
build directory.
|
||||
|
||||
This situation can be avoided entirely by never using
|
||||
the source tree as the build directory -- even for
|
||||
|
||||
@@ -1,235 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Building the GNU Debugger
|
||||
|
||||
GDB is not currently RTEMS aware. The following configurations have been
|
||||
successfully used with RTEMS applications:
|
||||
|
||||
@itemize @bullet
|
||||
@item Sparc Instruction Simulator (SIS)
|
||||
@item PowerPC Instruction Simulator (PSIM)
|
||||
@item DINK32
|
||||
@end itemize
|
||||
|
||||
Other configurations of gdb have successfully been used by RTEMS users
|
||||
but are not documented here.
|
||||
|
||||
@section Unarchive the gdb Distribution
|
||||
|
||||
Use the following commands to unarchive the gdb distribution:
|
||||
|
||||
@example
|
||||
cd tools
|
||||
tar xzf ../archive/@value{GDBTAR}
|
||||
@end example
|
||||
|
||||
The directory @value{GDBUNTAR} is created under the tools directory.
|
||||
|
||||
@c
|
||||
@c GDB GNAT Patch
|
||||
@c
|
||||
|
||||
@section Apply GNAT Patch to GDB
|
||||
|
||||
@ifclear GDB-GNATPATCH
|
||||
No GNAT specific patches are required for @value{GDBVERSION} to
|
||||
support @value{RTEMSVERSION} and @value{GNAT-VERSION}.
|
||||
@end ifclear
|
||||
|
||||
@ifset GDB-GNATPATCH
|
||||
|
||||
Apply the patch using the following command sequence:
|
||||
|
||||
@example
|
||||
cd tools/@value{GDBUNTAR}
|
||||
zcat archive/@value{GDB-GNATPATCH} | patch -p1
|
||||
@end example
|
||||
|
||||
Check to see if any of these patches have been rejected using the following
|
||||
sequence:
|
||||
|
||||
@example
|
||||
cd tools/@value{GDBUNTAR}
|
||||
find . -name "*.rej" -print
|
||||
@end example
|
||||
|
||||
If any files are found with the .rej extension, a patch has been rejected.
|
||||
This should not happen with a good patch file.
|
||||
|
||||
To see the files that have been modified use the sequence:
|
||||
|
||||
@example
|
||||
cd tools/@value{GDBUNTAR}
|
||||
find . -name "*.orig" -print
|
||||
@end example
|
||||
|
||||
The files that are found, have been modified by the patch file.
|
||||
|
||||
@end ifset
|
||||
|
||||
@c
|
||||
@c GDB RTEMS Patch
|
||||
@c
|
||||
|
||||
@section Apply RTEMS Patch to GDB
|
||||
|
||||
@ifclear GDBRTEMSPATCH
|
||||
No RTEMS specific patches are required for @value{GDBVERSION} to
|
||||
support @value{RTEMSVERSION}.
|
||||
@end ifclear
|
||||
|
||||
@ifset GDBRTEMSPATCH
|
||||
|
||||
Apply the patch using the following command sequence:
|
||||
|
||||
@example
|
||||
cd tools/@value{GDBUNTAR}
|
||||
zcat archive/@value{GDBRTEMSPATCH} | patch -p1
|
||||
@end example
|
||||
|
||||
Check to see if any of these patches have been rejected using the following
|
||||
sequence:
|
||||
|
||||
@example
|
||||
cd tools/@value{GDBUNTAR}
|
||||
find . -name "*.rej" -print
|
||||
@end example
|
||||
|
||||
If any files are found with the .rej extension, a patch has been rejected.
|
||||
This should not happen with a good patch file.
|
||||
|
||||
To see the files that have been modified use the sequence:
|
||||
|
||||
@example
|
||||
cd tools/@value{GDBUNTAR}
|
||||
find . -name "*.orig" -print
|
||||
@end example
|
||||
|
||||
The files that are found, have been modified by the patch file.
|
||||
|
||||
@end ifset
|
||||
|
||||
|
||||
@section GDB with Sparc Instruction Simulation (SIS)
|
||||
|
||||
@subheading Make the Build Directory
|
||||
|
||||
Create a build directory for the SIS Debugger
|
||||
|
||||
@example
|
||||
cd tools
|
||||
mkdir build-sis
|
||||
@end example
|
||||
|
||||
@subheading Configure for the Build
|
||||
|
||||
Configure the GNU Debugger for the
|
||||
Sparc Instruction Simulator (SIS):
|
||||
|
||||
@example
|
||||
cd tools/build-sis
|
||||
../@value{GDBUNTAR}/configure --target-sparc-erc32-aout \
|
||||
--program-prefix=sparc-rtems- \
|
||||
--disable-gdbtk \
|
||||
--enable-targets=all \
|
||||
--prefix=<INSTALL_POINT_FOR_SIS>
|
||||
@end example
|
||||
|
||||
Where <INSTALL_POINT_FOR_SIS> is a unique location where the gdb
|
||||
with SIS will be created.
|
||||
|
||||
@subheading Make the Debugger
|
||||
|
||||
From tools/build-sis execute the following command sequence:
|
||||
|
||||
@example
|
||||
make all install
|
||||
@end example
|
||||
|
||||
NOTE: The @code{make} utility used should be GNU make.
|
||||
|
||||
@section GDB with PowerPC Instruction Simulator
|
||||
|
||||
@subheading Make the Build Directory
|
||||
|
||||
Create a build directory for the SIS Debugger
|
||||
|
||||
@example
|
||||
cd tools
|
||||
mkdir build-ppc
|
||||
@end example
|
||||
|
||||
@subheading Configure for the Build
|
||||
|
||||
Configure the GNU Debugger for the PowerPC
|
||||
Instruction Simulator (PSIM):
|
||||
|
||||
@example
|
||||
cd tools/build-ppc
|
||||
../@value{GDBUNTAR}/configure \
|
||||
--target=powerpc-unknown-eabi \
|
||||
--program-prefix=powerpc-rtems- \
|
||||
--enable-sim-powerpc \
|
||||
--enable-sim-timebase \
|
||||
--enable-sim-inline \
|
||||
--enable-sim-hardware \
|
||||
--enable-targets=all \
|
||||
--prefix=<INSTALL_POINT_FOR_PPC>
|
||||
@end example
|
||||
|
||||
Where <INSTALL_POINT_FOR_PPC> is a unique location where the gdb
|
||||
with PSIM will be created.
|
||||
|
||||
|
||||
@subheading Make the Debugger
|
||||
|
||||
From tools/build-ppc execute the following command sequence:
|
||||
|
||||
@example
|
||||
make all install
|
||||
@end example
|
||||
|
||||
NOTE: The @code{make} utility used should be GNU make.
|
||||
|
||||
@section GDB for DINK32
|
||||
|
||||
@subheading Make the Build Directory
|
||||
|
||||
Create a build directory for the DINK32 Debugger
|
||||
|
||||
@example
|
||||
cd tools
|
||||
mkdir build-dink32
|
||||
@end example
|
||||
|
||||
@subheading Configure for the Build
|
||||
|
||||
Configure the GNU Debugger to communicate with
|
||||
the DINK32 ROM monitor:
|
||||
|
||||
@example
|
||||
cd tools/build-dink32
|
||||
../@value{GDBUNTAR}/configure --target-powerpc-elf \
|
||||
--program-prefix=powerpc-rtems- \
|
||||
--enable-targets=all \
|
||||
--prefix=<INSTALL_POINT_FOR_DINK32>
|
||||
@end example
|
||||
|
||||
Where <INSTALL_POINT_FOR_DINK32> is a unique location where the
|
||||
gdb Dink32 will be created.
|
||||
|
||||
@subheading Make the Debugger
|
||||
|
||||
From tools/build-dink32 execute the following command sequence:
|
||||
|
||||
@example
|
||||
make all install
|
||||
@end example
|
||||
|
||||
NOTE: The @code{make} utility used should be GNU make.
|
||||
@@ -1,162 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Introduction
|
||||
|
||||
The purpose of this document is to guide you through the process of
|
||||
installing a GNU cross development environment to use with RTEMS.
|
||||
|
||||
If you are already familiar with the concepts behind a cross compiler and
|
||||
have a background in Unix, these instructions should provide the bare
|
||||
essentials for performing a setup of the following items:
|
||||
|
||||
@itemize @bullet
|
||||
@item GNAT/RTEMS Cross Compilation Tools on your host system
|
||||
@item RTEMS OS for the target host
|
||||
@item GDB Debugger
|
||||
@end itemize
|
||||
|
||||
The remainder of this chapter provides background information on real-time
|
||||
embedded systems and cross development and an overview of other
|
||||
resources of interest on the Internet. If you are not familiar with
|
||||
real-time embedded systems or the other areas, please read those sections.
|
||||
These sections will help familiarize you with the
|
||||
types of systems RTEMS is designed to be used in and the cross development
|
||||
process used when developing RTEMS applications.
|
||||
|
||||
@section Real-Time Embedded Systems
|
||||
|
||||
Real-time embedded systems are found in practically every facet of our
|
||||
everyday lives. Today's systems range from the common telephone, automobile
|
||||
control systems, and kitchen appliances to complex air traffic control
|
||||
systems, military weapon systems, an d production line control including
|
||||
robotics and automation. However, in the current climate of rapidly changing
|
||||
technology, it is difficult to reach a consensus on the definition of a
|
||||
real-time embedded system. Hardware costs are continuing to rapidly decline
|
||||
while at the same time the hardware is increasing in power and functionality.
|
||||
As a result, embedded systems that were not considered viable two years ago
|
||||
are suddenly a cost effective solution. In this domain, it is not uncommon
|
||||
for a single hardware configuration to employ a variety of architectures and
|
||||
technologies. Therefore, we shall define an embedded system as any computer
|
||||
system that is built into a larger system consisting of multiple technologies
|
||||
such as digital and analog electronics, mechanical devices, and sensors.
|
||||
|
||||
Even as hardware platforms become more powerful, most embedded systems are
|
||||
critically dependent on the real-time software embedded in the systems
|
||||
themselves. Regardless of how efficiently the hardware operates, the
|
||||
performance of the embedded real-time software determines the success of the
|
||||
system. As the complexity of the embedded hardware platform grows, so does
|
||||
the size and complexity of the embedded software. Software systems must
|
||||
routinely perform activities which were only dreamed of a short time ago.
|
||||
These large, complex, real-time embedded applications now commonly contain
|
||||
one million lines of code or more.
|
||||
|
||||
Real-time embedded systems have a complex set of characteristics that
|
||||
distinguish them from other software applications. Real-time embedded
|
||||
systems are driven by and must respond to real world events while adhering to
|
||||
rigorous requirements imposed by the environment with which they interact.
|
||||
The correctness of the system depends not only on the results of
|
||||
computations, but also on the time at which the results are produced. The
|
||||
most important and complex characteristic of real-time application systems is
|
||||
that they must receive and respond to a set of external stimuli within rigid
|
||||
and critical time constraints.
|
||||
|
||||
A single real-time application can be composed of both soft and hard
|
||||
real-time components. A typical example of a hard real-time system is a
|
||||
nuclear reactor control system that must not only detect failures, but must
|
||||
also respond quickly enough to prevent a meltdown. This application also has
|
||||
soft real-time requirements because it may involve a man-machine interface.
|
||||
Providing an interactive input to the control system is not as critical as
|
||||
setting off an alarm to indicate a failure condition. However, th e
|
||||
interactive system component must respond within an acceptable time limit to
|
||||
allow the operator to interact efficiently with the control system.
|
||||
|
||||
@section Cross Development
|
||||
|
||||
Today almost all real-time embedded software systems are developed in a
|
||||
@b{cross development} environment using cross development tools. In the cross
|
||||
development environment, software development activities are typically
|
||||
performed on one computer system, the @b{host} system, while the result of the
|
||||
development effort (produced by the cross tools) is a software system that
|
||||
executes on the @b{target} platform. The requirements for the target platform are
|
||||
usually incompatible and quite often in direct conflict with the requirements
|
||||
for the host. Moreover, the target hardware is often custom designed for a
|
||||
particular project. This means that the cross development toolset must allow
|
||||
the developer to customize the tools to address target specific run-time
|
||||
issues. The toolset must have provisions for board dependent initialization
|
||||
code, device drivers, and error handling code.
|
||||
|
||||
The host computer is optimized to support the code development cycle with
|
||||
support for code editors, compilers, and linkers requiring large disk drives,
|
||||
user development windows, and multiple developer connections. Thus the host
|
||||
computer is typically a traditional UNIX workstation such as are available
|
||||
from SUN or Silicon Graphics, or a PC running either a version of MS-Windows
|
||||
or UNIX. The host system may also be required to execute office productivity
|
||||
applications to allow the software developer to write documentation, make
|
||||
presentations, or track the project's progress using a project management
|
||||
tool. This necessitates that the host computer be general purpose with
|
||||
resources such as a thirty-two or sixty-four bit processor, large amounts of
|
||||
RAM, a monitor, mouse, keyboard, hard and floppy disk drives, CD-ROM drive,
|
||||
and a graphics card. It is likely that the system will be multimedia capable
|
||||
and have some networking capability.
|
||||
|
||||
Conversely, the target platform generally has limited traditional computer
|
||||
resources. The hardware is designed for the particular functionality and
|
||||
requirements of the embedded system and optimized to perform those tasks
|
||||
effectively. Instead of hard driverss and keyboards, it is composed of
|
||||
sensors, relays, and stepper motors. The per-unit cost of the target platform
|
||||
is typically a critical concern. No hardware component is included without
|
||||
being cost justified. As a result, the processor of the target system is
|
||||
often from a different processor family than that of the host system and
|
||||
usually has lower performance. In addition to the processor families
|
||||
targeted only for use in embedded systems, there are versions of nearly every
|
||||
general-purpose process or specifically tailored for real-time embedded
|
||||
systems. For example, many of the processors targeting the embedded market
|
||||
do not include hardware floating point units, but do include peripherals such
|
||||
as timers, serial controllers, or network interfaces.
|
||||
|
||||
@section Resources on the Internet
|
||||
|
||||
This section describes various resources on the Internet which are of
|
||||
use to GNAT/RTEMS users.
|
||||
|
||||
@subsection RTEMS Mailing List
|
||||
|
||||
rtems-users@@rtems.com
|
||||
|
||||
This mailing list is dedicated to the discussion of issues related
|
||||
to RTEMS, including GNAT/RTEMS. If you have questions about RTEMS,
|
||||
wish to make suggestions, or just want to pick up hints, this is a
|
||||
good list to subscribe to. Subscribe by sending an empty mail
|
||||
message to rtems-users-subscribe@@rtems.com. Messages sent
|
||||
to rtems-users@@rtems.com are posted to the list.
|
||||
|
||||
@subsection CrossGCC Mailing List
|
||||
|
||||
crossgcc@@cygnus.com
|
||||
|
||||
This mailing list is dedicated to the use of the GNU tools in
|
||||
cross development environments. Most of the discussions
|
||||
focus on embedded issues. Subscribe by sending a message with
|
||||
the one line "subscribe" to crossgcc-request@@cygnus.com.
|
||||
|
||||
The crossgcc FAQ as well as a number of patches and utiliities
|
||||
of interest to cross development system users are available
|
||||
at ftp://ftp.cygnus.com/pub/embedded/crossgcc.
|
||||
|
||||
@subsection GNAT Chat Mailing List
|
||||
|
||||
chat@@gnat.com
|
||||
|
||||
This mailing list is dedicated to the general discussion
|
||||
of GNAT specific issues. The discussions try to avoid
|
||||
more general Ada95 language issues which have other
|
||||
forums. Subscribe by sending a message with
|
||||
the one line "subscribe" to chat-request@@gnat.com.
|
||||
|
||||
|
||||
@@ -1,122 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Requirements
|
||||
|
||||
A fairly large amount of disk space is required to perform the build of the
|
||||
GNU C/C++ Cross Compiler Tools for RTEMS. The following table may help in
|
||||
assessing the amount of disk space required for your installation:
|
||||
|
||||
@example
|
||||
+------------------------------------+--------------------------+
|
||||
| Component | Disk Space Required |
|
||||
+------------------------------------+--------------------------+
|
||||
| archive directory | 40 Mbytes |
|
||||
| tools src unarchived | 200 Mbytes |
|
||||
| each individual build directory | up to 500 Mbytes |
|
||||
| each installation directory | 20-200 Mbytes |
|
||||
+------------------------------------+--------------------------+
|
||||
@end example
|
||||
|
||||
It is important to understand that the above requirements only address
|
||||
the GNU C/C++ Cross Compiler Tools themselves. Adding additional
|
||||
languages such as Fortran or Objective-C can increase the size
|
||||
of the build and installation directories. Also, the unarchived
|
||||
source and build directories can be removed after the tools are
|
||||
installed.
|
||||
|
||||
After the tools themselves are installed, RTEMS must be built
|
||||
and installed for each Board Support Package that you wish
|
||||
to use. Thus the precise amount of disk space required
|
||||
for each installation directory depends highly on the number
|
||||
of RTEMS BSPs which are to be installed. If a single BSP is
|
||||
installed, then the additional size of each install directory
|
||||
will tend to be in the 40-60 Mbyte range.
|
||||
|
||||
There are a number of factors which must be taken into
|
||||
account in oreder to estimate the amount of disk space required
|
||||
to build RTEMS itself. Attempting to build multiple BSPs in
|
||||
a single step increases the disk space requirements. Similarly
|
||||
enabling optional features increases the build and install
|
||||
space requirements. In particular, enabling and building
|
||||
the RTEMS tests results in a significant increase in build
|
||||
space requirements but since the test are not installed has
|
||||
no impact on installation requirements.
|
||||
|
||||
The instructions in this manual should work on any computer running
|
||||
a UNIX variant. Some native GNU tools are used by this procedure
|
||||
including:
|
||||
|
||||
@itemize @bullet
|
||||
@item GCC
|
||||
@item GNAT
|
||||
@item GNU make
|
||||
@end itemize
|
||||
|
||||
In addition, some native utilities may be deficient for building
|
||||
the GNU tools.
|
||||
|
||||
@section Native GNAT
|
||||
|
||||
The native GNAT must be installed in the default location or built
|
||||
from source. No GCC or GNAT environment variables should be set during
|
||||
the build or use of the cross GNAT/RTEMS toolset as this could result in
|
||||
an unpredictable mix of native and cross toolsets.
|
||||
|
||||
Binaries for native GNAT installations are available at the primary
|
||||
GNAT ftp site (@value{GNAT-FTP}. Installation instructions are
|
||||
included with the binary GNAT distributions. The binary installation
|
||||
should be installed in the default location or installed in a
|
||||
non-default location and used ONLY to build a native GNAT from source.
|
||||
This final native GNAT will be used to build the GNAT/RTEMS cross
|
||||
development toolset.
|
||||
|
||||
@subsection Verifying Correct Operation of Native GNAT
|
||||
|
||||
It is imperative that the native GNAT installation work correctly for
|
||||
the installation of GNAT/RTEMS to succeed. It is recommended that the
|
||||
user verify that the native GNAT is installed correctly by performing
|
||||
these tests:
|
||||
|
||||
@subsubsection Native Hello World Test
|
||||
|
||||
Place the following Ada source code in hello.adb:
|
||||
|
||||
@example
|
||||
with Text_IO; use Text_IO;
|
||||
|
||||
procedure Hello is
|
||||
begin
|
||||
Put_Line ( "Hello World");
|
||||
end Hello;
|
||||
@end example
|
||||
|
||||
Use the following command sequence to ompile and execute the above program:
|
||||
|
||||
@example
|
||||
gnatmake hello
|
||||
./hello
|
||||
@end example
|
||||
|
||||
If the message @code{Hello World} is printed, then the native installation
|
||||
of GNAT operates well enough to proceed.
|
||||
|
||||
@subsubsection Insure GCC and GNAT Environment Variables Are Not Set
|
||||
|
||||
If any of the following commands produce output, then you have
|
||||
environment variables overriding the default behavior of the
|
||||
native GNAT toolset. These variables will conflict with the cross
|
||||
toolset. Please resolve this problem before proceeding further.
|
||||
|
||||
@example
|
||||
echo $GCC_EXEC_PREFIX
|
||||
echo $ADA_INCLUDE_PATH
|
||||
echo $ADA_OBJECTS_PATH
|
||||
echo $LD_RUN_PATH
|
||||
echo $C_INCLUDE_PATH
|
||||
@end example
|
||||
@@ -1,57 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Building the Sample Application
|
||||
|
||||
@section Unpack the Sample Application
|
||||
|
||||
Use the following command to unarchive the sample application:
|
||||
|
||||
@example
|
||||
cd tools
|
||||
tar xzf ../archive/hello_world_ada.tgz
|
||||
@end example
|
||||
|
||||
@section Create a BSP Specific Makefile
|
||||
|
||||
Provided are example Makefiles for multiple BSPs. Copy one of these to
|
||||
the file Makefile.<BOARD_SUPPORT_PACKAGE> and edit it as appropriate for
|
||||
your local configuration.
|
||||
|
||||
Use the <INSTALLATION_POINT> and <BOARD_SUPPORT_PACKAGE> specified when
|
||||
configuring and installing RTEMS.
|
||||
|
||||
@section Build the Sample Application
|
||||
|
||||
Use the following command to start the build of the sample application:
|
||||
|
||||
@example
|
||||
cd tools/hello_world_ada
|
||||
make -f Makefile.<BOARD_SUPPORT_PACKAGE>
|
||||
@end example
|
||||
|
||||
NOTE: GNU make is the preferred @code{make} utility. Other @code{make}
|
||||
implementations may work but all testing is done with GNU make.
|
||||
|
||||
If the BSP specific modifications to the Makefile were correct and
|
||||
no errors are detected during the sample application build, it is
|
||||
reasonable to assume that the build of the GNAT/RTEMS Cross Compiler Tools
|
||||
for RTEMS and RTEMS itself for the selected host and target
|
||||
combination was done properly.
|
||||
|
||||
@section Application Executable
|
||||
|
||||
If the sample application has successfully been build, then the application
|
||||
executable is placed in the following directory:
|
||||
|
||||
@example
|
||||
tools/hello_world_ada/o-optimize/<filename>.exe
|
||||
@end example
|
||||
|
||||
How this executable is downloaded to the target board is very dependent
|
||||
on the BOARD_SUPPORT_PACKAGE selected.
|
||||
@@ -1,110 +0,0 @@
|
||||
\input texinfo @c -*-texinfo-*-
|
||||
@c %**start of header
|
||||
@setfilename started_ada.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 Getting Started (C) Guide
|
||||
@c
|
||||
|
||||
@include version.texi
|
||||
@include common/setup.texi
|
||||
@include common/rtems.texi
|
||||
|
||||
@c
|
||||
@c Now set all the tool version dependent information
|
||||
@c
|
||||
@include tversions.texi
|
||||
|
||||
@ifset use-ascii
|
||||
@dircategory RTEMS On-Line Manual
|
||||
@direntry
|
||||
* Getting Started with GNAT/RTEMS: (started_ada)
|
||||
@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 Getting Started with RTEMS
|
||||
|
||||
@setchapternewpage odd
|
||||
@settitle Getting Started with GNAT/RTEMS
|
||||
@titlepage
|
||||
@finalout
|
||||
|
||||
@title Getting Started with GNAT/RTEMS
|
||||
@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.
|
||||
|
||||
@contents
|
||||
|
||||
@include intro.texi
|
||||
@include require.texi
|
||||
@include buildada.texi
|
||||
@include buildrt.texi
|
||||
@include sample.texi
|
||||
@include gdb.texi
|
||||
|
||||
@ifinfo
|
||||
@node Top, Introduction, (dir), (dir)
|
||||
@top started_ada
|
||||
|
||||
This is the online version of the Getting Started with GNAT/RTEMS.
|
||||
|
||||
@menu
|
||||
* Introduction::
|
||||
* Requirements::
|
||||
* Building the GNAT Cross Compiler Toolset::
|
||||
* Building RTEMS::
|
||||
* Building the Sample Application::
|
||||
* Building the GNU Debugger::
|
||||
@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, GDB for DINK32, 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
|
||||
|
||||
@bye
|
||||
|
||||
@@ -1,86 +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 This file contains all toolset version dependent information
|
||||
@c
|
||||
|
||||
@c
|
||||
@c Comment out setting the "XYZ-RTEMSPATCH" variable if there is no
|
||||
@c patch required. The documentation will detect this and print
|
||||
@c an appropriate message in a short section.
|
||||
@c
|
||||
|
||||
|
||||
@c
|
||||
@c GCC Version
|
||||
@c
|
||||
|
||||
@set GCCVERSION gcc 2.8.1
|
||||
@set GCCTAR gcc-2.8.1.tar.gz
|
||||
@set GCCUNTAR gcc-2.8.1
|
||||
@set GCCFTPSITE ftp.gnu.org
|
||||
@set GCCFTPDIR /pub/gnu/gcc
|
||||
@set GCCRTEMSPATCH gcc-2.8.1-rtems-gnat-3.13p-20000429.diff.gz
|
||||
|
||||
@c
|
||||
@c GNAT Version
|
||||
@c
|
||||
|
||||
@set GNAT-VERSION gnat 3.13p
|
||||
@set GNAT-TAR gnat-3.13p-src.tar.gz
|
||||
@set GNAT-UNTAR gnat-3.13p-src
|
||||
@set GNAT-FTPSITE NONE
|
||||
@set GNAT-FTPDIR NO_DIRECTORY
|
||||
@set GNAT-RTEMSPATCH gnat-3.13p-rtems-20000829.diff
|
||||
|
||||
@c
|
||||
@c BINUTILS Version
|
||||
@c
|
||||
|
||||
@c The "official" binutils
|
||||
@set BINUTILSVERSION binutils 2.10
|
||||
@set BINUTILSTAR binutils-2.10.tar.gz
|
||||
@set BINUTILSUNTAR binutils-2.10
|
||||
@set BINUTILSFTPSITE ftp.gnu.org
|
||||
@set BINUTILSFTPDIR /pub/gnu/binutils
|
||||
@set BINUTILSRTEMSPATCH binutils-2.10-rtems-gnat-3.13p-20001107.diff
|
||||
|
||||
@c
|
||||
@c NEWLIB Version
|
||||
@c
|
||||
|
||||
@set NEWLIBVERSION newlib 1.8.2
|
||||
@set NEWLIBTAR newlib-1.8.2.tar.gz
|
||||
@set NEWLIBUNTAR newlib-1.8.2
|
||||
@set NEWLIBFTPSITE sources.redhat.com
|
||||
@set NEWLIBFTPDIR /pub/newlib
|
||||
@set NEWLIBRTEMSPATCH newlib-1.8.2-rtems-20000606.diff.gz
|
||||
|
||||
@c
|
||||
@c GDB Version
|
||||
@c
|
||||
|
||||
@set GDBVERSION gdb 4.17
|
||||
@set GDBTAR gdb-4.17.tar.gz
|
||||
@set GDBUNTAR gdb-4.17
|
||||
@set GDBFTPSITE ftp.gnu.org
|
||||
@set GDBFTPDIR /pub/gnu/gdb/
|
||||
@set GDBRTEMSPATCH gdb-4.17-rtems-gnat-3.13p-20000918.diff
|
||||
@c @set GDB-GNATPATCH gdb-ada-patch-1.17.8.gz
|
||||
|
||||
@c
|
||||
@c RTEMS Version
|
||||
@c
|
||||
|
||||
@set RTEMSVERSION RTEMS Snapshot
|
||||
@set RTEMSTAR rtems-ss-DATE.tgz
|
||||
@set RTEMSUNTAR rtems-DATE
|
||||
@set RTEMSFTPSITE ftp.rtems.com
|
||||
@set RTEMSFTPDIR /pub/rtems/snapshots/current
|
||||
|
||||
Reference in New Issue
Block a user