Open Projects

Welcome! Whether you're here because of Summer of Code (SOC) or just want to scratch an itch to hack, we invite you to peruse our projects and ask about them on the RTEMS mailing list or IRC. If you plan to submit a proposal to do something for the RTEMS Project as part of a SOC, see Getting Started for SoC Students. RTEMS projects span kernel hacking, adding support for a new board (BSP), improving the development environment, developing tests, and more.

If you want to get your feet wet with RTEMS then check out our small projects page where you can find projects that require little coding skill and are appropriate for those new to RTEMS or open source software projects. If you are interested in one of these projects but are not able to code and test it yourself, consider sponsoring one of the core RTEMS developers to do it for you. Volunteering or sponsoring is how things get done -- users keep RTEMS development alive!

Most of these projects will take between a few weeks and a few months of effort by a person who is familiar with the general use of GNU/Linux and GNU tools. Many RTEMS projects are done by student or volunteer coders, so we try to define small projects or subtasks that can be completed and committed individually. Most of the projects are feasible as a Summer of Code project. Since some projects have multiple steps, students should work with prospective mentors to define the scope of work in their proposal. Similarly, some projects might be a starting point for a class project or graduate thesis.

Projects in Bold text are higher priority simply meaning that users or developers have expressed a lot of interest in such projects. Projects in Italic text are space-oriented and therefore suitable for ​SOCIS.

Overview

The order of projects in the list does not reflect their importance, difficulty, or feasibility. Our project list is not exclusive: if you have an idea, solicit feedback from the project's mailing list or IRC channel; many developers sit in IRC and check it (and their email) infrequently throughout the day, so be patient! There may or may not be enough work on a project to constitute an SOC project, and some of these are past SOC projects. If you are interested in one of these, please ask on the mailing list or IRC.

If you have a new project add it to the appropriate list below, link to a wiki page below Projects/Open/ and use the Open Project Template. Briefly (1 sentence) summarize the project.

If one of the projects sounds interesting, but lacks detail, ask on an RTEMS mailing list for details and we can all help scope the project.

Help Convert to Tickets

We have started converting each of the projects listed here to tickets. Any help in the process is appreciated. A standard workflow for the same would be:

• Create a new ticket (New Ticket(direct) in Trac).
• The summary of the ticket should be the title of the open project.
• The content of the project page should form the description of the ticket. May require ​WikiFormatting. (Perhaps it would be a good idea to just click on "Edit this page" down on the project's page and copy the already wikiformatted text.)
• Put the "Type" of the ticket as "project"
• Put the "milestone" to be "indefinite".
• One of the mentors of the project should be mentioned in the "Owner" field and you should CC the rest of them. If no mentors are mentioned, keep the fields blank.
• The "Keywords" field should be put to "SoC" denoting any Summer of Code RTEMS participates in.
• We might want to use some other keywords e.g. to define the project type (e.g. one of: testing, ecosystem, kernel, statistics, BSP, API, libbsd, languages, libraries)
• Add an appropriate "component"

If you are unsure about anything, ask on the mailing list.

The tickets are the newer and more relevant version of the content on the project's page. When in doubt, consider the description in the tickets as valid.

Testing

Testing a large body of software like RTEMS is in a continual state of improvement. There is always a need for more test cases and easier ways to run them all and decode the results. In addition, we want to be able to run all tests on as many hardware and simulator configurations as possible. Testing doesn't sound exciting to most people but when you combine the breadth of what we need to test with our desire for 100% instruction and branch path coverage, you get some very interesting and challenging work.

Some of the identified activities which would augment our testing capabilities are listed here:

• RTEMS Testing - General testing framework for RTEMS.
• RTEMS Test Specification - Develop a formal test specification.
• RTEMS Test Screen Validation - Create a tool to validate test output.
• Improve Coverage Analysis - Strive for 100% coverage.
• Improve GDB Simulation - Fixing some issues in GDB Simulators.
• Simulator Updates - Find and fix problems in BSPs that target simulators.
• Testing of the GNU Tools - Improve Tools Testing on RTEMS targets
• POSIX Compliance Test Suite Develop cross-platform POSIX API Compliance tests (Ticket #2262).
• RTEMS Test Template - Improve automatic generation of tests.
• Fault tolerance - get a fault injection tool to work with RTEMS and create tutorials and examples.

Development Ecosystem

RTEMS applications are cross-compiled on a development host to produce executables that are transferred to and executed on target systems. The projects in this section focus on the host side of that equation. This means they will run on a developer's computer and possibly communicate with embedded hardware.

The following areas have been identified for projects related to improving RTEMS development:

• Config GUI (Python) - GUI for configuring RTEMS build.
• Build Variables (Python) - Add bounds checking for all build options as well as cleanup.
• Improve RSB (Python) - General improvements to the RTEMS Source Builder.
• Python GDB Support (Python) - Add Python Script support for debugging RTEMS with GDB.
• Static Analysis of Stack Usage - Develop a tool for static analysis of stack usage.
• Python Coverage Reporting (Python) - Convert coverage reporting to Python and integrate into RTEMS Tools.
• RTEMS Test Improvements (Python) - Improve RTEMS Tester (rtems-test) by adding simulator recipes for more simulators.
• GCov Reports - Use gcov output as generated by covoar to generate useful reports.
• GProf Reports - Use gprof output as generated by covoar to generate useful reports.
• GDB Coverage - Add execution coverage logging to the GDB simulators used by RTEMS.
• Improve Eclipse Plugin - Improvements in the RTEMS Eclipse Integration.
• Using clang - Compiling RTEMS with CLANG.
• eVisual Studio - Integration of RTEMS cross development environment into eVisual Studio.
• ArgoUML - UML for RTEMS.

RTEMS Run-Time Oriented

The projects in this category are more focused on the development of software that runs on RTEMS on target hardware.

Executive (SuperCore, SuperCoreCPU, libcpu): a.k.a. kernel

• Improvements to SMP support - Propose an improvement to the existing SMP capabilities.
• Condition Variables (CV) - Implement Classic API and supercore condition variables.
• Unified Interrupts - Unify the interrupt and PCI interfaces.
• Rump Kernels - Provide the hypercall interface for ​Rump Kernels in RTEMS.
• TinyRTEMS - Improve some aspect of TinyRTEMS.
• Paravirtualization- Make RTEMS suitable to run as a guest in a hypervisor.

Runtime Statistics

• Run-Time Tracing - Trace improvements and visualization.
• CPU Statistics - Improvements to CPU Usage Statistics.
• Stack Checker - Improvements to Stack Bounds Checker.

Board Support Package (BSP)

• x86_64 BSP - Create an x86_64 BSP to allow RTEMS to run on OTS hardware and popular emulators. This is related to some of the pc386 BSP Improvements.
• PC386 BSP Improvements - The BSP needs to support non-legacy PC configurations as well as address a few other issues. The x86_64 BSP project should only support non-legacy PC configurations.
• Beagle BSP improvements - More peripherals and other improvements for the Beagleboard family.
• Raspberry Pi improvements - More peripherals and other improvements for Raspberry Pi.
• x86 BIOS emulation for VESA - This is Pavel Pisa's idea.
• Port RTEMS to Microblaze architecture? - New architecture port.
• More BSPs for Simulators - RTEMS can always use more BSPs for simulators (and readily available boards or open cores).
• Memory Protection - Implement MMU low-level support code for more BSPs.
• Merge Leon - Merging Gaisler LEON support code into mainstream RTEMS.
• x86 Edison? - on hold due to unavailability of open information

Ticket	Summary	Owner
No tickets found

API Layers (POSIX, Classic, SAPI)

• Classic API Atomic API: Create Classic API wrapper for SuperCore Atomic API so they can be used portably in applications. See Ticket #2366.
• POSIX Compliance? - Improve POSIX compliance for RTEMS.
• OSEK - Implement ​OSEK automotive APIs.
• Programmable Logic Controller - Enable RTEMS as a ​Programmable Logic Controller (PLC).
• ARINC653 in RTEMS - Implement ARINC-653 avionics APIs.

rtems-libbsd

• Update the RTEMS TCP/IP stack? - Ask about possibilities about Ethernet over USB and Wifi support.
• USB stack - Ask about possible addition of other device types.

Languages

• Mono On RTEMS - Add support for ​Mono.
• Port V8 JavaScript Engine to RTEMS - Add support for the ​V8 Engine.
• SWIG on RTEMS - Add support for SWIG.

Libraries and Applications

• Projects/Open/InternetOfThings Internet of Things (IoT) - Port IoT infrastructure
• Port Monkey HTTP Server - Port the ​Monkey HTTP Server.
• Port Transparent IPC - Port ​Transparent IPC (TIPC).
• Line Editor. Implement a simple line editor. Existing code can be refactored for a starting point.
• Runtime Loader (RTL)? - Dynamic object code loading.
• RTEMS Toolkits - Define a generic (RTEMS Source Builder based) infrastructure for building and maintaining toolkits.
• Turn the current port of LWIP into a first class citizen that RSB can build. Submit port, make target independent, create maintenance plan.
• Rock on RTEMS - Improve the existing port of Rock on RTEMS.

Retired Projects

The following projects are complete or pending.

• Testing
  • File System Test Suite
• Tools
  • Application Configuration GUI.
• Runtime
  • Sixty-Four Bit Timestamps
  • Refactor the filesystem infrastructure
  • Use Maps or Hashes in the implementation of Classic API Notepads and POSIX API Keys.
  • Bdbuf improvements. The current block device buffer implementation can benefit from a number of improvements.
  • Improve the RTEMS SuperCore Scheduler
  • kqueue(2) or taskqueue(9) is a project to port the kqueue(2) or taskqueue(9) API from FreeBSD.
  • ISO9660 file system
  • POSIX Asynchronous IO?. POSIX Asynchronous IO should be nearly done, with perhaps a little more work to do. POSIX List IO is not currently implemented. This would involve implementing and fully list IO per the ​POSIX specification as well as completing the Asynchronous IO. First step work is to save the state of the project as a report under the appropriate GSOC/YYYY year topic.
• Languages
  • Parrot On RTEMS
  • GNU GCC Go?
  • RTEMS port of the GNU Java Compiler (gjc)
  • Lua in RTEMS
• Porting RTEMS to OpenRISC.
• Nested Mutexes: See Ticket #2124 for a problem description.
• RTEMS Sequenced Initialization - Initialize RTEMS dynamically, conceptually like C++ global constructors.

Obsolete Projects

Some projects have been proposed that are viewed as being of minor use. This list is meant to provide a way to avoid wasted effort on projects that are not widely desired. However, projects on this list might still be useful to someone, given a motivated individual to work on them.

• Various ideas have been proposed related to using RTEMS as a hypervisor. The lack of protected (kernel mode) execution precludes any feasible implementations.
• Merge BSP for Simplescalar simulator. The BSP is heavily bit-rotted and the simulator is a dead project.
• ​Rosetta OS OS Independent Device Driver API.
• Implement current version of ​µITRON Interface. itron support was removed from RTEMS due to lack of interest.
• More NIC device drivers for the old networking stack. See instead new TCP/IP stack?.
• Integrate CEXP into main RTEMS distribution. Possible licensing issues, please apply to the RTL project instead.
• Scripts and documentation for creating and installing prebuilt tool packages Building Tool RPM Packages, Debian Packages, MacOS tools, MinGW Tools for Windows, Canadian Cross Compiler. Please apply to the RSB project instead.