path: root/user/hardware/tiers.rst
diff options
authorJoel Sherrill <>2019-12-09 14:59:49 -0600
committerJoel Sherrill <>2019-12-12 10:59:38 -0600
commit01be51383f39afb3803a05f4bbcce5d91737b06e (patch)
tree692ab68ef41e7e7c4e0ed56d6ef38f49c5a5c842 /user/hardware/tiers.rst
parentf7d56f579869ff0bd3acd95c8e245743605f4633 (diff)
user/hardware/tiers.rst: Merge info from Wiki.
Tiers had a write up on the Wiki which was similar but different. Merged content from the Wiki which allows the Wiki page to be deleted. closes #3831.
Diffstat (limited to '')
1 files changed, 28 insertions, 5 deletions
diff --git a/user/hardware/tiers.rst b/user/hardware/tiers.rst
index aeea26c..9465eb6 100644
--- a/user/hardware/tiers.rst
+++ b/user/hardware/tiers.rst
@@ -14,9 +14,32 @@ RTEMS has a tiered structure for architecture and BSPs. It provides:
#. A quaility measure for changes entering the RTEMS source code.
+The RTEMS project supports RTEMS Architecture Tiers. Each architecture
+resided in one of the numbered tiers. The tiers are number 1 to 4 where
+Tier 1 is the highest tier and Tier 4 is the lowest. Architectures move
+between tiers based on the level of support and the level of testing that
+is performed. An architecture requires continual testing and reporting
+of test results to maintain a tier level. The RTEMS Project's continuous
+integration testing program` continually monitors and reports the test
+The RTEMS Architecture Tier system provides a defined way to determine
+the state of an architecture in RTEMS. Architectures age and support
+for them drops off and the RTEMS Project needs a way to determine
+if an architecture should stay and be supported or depreciated and
+removed. The tier system also provides users with a clear understanding of
+the state of an architecture in RTEMS, often useful when deciding on
+a processor for a new project. It can also let a user know the RTEMS
+Project needs support to maintain a specific architecture. Access to
+hardware to perform testing is a large and complex undertaking and the
+RTEMS Project is always looking for user support and help. If you can
+help please contact someone and let us know.
The tier structure in RTEMS is support by the Buildbot continuous integration
server. Changes to RTEMS are automatically built and tested and the results
-indicate if a BSP currently meets it's tier status.
+indicate if a BSP currently meets its tier status. As the RTEMS Project
+does not own hardware for every BSP, it is critical that users provide
+test results on hardware of interest.
The rules for Tiers are:
@@ -43,11 +66,11 @@ The rules for Tiers are:
#. The tier level for a BSP is set by the RTEMS Project team. Movement of BSP
between tier level requires agreement. The Buildbot results indicate the
- current tier level.
+ minimum current tier level.
-#. Changes to RTEMS may result in a BSP not meeting it's tier are acceptable if
+#. Changes to RTEMS may result in a BSP not meeting its tier are acceptable if
the change is accompanied by an announcement and a plan on how this is to be
- resolved.
+ resolved. Temporary drops in tier are expected and should be brief.
#. Test results are set on a per BSP basis by the RTEMS Project team. Changes
to the test result values requires agreement. The test results are defined
@@ -58,4 +81,4 @@ The rules for Tiers are:
#. Expected Failures
Expected failures must be explicitly listed. A BSP is required to have a
- valid test result entry to reach tier 1.
+ valid test result entry on target hardware to reach tier 1.