Version 12 (modified by Tanu Hari Dixit, on May 24, 2017 at 1:29:58 PM) (diff)


RTEMS Tester Improvements

Student: Tanu Hari Dixit.

Mentors: Kuan-Hsun Chen, Chris Johns.

Introduction: RTEMS-Tester is a test framework which can execute tests not only those related to RTEMS but also for any suitable application. The RTEMS testing tool resides in the RTEMS Tools package and this project aims at enhancing and improving some of the existing functionality and to complete needed parts.

Related Open Project Tickets:

Objectives: The objectives of the project are:

  • As of now, the configuration file format is a simple text file (with .mc extension) that serves to provide all the needed macros. This is really cryptic and needs to be converted to a suitable configuration format. I believe if I could add support for configuration files in YAML INI format, which will make it more readable, it would come really handy for developers to understand and tune them to their needs.
  • Also, sometimes a BSP configuration needs some user-specific data to function as expected. For example, look at this1 macro file. Here, the path to the first stage bootloader (fsbl) has to be provided that is placed somewhere in the host machine. For this there should be proper control provided to the user as opposed to the hard coded configuration that is presently the case. This will help in the tunability of the configuration files.
  • Currently, the tests that are expected to fail, the results of which are indeterminate and those which timeout because they expect input from user, all are counted as failed (or timeouts in the last case). This masks the actual reasons why a certain test failed (or timed out) and eventuate into test statistics that can be easily misunderstood. Therefore, one objective of the project is to add support for test states “expected-fail”, “indeterminate” and “user-input”, so that they can be tracked separately.
  • Furthermore, regression analysis is another objective of the project. Adding YAML files for each bsp that contain an expected statistic for the tests, shall help the cause. Hence, this statistic can be compared with the current number of failed tests and help determine if the BSP has regressed against a change in rtems (or the test results in RTEMS need updating.)
  • The present console support in the back end of rtems-tester is given by termios2. This python library does not work on Windows3. Hence, my goal is to integrate PySerial? 4 so that the benefits of it being a cross-platform tool help support consoles on both Windows and Unix.
  • Ser2net is used for providing remote access to a unit’s server ports over telnet. It is proposed to add support for a telnet console in rtems-tester so that it becomes convenient to telnet into serially connected devices and test applications on them, remotely.
  • I’ll add simulator recipes for RTEMS to work with gem5 for sparc64/usiii and arm/realview_pbx_a9_qemu BSPs.
  • I also plan to export the results of rtems-tester to xml format and text-report so that it can be plotted easily and used for other analysis as developers and users deem fit.


We have decided to rewrite configuration files in INI format instead of YAML in the absence of standard support for YAML in Python. Using PyYAML would add a dependency in the tool that would be difficult to handle across all hosts we support.

Handling macro values like %{_rtscripts}:

We will use RawConfigParser? to parse the macros from INI files. It handles %(value) and %{value} both as format specification.

Handling those macro files that need user-specific things

We plan on taking assistance from a user-specified "settings" file that can help the main configuration file with user-specifics. THe ini file should have some defaults that lead to suitable errors which the user can rectify in the settings file.

Macro Maps

The macro maps are like namespaces and shouldn't be mixed for re-usability in different macro files for different BSPs.