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

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.

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

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)

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

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.

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.

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.

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

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

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

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

​http://ecss.nl/

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.

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

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

4. 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:

• ​Edisoft (prime) and ​CISTER from Portugal

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

• ​Jena-Optronik GmbH and ​embedded brains GmbH from Germany

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

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.

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

​https://docs.rtems.org/doxygen/branches/master/modules.html

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

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