|author||Chris Johns <email@example.com>||2017-11-13 13:25:18 +1100|
|committer||Chris Johns <firstname.lastname@example.org>||2017-11-13 13:25:18 +1100|
Clean up sphinx warnings.
- Fix minor formatting issues. - Fix reference the gloassary TLS using ':term:'. - Make sure nothing is between an anchor and the heading where ':ref:' references the anchor. This meant moving all the recently added '.. index::' entries. Update #3232. Update #3229.
Diffstat (limited to 'user/tools')
3 files changed, 38 insertions, 46 deletions
diff --git a/user/tools/index.rst b/user/tools/index.rst
index 6cf3509..00d6b21 100644
@@ -19,6 +19,5 @@ developers.
diff --git a/user/tools/simulation.rst b/user/tools/simulation.rst
deleted file mode 100644
@@ -1,13 +0,0 @@
-.. comment SPDX-License-Identifier: CC-BY-SA-4.0
-.. index:: Simulation Tools, rtems-run
diff --git a/user/tools/tester.rst b/user/tools/tester.rst
index 6e79799..0c07415 100644
@@ -3,34 +3,34 @@
.. comment: Copyright (c) 2017 Chris Johns <email@example.com>
.. comment: All rights reserved.
-.. index:: Tools, rtems-tester
+RTEMS Tester and Run Commands
-The RTEMS Tester is a test framework. It includes a command line interface to
-run tests on supported targets. The framework provides back-end support for
-common simulators and debuggers. The board support package (BSP) configurations
-for RTEMS are provided and can be used to run all the tests provided with
-RTEMS. The framework is not specific to RTEMS and can be configured to run any
+.. index:: Tools, rtems-test, rtems-run
+The RTEMS Tester is a test tool that provides a command line interface to run
+test executable on supported targets. The tool provides back-end support for
+common simulators, debuggers and boot loaders. Board support package (BSP)
+configurations for RTEMS are provided and can be used to run all the tests in
+the RTEMS test suite. The tool and it's framework is not specific to RTEMS and
+can be configured to run any suitable application.
RTEMS is an embedded operating system and is cross-compiled on a range of host
machines. The executables run on the target hardware and this can vary widely
from open source simulators, commercial simulators, debuggers with simulators,
-to debuggers with hardware specific pods and devices. Testing RTEMS requires
-the cross-compiled test executable is transferred to the target hardware,
-executed and the output returned to the host where it is analyzed to determine
-the test result. The RTEMS Tester provides a framework to do this.
-Running all the RTEMS tests on your target is very important. It provides you
-with a traceable record showing that your RTEMS version and its tools are
-working at the level the RTEMS development team expect when releasing
-RTEMS. Being able to easily run the tests and verify the results is critical in
-maintaining a high standard.
-This document is for users of the RTEMS Tester as well as those wanting to
-develop, extend and investigate the RTEMS Tester.
+debuggers with hardware specific pods and devices to targe boot
+loaders. Testing RTEMS requires the cross-compiled test executable is
+transferred to the target hardware, executed and the output captured and
+returned to the test host where it is analyzed to determine the test
+Running the RTEMS tests on your target is very important. It provides you with
+a traceable record showing that your RTEMS version and its tools are working at
+the level the RTEMS development team expect when releasing RTEMS. Being able to
+easily run the tests and verify the results is critical in maintaining a high
Available BSP testers
@@ -42,9 +42,11 @@ You can list the available BSP testers with:
$ rtems-test --list-bsps
@@ -54,6 +56,7 @@ You can list the available BSP testers with:
.. note:: The list is growing all the time and if your BSP is not supported we
encourage you to add it and submit the configuration back to the
@@ -70,7 +73,7 @@ Building RTEMS Tests
Build the RTEMS Kernel (See :ref:`rtems-kernel`) by cloning the repository,
-running the ``bootstrap`` procecure, building and finally installing the
+running the ``bootstrap`` procedure, building and finally installing the
kernel. Be sure to enable tests by using ``--enable-tests`` option with
configure after running ``bootstrap``.
@@ -80,15 +83,20 @@ configure after running ``bootstrap``.
-Add the -j option to the make command with the number of cores to run the
-build parallel where it can.
+Add the `-j` option to the make command with the number of cores to run a
Building all the tests takes time and it uses more disk so be patient. When
-finished all the tests will be built and ready to run. Before running all the
-tests it is a good idea to run the ``hello`` test. The ``hello`` test is an
-RTEMS version of the classic "Hello World" example and running it shows you
-have a working tool chain and build of RTEMS ready to run the tests. Using the
+finished all the tests will have been built. Some BSPs may require a post-build
+process to be run on the RTEMS ELF executable to create an image suitable for
+execution. This can be built into the configuration script and the tester will
+perform a pre-test command to covert the executable to a suitable format for
+Before running all the tests it is a good idea to run the ``hello`` test. The
+``hello`` test is an RTEMS version of the classic "Hello World" example and
+running it shows you have a working tool chain and build of RTEMS ready to run
+the tests. Using the run with the ERC32 BSP the command is:
.. code-block:: shell
@@ -186,8 +194,6 @@ BSP build tree:
Average test time: 0:00:27.963000
Testing time : 0:06:03.519012
* The RTEMS Tester's test command. In this example we are using an absolute
* The ``--log`` option sends the output to a log file. By default only failed