6. Hardware

This section discusses supported Hardware, Architectures, Board Support Packages, and running RTEMS on real hardware and simulators.

6.1. Targets

Hardware that can run RTEMS is often referred to as a target because RTEMS is specifically aimed at that hardware or target. An RTEMS executable is statically linked and executes in a single address space on the target hardware. A statically linked executable means the RTEMS Kernel, drivers, third party packages and application code is linked into a single executable image. A single address space means no virtual memory and no memory protected process address space is running within the RTEMS arena and the RTEMS Kernel, drivers and application have unprotected access to the whole address space and all hardware.

Target hardware supported by RTEMS has a Board Support Package or BSP. A BSP is a specific instance of an RTEMS architecture that allows the creation of an RTEMS executable. You can view the layering as:

Software Layers on Hardware

RTEMS Targets are grouped by architectures and within an architecture there are a number of Board Support Packages or BPSs. An architecture is a specific class or family of processors and can be large such as ARM or specific such as the NIOS-II or Microblaze.

RTEMS is designed to be ported to new target hardware easily and efficiently.

6.2. Architectures

An RTEMS architecture is a class or family of a processor that RTEMS supports. The RTEMS architecture model follows the architecture model of GCC. An architecture in GCC results in a specific RTEMS GCC compiler. This compiler may support a range of processors in the family that may have differences in instructions sets or floating point support. RTEMS configures GCC to create separate runtime libraries for each supported instruction set and floating point unit in the architecture. This is termed multlib. Multlibs are manage automatically by GCC by selecting a specific instruction set or specific device in a family.

RTEMS executables are statically linked for a specific target therefore a precise and exact match can be made for the hardware that extracts the best possible performance. The compiler supports the variants to the instruction set and RTEMS extends the specialization to specific processors in an architecture. This specialization gives RTEMS a finer resolution of features and capabilites a specific device may offer allowing the kernel, drivers and application to make the most of those resources. The trade off is portability however this is not important because the executable are statically linked for a single target.

Note

RTEMS support dynamically load code through the dlopen interface. Loading code via this interface results in an executable image that is equivalent to statically linked executable of the same code. Dynamic loading is a system level tool for system architects.

RTEMS supports 17 architectures:

  • arm
  • bfin
  • epiphany
  • i386
  • lm32
  • m32c
  • m68k
  • mips
  • moxie
  • nios2
  • no_cpu
  • or1k
  • powerpc
  • sh
  • sparc
  • sparc64
  • v850

6.3. Board Support Packages (BSP)

A Board Suport Package is a historical term for a package of code, and supporting documentation for a target. The sparation is still important today for users with custom hardware.

RTEMS includes 173 board support packages in it’s source tree and this is a small number of actual targets running because it does not take into account the custom targets.

You can see the BSP list in RTEMS by asking RTEMS with:

$ ./rtems-bsps

6.4. Tiers

RTEMS has a tiered structure for architecture and BSPs. It provides:

  1. A way to determine the state of a BSP in RTEMS.
  2. A quaility measure for changes entering the RTEMS source code.

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.

The rules for Tiers are:

  1. A BSP can only be in one of the following tiers:

    Tier Description
    1
    • The RTEMS Kernel must build without error.
    • Tests are run on target hardware.
    2
    • The RTEMS Kernel must build without error.
    • Tests can be run on simulation.
    3
    • The RTEMS Kernel must build without error.
    • There are no test results.
    4
    • The RTEMS Kernel does not build.
    5
    • The BSP is to be removed after the next release.

  2. An architecuture’s tier is set by the highest BSP tier reached.

  3. 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.

  4. Changes to RTEMS may result in a BSP not meeting it’s tier are acceptable if the change is accompanied by an announcement and a plan on how this is to be resolved.

  5. 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 as:

    1. Passes
    2. Expected Failures

    Expected failures must be explicitly listed. A BSP is required to have a valid test result entry to reach tier 1.