summaryrefslogtreecommitdiffstats
path: root/doc/started
diff options
context:
space:
mode:
Diffstat (limited to 'doc/started')
-rw-r--r--doc/started/Makefile.am17
-rw-r--r--doc/started/binaries.t108
-rw-r--r--doc/started/buildc.t937
-rw-r--r--doc/started/buildrt.t267
-rw-r--r--doc/started/gdb.t270
-rw-r--r--doc/started/intro.t95
-rw-r--r--doc/started/nextstep.t12
-rw-r--r--doc/started/nt.t139
-rw-r--r--doc/started/require.t158
-rw-r--r--doc/started/sample.t83
-rw-r--r--doc/started/stamp-vti4
-rw-r--r--doc/started/started.texi5
-rw-r--r--doc/started/tversions.texi58
-rw-r--r--doc/started/version.texi4
14 files changed, 1580 insertions, 577 deletions
diff --git a/doc/started/Makefile.am b/doc/started/Makefile.am
index 41e1141390..ba307bd9fe 100644
--- a/doc/started/Makefile.am
+++ b/doc/started/Makefile.am
@@ -1,5 +1,5 @@
#
-# COPYRIGHT (c) 1988-1999.
+# COPYRIGHT (c) 1988-2002.
# On-Line Applications Research Corporation (OAR).
# All rights reserved.
#
@@ -15,7 +15,7 @@ SUBDIRS = pictures
include $(top_srcdir)/project.am
-GENERATED_FILES = binaries.texi buildc.texi buildrt.texi gdb.texi intro.texi \
+GENERATED_FILES = binaries.texi buildc.texi buildrt.texi intro.texi \
nt.texi require.texi nextstep.texi sample.texi
COMMON_FILES = $(top_srcdir)/common/setup.texi \
@@ -37,12 +37,12 @@ $(srcdir)/require.texi: require.t tversions.texi
-n "Prebuilt Toolset Executables" < $< > $@
$(srcdir)/binaries.texi: binaries.t tversions.texi
- $(BMENU2) -c -p "GNU makeinfo Version Requirements" \
+ $(BMENU2) -c -p "Archive and Build Directory Format" \
-u "Top" \
-n "Building the GNU C/C++ Cross Compiler Toolset" < $< > $@
$(srcdir)/buildc.texi: buildc.t tversions.texi
- $(BMENU2) -c -p "Removing RPMs" \
+ $(BMENU2) -c -p "Removing Zipped Tar Files" \
-u "Top" \
-n "Building RTEMS" < $< > $@
@@ -52,17 +52,12 @@ $(srcdir)/buildrt.texi: buildrt.t tversions.texi
-n "Building the Sample Application" < $< > $@
$(srcdir)/sample.texi: sample.t tversions.texi
- $(BMENU2) -c -p "Using the RTEMS configure Script Directly" \
- -u "Top" \
- -n "Building the GNU Debugger" < $< > $@
-
-$(srcdir)/gdb.texi: gdb.t tversions.texi
- $(BMENU2) -c -p "More Information on RTEMS Application Makefiles" \
+ $(BMENU2) -c -p "Using the bit_rtems Script" \
-u "Top" \
-n "Where To Go From Here" < $< > $@
$(srcdir)/nextstep.texi: nextstep.t tversions.texi
- $(BMENU2) -c -p "GDB for DINK32" \
+ $(BMENU2) -c -p "More Information on RTEMS Application Makefiles" \
-u "Top" \
-n "Using MS-Windows as a Development Host" < $< > $@
diff --git a/doc/started/binaries.t b/doc/started/binaries.t
index 0eab5cc0e0..283a49b3ce 100644
--- a/doc/started/binaries.t
+++ b/doc/started/binaries.t
@@ -1,5 +1,5 @@
@c
-@c COPYRIGHT (c) 1988-1999.
+@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@@ -8,33 +8,51 @@
@chapter Prebuilt Toolset Executables
-Precompiled toolsets are available for Linux and Cygwin. These are
-packaged using the RedHat Package Manager (RPM). RPM is the
+Precompiled toolsets are available for Linux, Cygwin, FreeBSD,
+and Solaris. These are packaged in the following formats:
+
+@itemize @bullet
+@item Linux - RPM and Debian
+@item Cygwin - RPM and zipped tar
+@item FreeBSD - native package
+@item Solaris - RPM and zipped tar
+@end itemize
+
+RPM is an acronym for the RedHat Package Manager. RPM is the
native package installer for many Linux distributions including
-RedHat and SUSE. RPM supports other operating systems including
-Cygwin. David Fiddes <D.J@@fiddes.surfaid.org> has graciously
-build Cygwin RPMs for a number of popular target CPU families.
+RedHat and SuSE. RPM supports other operating systems including
+Cygwin. @uref{mailto:D.J@@fiddes.surfaid.org,David Fiddes <D.J@@fiddes.surfaid.org>}
+did the initial groundwork that lead to Cygwin RPMs being available.
-RPMs are very easy to install and the instructions are the same
-regardless of the host environment. There are a few structural
-issues with the packaging of the RTEMS Cross Toolset RPMs
-that you need to be aware of.
+The prebuilt binaries are intended to be easy to install and
+the instructions are similar regardless of the host environment.
+There are a few structural issues with the packaging of the RTEMS
+Cross Toolset binaries that you need to be aware of.
@enumerate
@item There are dependencies between the various packages.
This requires that certain packages be installed before others may be.
+Some packaging formats enforce this dependency.
-@item Some packages are target CPU family indepedent and shared
+@item Some packages are target CPU family independent and shared
across all target architectures. These are referred to as
"base" packages.
@item If buildable for a particular CPU, RPMs are provided for
Chill, Java (gcj), Fortran (g77), and Objective-C (objc). These
-RPMs are strictly optional.
+binaries are strictly optional.
@end enumerate
-@section Installing RPMs
+NOTE: Installing toolset binaries does not install RTEMS itself, only the tools
+required to build RTEMS. See @ref{Building RTEMS} for the next
+step in the process.
+
+@section RPMs
+
+This section provides information on installing and removing RPMs.
+
+@subsection Installing RPMs
The following is a sample session illustrating the installation
of a C/C++ toolset targeting the SPARC architecture.
@@ -42,23 +60,31 @@ of a C/C++ toolset targeting the SPARC architecture.
@example
rpm -i rtems-base-binutils-2.9.5.0.24-1.i386.rpm
rpm -i sparc-rtems-binutils-2.9.5.0.24-1.i386.rpm
-rpm -i rtems-base-gcc-gcc2.95.2newlib1.8.2-4.i386.rpm
-rpm -i sparc-rtems-gcc-gcc2.95.2newlib1.8.2-4.i386.rpm
-rpm -i rtems-base-gdb-4.18-2.i386.rpm
-rpm -i sparc-rtems-gdb-4.18-2.i386.rpm
+rpm -i rtems-base-gcc-gcc2.95.2newlib1.8.2-7.i386.rpm
+rpm -i sparc-rtems-gcc-gcc2.95.2newlib1.8.2-7.i386.rpm
+rpm -i rtems-base-gdb-4.18-4.i386.rpm
+rpm -i sparc-rtems-gdb-4.18-4.i386.rpm
@end example
Upon successful completion of the above command sequence, a
-C/C++ cross development toolset targetting the SPARC is
+C/C++ cross development toolset targeting the SPARC is
installed in @code{/opt/rtems}. In order to use this toolset,
the directory @code{/opt/rtems/bin} must be included in your
PATH.
-NOTE: This process does not install RTEMS itself, only the tools
-required to build RTEMS. See @ref{Building RTEMS} for the next
-step in the process.
+Once you have successfully installed the RPMs for BINUTILS, GCC,
+NEWLIB, and GDB, then you may proceed directly to @ref{Building RTEMS}.
+
+@subsection Determining Which RTEMS RPMs are Installed
-@section Removing RPMs
+The following command will report which RTEMS RPMs are currently
+installed:
+
+@example
+rpm -q -g rtems
+@end example
+
+@subsection Removing RPMs
The following is a sample session illustrating the removal
of a C/C++ toolset targeting the SPARC architecture.
@@ -72,3 +98,41 @@ rpm -e sparc-rtems-binutils-2.9.5.0.24-1.i386.rpm
rpm -e rtems-base-binutils-2.9.5.0.24-1.i386.rpm
@end example
+NOTE: If you have installed any RTEMS BSPs, then it is likely that
+RPM will complain about not being able to remove everything.
+
+@section Zipped Tar Files
+
+This section provides information on installing and removing
+Zipped Tar Files (.tgz).
+
+@subsection Installing Zipped Tar Files
+
+The following is a sample session illustrating the installation
+of a C/C++ toolset targeting the SPARC architecture assuming
+that GNU tar is installed as @code{tar}:
+
+@example
+cd /
+tar xzf rtems-base-binutils-2.9.5.0.24-1.tgz
+tar xzf sparc-rtems-binutils-2.9.5.0.24-1.tgz
+tar xzf rtems-base-gcc-gcc2.95.2newlib1.8.2-4.tgz
+tar xzf sparc-rtems-gcc-gcc2.95.2newlib1.8.2-4.tgz
+tar xzf rtems-base-gdb-4.18-2.tgz
+tar xzf sparc-rtems-gdb-4.18-2.tgz
+@end example
+
+Upon successful completion of the above command sequence, a
+C/C++ cross development toolset targeting the SPARC is
+installed in @code{/opt/rtems}. In order to use this toolset,
+the directory @code{/opt/rtems/bin} must be included in your
+PATH.
+
+@subsection Removing Zipped Tar Files
+
+There is no automatic way to remove the contents of a @code{tgz} once
+it is installed. The contents of the directory @code{/opt/rtems}
+can be removed but this will likely result in other packages
+being removed as well.
+
+
diff --git a/doc/started/buildc.t b/doc/started/buildc.t
index 24e4b30ac0..3e714e77e5 100644
--- a/doc/started/buildc.t
+++ b/doc/started/buildc.t
@@ -1,5 +1,5 @@
@c
-@c COPYRIGHT (c) 1988-1999.
+@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@@ -8,6 +8,14 @@
@chapter Building the GNU C/C++ Cross Compiler Toolset
+NOTE: This chapter does @b{NOT} apply if you installed
+prebuilt toolset executables for BINUTILS, GCC, NEWLIB,
+and GDB. If you installed prebuilt executables for all
+of those, proceed to @ref{Building RTEMS}. If you require
+a GDB with a special configuration to connect to your
+target board, then proceed to @ref{Building the GNU Debugger GDB}
+for some advice.
+
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
@@ -17,43 +25,34 @@ It is recommended that when toolset binaries are available for
your particular host, that they be used. Prebuilt binaries
are much easier to install.
-@section Create the Archive and Build Directories
+@c
+@c Building BINUTILS GCC and NEWLIB
+@c
+@section Building BINUTILS GCC and NEWLIB
-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:
+NOTE: This step is NOT required if prebuilt executables for
+BINUTILS, GCC, and NEWLIB were installed.
-@example
-mkdir archive
-mkdir tools
-@end example
-
-This will result in an initial directory structure similar to the
-one shown in the following figure:
+This section describes the process of building BINUTILS, GCC, and
+NEWLIB using a variety of methods. Included is information on
+obtaining the source code and patches, applying patches, and
+building and installing the tools using multiple methods.
-@example
-@group
-/whatever/prefix/you/choose/
- archive/
- tools/
-
-@end group
-@end example
+@c
+@c Obtain Source and Patches for BINUTILS GCC and NEWLIB
+@c
-@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
+@subsection Obtain Source and Patches for BINUTILS GCC and NEWLIB
-@section Get All the Pieces
+NOTE: This step is required for all methods of building BINUTILS,
+GCC, and NEWLIB.
-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.
+This section lists the components required to build BINUTILS, GCC,
+and NEWLIB from source to target RTEMS. These files should be
+placed in your @code{archive} directory. Included are the locations
+of each component as well as any required RTEMS specific patches.
+@need 1000
@subheading @value{GCC-VERSION}
@example
FTP Site: @value{GCC-FTPSITE}
@@ -65,6 +64,7 @@ specific patches.
@end ifset
@end example
+@need 1000
@subheading @value{BINUTILS-VERSION}
@example
FTP Site: @value{BINUTILS-FTPSITE}
@@ -76,6 +76,7 @@ specific patches.
@end ifset
@end example
+@need 1000
@subheading @value{NEWLIB-VERSION}
@example
FTP Site: @value{NEWLIB-FTPSITE}
@@ -87,28 +88,7 @@ specific patches.
@end ifset
@end example
-@subheading @value{RTEMS-VERSION}
-@example
- FTP Site: @value{RTEMS-FTPSITE}
- Directory: @value{RTEMS-FTPDIR}
- File: @value{RTEMS-TAR}
-@ifset use-html
-@c URL: @uref{ftp://@value{RTEMS-FTPSITE}@value{RTEMS-FTPDIR}, Download RTEMS components}
- URL: ftp://@value{RTEMS-FTPSITE}@value{RTEMS-FTPDIR}
-@end ifset
-@end example
-
-@subheading RTEMS Hello World
-@example
- FTP Site: @value{RTEMS-FTPSITE}
- Directory: @value{RTEMS-FTPDIR}
- File: hello_world_c.tgz
-@ifset use-html
-@c URL: @uref{ftp://@value{RTEMS-FTPSITE}@value{RTEMS-FTPDIR}/hello_world_c.tgz, Download RTEMS Hello World}
- URL: ftp://@value{RTEMS-FTPSITE}@value{RTEMS-FTPDIR}/hello_world_c.tgz
-@end ifset
-@end example
-
+@need 1000
@subheading RTEMS Specific Tool Patches and Scripts
@example
FTP Site: @value{RTEMS-FTPSITE}
@@ -129,7 +109,15 @@ specific patches.
@end ifset
@end example
-@section Unarchiving the Tools
+@c
+@c Unarchiving the Tools
+@c
+@subsection Unarchiving the Tools
+
+NOTE: This step is required if building BINUTILS, GCC, and NEWLIB
+using the procedures described in @ref{Using configure and make}
+or @ref{Using the bit Script}. It is @b{NOT} required if using the procedure
+described in @ref{Using RPM to Build BINUTILS GCC and NEWLIB}.
While in the @code{tools} directory, unpack the compressed
tar files using the following command sequence:
@@ -139,7 +127,6 @@ cd tools
tar xzf ../archive/@value{GCC-TAR}
tar xzf ../archive/@value{BINUTILS-TAR}
tar xzf ../archive/@value{NEWLIB-TAR}
-tar xzf ../archive/@value{BUILDTOOLS-TAR}
@end example
After the compressed tar files have been unpacked, the following
@@ -151,29 +138,6 @@ directories will have been created under tools.
@item @value{NEWLIB-UNTAR}
@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
-@item bit_gdb
-@item bit_rtems
-@item common.sh
-@item user.cfg
-@end itemize
-
-When the @code{bit} script is executed later in this process,
-it will automatically create this subdirectory:
-
-@itemize @bullet
-@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 tree should look something like the following figure:
@example
@@ -183,8 +147,6 @@ The tree should look something like the following figure:
@value{GCC-TAR}
@value{BINUTILS-TAR}
@value{NEWLIB-TAR}
- @value{RTEMS-TAR}
- @value{BUILDTOOLS-TAR}
@ifset GCC-RTEMSPATCH
@value{GCC-RTEMSPATCH}
@end ifset
@@ -194,21 +156,13 @@ The tree should look something like the following figure:
@ifset NEWLIB-RTEMSPATCH
@value{NEWLIB-RTEMSPATCH}
@end ifset
- hello_world_c.tgz
- bit
tools/
@value{BINUTILS-UNTAR}/
@value{GCC-UNTAR}/
@value{NEWLIB-UNTAR}/
- bit
- bit_gdb
- bit_rtems
- common.sh
- user.cfg
@end group
@end example
-
@c @ifset use-html
@c @html
@c <IMG SRC="bit_c.jpg" WIDTH=816 HEIGHT=267 ALT="Directory Organization">
@@ -216,63 +170,24 @@ The tree should look something like the following figure:
@c @end ifset
@c
-@c Host Specific Notes
+@c Applying RTEMS Patches
@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}, @code{bit_gdb}, and @code{bit_rtems} to use the
-@code{/bin/ksh} shell instead.
+@subsection Applying RTEMS Patches
-@subsection Linux
+NOTE: This step is required if building BINUTILS, GCC, and NEWLIB
+using the procedures described in @ref{Using configure and make}
+or @ref{Using the bit Script}. It is @b{NOT} required if using the procedure
+described in @ref{Using RPM to Build BINUTILS GCC and NEWLIB}.
-@subsubsection Broken install Program
-
-Certain versions of GNU fileutils include a version of @code{install} which
-does not work properly. Please perform the following test to see if you
-need to upgrade:
-
-@example
-install -c -d /tmp/foo/bar
-@end example
-
-If this does not create the specified directories your install
-program will not install RTEMS properly. You will need to upgrade
-to at least GNU fileutile version 3.16 to resolve this problem.
-
-@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.
-Much of that documentation is available on-line. The following is
-a list of URLs where can find HTML versions of the manuals.
-
-@table @b
-GCC Documentation
-http://gcc.gnu.org/onlinedocs
-
-Newlib Documentation
-Not currently online at http://sourceware.cygnus.com/newlib
-
-Binutils Documentation
-Not currently online at http://sourceware.cygnus.com/binutils
-@end table
+This section describes the process of applying the RTEMS patches
+to GCC, NEWLIB, and BINUTILS.
@c
@c GCC patches
@c
-@section Apply RTEMS Patch to GCC
+@subheading Apply RTEMS Patch to GCC
@ifclear GCC-RTEMSPATCH
No RTEMS specific patches are required for @value{GCC-VERSION} to
@@ -285,7 +200,8 @@ Apply the patch using the following command sequence:
@example
cd tools/@value{GCC-UNTAR}
-zcat ../../archive/@value{GCC-RTEMSPATCH} | patch -p1
+zcat ../../archive/@value{GCC-RTEMSPATCH} | \
+ patch -p1
@end example
Check to see if any of these patches have been rejected using the following
@@ -305,7 +221,7 @@ This should not happen with a good patch file which is properly applied.
@c BINUTILS patches
@c
-@section Apply RTEMS Patch to binutils
+@subheading Apply RTEMS Patch to binutils
@ifclear BINUTILS-RTEMSPATCH
No RTEMS specific patches are required for @value{BINUTILS-VERSION} to
@@ -317,7 +233,8 @@ Apply the patch using the following command sequence:
@example
cd tools/@value{BINUTILS-UNTAR}
-zcat ../../archive/@value{BINUTILS-RTEMSPATCH} | patch -p1
+zcat ../../archive/@value{BINUTILS-RTEMSPATCH} | \
+ patch -p1
@end example
Check to see if any of these patches have been rejected using the following
@@ -337,7 +254,7 @@ This should not happen with a good patch file which is properly applied.
@c Newlib patches
@c
-@section Apply RTEMS Patch to newlib
+@subheading Apply RTEMS Patch to newlib
@ifclear NEWLIB-RTEMSPATCH
No RTEMS specific patches are required for @value{NEWLIB-VERSION} to
@@ -350,7 +267,8 @@ Apply the patch using the following command sequence:
@example
cd tools/@value{NEWLIB-UNTAR}
-zcat ../../archive/@value{NEWLIB-RTEMSPATCH} | patch -p1
+zcat ../../archive/@value{NEWLIB-RTEMSPATCH} | \
+ patch -p1
@end example
Check to see if any of these patches have been rejected using the following
@@ -366,11 +284,342 @@ This should not happen with a good patch file which is properly applied.
@end ifset
+
+@c
+@c Compiling and Installing BINUTILS GCC and NEWLIB
+@c
+
+@subsection Compiling and Installing BINUTILS GCC and NEWLIB
+
+There are three methods to compile and install BINUTILS, GCC, and NEWLIB:
+
+@itemize @bullet
+@item RPM
+@item direct invocation of @code{configure} and @code{make}
+@item using the @code{bit} script
+@end itemize
+
+Direct invocation of @code{configure} and @code{make} provides more control
+and easier recovery from problems when building.
+
+@c
+@c Using RPM to Build BINUTILS GCC and NEWLIB
+@c
+
+@subsubsection Using RPM to Build BINUTILS GCC and NEWLIB
+
+NOTE: The procedures described in the following sections must
+be completed before this step:
+
+@itemize @bullet
+@item @ref{Obtain Source and Patches for BINUTILS GCC and NEWLIB}
+@end itemize
+
+RPM automatically unarchives the source and applies any needed
+patches so you do @b{NOT} have to manually perform the procedures
+described @ref{Unarchiving the Tools} and
+@ref{Applying RTEMS Patches}.
+
+This section describes the process of building binutils, gcc, and
+newlib using RPM. RPM is a packaging format which can be used to
+distribute binary files as well as to capture the procedure and
+source code used to produce those binary files. Before
+attempting to build any RPM from source, it is necessary to
+ensure that all required source and patches are in the @code{SOURCES}
+directory under the RPM root (probably @code{/usr/src/redhat} or
+@code{/usr/local/src/redhat}) on your machine. This procedure
+starts by installing the source RPMs as shown in the following
+example:
+
+@example
+rpm -i i386-rtems-binutils-collection-2.9.5.0.24-1.nosrc.rpm
+rpm -i i386-rtems-gcc-newlib-gcc2.95.2newlib1.8.2-7.nosrc.rpm
+@end example
+
+Because RTEMS tool RPMS are called "nosrc" to indicate that one or
+more source files required to produce the RPMs are not present.
+The RTEMS source RPMs do not include the large @code{.tar.gz} or
+@code{.tgz} files for
+each component such as BINUTILS, GCC, or NEWLIB. These are shared
+by all RTEMS RPMs regardless of target CPU and there was no reason
+to duplicate them. You will have to get the required source
+archive files by hand and place them in the @code{SOURCES} directory
+before attempting to build. If you forget to do this, RPM is
+smart -- it will tell you what is missing. To determine what is
+included or referenced by a particular RPM, use a command like the
+following:
+
+@example
+$ rpm -q -l -p i386-rtems-binutils-collection-2.9.5.0.24-1.nosrc.rpm
+binutils-2.9.5.0.24-rtems-20000207.diff
+binutils-2.9.5.0.24.tar.gz
+i386-rtems-binutils-2.9.5.0.24.spec
+@end example
+
+Notice that there is a patch file (the @code{.diff} file), a source archive
+file (the @code{.tar.gz}), and a file describing the build procedure and
+files produced (the @code{.spec} file). The @code{.spec} file is placed
+in the @code{SPECS} directory under the RPM root directory.
+
+@c
+@c Configuring and Building BINUTILS using RPM
+@c
+
+@subheading Configuring and Building BINUTILS using RPM
+
+The following example illustrates the invocation of RPM to build a new,
+locally compiled, binutils binary RPM that matches the installed source
+RPM. This example assumes that all of the required source is installed.
+
+@example
+cd <RPM_ROOT_DIRECTORY>/SPECS
+rpm -bb i386-rtems-binutils-2.9.5.0.24.spec
+@end example
+
+If the build completes successfully, RPMS like the following will
+be generated in a build-host architecture specific subdirectory
+of the RPMS directory under the RPM root directory.
+
+@example
+rtems-base-binutils-2.9.5.0.24-1.i386.rpm
+i386-rtems-binutils-2.9.5.0.24-1.i386.rpm
+@end example
+
+NOTE: It may be necessary to remove the build tree in the
+@code{BUILD} directory under the RPM root directory.
+
+@c
+@c Configuring and Building GCC and NEWLIB using RPM
+@c
+
+@subheading Configuring and Building GCC and NEWLIB using RPM
+
+The following example illustrates the invocation of RPM to build a new,
+locally compiled, set of GCC and NEWLIB binary RPMs that match the
+installed source RPM. It is also necessary to install the BINUTILS
+RPMs and place them in your PATH. This example assumes that all of
+the required source is installed.
+
+@example
+cd <RPM_ROOT_DIRECTORY>/RPMS/i386
+rpm -i rtems-base-binutils-2.9.5.0.24-1.i386.rpm
+rpm -i i386-rtems-binutils-2.9.5.0.24-1.i386.rpm
+export PATH=/opt/rtems/bin:$PATH
+cd <RPM_ROOT_DIRECTORY>/SPECS
+rpm -bb i386-rtems-gcc-2.95.2-newlib-1.8.2.spec
+@end example
+
+If the build completes successfully, a set of RPMS like the following will
+be generated in a build-host architecture specific subdirectory
+of the RPMS directory under the RPM root directory.
+
+@example
+rtems-base-gcc-gcc2.95.2newlib1.8.2-7.i386.rpm
+rtems-base-chill-gcc2.95.2newlib1.8.2-7.i386.rpm
+rtems-base-g77-gcc2.95.2newlib1.8.2-7.i386.rpm
+rtems-base-gcj-gcc2.95.2newlib1.8.2-7.i386.rpm
+i386-rtems-gcc-gcc2.95.2newlib1.8.2-7.i386.rpm
+i386-rtems-chill-gcc2.95.2newlib1.8.2-7.i386.rpm
+i386-rtems-g77-gcc2.95.2newlib1.8.2-7.i386.rpm
+i386-rtems-gcj-gcc2.95.2newlib1.8.2-7.i386.rpm
+i386-rtems-objc-gcc2.95.2newlib1.8.2-7.i386.rpm
+@end example
+
+NOTE: Some targets do not support building all languages.
+
+NOTE: It may be necessary to remove the build tree in the
+@code{BUILD} directory under the RPM root directory.
+
+@c
+@c Using configure and make
+@c
+
+@subsubsection Using configure and make
+
+NOTE: The procedures described in the following sections must
+be completed before this step:
+
+@itemize @bullet
+@item @ref{Obtain Source and Patches for BINUTILS GCC and NEWLIB}
+@item @ref{Unarchiving the Tools}
+@item @ref{Applying RTEMS Patches}
+@end itemize
+
+This section describes the process of building binutils, gcc, and
+newlib manually using @code{configure} and @code{make} directly.
+
+@c
+@c Configuring and Building BINUTILS
+@c
+
+@subheading Configuring and Building BINUTILS
+
+The following example illustrates the invocation of
+@code{configure} and @code{make}
+to build and install @value{BINUTILS-UNTAR} for the
+sparc-rtems target:
+
+@example
+mkdir b-binutils
+cd b-binutils
+../@value{BINUTILS-UNTAR}/configure --target=sparc-rtems \
+ --prefix=/opt/rtems
+make all
+make info
+make install
+@end example
+
+After @value{BINUTILS-UNTAR} is built and installed the
+build directory @code{b-binutils} may be removed.
+
+For more information on the invocation of @code{configure}, please
+refer to the documentation for @value{BINUTILS-UNTAR} or
+invoke the @value{BINUTILS-UNTAR} @code{configure} command with the
+@code{--help} option.
+
+@c
+@c Configuring and Building GCC and NEWLIB
+@c
+
+@subheading Configuring and Building GCC and NEWLIB
+
+Before building @value{GCC-UNTAR} and @value{NEWLIB-UNTAR},
+@value{BINUTILS-UNTAR} must be installed and the directory
+containing those executables must be in your PATH.
+
+The C Library is built as a subordinate component of
+@value{GCC-UNTAR}. Because of this, the @value{NEWLIB-UNTAR}
+directory source must be available inside the @value{GCC-UNTAR}
+source tree. This is normally accomplished using a symbolic
+link as shown in this example:
+
+@example
+cd @value{GCC-UNTAR}
+ln -s ../@value{NEWLIB-UNTAR}/newlib .
+@end example
+
+The following example illustrates the invocation of
+@code{configure} and @code{make}
+to build and install @value{BINUTILS-UNTAR} for the
+sparc-rtems target:
+
+@example
+mkdir b-gcc
+cd b-gcc
+../@value{GCC-UNTAR}/configure --target=sparc-rtems \
+ --with-gnu-as --with-gnu-ld --with-newlib --verbose \
+ --enable-threads --prefix=/opt/rtems
+make all
+make info
+make install
+@end example
+
+After @value{GCC-UNTAR} is built and installed the
+build directory @code{b-gcc} may be removed.
+
+For more information on the invocation of @code{configure}, please
+refer to the documentation for @value{GCC-UNTAR} or
+invoke the @value{GCC-UNTAR} @code{configure} command with the
+@code{--help} option.
+
+@c
+@c Using the bit Script
+@c
+
+@subsubsection Using the bit Script
+
+NOTE: The procedures described in the following sections must
+be completed before this step:
+
+@itemize @bullet
+@item @ref{Obtain Source and Patches for BINUTILS GCC and NEWLIB}
+@item @ref{Unarchiving the Tools}
+@item @ref{Applying RTEMS Patches}
+@end itemize
+
+This section describes the process of building using the
+@code{bit} script. This script hides many of the details
+of building the tools but can be a hindrance if you
+encounter problems building the tools.
+
+@c
+@c Unarchiving the Build Scripts
+@c
+
+@subheading Unarchiving the Build Scripts
+
+While in the @code{tools} directory, unpack the compressed
+tar file for the build tools using the following command sequence:
+
+@example
+cd tools
+tar xzf ../archive/@value{BUILDTOOLS-TAR}
+@end example
+
+After the compressed tar file @value{BUILDTOOLS-TAR} has been unpacked, there
+will be a set of scripts in the tools directory along with
+any source code you have previously unarchived.
+These scripts are intended to aid in building the tools and RTEMS.
+These scripts may be used to automate the tool building process and hide
+the invocation of @code{configure} and @code{make} from you. They are:
+
+@itemize @bullet
+@item bit
+@item bit_gdb
+@item bit_rtems
+@item common.sh
+@item user.cfg
+@end itemize
+
+If @code{bit} is executed later in this process,
+it will automatically create this subdirectory:
+
+@itemize @bullet
+@item build-$@{CPU@}-tools
+@end itemize
+
+At this point, the tree should look something like the following figure:
+
+@example
+@group
+/whatever/prefix/you/choose/
+ archive/
+ @value{GCC-TAR}
+ @value{BINUTILS-TAR}
+ @value{NEWLIB-TAR}
+ @value{BUILDTOOLS-TAR}
+@ifset GCC-RTEMSPATCH
+ @value{GCC-RTEMSPATCH}
+@end ifset
+@ifset BINUTILS-RTEMSPATCH
+ @value{BINUTILS-RTEMSPATCH}
+@end ifset
+@ifset NEWLIB-RTEMSPATCH
+ @value{NEWLIB-RTEMSPATCH}
+@end ifset
+ tools/
+ @value{BINUTILS-UNTAR}/
+ @value{GCC-UNTAR}/
+ @value{NEWLIB-UNTAR}/
+ bit
+ bit_gdb
+ bit_rtems
+ common.sh
+ user.cfg
+@end group
+@end example
+
+@c @ifset use-html
+@c @html
+@c <IMG SRC="bit_c.jpg" WIDTH=816 HEIGHT=267 ALT="Directory Organization">
+@c @end html
+@c @end ifset
+
@c
@c Localizing the Configuration
@c
-@section Localizing the Configuration
+@subheading Localizing the Configuration
Edit the @code{user.cfg} file to alter the settings of various
variables which are used to tailor the build process.
@@ -404,6 +653,14 @@ For example,
GCC=@value{GCC-UNTAR}
@end example
+@item GDB
+is the directory under tools that contains @value{GDB-UNTAR}.
+For example,
+
+@example
+GDB=@value{GDB-UNTAR}
+@end example
+
@item NEWLIB
is the directory under tools that contains @value{NEWLIB-UNTAR}.
For example:
@@ -440,78 +697,18 @@ 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{RTEMS-UNTAR}.
-
-@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}.
-
-@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 Script
+The other variables in @code{user.cfg} are RTEMS specific and are
+not technically required to be set unless you build RTEMS using
+the @code{bit_rtems} script as described in
+@ref{Using the bit_rtems Script}. They are described in detail
+in that section.
+
+@c
+@c Running the bit Script
+@c
+@subheading Running the bit Script
After the @code{bit} script has been modified to reflect the
local installation, the modified @code{bit} script is run
@@ -527,13 +724,15 @@ Where <target configuration> is one of the following:
@itemize @bullet
@item hppa1.1
@item i386
+@item i386-coff
@item i386-elf
-@item i386-go32
@item i960
@item m68k
+@item m68k-coff
@item mips64orion
@item powerpc
@item sh
+@item sh-elf
@item sparc
@end itemize
@@ -542,7 +741,7 @@ 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 &
+./bit <target configuration> >bit.log 2>&1 &
tail -f bit.log
@end example
@@ -563,6 +762,308 @@ GNU C/C++ cross compilation tools are installed.
If the @code{bit} script does not successfully complete, then investigation
will be required to determine the source of the error.
+@c -------------------
+
+@c
+@c Building the GNU Debugger GDB
+@c
+
+@section Building the GNU Debugger GDB
+
+NOTE: This step is NOT required if prebuilt executables for
+the GNU Debugger GDB were installed.
+
+The GNU Debugger GDB supports many configurations but requires some
+means of communicating between the host computer and target board.
+This communication can be via a serial port, Ethernet, BDM, or ROM emulator.
+The communication protocol can be the GDB remote protocol or GDB
+can talk directly to a ROM monitor. This setup is target board
+specific. The following configurations have been
+successfully used with RTEMS applications:
+
+@itemize @bullet
+@item Sparc Instruction Simulator (SIS)
+@item PowerPC Instruction Simulator (PSIM)
+@item DINK32
+@item BDM with 68360 and MPC860 CPUs
+@item Motorola Mxxxbug found on M68xxx VME boards
+@item Motorola PPCbug found on PowerPC VME and CompactPCI boards
+@end itemize
+
+GDB is currently RTEMS thread/task aware only if you are using the
+remote debugging support via Ethernet. These are configured
+using gdb targets of the form CPU-RTEMS. Note the capital RTEMS.
+
+It is recommended that when toolset binaries are available for
+your particular host, that they be used. Prebuilt binaries
+are much easier to install but in the case of gdb may or may
+not include support for your particular target board.
+
+@c
+@c Obtain Source and Patches for GDB
+@c
+
+@subsection Obtain Source and Patches for GDB
+
+NOTE: This step is required for all methods of building GDB.
+
+This section lists the components required to build GDB
+from source to target RTEMS. These files should be
+placed in your @code{archive} directory. Included are the locations
+of each component as well as any required RTEMS specific patches.
+
+@need 1000
+@subheading @value{GDB-VERSION}
+@example
+ FTP Site: @value{GDB-FTPSITE}
+ Directory: @value{GDB-FTPDIR}
+ File: @value{GDB-TAR}
+@ifset use-html
+@c URL: @uref{Download @value{GDB-VERSION}, ftp://@value{GDB-FTPSITE}@value{GDB-FTPDIR}}
+ URL: ftp://@value{GDB-FTPSITE}@value{GDB-FTPDIR}
+@end ifset
+@end example
+
+@need 1000
+@subheading RTEMS Specific Tool Patches and Scripts
+@example
+ FTP Site: @value{RTEMS-FTPSITE}
+ Directory: @value{RTEMS-FTPDIR}/c_tools/source
+ File: @value{BUILDTOOLS-TAR}
+@ifset GDB-RTEMSPATCH
+ File: @value{GDB-RTEMSPATCH}
+@end ifset
+@ifset use-html
+@c URL: @uref{ftp://@value{RTEMS-FTPSITE}@value{RTEMS-FTPDIR}/c_tools/source,Download RTEMS Patches and Scripts}
+ URL: ftp://@value{RTEMS-FTPSITE}@value{RTEMS-FTPDIR}/c_tools/source
+@end ifset
+@end example
+
+@c
+@c Unarchiving the GDB Distribution
+@c
+@subsection Unarchiving the GDB Distribution
+
+Use the following commands to unarchive the GDB distribution:
+
+@example
+cd tools
+tar xzf ../archive/@value{GDB-TAR}
+@end example
+
+The directory @value{GDB-UNTAR} is created under the tools directory.
+
+@c
+@c Applying RTEMS Patch to GDB
+@c
+
+@subsection Applying RTEMS Patch to GDB
+
+@ifclear GDB-RTEMSPATCH
+No RTEMS specific patches are required for @value{GDB-VERSION} to
+support @value{RTEMS-VERSION}.
+@end ifclear
+
+@ifset GDB-RTEMSPATCH
+
+Apply the patch using the following command sequence:
+
+@example
+cd tools/@value{GDB-UNTAR}
+zcat archive/@value{GDB-RTEMSPATCH} | \
+ patch -p1
+@end example
+
+Check to see if any of these patches have been rejected using the following
+sequence:
+
+@example
+cd tools/@value{GDB-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.
+
+@end ifset
+
+@c
+@c Compiling and Installing the GNU Debugger GDB
+@c
+
+@subsection Compiling and Installing the GNU Debugger GDB
+
+There are three methods of building the GNU Debugger:
+
+@itemize @bullet
+@item RPM
+@item direct invocation of @code{configure} and @code{make}
+@item using the @code{bit_gdb} script
+@end itemize
+
+Direct invocation of @code{configure} and @code{make} provides more control
+and easier recovery from problems when building.
+
+@c
+@c Using RPM to Build GDB
+@c
+
+@subsubsection Using RPM to Build GDB
+
+This section describes the process of building binutils, gcc, and
+newlib using RPM. RPM is a packaging format which can be used to
+distribute binary files as well as to capture the procedure and
+source code used to produce those binary files. Before
+attempting to build any RPM from source, it is necessary to
+ensure that all required source and patches are in the @code{SOURCES}
+directory under the RPM root (probably @code{/usr/src/redhat} or
+@code{/usr/local/src/redhat}) on your machine. This procedure
+starts by installing the source RPMs as shown in the following
+example:
+
+@example
+rpm -i i386-rtems-gdb-collection-4.18-4.nosrc.rpm
+@end example
+
+Because RTEMS tool RPMS are called "nosrc" to indicate that one or
+more source files required to produce the RPMs are not present.
+The RTEMS source GDB RPM does not include the large @code{.tar.gz} or
+@code{.tgz} files for GDB. This is shared by all RTEMS RPMs
+regardless of target CPU and there was no reason
+to duplicate them. You will have to get the required source
+archive files by hand and place them in the @code{SOURCES} directory
+before attempting to build. If you forget to do this, RPM is
+smart -- it will tell you what is missing. To determine what is
+included or referenced by a particular RPM, use a command like the
+following:
+
+@example
+$ rpm -q -l -p i386-rtems-gdb-collection-4.18-4.nosrc.rpm
+gdb-4.18-rtems-20000524.diff
+gdb-4.18.tar.gz
+i386-rtems-gdb-4.18.spec
+@end example
+
+Notice that there is a patch file (the @code{.diff} file), a source archive
+file (the @code{.tar.gz}), and a file describing the build procedure and
+files produced (the @code{.spec} file). The @code{.spec} file is placed
+in the @code{SPECS} directory under the RPM root directory.
+
+@c
+@c Configuring and Building GDB using RPM
+@c
+
+@subheading Configuring and Building GDB using RPM
+
+The following example illustrates the invocation of RPM to build a new,
+locally compiled, binutils binary RPM that matches the installed source
+RPM. This example assumes that all of the required source is installed.
+
+@example
+cd <RPM_ROOT_DIRECTORY>/SPECS
+rpm -bb i386-rtems-gdb-4.18.spec
+@end example
+
+If the build completes successfully, RPMS like the following will
+be generated in a build-host architecture specific subdirectory
+of the RPMS directory under the RPM root directory.
+
+@example
+rtems-base-gdb-4.18-4.i386.rpm
+i386-rtems-gdb-4.18-4.i386.rpm
+@end example
+
+NOTE: It may be necessary to remove the build tree in the
+@code{BUILD} directory under the RPM root directory.
+
+@c
+@c Using the GDB configure Script Directly
+@c
+
+@subsubsection Using the GDB configure Script Directly
+
+This section describes how to configure the GNU debugger for
+RTEMS targets using @code{configure} and @code{make} directly.
+The following example illustrates the invocation of @code{configure}
+and @code{make} to build and install @value{GDB-UNTAR} for the
+m68k-rtems target:
+
+@example
+mkdir b-gdb
+cd b-gdb
+../@value{GDB-UNTAR}/configure --target=m68k-rtems \
+ --prefix=/opt/rtems
+make all
+make info
+make install
+@end example
+
+For some configurations, it is necessary to specify extra options
+to @code{configure} to enable and configure option components
+such as a processor simulator. The following is a list of
+configurations for which there are extra options:
+
+@table @b
+@item i960-rtems
+@code{--enable-sim}
+
+@item powerpc-rtems
+@code{--enable-sim --enable-sim-powerpc --enable-sim-timebase --enable-sim-hardware}
+
+@item sparc-rtems
+@code{--enable-sim}
+
+@end table
+
+After @value{GDB-UNTAR} is built and installed the
+build directory @code{b-gdb} may be removed.
+
+For more information on the invocation of @code{configure}, please
+refer to the documentation for @value{GDB-UNTAR} or
+invoke the @value{GDB-UNTAR} @code{configure} command with the
+@code{--help} option.
+
+@subsubsection Using the bit_gdb Script
+
+The simplest way to build gdb for RTEMS is to use the @code{bit_gdb} script.
+This script interprets the settings in the @code{user.cfg} file to
+produce the GDB configuration most appropriate for the target CPU.
+The variables in @code{user.cfg} were described in @ref{Using the bit Script}
+but only the @code{GDB} variable setting is used by @code{bit_gdb}.
+
+The @code{bit_gdb} script is invoked as follows:
+
+@example
+./bit_gdb CPU
+@end example
+
+Where CPU is one of the RTEMS supported CPU families from the following
+list:
+
+@itemize @bullet
+@item hppa1.1
+@item i386
+@item i386-coff
+@item i386-elf
+@item i960
+@item m68k
+@item m68k-coff
+@item mips64orion
+@item powerpc
+@item sh
+@item sh-elf
+@item sparc
+@end itemize
+
+If gdb supports a CPU instruction simulator for this configuration, then
+it is included in the build.
+
+@c -------------------
+
+@c
+@c Common Problems
+@c
+
@section Common Problems
@subsection Error Message Indicates Invalid Option to Assembler
@@ -580,7 +1081,7 @@ This can occur for one of the following reasons:
@end itemize
-If you are using binutils 2.9.1 or newer with certain versions of
+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
@@ -599,7 +1100,7 @@ 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 remove "."
+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".
@@ -609,7 +1110,7 @@ If you see error messages like the following,
@itemize @bullet
-@item cannot configure libliberty
+@item cannot configure libiberty
@item coff-emulation not found
@item etc.
@@ -647,4 +1148,4 @@ build directory.
This situation can be avoided entirely by never using
the source tree as the build directory -- even for
-native builds.
+
diff --git a/doc/started/buildrt.t b/doc/started/buildrt.t
index 0b60bcdfba..0ab4d00287 100644
--- a/doc/started/buildrt.t
+++ b/doc/started/buildrt.t
@@ -1,6 +1,6 @@
@c
@c
-@c COPYRIGHT (c) 1988-1999.
+@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@@ -9,40 +9,55 @@
@chapter Building RTEMS
-@section Unpack the RTEMS Source
+@section Obtain the RTEMS Source Code
-Use the following command sequence to unpack the RTEMS source into the
-tools directory:
+This section provides pointers to the RTEMS source code and
+Hello World example program. These files should be
+placed in your @code{archive} directory.
+@subheading @value{RTEMS-VERSION}
@example
-cd tools
-tar xzf ../archive/@value{RTEMS-TAR}
+ FTP Site: @value{RTEMS-FTPSITE}
+ Directory: @value{RTEMS-FTPDIR}
+ File: @value{RTEMS-TAR}
+@ifset use-html
+@c URL: @uref{ftp://@value{RTEMS-FTPSITE}@value{RTEMS-FTPDIR}, Download RTEMS components}
+ URL: ftp://@value{RTEMS-FTPSITE}@value{RTEMS-FTPDIR}
+@end ifset
@end example
-If you did not build and install the tools from source, then you
-will need to unarchive the build scripts at this point. In this
-case, you will have to execute the following additional command
-since you did not do it as part of building the tools.
+@subheading RTEMS Hello World
+@example
+ FTP Site: @value{RTEMS-FTPSITE}
+ Directory: @value{RTEMS-FTPDIR}
+ File: hello_world_c.tgz
+@ifset use-html
+@c URL: @uref{ftp://@value{RTEMS-FTPSITE}@value{RTEMS-FTPDIR}/hello_world_c.tgz, Download RTEMS Hello World}
+ URL: ftp://@value{RTEMS-FTPSITE}@value{RTEMS-FTPDIR}/hello_world_c.tgz
+@end ifset
+@end example
+
+@c
+@c Unarchive the RTEMS Source
+@c
+
+@section Unarchive the RTEMS Source
+
+Use the following command sequence to unpack the RTEMS source into the
+tools directory:
@example
-tar xzf ../archive/@value{BUILDTOOLS-TAR}
+cd tools
+tar xzf ../archive/@value{RTEMS-TAR}
@end example
-At this point, the following files and directories should
-exist in the current directory in order to build RTEMS:
+This creates the directory @value{RTEMS-UNTAR}.
-@itemize @bullet
-@item bit
-@item bit_rtems
-@item common.sh
-@item @value{RTEMS-UNTAR}
-@item user.cfg
-@end itemize
@section Add <INSTALL_POINT>/bin to Executable PATH
In order to compile RTEMS, you must have the cross compilation toolset
-in your search patch. The following command appends the directory
+in your search path. The following command appends the directory
where the tools were installed prior to this point:
@example
@@ -58,9 +73,9 @@ derivatives of the C Shell.
In order to insure that the cross-compiler is invoking the correct
subprograms (like @code{as} and @code{ld}), one can test assemble
-a small program. When in verbose more, @code{gcc} prints out information
-showing where it found the subprograms it invokes. Place the following
-function in a file named @code{f.c}:
+a small program. When in verbose mode, @code{gcc} prints out information
+showing where it found the subprograms it invokes. In a temporary
+working directory, place the following function in a file named @code{f.c}:
@example
int f( int x )
@@ -81,48 +96,40 @@ a sequence of output showing where the cross-compiler searched for
and found its subcomponents. Verify that these paths correspond
to your <INSTALL_POINT>.
-@b{NOTE:} One of the most common installation errors is for the
-cross-compiler not to be able to find the cross assembler and default
-to using the native @code{as}. This can result in very confusing
-error messages.
+Look at the created file @code{f.s} and verify that it is in fact
+for your target processor.
-@section Generate RTEMS for a Specific Target and BSP
-
-@subsection Using the bit_rtems Script
-
-The simplest way to build RTEMS is to use the @code{bit_rtems} script.
-This script interprets the settings in the @code{user.cfg} file to
-enable or disable the various RTEMS options.
-
-This script is invoked as follows:
+Then try to compile the file @code{f.c} directly to object code
+using a command like the following:
@example
-./bit_rtems CPU [BSP]
+m68k-rtems-gcc -v -c f.c
@end example
-Where CPU is one of the RTEMS supported CPU families from the following
-list:
+If this produces messages that indicate the assembly code is
+not valid, then it is likely that you have fallen victim to
+one of the problems described in
+@ref{Error Message Indicates Invalid Option to Assembler}
+Don't feel bad about this, one of the most common installation errors
+is for the cross-compiler not to be able to find the cross assembler
+and default to using the native @code{as}. This can result in very confusing
+error messages.
+
+@section Building RTEMS for a Specific Target and BSP
+
+This section describes how to configure and build RTEMS
+so that it is specifically tailored for your BSP and the
+CPU model it uses. There are two methods to compile and install RTEMS:
@itemize @bullet
-@item hppa1.1
-@item i386
-@item i386-elf
-@item i386-go32
-@item i960
-@item m68k
-@item mips64orion
-@item powerpc
-@item sh
-@item sparc
+@item direct invocation of @code{configure} and @code{make}
+@item using the @code{bit} script
@end itemize
-BSP is a supported BSP for the selected CPU family. The list of
-supported BSPs may be found in the file
-tools/@value{RTEMS-UNTAR}/README.configure
-in the RTEMS source tree. If the BSP parameter is not specified,
-then all supported BSPs for the selected CPU family will be built.
+Direct invocation of @code{configure} and @code{make} provides more control
+and easier recovery from problems when building.
-@b{NOTE:} The POSIX API must be enabled to use GNAT/RTEMS.
+This section describes how to build RTEMS.
@subsection Using the RTEMS configure Script Directly
@@ -130,13 +137,14 @@ Make a build directory under tools and build the RTEMS product in this
directory. The ../@value{RTEMS-UNTAR}/configure
command has numerous command line
arguments. These arguments are discussed in detail in documentation that
-comes with the RTEMS distribution. In the installation described in the
-section "Unpack the RTEMS source", these configuration options can be found
-in the file tools/@value{RTEMS-UNTAR}/README.configure.
+comes with the RTEMS distribution. If you followed the procedure
+described in the section @ref{Unarchive the RTEMS Source}, these
+configuration options can be found in the file
+tools/@value{RTEMS-UNTAR}/README.configure.
-The GNAT/RTEMS run-time implementation is based on the POSIX API. Thus
-the RTEMS configuration for a GNAT/RTEMS environment MUST include the
-@code{--enable-posix} flag.
+@b{NOTE}: The GNAT/RTEMS run-time implementation is based on the POSIX
+API. Thus the RTEMS configuration for a GNAT/RTEMS environment MUST
+include the @code{--enable-posix} flag.
The following shows the command sequence required to configure,
compile, and install RTEMS with the POSIX API, FreeBSD TCP/IP,
@@ -153,11 +161,140 @@ cd build-rtems
make all install
@end example
-Where the list of currently supported of <TARGET_CONFIGURATION>'s and
+Where the list of currently supported <TARGET_CONFIGURATION>'s and
<BOARD_SUPPORT_PACKAGE>'s can be found in
tools/@value{RTEMS-UNTAR}/README.configure.
-<INSTALL_POINT> is the installation point from the previous step
-"Modify the bit script" in the build of the tools.
+<INSTALL_POINT> is typically the installation point for the
+tools and is @code{/opt/rtems} when using prebuilt toolset executables.
NOTE: The @code{make} utility used should be GNU make.
+
+@c
+@c Using the bit_rtems Script
+@c
+
+@subsection Using the bit_rtems Script
+
+If you have not previously unarchived the build tools, then you
+will need to unarchive the build scripts at this point if you
+plan to use @code{bit_rtems} to build RTEMS. If this is the
+case, you will have to execute the following additional command
+since you did not do it as part of building the tools.
+
+@example
+cd tools
+tar xzf ../archive/@value{BUILDTOOLS-TAR}
+@end example
+
+This script interprets the settings in the @code{user.cfg} file to
+enable or disable the various RTEMS options. The RTEMS
+specific entries described below must be set to
+tailor the RTEMS configuration to meet your application requirements:
+
+@table @code
+
+@item RTEMS
+is the directory under tools that contains @value{RTEMS-UNTAR}.
+
+@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}.
+
+@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
+
+After tailoring @code{user.cfg} for your application, the @code{bit_rtems}
+script may be invoked as follows:
+
+@example
+./bit_rtems CPU [BSP]
+@end example
+
+Where CPU is one of the RTEMS supported CPU families from the following
+list:
+
+@itemize @bullet
+@item hppa1.1
+@item i386
+@item i386-coff
+@item i386-elf
+@item i960
+@item m68k
+@item m68k-coff
+@item mips64orion
+@item powerpc
+@item sh
+@item sh-elf
+@item sparc
+@end itemize
+
+BSP is a supported BSP for the selected CPU family. The list of
+supported BSPs may be found in the file
+tools/@value{RTEMS-UNTAR}/README.configure
+in the RTEMS source tree. If the BSP parameter is not specified,
+then all supported BSPs for the selected CPU family will be built.
+
+@b{NOTE:} The POSIX API must be enabled to use GNAT/RTEMS.
+
diff --git a/doc/started/gdb.t b/doc/started/gdb.t
index 57f3bb1981..784f265fc6 100644
--- a/doc/started/gdb.t
+++ b/doc/started/gdb.t
@@ -1,5 +1,5 @@
@c
-@c COPYRIGHT (c) 1988-1999.
+@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@@ -8,26 +8,51 @@
@chapter Building the GNU Debugger
-GDB is currently RTEMS aware only if you are using the remote debugging
-support via Ethernet. The following configurations have been
+The GNU Debugger GDB supports many configurations but requires some
+means of communicating between the host computer and target board.
+This communication can be via a serial port, Ethernet, BDM, or ROM emulator.
+The communication protocol can be the GDB remote protocol or GDB
+can talk directly to a ROM monitor. This setup is target board
+specific. The following configurations have been
successfully used with RTEMS applications:
@itemize @bullet
@item Sparc Instruction Simulator (SIS)
@item PowerPC Instruction Simulator (PSIM)
@item DINK32
+@item BDM with 68360 and MPC860 CPUs
+@item Motorola Mxxxbug found on M68xxx MVME boards
+@item Motorola PPCbug found on PowerPC MVME boards
@end itemize
-Other configurations of gdb have successfully been used by RTEMS users
-but are not documented here.
+GDB is currently RTEMS thread/task aware only if you are using the
+remote debugging support via Ethernet. These are configured
+using gdb targets of the form CPU-RTEMS. Note the capital RTEMS.
It is recommended that when toolset binaries are available for
your particular host, that they be used. Prebuilt binaries
-are much easier to install.
+are much easier to install but in the case of gdb may or may
+not include support for your particular target board.
-@section Unarchive the gdb Distribution
+@c
+@c Getting Ready to Build GDB
+@c
+@section Getting Ready to Build GDB
+
+This section describes the process of unarchiving GDB
+as well as applying RTEMS specific patches. This is required when building
+the tools via the instructions in the
+@ref{Using the GDB configure Script Directly} or
+@ref{Using the bit_gdb Script} sections. It is @b{NOT} required when
+using RPM to build tool binaries.
+
+
+@c
+@c Unarchive the GDB Distribution
+@c
+@subsection Unarchive the GDB Distribution
-Use the following commands to unarchive the gdb distribution:
+Use the following commands to unarchive the GDB distribution:
@example
cd tools
@@ -37,10 +62,10 @@ tar xzf ../archive/@value{GDB-TAR}
The directory @value{GDB-UNTAR} is created under the tools directory.
@c
-@c GDB Patch
+@c Apply RTEMS Patch to GDB
@c
-@section Apply RTEMS Patch to GDB
+@subsection Apply RTEMS Patch to GDB
@ifclear GDB-RTEMSPATCH
No RTEMS specific patches are required for @value{GDB-VERSION} to
@@ -69,153 +94,176 @@ This should not happen with a good patch file.
@end ifset
-@section Using the bit_gdb script
-
-The simplest way to build gdb for RTEMS is to use the @code{bit_gdb} script.
-This script interprets the settings in the @code{user.cfg} file to
-produce the gdb configuration most appropriate for the target CPU.
+@c
+@c Building the GNU Debugger GDB
+@c
-This script is invoked as follows:
+@section Building the GNU Debugger GDB
-@example
-./bit_gdb CPU
-@end example
-
-Where CPU is one of the RTEMS supported CPU families from the following
-list:
+There are three methods of build the GNU Debugger:
@itemize @bullet
-@item hppa1.1
-@item i386
-@item i386-elf
-@item i386-go32
-@item i960
-@item m68k
-@item mips64orion
-@item powerpc
-@item sh
-@item sparc
+@item RPM
+@item direct invocation of configure and make
+@item using the @code{bit_gdb} script
@end itemize
-If gdb supports a CPU instruction simulator for this configuration, then
-it is included in the build.
-
-@section Using the gdb configure Script Directly
+Direct invocation of configure and make provides more control
+and easier recovery from problems when building.
-@subsection GDB with Sparc Instruction Simulation (SIS)
+@c
+@c Using RPM to Build GDB
+@c
-@subheading Make the Build Directory
+@subsection Using RPM to Build GDB
-Create a build directory for the SIS Debugger
+This section describes the process of building binutils, gcc, and
+newlib using RPM. RPM is a packaging format which can be used to
+distribute binary files as well as to capture the procedure and
+source code used to produce those binary files. Before
+attempting to build any RPM from source, it is necessary to
+ensure that all required source and patches are in the @code{SOURCES}
+directory under the RPM root (probably @code{/usr/src/redhat} or
+@code{/usr/local/src/redhat} on your machine. This procedure
+starts by installing the source RPMs as shown in the following
+example:
@example
-cd tools
-mkdir build-sis
+rpm -i i386-rtems-gdb-collection-4.18-4.nosrc.rpm
@end example
-@subheading Configure for the Build
-
-Configure the GNU Debugger for the
-Sparc Instruction Simulator (SIS):
+Because RTEMS tool RPMS are called "nosrc" to indicate that one or
+more source files required to produce the RPMs are not present.
+The RTEMS source GDB RPM does not include the large @code{.tar.gz} or
+@code{.tgz} files for GDB. This is shared by all RTEMS RPMs
+regardless of target CPU and there was no reason
+to duplicate them. You will have to get the required source
+archive files by hand and place them in the @code{SOURCES} directory
+before attempting to build. If you forget to do this, RPM is
+smart -- it will tell you what is missing. To determine what is
+included or referenced by a particular RPM, use a command like the
+following:
@example
-cd tools/build-sis
-../@value{GDB-UNTAR}/configure --target-sparc-erc32-aout \
- --program-prefix=sparc-rtems- \
- --disable-gdbtk \
- --enable-targets=all \
- --prefix=<INSTALL_POINT_FOR_SIS>
+$ rpm -q -l -p i386-rtems-gdb-collection-4.18-4.nosrc.rpm
+gdb-4.18-rtems-20000524.diff
+gdb-4.18.tar.gz
+i386-rtems-gdb-4.18.spec
@end example
-Where <INSTALL_POINT_FOR_SIS> is a unique location where the gdb
-with SIS will be created.
+Notice that there is a patch file (the @code{.diff} file), a source archive
+file (the @code{.tar.gz}), and a file describing the build procedure and
+files produced (the @code{.spec} file). The @code{.spec} file is placed
+in the @code{SPECS} directory under the RPM root directory.
+
+c
+@c Configuring and Building GDB using RPM
+@c
-@subheading Make the Debugger
+@subsubsection Configuring and Building GDB using RPM
-From tools/build-sis execute the following command sequence:
+The following example illustrates the invocation of RPM to build a new,
+locally compiled, binutils binary RPM that matches the installed source
+RPM. This example assumes that all of the required source is installed.
@example
-make all install
+cd <RPM_ROOT_DIRECTORY>/SPECS
+rpm -bb i386-rtems-gdb-4.18.spec
@end example
-NOTE: The @code{make} utility used should be GNU make.
-
-@subsection GDB with PowerPC Instruction Simulator
-
-@subheading Make the Build Directory
-
-Create a build directory for the SIS Debugger
+If the build completes successfully, RPMS like the following will
+be generated in a build-host architecture specific subdirectory
+of the RPMS directory under the RPM root directory.
@example
-cd tools
-mkdir build-ppc
+rtems-base-gdb-4.18-4.i386.rpm
+i386-rtems-gdb-4.18-4.i386.rpm
@end example
-@subheading Configure for the Build
-
-Configure the GNU Debugger for the PowerPC
-Instruction Simulator (PSIM):
+NOTE: It may be necessary to remove the build tree in the
+@code{BUILD} directory under the RPM root directory.
-@example
-cd tools/build-ppc
-../@value{GDB-UNTAR}/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
+@c
+@c Using the GDB configure Script Directly
+@c
-Where <INSTALL_POINT_FOR_PPC> is a unique location where the gdb
-with PSIM will be created.
+@subsection Using the GDB configure Script Directly
+This section describes how to configure the GNU debugger for
+standard RTEMS configurations as well as some alternative
+configurations that have been used in the past.
-@subheading Make the Debugger
+@subsubsection Standard RTEMS GDB Configuration
-From tools/build-ppc execute the following command sequence:
+The following example illustrates the invocation of configure
+and make to build and install @value{GDB-UNTAR} for the
+m68k-rtems target:
@example
-make all install
+mkdir b-gdb
+cd b-gdb
+../@value{GDB-UNTAR}/configure --target=m68k-rtems \
+ --prefix=/opt/rtems
+make all
+make info
+make install
@end example
-NOTE: The @code{make} utility used should be GNU make.
-
-@subsection GDB for DINK32
+For some configurations, it is necessary to specify extra options
+to @code{configure} to enable and configure option components
+such as a processor simulator. The following is a list of
+configurations for which there are extra options:
-@subheading Make the Build Directory
+@table @b
+@item i960-rtems
+@code{--enable-sim}
-Create a build directory for the DINK32 Debugger
+@item powerpc-rtems
+@code{--enable-sim --enable-sim-powerpc --enable-sim-timebase --enable-sim-hardware}
-@example
-cd tools
-mkdir build-dink32
-@end example
+@item sparc-rtems
+@code{--enable-sim}
-@subheading Configure for the Build
+@end table
-Configure the GNU Debugger to communicate with
-the DINK32 ROM monitor:
+After @value{GDB-UNTAR} is built and installed the
+build directory @code{b-gdb} may be removed.
-@example
-cd tools/build-dink32
-../@value{GDB-UNTAR}/configure --target-powerpc-elf \
- --program-prefix=powerpc-rtems- \
- --enable-targets=all \
- --prefix=<INSTALL_POINT_FOR_DINK32>
-@end example
+For more information on the invocation of @code{configure}, please
+refer to the documentation for @value{GDB-UNTAR} or
+invoke the @value{GDB-UNTAR} configure command with the
+@code{--help} option.
-Where <INSTALL_POINT_FOR_DINK32> is a unique location where the
-gdb Dink32 will be created.
+@subsection Using the bit_gdb Script
-@subheading Make the Debugger
+The simplest way to build gdb for RTEMS is to use the @code{bit_gdb} script.
+This script interprets the settings in the @code{user.cfg} file to
+produce the GDB configuration most appropriate for the target CPU.
-From tools/build-dink32 execute the following command sequence:
+This script is invoked as follows:
@example
-make all install
+./bit_gdb CPU
@end example
-NOTE: The @code{make} utility used should be GNU make.
+Where CPU is one of the RTEMS supported CPU families from the following
+list:
+
+@itemize @bullet
+@item hppa1.1
+@item i386
+@item i386-coff
+@item i386-elf
+@item i960
+@item m68k
+@item m68k-coff
+@item mips64orion
+@item powerpc
+@item sh
+@item sh-elf
+@item sparc
+@end itemize
+
+If gdb supports a CPU instruction simulator for this configuration, then
+it is included in the build.
+
diff --git a/doc/started/intro.t b/doc/started/intro.t
index 89cd6ec8ab..5a9a51e102 100644
--- a/doc/started/intro.t
+++ b/doc/started/intro.t
@@ -1,5 +1,5 @@
@c
-@c COPYRIGHT (c) 1988-1999.
+@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@@ -16,8 +16,8 @@ have a background in Unix, these instructions should provide the bare
essentials for performing a setup of the following items:
@itemize @bullet
-@item GNU C/C++ Cross Compilation Tools for RTEMS on your host system
-@item RTEMS OS for the target host
+@item GNU C/C++ Cross Compilation Tools for RTEMS on your build-host system
+@item RTEMS OS for the target
@item GDB Debugger
@end itemize
@@ -34,7 +34,7 @@ process used when developing RTEMS applications.
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
+systems, military weapon systems, and 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
@@ -72,7 +72,7 @@ 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
+setting off an alarm to indicate a failure condition. However, the
interactive system component must respond within an acceptable time limit to
allow the operator to interact efficiently with the control system.
@@ -81,26 +81,27 @@ allow the operator to interact efficiently with the control system.
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
+performed on one computer system, the @b{build-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
+for the build-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
+The build-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
+user development windows, and multiple developer connections. Thus the build-host
+computer is typically a traditional UNIX workstation such as those 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
+or UNIX. The build-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
+build-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.
@@ -108,14 +109,14 @@ 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
+effectively. Instead of hard drives 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
+often from a different processor family than that of the build-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
+designed only for use in embedded systems, there are versions of nearly every
+general-purpose processor 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.
@@ -125,35 +126,65 @@ as timers, serial controllers, or network interfaces.
This section describes various resources on the Internet which are of
use to RTEMS users.
+@c
+@c Online Tool Documentation
+@c
+
+@subsection Online Tool 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.
+The RTEMS Project provides formatted documentation for the primary
+tools in the cross development toolset including BINUTILS, GCC,
+NEWLIB, and GDB at
+@uref{http://www.oarcorp.com/rtemsdoc-4.5.0, http://www.oarcorp.com/rtemsdoc-4.5.0}.
+
+Much of the documentation is available at other sites on the Internet.
+The following is a list of URLs where one can find HTML versions of
+the GNU manuals:
+
+@table @b
+
+@item Free Software Foundation
+@uref{http://www.gnu.org/manual/manual.html, http://www.gnu.org/manual/manual.html}
+
+@item Delorie Software
+@uref{http://www.delorie.com/gnu/docs, http://www.delorie.com/gnu/docs}
+
+@end table
+
+
@subsection RTEMS Mailing List
-rtems-users@@OARcorp.com
+@uref{mailto:rtems-users@@OARcorp.com,rtems-users@@OARcorp.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@@OARcorp.com. Messages sent
-to rtems-users@@OARcorp.com are posted to the list.
+good list to monitor. Subscribe by sending an empty mail message to
+@uref{mailto:rtems-users-subscribe@@OARcorp.com,rtems-users-subscribe@@OARcorp.com}. Messages sent
+to @uref{mailto:rtems-users@@OARcorp.com,rtems-users@@OARcorp.com}
+are posted to the list.
@subsection CrossGCC Mailing List
-crossgcc@@cygnus.com
+@uref{mailto:crossgcc@@sources.redhat.com,crossgcc@@sources.redhat.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.
+focus on embedded issues. Information on subscribing
+to this mailing list is included in the
+@uref{http://www.objsw.com/CrossGCC/,CrossGCC FAQ}.
-The crossgcc FAQ as well as a number of patches and utiliities
+The CrossGCC FAQ as well as a number of patches and utilities
of interest to cross development system users are available
-at ftp://ftp.cygnus.com/pub/embedded/crossgcc.
+at @uref{ftp://ftp.cygnus.com/pub/embedded/crossgcc}.
@subsection GCC Mailing Lists
-See http://gcc.gnu.org for details.
-The GCC Project maintains multiple mailing lists. They
-are described at the above web site along with subscription
-information.
+The GCC Project is hosted at @uref{http://gcc.gnu.org,http://gcc.gnu.org}.
+They maintain multiple mailing lists that are described at the web site
+along with subscription information.
diff --git a/doc/started/nextstep.t b/doc/started/nextstep.t
index 22d16279ed..c1460c214b 100644
--- a/doc/started/nextstep.t
+++ b/doc/started/nextstep.t
@@ -1,6 +1,6 @@
@c
@c
-@c COPYRIGHT (c) 1988-1999.
+@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@@ -66,7 +66,7 @@ C Math Library functionality provided by Newlib's libm.
@end itemize
Finally, the RTEMS FAQ and mailing list archives are available
-at http://www.oarcorp.com.
+at @uref{http://www.oarcorp.com}.
There is a wealth of documentation available for RTEMS and
the GNU tools supporting it. If you run into something
@@ -74,7 +74,11 @@ that is not clear or missing, bring it to our attention.
Also, some of the RTEMS documentation is still under
construction. If you would like to contribute to this
-effort, please contact the RTEMS Team.
+effort, please contact the RTEMS Team at
+@uref{mailto:rtems-users@@OARcorp.com, rtems-users@@OARcorp.com}.
+If you are interested in sponsoring the development of a new
+feature, BSP, device driver, port of an existing library, etc.,
+please contact @uref{mailto:sales@@OARcorp.com, sales@@OARcorp.com}.
@section Writing an Application
@@ -114,7 +118,7 @@ most of the examples, the initialization task completes by
deleting itself.
As you begin to write RTEMS application code, you may be confused
-by the plethora of alternatives. Supporting multiple tasking
+by the range of alternatives. Supporting multiple tasking
APIs can make the choices confusing. Many application groups
writing new code choose one of the APIs as their primary API
and only use services from the others if nothing comparable
diff --git a/doc/started/nt.t b/doc/started/nt.t
index 5a203e6f9f..dc3e3ef02b 100644
--- a/doc/started/nt.t
+++ b/doc/started/nt.t
@@ -1,53 +1,78 @@
@c
-@c COPYRIGHT (c) 1988-1999.
+@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
-@set CYGWIN-VERSION B19
-@set CYGWIN-FTP http://www.cygnus.com/misc/gnu-win32/
-@set CYGWIN-COOLVIEW http://www.lexa.ru/sos/
-@set DOS2UNIX-FTP ftp://ftp.micros.hensa.ac.uk/platforms/ibm-pc/ms-dos/simtelnet/txtutl/dos2unix.zip
-
-@c @set PFE-FTP http://www.lancs.ac.uk/people/cpaap/pfe
-@set PFE-FTP http://www.simtel.net/pub/simtelnet/win95/editor/pfe101i.zip
-
-@chapter Using MS-Windows as a Development Host
+@appendix Using MS-Windows as a Development Host
This chapter discusses the installation of the GNU tool chain
on a computer running the Microsoft Windows NT operating system.
-This chapter is based on a draft provided by
-Geoffroy Montel <g_montel@@yahoo.com>. Geoffroy's
-procedure was based on information from
-David Fiddes <D.J@@fiddes.surfaid.org>.
+@section Cygwin 1.0 or Newer
+
+Recent versions of Cygwin are vastly improved over the beta
+versions. Most of the oddities, instabilities, and performance
+problems have been resolved. The installation procedure
+is much simpler. However, there are a handful of issues
+that remain to successfully use Cygwin as an RTEMS development
+environment.
+
+@itemize @bullet
+
+@item There is no @code{cc} program by default. The GNU configure
+scripts used by RTEMS require this to be present to work properly.
+The solution is to link @code{gcc.exe} to @code{cc.exe}.
+
+@item Make sure you unarchive and build in a binary mounted
+filesystem (e.g. mounted with the @code{-b} option). Otherwise,
+many confusing errors will result.
+
+@item If you want to use RPM, you will have to obtain that
+separately by following the links from the main Cygwin site.
+
+@item When using the RPMs, there may be warnings about
+@code{/etc/mtab} while installing the info files. This can be
+ignored.
+
+@item A user has reported that they needed
+to set CYGWIN=ntsec for chmod to work correctly, but had to set
+CYGWIN=nontsec for compile to work properly (otherwise there were
+complaints about permissions on a temporary file).
+
+@item If you want to build the tools from source, you have the
+same options as UNIX users -- @code{bit} or @code{RPM}.
+
+@end itemize
+
+@section Cygwin B19
+
+This section is based on a draft provided by
+@uref{mailto:g_montel@@yahoo.com, Geoffroy Montel <g_montel@@yahoo.com>}.
+Geoffroy's procedure was based on information from
+@uref{mailto:<D.J@@fiddes.surfaid.org>, David Fiddes <D.J@@fiddes.surfaid.org>}.
Their input and feedback is greatly appreciated.
@b{STATUS:} This chapter should be considered preliminary.
Please be careful when following these instructions.
-@section Version Information
-
This installation process works well under Windows NT.
Using Windows 95 or 98 is not recommended although it
should be possible with version 3.77 of GNU make and an updated
cygwinb19.dll.
-This procedure should also work with newer version of
+This procedure should also work with newer versions of
the tool versions listed in this chapter, but this has
-not been verified. If you have success with a particular
-version of the toolset or notice problems in this chapter,
-please let the RTEMS maintainers know so they can be
-addressed in future revisions of this document.
+not been verified.
-@section MS-Windows Host Specific Requirements
+@subsection MS-Windows Host Specific Requirements
This section details the components required to install
and build a Windows hosted GNU cross development toolset.
-@subsection Unzipping Archives
+@subsubsection Unzipping Archives
You will have to uncompress many archives during this
process. You must @b{NOT} use @code{WinZip} or
@@ -60,14 +85,13 @@ tar -xzvf archive.tgz
@code{tar} is provided with Cygwin32.
-@subsection Text Editor
+@subsubsection Text Editor
You absolutely have to use a text editor which can
save files with Unix format (so don't use Notepad
nor Wordpad). There are a number of editors
freely available that can be used.
-
@itemize @bullet
@item @b{VIM} (@b{Vi IMproved}) is available from
@b{http://www.vim.org/}. This editor has the very
@@ -81,14 +105,14 @@ The GNU Emacs on Windows NT and Windows 95/98 FAQ is
at @b{http://www.gnu.org/software/emacs/windows/ntemacs.html}.
@item @b{PFE} (@b{Programmers File Editor}) may be downloaded
-from @b{@value{PFE-FTP},@value{PFE-FTP}}. Note this
+from @b{http://www.simtel.net/pub/simtelnet/win95/editor/pfe101i.zip}. Note this
editor is no longer actively supported.
-@c @uref{@value{PFE-FTP},@value{PFE-FTP}}
+@c @uref{http://www.simtel.net/pub/simtelnet/win95/editor/pfe101i.zip}
@end itemize
-@subsection Bug in Patch Utility
+@subsubsection Bug in Patch Utility
There is a bug in the @code{patch} utility
provided in Cygwin32 B19. The files modified end up
@@ -103,35 +127,36 @@ Dos2Unix: Cleaning file XYZ ...
The dos2unix utility may be downloaded from:
-@c @uref{@value{DOS2UNIX-FTP},@value{DOS2UNIX-FTP}}
-@b{@value{DOS2UNIX-FTP},@value{DOS2UNIX-FTP}}
+@c @uref{ftp://ftp.micros.hensa.ac.uk/platforms/ibm-pc/ms-dos/simtelnet/txtutl/dos2unix.zip,ftp://ftp.micros.hensa.ac.uk/platforms/ibm-pc/ms-dos/simtelnet/txtutl/dos2unix.zip}
+@b{ftp://ftp.micros.hensa.ac.uk/platforms/ibm-pc/ms-dos/simtelnet/txtutl/dos2unix.zip}
You @b{must} change the format of every patched file
for the toolset build to work correctly.
-@subsection Files Needed
+@subsubsection Files Needed
This section lists the files required to build and install
a Windows hosted GNU cross development toolset and their
home WWW site. In addition to the sources required
-for the cross environment listed earlier in @ref{Get All the Pieces},
-you will need to download the following
+for the RTEMS cross environment listed earlier in this manual,
+you may need to download the following
files from their respective sites using your favorite
-Web browser or ftp client.
+Web browser or ftp client. [NOTE: This information was current when B19
+was released and URLs may no longer be correct.]
@table @b
@item cdk.exe
-@c @uref{@value{CYGWIN-FTP},@value{CYGWIN-FTP}}
-@b{@value{CYGWIN-FTP},@value{CYGWIN-FTP}}
+@c @uref{http://www.cygnus.com/misc/gnu-win32/,http://www.cygnus.com/misc/gnu-win32/}
+@b{http://www.cygnus.com/misc/gnu-win32/}
@item coolview.tar.gz
-@c @uref{@value{CYGWIN-COOLVIEW},@value{CYGWIN-COOLVIEW}}
-@b{@value{CYGWIN-COOLVIEW},@value{CYGWIN-COOLVIEW}}
+@c @uref{http://www.lexa.ru/sos/,http://www.lexa.ru/sos/}
+@b{http://www.lexa.ru/sos/}
@end table
-@subsection System Requirements
+@subsubsection System Requirements
Although the finished cross-compiler is fairly easy on resources,
building it can take a significant amount of processing power and
@@ -152,10 +177,10 @@ Even with this spec of machine expect the full suite to take over 2 hours to
build with a further half an hour for RTEMS itself.
-@section Installing Cygwin32 B19
+@subsection Installing Cygwin32 B19
This section describes the process of installing the
-version @value{CYGWIN-VERSION} of the Cygwin32 environment. It assumes
+version B19 of the Cygwin32 environment. It assumes
that this toolset is installed in a directory
referred to as @code{<RTOS>}.
@@ -214,16 +239,16 @@ cp <RTOS>/cygnus/b19/H-i386-cygwin32/bin/bash.exe /bin
@item Open the file
@code{/cygnus/b19/H-i386-cygwin32/lib/gcc-lib/i386-cygwin32/2.7-b19/specs},
-and change the following line:
+and append
@example
--lcygwin %@{mwindows:-luser32 -lgdi32 -lcomdlg32@} -lkernel32
+-ladvapi32
@end example
-to:
+to the following line:
@example
--lcygwin %@{mwindows:-luser32 -lgdi32 -lcomdlg32@} -lkernel32 -ladvapi32
+-lcygwin %@{mwindows:-luser32 -lgdi32 -lcomdlg32@} -lkernel32
@end example
@end enumerate
@@ -235,25 +260,26 @@ are ready to proceed to building a cross-compiler.
@c BINUTILS
@c
-@section Installing binutils
+@subsection Installing binutils
@enumerate
@item Unarchive @value{BINUTILS-TAR} following the
instructions in @ref{Unarchiving the Tools} into the /source directory.
Apply the appropriate RTEMS specific patch as detailed in
-@ref{Apply RTEMS Patch to binutils}.
+@ref{Applying RTEMS Patches}.
@item In the @code{/build/binutils} directory, execute the following
command to configure @value{BINUTILS-VERSION}:
@example
-/source/@value{BINUTILS-UNTAR}/configure --verbose --target=m68k-rtems \
+/source/@value{BINUTILS-UNTAR}/configure \
+ --verbose --target=m68k-rtems \
--prefix=/gcc-m68k-rtems --with-gnu-as --with-gnu-ld
@end example
Replace @code{m68k-rtems} with the target configuration
-of your choice. See @ref{Running the bit Script} for a
+of your choice. See @ref{Using the bit Script} for a
list of the targets available.
@item Execute the following command to compile the toolset:
@@ -269,7 +295,7 @@ make -k install
@end example
There is a problem with the gnu info package which will cause an
-error during installation. Telling make to keep going with -k allows
+error during installation. Telling make to keep going with @code{-k} allows
the install to complete.
@item In the @code{cygnus.bat} file, add the directory
@@ -292,13 +318,13 @@ the Cygwin32 environment with the new path.
@c GCC
@c
-@section Installing GCC AND NEWLIB
+@subsection Installing GCC AND NEWLIB
@enumerate
@item Unarchive and patch @value{GCC-TAR} and @value{NEWLIB-TAR}
following the instructions in @ref{Unarchiving the Tools}.
Apply the appropriate RTEMS specific patches as detailed in
-@ref{Apply RTEMS Patch to GCC} and @ref{Apply RTEMS Patch to newlib}.
+@ref{Applying RTEMS Patches}.
@b{NOTE}: See @ref{Bug in Patch Utility}.
@@ -324,13 +350,14 @@ or Objective-C as Cygwin32 cross-compilers):
@item Change to the /build/gcc directory to configure the compiler:
@example
-/source/@value{GCC-UNTAR}/configure --verbose --target=m68k-rtems \
+/source/@value{GCC-UNTAR}/configure \
+ --verbose --target=m68k-rtems \
--prefix=/gcc-m68k --with-gnu-as --with-gnu-ld \
--with-newlib
@end example
Replace @code{m68k-rtems} with the target configuration
-of your choice. See @ref{Running the bit Script} for a
+of your choice. See @ref{Using the bit Script} for a
list of the targets available.
@item Compile the toolset as follows:
@@ -354,10 +381,6 @@ make -k install
info package not building correctly requires that you use -k to
keep going.
-@example
-make -k install
-@end example
-
@end enumerate
With any luck, at this point you having a working cross-compiler. So
diff --git a/doc/started/require.t b/doc/started/require.t
index bbd619fca8..0aff933b7d 100644
--- a/doc/started/require.t
+++ b/doc/started/require.t
@@ -1,5 +1,5 @@
@c
-@c COPYRIGHT (c) 1988-1999.
+@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@@ -8,6 +8,11 @@
@chapter Requirements
+This chapter describes the build-host system requirements and initial steps
+in installing the GNU C/C++ Cross Compiler Tools and RTEMS on a build-host.
+
+@section Disk Space
+
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:
@@ -18,7 +23,7 @@ assessing the amount of disk space required for your installation:
+------------------------------------+--------------------------+
| archive directory | 35 Mbytes |
| tools src unarchived | 150 Mbytes |
-| each individual build directory | 300 Mbytes |
+| each individual build directory | up to 500 Mbytes |
| each installation directory | 20-200 Mbytes |
+------------------------------------+--------------------------+
@end example
@@ -39,14 +44,16 @@ 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
+account in order 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.
+space requirements but since the tests are not installed has,
+enabling them has no impact on installation requirements.
+
+@section General Host Software Requirements
The instructions in this manual should work on any computer running
a UNIX variant. Some native GNU tools are used by this procedure
@@ -61,10 +68,34 @@ including:
In addition, some native utilities may be deficient for building
the GNU tools.
-@section GNU makeinfo Version Requirements
+@subsection GCC
+
+Although RTEMS itself is intended to execute on an embedded target,
+there is source code for some native programs included with the RTEMS
+distribution. Some of these programs are used to assist in the building
+of RTEMS itself, while others are BSP specific tools. Regardless,
+no attempt has been made to compile these programs with a non-GNU
+compiler.
+
+@subsection GNU Make
+
+Both NEWLIB and RTEMS use GNU make specific features and can only be built
+using GNU make. Many systems include a make utility that is not GNU make.
+The safest way to meet this requirement is to ensure that when you invoke
+the command @code{make}, it is GNU make. This can be verified by
+attempting to print the GNU make version information:
+
+@example
+make --version
+@end example
+
+If you have GNU make and another make on your system, it is common to put
+the directory containing GNU make before the directory containing other
+implementations of make.
+
+@subsection GNU makeinfo Version Requirements
-In order to build egcs 1.1b, gcc 2.9.x, or newer versions, the GNU
-@code{makeinfo} program
+In order to build gcc 2.9.x or newer versions, the GNU @code{makeinfo} program
installed on your system must be at least version 1.68. The appropriate
version of @code{makeinfo} is distributed with @code{gcc}.
@@ -75,3 +106,114 @@ on your machine:
makeinfo --version
@end example
+@c
+@c Host Specific Notes
+@c
+
+@section Host Specific Notes
+
+@subsection Solaris 2.x
+
+The following problems have been reported by Solaris 2.x users:
+
+@itemize @bullet
+
+@item 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}, @code{bit_gdb}, and @code{bit_rtems} to use the
+@code{/bin/ksh} shell instead.
+
+@item The native @code{patch} program is broken. Install the GNU version.
+
+@item The native @code{m4} program is deficient. Install the GNU version.
+
+@end itemize
+
+@subsection Linux
+
+The following problems have been reported by Linux users:
+
+@itemize @bullet
+
+@item Certain versions of GNU fileutils include a version of
+@code{install} which does not work properly. Please perform
+the following test to see if you need to upgrade:
+
+@example
+install -c -d /tmp/foo/bar
+@end example
+
+If this does not create the specified directories your install
+program will not install RTEMS properly. You will need to upgrade
+to at least GNU fileutils version 3.16 to resolve this problem.
+
+@end itemize
+
+@section Archive and Build Directories
+
+If you are using RPM or another packaging format that supports
+building a package from source, then there is probably a directory
+structure assumed by that packaging format. Otherwise, you
+are free to use whatever organization you like. However, this
+document will use the directory organization described
+in @ref{Archive and Build Directory Format}.
+
+@subsection RPM Archive and Build Directory Format
+
+For RPM, it is assumed that the following subdirectories
+are under a root directory such as @code{/usr/src/redhat}:
+
+@example
+BUILD
+RPMS
+SOURCES
+SPECS
+SRPMS
+@end example
+
+For the purposes of this document, the RPM @code{SOURCES} directory
+is the directory into which all tool source and patches are
+assumed to reside. The @code{BUILD} directory is where the actual
+build is performed when building binaries from a source RPM.
+The @code{SOURCES} and @code{BUILD} are logically equivalent to
+the @code{archive} and @code{tools} directory discussed in the
+next section.
+
+@subsection Archive and Build Directory Format
+
+When no packaging format requirements are present, the root directory for
+the storage of source archives and patches as well as for building the
+tools is up to the user. The only concern is that there be enough
+disk space to complete the build.
+
+Make an @code{archive} directory to contain the downloaded
+source code and a @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
+
+
diff --git a/doc/started/sample.t b/doc/started/sample.t
index 4fd763838d..18b8cfef05 100644
--- a/doc/started/sample.t
+++ b/doc/started/sample.t
@@ -1,5 +1,5 @@
@c
-@c COPYRIGHT (c) 1988-1999.
+@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@@ -8,7 +8,7 @@
@chapter Building the Sample Application
-@section Unpack the Sample Application
+@section Unarchive the Sample Application
Use the following command to unarchive the sample application:
@@ -19,11 +19,11 @@ tar xzf ../archive/hello_world_c.tgz
@section Set the Environment Variable RTEMS_MAKEFILE_PATH
-It must point to the appropriate directory containing RTEMS build for our
-target and board support package combination.
+RTEMS_MAKEFILE_PATH must point to the appropriate directory containing
+RTEMS build for our target and board support package combination.
@example
-export RTEMS_MAKEFILE_PATH = <INSTALLATION_POINT>/<BOARD_SUPPORT_PACKAGE>
+export RTEMS_MAKEFILE_PATH=<INSTALLATION_POINT>/<BOARD_SUPPORT_PACKAGE>
@end example
Where <INSTALLATION_POINT> and <BOARD_SUPPORT_PACKAGE> are those used when
@@ -35,10 +35,11 @@ was changed to be more in compliance with GNU standards.
@section Build the Sample Application
-Use the following command to start the build of the sample application:
+Use the following command to start the build of the sample hello
+world application:
@example
-cd tools/hello_world_c
+cd hello_world_c
make
@end example
@@ -52,21 +53,79 @@ combination was done properly.
@section Application Executable
-If the sample application has successfully been build, then the application
+If the sample application has successfully been built, then the application
executable is placed in the following directory:
@example
-tools/hello_world_c/o-optimize/<filename>.exe
+hello_world_c/o-optimize/<filename>.exe
@end example
How this executable is downloaded to the target board is very dependent
-on the BOARD_SUPPORT_PACKAGE selected.
+on the BOARD_SUPPORT_PACKAGE selected. The following is a list of
+commonly used BSPs classified by their RTEMS CPU family and pointers
+to instructions on how to use them. [NOTE: All file names should be
+prepended with @value{RTEMS-UNTAR}/c/src/lib/libbsp.]
+
+@need 1000
+@table @b
+
+@item i386/pc386
+See @code{i386/pc386/HOWTO}
+
+@item i386/pc486
+The i386/pc386 BSP specially compiled for an i486-class CPU.
+
+@item i386/pc586
+The i386/pc386 BSP specially compiled for a Pentium-class CPU.
+
+@item i386/pc686
+The i386/pc386 BSP specially compiled for a Pentium II.
+
+@item i386/pck6
+The i386/pc386 BSP specially compiled for an AMD K6.
+
+@item m68k/gen68360
+This BSP is for a MC68360 CPU. See @code{m68k/gen68360/README} for details.
+
+@item m68k/mvme162
+See @code{m68k/mvme162/README}.
+
+@item m68k/mvme167
+See @code{m68k/mvme167/README}.
+
+@item powerpc/mcp750
+See @code{powerpc/motorola_shared/README}.
+
+@item powerpc/mvme230x
+See @code{powerpc/motorola_shared/README.MVME2300}.
+
+@item powerpc/psim
+This is a BSP for the PowerPC simulator included with @code{powerpc-rtems-gdb}.
+The simulator is complicated to initialize by hand. The user is referred
+to the script @code{powerpc/psim/tools/psim}.
+
+@item sparc/erc32
+The ERC32 is a radiation hardened SPARC V7. This BSP can be used with
+either real ERC32 hardware or with the simulator included with
+@code{sparc-rtems-gdb}. An application can be run on the simulator
+by executing the following commands upon entering @code{sparc-rtems-gdb}:
+
+@example
+target sim
+load
+run
+@end example
+
+@end table
+
+RTEMS has many more BSPs and new BSPs for commercial boards and CPUs
+with on-CPU peripherals are generally welcomed.
@section More Information on RTEMS Application Makefiles
The hello world sample application is a simple example of an
-RTEMS application the uses the RTEMS Application Makefile
-system. This Makefile system gives simplifies building
+RTEMS application that uses the RTEMS Application Makefile
+system. This Makefile system simplifies building
RTEMS applications by providing Makefile templates and
capturing the configuration information used to build
RTEMS specific to your BSP. Building an RTEMS application
diff --git a/doc/started/stamp-vti b/doc/started/stamp-vti
index 27e5ccd0cb..91e60ee8f2 100644
--- a/doc/started/stamp-vti
+++ b/doc/started/stamp-vti
@@ -1,3 +1,3 @@
-@set UPDATED 1 June 2000
+@set UPDATED 17 January 2002
@set EDITION 1
-@set VERSION 4.5.0-beta3
+@set VERSION 4.5.1-pre3
diff --git a/doc/started/started.texi b/doc/started/started.texi
index 17516cc21d..54a06d1bda 100644
--- a/doc/started/started.texi
+++ b/doc/started/started.texi
@@ -1,13 +1,14 @@
\input texinfo @c -*-texinfo-*-
@c %**start of header
@setfilename started
+@setcontentsaftertitlepage
@syncodeindex vr fn
@synindex ky cp
@c @paragraphindent 0
@c %**end of header
@c
-@c COPYRIGHT (c) 1988-1999.
+@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@@ -65,7 +66,6 @@
@include buildc.texi
@include buildrt.texi
@include sample.texi
-@include gdb.texi
@include nextstep.texi
@include nt.texi
@@ -82,7 +82,6 @@ This is the online version of the Getting Started with RTEMS for C/C++ Users.
* Building the GNU C/C++ Cross Compiler Toolset::
* Building RTEMS::
* Building the Sample Application::
-* Building the GNU Debugger::
* Where To Go From Here::
* Using MS-Windows as a Development Host::
@end menu
diff --git a/doc/started/tversions.texi b/doc/started/tversions.texi
index 0dbf7fbeac..1ecde954a0 100644
--- a/doc/started/tversions.texi
+++ b/doc/started/tversions.texi
@@ -1,5 +1,5 @@
@c
-@c COPYRIGHT (c) 1988-1999.
+@c COPYRIGHT (c) 1988-2002.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@@ -21,33 +21,33 @@
@c GCC Version
@c
-@set GCC-VERSION gcc 2.95.2
-@set GCC-TAR gcc-2.95.2.tar.gz
-@set GCC-UNTAR gcc-2.95.2
+@set GCC-VERSION gcc 2.95.3
+@set GCC-TAR gcc-everything-2.95.3.tar.gz
+@set GCC-UNTAR gcc-2.95.3
@set GCC-FTPSITE gcc.gnu.org
-@set GCC-FTPDIR /pub/gcc/gcc-2.95.2
+@set GCC-FTPDIR /pub/gnu/gcc/
@set GCC-HTTPDIR /pub/gcc/releases/index.html
-@set GCC-RTEMSPATCH gcc-2.95.2-rtems-20000427.diff.gz
+@set GCC-RTEMSPATCH gcc-2.95.3-rtems-20010622a.diff.gz
@c
@c BINUTILS Version
@c
@c The "official" binutils
-@c @set BINUTILS-VERSION binutils 2.9.1
-@c @set BINUTILS-TAR binutils-2.9.1.tar.gz
-@c @set BINUTILS-UNTAR binutils-2.9.1
-@c @set BINUTILS-FTPSITE ftp.gnu.org
-@c @set BINUTILS-FTPDIR /pub/gnu
-@c @set BINUTILS-RTEMSPATCH binutils-2.9.1-rtems-diff-19981012.gz
+@set BINUTILS-VERSION binutils 2.10
+@set BINUTILS-TAR binutils-2.10.tar.gz
+@set BINUTILS-UNTAR binutils-2.10
+@set BINUTILS-FTPSITE ftp.gnu.org
+@set BINUTILS-FTPDIR /pub/gnu/binutils
+@set BINUTILS-RTEMSPATCH binutils-2.10-rtems-diff-20001107.gz
@c The "official" Linux binutils
-@set BINUTILS-VERSION binutils 2.9.5.0.24
-@set BINUTILS-TAR binutils-2.9.5.0.24.tar.gz
-@set BINUTILS-UNTAR binutils-2.9.5.0.24
-@set BINUTILS-FTPSITE ftp.varesearch.com
-@set BINUTILS-FTPDIR /pub/support/hjl/binutils
-@set BINUTILS-RTEMSPATCH binutils-2.9.5.0.24-rtems-20000207.diff.gz
+@c @set BINUTILS-VERSION binutils 2.9.5.0.24
+@c @set BINUTILS-TAR binutils-2.9.5.0.24.tar.gz
+@c @set BINUTILS-UNTAR binutils-2.9.5.0.24
+@c @set BINUTILS-FTPSITE ftp.varesearch.com
+@c @set BINUTILS-FTPDIR /pub/support/hjl/binutils
+@c @set BINUTILS-RTEMSPATCH binutils-2.9.5.0.24-rtems-20000207.diff.gz
@c When forced to use a snapshot
@c @set BINUTILS-VERSION gas 980314
@@ -65,30 +65,30 @@
@set NEWLIB-VERSION newlib 1.8.2
@set NEWLIB-TAR newlib-1.8.2.tar.gz
@set NEWLIB-UNTAR newlib-1.8.2
-@set NEWLIB-FTPSITE sourceware.cygnus.com
+@set NEWLIB-FTPSITE sources.redhat.com
@set NEWLIB-FTPDIR /pub/newlib
-@set NEWLIB-RTEMSPATCH newlib-1.8.2-rtems-20000501.diff.gz
+@set NEWLIB-RTEMSPATCH newlib-1.8.2-rtems-20000606.diff.gz
@c
@c GDB Version
@c
-@set GDB-VERSION gdb 4.18
-@set GDB-TAR gdb-4.18.tar.gz
-@set GDB-UNTAR gdb-4.18
+@set GDB-VERSION gdb 5.0
+@set GDB-TAR gdb-5.0.tar.gz
+@set GDB-UNTAR gdb-5.0
@set GDB-FTPSITE ftp.gnu.org
@set GDB-FTPDIR /pub/gnu/gdb
-@set GDB-RTEMSPATCH gdb-4.18-rtems-20000502.diff.gz
+@set GDB-RTEMSPATCH gdb-5.0-rtems-20010314.diff.gz
@c
@c RTEMS Version
@c
-@set RTEMS-VERSION RTEMS 4.5.0-beta3
-@set RTEMS-TAR rtems-4.5.0-beta3.tgz
-@set RTEMS-UNTAR rtems-4.5.0-beta3
+@set RTEMS-VERSION RTEMS 4.5.1
+@set RTEMS-TAR rtems-4.5.1.tgz
+@set RTEMS-UNTAR rtems-4.5.1
@set RTEMS-FTPSITE ftp.OARcorp.com
-@set RTEMS-FTPDIR /pub/rtems/betas/rtems-4.5.0-beta
-@set BUILDTOOLS-TAR c_build_scripts-4.5.0-beta3.tgz
+@set RTEMS-FTPDIR /pub/rtems/releases/4.5.1
+@set BUILDTOOLS-TAR c_build_scripts-4.5.1.tgz
diff --git a/doc/started/version.texi b/doc/started/version.texi
index 27e5ccd0cb..91e60ee8f2 100644
--- a/doc/started/version.texi
+++ b/doc/started/version.texi
@@ -1,3 +1,3 @@
-@set UPDATED 1 June 2000
+@set UPDATED 17 January 2002
@set EDITION 1
-@set VERSION 4.5.0-beta3
+@set VERSION 4.5.1-pre3