{5} Accepted, Active Tickets by Owner (Full Description) (27 matches)

List tickets accepted, group by ticket owner. This report demonstrates the use of full-row display.

Christian Mauderer (2 matches)

Ticket Summary Component Milestone Type Created
#3222 libbsd: WiFi Support needs rc.conf integration network/libbsd Indefinite enhancement 11/09/17

Currently WLAN is still only poorly integrated into libbsd. A number of manual commands are necessary to create a WLAN device.

FreeBSD supports rc.conf lines like the following one for setting up a WLAN device (see rc.conf(5) section ''network_interfaces''):


The rtems-libbsd should support this notation too.

Problematic in this context is that all currently supported WLAN devices are USB devices. These devices need some time to enumerate or can even be hot plugged. Therefore they might not be available during the first parsing of rc.conf.

We need a method to handle such hot plugged events. For that it will be necessary to keep relevant information from the rc.conf available.

Possible Approach The way freebsd handles hot-plug events in general or network device events in special should be analyzed. If possible, a similar method should be implemented in rtems-libbsd.

Necessary Hardware Some board which is supported in rtems-libbsd and has a (supported) USB host connection and a (supported) USB-WiFi?? interface is necessary. A known working board is the Beagle Bone Black with a RTL8188 USB dongle. Some kind of hardware debugger (Segger J-Link, Flyswatter 2, something supported by OpenOCD, ...) is strongly recommended.

Related projects #3223 will need some WiFi?? related rc.conf integration too and maybe depends on some of the functionality here (creating interfaces).

Skills C and low-level programming skills are needed.

This is a large (350-hour) project of hard difficulty.

#3223 libbsd: wpa_supplicant has to be started dynamically network/libbsd Indefinite enhancement 11/09/17

To connect to a WPA encrypted network using libbsd it is currently necessary to restart the wpa_supplicant for each new connection. A better solution for that should be found.

In FreeBSD, the wpa_supplicant will somehow automatically be started if the ifconfig_<interface> line or rc.conf contains a WPA (see rc.conf(5) section network_interfaces).

The rtems-libbsd should have a similar mechanism. One possibility would be to try to make the dhcpcd script hooks usable on RTEMS and start wpa_supplicant from a hook.

Possible Approaches The DHCP client used in the libbsd (dhcpcd) has a script hook support. That support has been removed in the RTEMS port because there is no script interpreter. One possibility would be to try to make the dhcpcd script hooks usable on RTEMS so that they can call C functions instead of the scripts. Such a hook could then start a wpa_supplicant from a hook. Another solution would be to take a detailed look at the FreeBSD implementation and create something similar.

Additional Problems Most likely it will be necessary to start more then one instance of wpa_supplicant (for example if two interfaces are connected). Currently that is not possible. The wpa_supplicant should be reviewed whether it can be started multiple times in parallel.

Necessary Hardware I would recommend some real hardware (like a Beagle Bone Black with a RTL8188 based USB WiFi?? dongle) and a hardware debugger (Segger J-Link, Flyswatter 2, something supported by OpenOCD, ...). Real hardware with WiFi?? is the most likely later use case. Theoretically WPA should be usable on wired interfaces. So it might be possible to develop this in a simulator too. The advantage of this is that there are no hardware costs and a simple debug integration. If you think about that solution, please discuss it with your (planned) mentor before starting.

Related projects #3222 will need some WiFi?? related rc.conf integration too. Maybe the hot-plug detection of that project could be of some use too.

Skills C programming and understanding of system configuration/administration.

This is a 350-hour project of hard difficulty.

Amar Takhar (1 match)

Ticket Summary Component Milestone Type Created
#2262 psxhdr Improvements unspecified Indefinite defect 02/11/15

The test directory testsuites/psxtests/psxhdrs has simple programs which ensure that the RTEMS POSIX implementation defines methods in compliance with that Open Group specification. That specification defines the precise set of header files which are to be included and the method signature. There is one small file per method defined.

The improvements are as follows:

  • reorganize so tests related to the methods in a single POSIX header file are in a logically named directory. For example stdio/ or sys/socket. Directory structure should reflect .h file names.
  • Augment to add cases for missing methods.
  • Older test files do not follow Doxygen header standards and need to be updated.

It would also be nice if this can be easily built on a non-RTEMS platform since it is checking API conformance.

Chris Johns (8 matches)

Ticket Summary Component Milestone Type Created
#2861 Collaspe boxes hover on docs.rtems.org should indicate clickable. doc Indefinite defect 01/14/17

Make the collapse boxes change colour when hovering to indicate the box can be clicked.

#2486 RSB: 4.10 invalid kernel URL tool/rsb 4.10.3 defect 12/08/15
config: tools/rtems-kernel-4.10.2.cfg
package: arm-rtems4.10-kernel-4.10.2-1
download: http://ftp.rtems.org/pub/rtems/4.10.2/rtems-4.10.2.tar.bz2 -> sources/rtems-4.10.2.tar.bz2

download: http://ftp.rtems.org/pub/rtems/4.10.2/rtems-4.10.2.tar.bz2: error: HTTP Error 404: Not Found
error: downloading http://ftp.rtems.org/pub/rtems/4.10.2/rtems-4.10.2.tar.bz2: all paths have failed, giving up
  See error report: rsb-report-arm-rtems4.10-kernel-4.10.2-1.txt
error: downloading http://ftp.rtems.org/pub/rtems/4.10.2/rtems-4.10.2.tar.bz2: all paths have failed, giving up
Build Set: Time 0:09:29.097373
error: downloading http://ftp.rtems.org/pub/rtems/4.10.2/rtems-4.10.2.tar.bz2: all paths have failed, giving up
Build Set: Time 0:09:34.367852

#2960 RSB: Reports modified Git version in case RSB is a Git submodule tool/rsb Indefinite defect 03/30/17

In case the RSB is used as a Git submodules the git status yields

git status
# HEAD detached at b64b38e
nothing to commit, working directory clean

leading to

RTEMS Source Builder - Set Builder, 4.12 (b64b38ef076c modified)

#2979 Load rap files failure with zeroed sections lib/dl 6.1 defect 04/05/17

After patch "libdl: Add C++ exception support to loaded modules." (ticket 2767 Chris Johns <chrisj@…> 2016-12-13 22:07:16 (UTC)) in function rtems_rtl_obj_add_section sections with size == 0 not added to sections list for relocate. In function rtems_rtl_rap_relocate for this sectiions generate error "no target section found". The introduction of the condition "size > 0" in rtems_rtl_obj_add_section was a mistake. I use rap files and plain C (.ctor and .dtor have size == 0).

#3230 RSB does not report --rsb-file for patches correctly. tool/rsb 6.1 defect 11/12/17

The reports from the RSB do not report the --rsb-file option correctly.

#3439 buffer overflow in rtems_rfs_bitmap_create_search() fs/rfs defect 05/30/18

I am encountering a buffer overrun in rtems_rfs_bitmap_create_search(). It seems that whenever the bitmap uses the last bit of its search_map (i.e. (control->size + 31) % 32 == 32)), the loop will write to the word one beyond the end of search_map.

Attached is a simple patch that fixes the problem.

#2612 R_ARM_GOT_BREL relocation type unsupported lib/dl enhancement 02/24/16

If a run-time loaded library contains global variables, its load fails because of an unsupported relocation type. The following is the dlerror message:

.text: Unsupported relocation type 26 in non-PLT relocations

After examining the library's object file, the relocation type for the symbol was determined to be R_ARM_GOT_BREL.

I will update the ticket with a small program that reproduces the error within a couple of days.

#3120 RTEMS - EtherCAT SOEM integration network/legacy Indefinite task 09/05/17

Aim of this ticket is to track the progress of the effort to integrate the EtherCAT Simple Open Source EtherCAT Master (SOEM) with RTEMS.

Issues to be tackled:

  • Generate the required config files to build the upstream source
  • Create the required patches in SOEM to support the RTEMS libraries

Gedare Bloom (2 matches)

Ticket Summary Component Milestone Type Created
#2004 sparc64: problem using softint and timer together bsps Indefinite defect 02/01/12

sparc64 hardware shares an interrupt level (14) between tick comparison and software-raised interrupts. current bsps do not handle the situation of both interrupt sources simultaneously, so software interrupts cannot be used when the timer also is used. What happens is the interrupt level (PIL) does not get set/reset properly and interrupts are missed.

The attached patch is a work-around that hacks the clock isr, but I need to look more closely at the generic ISR handling code to see if the bug is due to interactions between PIL assignment, interrupt enable/disable, and scheduling.

#3939 sparc64: _CPU_ISR_Disable seems broken admin 6.1 defect 04/06/20

Both sparc64 BSPs (usiii, niagara) hang at the first call to _CPU_ISR_Disable in boot_card when run using qemu-system-sparc64.

Hesham Almatary (5 matches)

Ticket Summary Component Milestone Type Created
#3930 RISC-V Clang/LLVM support rtems Indefinite task 04/05/20

This ticket is to monitor progress and RTEMS repos that need to be Clang/LLVM aware. RISC-V is the target backend I work with for RTEMS, and can be used a reference for other architectures.

#3931 Upstream support for RTEMS backend in Clang/LLVM unspecified task 04/05/20

Currently, Clang/LLVM don't have support for RTEMS as a backend. I have pending support that I am planning to submit to Clang/LLVM upstream [1].

[1] https://github.com/CTSRD-CHERI/llvm-project/commits?author=heshamelmatary

#3932 RISC-V Clang/LLVM support in the new RTEMS build system (waf) build Indefinite task 04/05/20

That's basically done [1], just need to submit those patches.

[1] https://github.com/CTSRD-CHERI/rtems/compare/967b62464bf39602f8b0f2baf57617ad74c3643d...8847fa44e68a0d7e0f9e96faf54c88928f8ac141

#3933 rtems_waf support to build with Clang/LLVM build Indefinite task 04/05/20

Patch submitted, but still needs review/corrections [1]

[1] https://lists.rtems.org/pipermail/devel/2020-March/058307.html

#3934 RISC-V libbsd support network/libbsd Indefinite task 04/05/20

I am currently working on RISC-V libbsd and will be submitting patches as soon as I can. Basic applications can build with GCC and internal networking apps (i.e., no ethernet) do seem to be passing. I have on-going Clang/LLVM WIP as well.

Hesham should looped in to get work in process.

Possible Mentors: Hesham, Chris Johns Skills: C Difficulty: Medium

Sebastian Huber (8 matches)

Ticket Summary Component Milestone Type Created
#3034 Convert all serial device drivers to use the new Termios device API bsps Indefinite enhancement 06/08/17

The new Termios device API is documented here:


Legacy drivers can be found via the rtems_termios_open() function.

#3701 RTEMS Pre-Qualification (ECSS) for SMP unspecified 6.1 project 02/26/19

This ticket summarises activities carried out by a 24 month project sponsored by the European Space Agency (ESA). The project start was February 2019.

The main goal of the project is to enable European space missions to use RTEMS as a software product in criticality category C (this is basically category B without independent software verification and validation, ISVV). Criticality category C means according to ECSS-Q-ST-80C:

"Software that if not executed, or if not correctly executed, or whose anomalous behaviour can cause or contribute to a system failure resulting in: Major consequences"

In ECSS-Q-ST-40C major consequences are characterized in Table 6-1 as a major mission degradation without effects to the outside world of the system. A future activity may perform ISVV to enable a use in category B settings.

The qualification will be done according to ECSS standards (ECSS-E-ST-40C and ECSS-Q-ST-80C). The standards are available at


free of charge after registration.

The project consists of four major tasks.

  1. Qualification toolchain

    This task aims to produce a tool chain so that qualification related work can be carried out efficiently. For example: document generation, test suite runs (including code coverage), test reporting, test result archiving, code metrics, static code analysis, traceability (e.g. requirements to tests), etc.
  1. RTEMS SMP qualification data package

    This task covers the main RTEMS components (source code, tests, documentation; new: requirements document, ECSS standard tailoring) so that a data package for space mission consumers can be generated.

    • #3702: Space profile for RTEMS SMP
    • #3703: Technical Specification (TS) for space profile
      • #3715: Add Requirements Engineering chapter to RTEMS Software Engineering Handbook
      • #3726: Select a requirements engineering tool
    • #3705: Software Design Document (SDD) for space profile
      • #3704: Review and update Doxygen recommendations
      • #3706: Create a hierarchy of RTEMS software components using Doxygen groups
      • #3707: Assign each code file to a Doxygen group
      • #3708: Remove Doxygen comments from confdefs.h
    • #3716: Unit, integration and validation tests for space profile
      • #3717: Add test guidelines chapter to RTEMS Software Engineering Handbook
      • #3718: Add support for test plans
      • #3199: New test framework
  1. RTEMS SMP formal verification

    This is a research project. The aim is to apply formal methods for the verification of a subset of the RTEMS SMP algorithms.
  1. RTEMS SMP application porting

    The goal of this task is to port an existing uniprocessor space software from RTEMS 4.8 (RTEMS Improvement by Edisoft) to RTEMS SMP. The algorithms used by the software needs to be parallelized.

The project partners are:

  • Lero with Lero researchers from Trinity College Dublin and University of Limerick from Ireland

The results of this activity should be open source and available to the RTEMS community.

#3703 Technical Specification (TS) for space profile doc 6.1 task 02/26/19

A Technical Specification (TS) is required by ECSS-E-ST-40C and consists of

  • the Software Requirements Specification (SRS, ECSS‐E‐ST‐40C Annex D), and
  • the Software Interface Control Document (ICD, ECSS‐E‐ST‐40C Annex E).

There is currently no requirements document for RTEMS. Requirements must be reverse engineered from the documentation, the source code and the tests. The TS will be created for the space profile of RTEMS SMP. It should be easy to extend the TS so that more functionality can be covered once the ground work is done.

ECSS-E-ST-10-06C places requirements on requirements and the specification content.

We need a format for requirements. One idea is to define a custom XML data model for RTEMS requirements and use an XML document to store the requirements in the RTEMS kernel repository (requirements master document, RMD). The RMD can be used to generate human readable documents via Sphinx.

ECSS-E-ST-10-06C and ECSS-E-ST-40C mandate some of traceability information:

  1. ECSS-E-ST-10-06C, 8.2.3 Configuration management and traceability: The history of requirements shall be traceable. In the XML documents the history of requirements changes, removals, additions, etc. could be stored in a special section along with additional information, e.g. reason for change, date, approval status, etc. A Git pre-commit hook could check that changes in the requirements document follow a specified procedure, e.g. one commit may change at most one requirement and there must be a corresponding revision entry for this change.
  1. ECSS-E-ST-10-06C, 8.2.3 Configuration management and traceability: If a requirements is derived from other requirements, then this information must be visible (backward traceability).
  1. ECSS-E-ST-40C, Verification of the software architectural design: Each software component shall provide a link to the requirements it implements (forward traceability). Software architectural design to requirements traceability matrices shall be provided.
  1. ECSS-E-ST-40C, Verification of code: Source code shall be traceable to design and requirements. Software code traceability matrices shall be provided.
  1. ECSS-E-ST-40C, Verification of software unit testing (plan and results): Unit test shall be traceable to software requirements. Software unit tests traceability matrices shall be provided.

The presentation in a human readable form of the traceability information should be done by tools using the RMD as input and the overall source code with requirement link annotations. This requires that we have a human and machine readable requirements identifier (also ECSS-E-ST-10-06C, 8.2.6 Identifiability).

#3704 Review and update Doxygen recommendations doc 6.1 task 02/26/19

Review and update the Doxygen recommendations.

Due to the removal of the pre-install build step we can now use Doxygen directly with header files in the source tree. It should be possible to generate documentation for all architectures and BSPs.

All code files (headers, C source, assembler) should have an @file entry belong to at least one Doxygen group (@ingroup).

There are a lot of source file in RTEMS (excluding test code and legacy network stack):

find bsps cpukit -name '*.[chsS]' | grep -v libnetworking | wc
   4898    4898  187167

Creating the groups and categorizing all code file is a labour intensive work package. Therefore it should be discussed if the @brief and descriptions for files should be removed. The file content will be covered by groups and individual documentation.

The use of @param should be clarified. It is not clear if the [in], [out] or [in,out] should be used. If they should be used, what they mean exactly.

#3705 Software Design Document (SDD) for space profile doc 6.1 task 02/26/19

A Software Design Document (SDD) is required by ECSS-E-ST-40C specified by Annex F. The plan is to use Doxygen for the software

  • architecture, and
  • detailed design.

How should links to from a software component (Doxygen group) to requirements be handled?

#3706 Create a hierarchy of RTEMS software components using Doxygen groups doc 6.1 task 02/26/19

Create a hierarchy of RTEMS software components using Doxygen groups. Review the existing Doxygen groups (software components) first.


Grouping should be done by at BSP level architecture and then by BSP.

There should be a device driver group with subgroups for each device class and specific device drivers, e.g. a BSP-specific device driver belongs to a device class and BSP.

There should be groups for APIs, file systems, support libraries, super core, etc.

  • Board Support Packages
  • Device Drivers
    • Block Devices
      • Block Device Buffer Management
      • Block Device Disk Management
      • Block Device Management
        • XYZ Block Device
      • Block Device Partition Management
    • Cache
      • XYZ Cache Support
    • Console
      • Termios
        • XYZ Driver
    • Framebuffer
      • XYZ Driver
    • I2C
      • Bus Driver
        • XYZ Driver
      • Device Driver
        • XYZ Driver
    • Legacy I2C
    • Legacy Network
    • RTC
      • XYZ Driver
    • Serial Mouse
      • XYZ Driver
    • SPI
      • Bus Driver
        • XYZ Driver
      • Device Driver
        • XYZ Driver
  • API
    • Classic
      • Tasks
    • Dynamic Loading
    • File Systems
    • Memory Management
    • Shell
    • Tracing
      • Event Recording
      • Capture Engine
  • Internal
    • C Library Support
    • POSIX
    • Shell
    • Super Core
      • Thread Handler
      • CPU
        • ARM

#3707 Assign each code file to a Doxygen group doc 6.1 task 02/26/19

Assign each code file (header, C source, assembler) to a Doxygen group. Exclude the legacy network stack and test suites. For third-party code decide case by case. Use this template and place it at the top of the file:

 * @file
 * @ingroup RTEMSClassicTasks

Do not use @brief and a file description.

#3715 Add Requirements Engineering chapter to RTEMS Software Engineering Handbook doc 6.1 task 03/04/19

The chapter should cover the following topics:

  • Overview and introduction
  • Evaluation of tools for requirements management
  • Selected tool for requirements management
  • Evaluation of data models and formats for the requirements
  • Definition of data model and format actually used for the project (may overlap with tool)
  • Requirements management workflow used in the project
  • Requirements on requirements, e.g. derived from standards such as ECSS-E-ST-10-06C
  • Requirement identifiers used to ensure traceability

Jan Sommer (1 match)

Ticket Summary Component Milestone Type Created
#4464 gpiolib: Add support for newer grgpio features unspecified 5.2 defect 07/01/21

Current version of gpiolib is not aware of the input enable register of the grgpio core, when presence is indicated through capability register.

Also currently only interrupt support for "irqgen == 0" is supported. Our interface card has the mode "irqgen == 1" according to the capabilities register.

Note: See TracReports for help on using and creating reports.