RTEMS Project

Web Page: http://www.rtems.org/wiki/index.php/Open_Projects

Mailing List: http://www.rtems.org/mailman/listinfo/rtems-devel

RTEMS (Real-Time Executive for Multiprocessor Systems) is a free real-time operating system designed for deeply embedded systems. The systems RTEMS is designed to execute on are not the general purpose PCs and Macs you are familiar with. The usual target for RTEMS is specially designed computers inside devices -- although RTEMS does support PC hardware which is also commonly embedded. Embedded systems are preprogrammed to perform a narrow range of functions with minimal end user or operator intervention. For example, an automobile's electronic fuel injection system and robotic controllers are examples of embedded systems. RTEMS is a free open source solution that supports multi-processor systems and has been ported to over a dozen CPU architectures and includes support for over 100 boards.

In addition, RTEMS is designed to support embedded applications with the most stringent real-time requirements while being compatible with open standards such as POSIX. RTEMS includes optional functional features such as TCP/IP and various file systems while still offering minimum executable sizes under 20 KB in useful configurations. The RTEMS Project is the collection of individuals, companies, universities, and research institutions that collectively maintain and enhance the RTEMS software base.

Projects

• ARINC 653 API The goal is to create a layer of abstraction enabling RTEMS to run inside an ARINC 653 compatible hypervisor.
• Atomic Operations for RTEMS This project’ goal is to define and implement the atomic primitives for RTEMS which completely support multiprocessor systems. The atomic operations on the multiprocessor systems also involve memory barriers. So in addition to the implementation of the atomic primitives API, the development of memory barriers will also be part of tasks.
• Bdbuf Improvements Ddbuf is block device buffer management. The main goal of the project is to change existing replacement strategy (LRU) to more advanced cache algorithms in a configurable way. IO performance will benefit from this change.
• Code a board support package for BeagleBoard and/or BeagleBone The BeagleBoard and BeagleBone are ARM based single-board computers. These boards are widely used by hobbyists. RTEMS does support the ARM architecture but lacks a board support package for the BeagleBoard and BeagleBone. I propose to write a board support package for the board which is more needed.
• Porting NXLib and updating libraries in RTEMSGraphicsToolkit This project aims to add NXLib functionality to RTEMS. This will allow applications written for X11 (libX11) to run on RTEMS Nano-X implementation.
• RTEMS MMU/MPU support for ARM architecture The main goal of the project is to make RTEMS capable of supporting memory protection through MMU/MPU for any target by redesigning the current High-level API that could be used by developers without the need to know low-level implementations for a specific target. Then implementing mid/low-level API for ARM architecture to be used by the defined High-level API.
• RTEMS on Asymmetric Multiprocessor (OMAP4) To improve the energy efficiency, some modern SoCs adopt AMPs (Asymmetric Multiprocessors) which consists big and small cores. For example, OMAP4, has two powerful Cortex A9 cores and two tiny Cortex M3 cores. This project is porting RTEMS to M3 cores running in SMP configuration and enable RTEMS to communicate with Linux on A9 cores by using AMP/IPC framwork.
• RTEMS Testing Project As the current testing framework provides limited support for tests automation and adding of new test, this projects is aiming to write new testing framework which exhibits new good testing harness and allowing for easier additions of new tests.
• Update the RTEMS TCP/IP Stack The goal of this project is to assist in the effort to port the FreeBSD 8.2 TCP/IP stack to RTEMS.
• Use hash or map in POSIX keys The objective of this project is reducing the memory overhead in the implementation of POSIX keys without adding any extra lookup overhead by some proper hash or map algorithm. This feature is required by two reasons: first, the POSIX key area is not properly extended when the number of threads is increased(dynamically created) if POSIX threads are configured as "unlimited", which is a known bug. Second, extra memory is reserved in keys for each thread or task in current implementation, which can be heavy memory overhead when keys increase since key can be dynamically created.