Version 86 (modified by Sh, on Dec 22, 2008 at 7:53:19 PM) (diff)

Redirected to separate page

Open Projects

Welcome Google Summer of Code Students. Peruse our projects and see what interests you. If you have questions ask them on the Wiki talk page or the RTEMS mailing list. If you plan to submit a GSoC 2009 (if and when it happens <wink>) proposal to do something for the RTEMS Project, we now require that you demonstrate that you have a basic RTEMS development environment installed. See GSoC Getting Started for details on what we want you to have done. We want you to succeed and have fun on an RTEMS related effort.

This page captures ideas for RTEMS projects. They range from OS projects to development environment to testing to just about anything else. If you like one of the ideas, you can pitch in and tackle it. If you aren't able to code and test it yourself, consider sponsoring one of the core RTEMS developers to do it for you. This is really the only way things get done -- USERS LIKE YOU KEEP RTEMS DEVELOPMENT ALIVE!!!

The projects on this page are lumped into broad categories but there is no prioritization applied to the order. It is just an organized dump of ideas with enough details to give an outline of the effort required.

We do not provide time estimates on these because the time depends on the experience and skill of the developer. Most of these projects will fall between a few weeks and a few months of effort by a person who is not completely unfamiliar with the general use of GNU/Linux and GNU tools. Some of these projects may consist of multiple steps. In this case, each step is defined to fall into short discrete steps.

Many RTEMS projects are done as student or volunteer efforts in a person's spare time or as a hobby. This means it is imperative that projects be either relatively small or divided into steps that can be considered complete and committed to the main RTEMS source base. Thus we have lots of experience in defining useful projects that are sized to be doable and useful to the community in relatively small work packages.

Most of the projects are feasible as a Google Summer of Code project. Since some projects have multiple steps, a Google Summer of Code participant should work with us to size up how many of those steps to undertake.

Project Template

Credit to Boost C++'s Google SoC page for the inspiration for the template entry.

Project Name

Status: Current status of project.

Introduction: Introduce the main concepts around the project: Theoretical preliminaries, preexisting RTEMS capabilities used or augmented (if any), important concepts, problems/needs the project will try to solve/satisfy.

Goal: Concise statement of the overall goal of the project. Refine this initial statement to include: project deliverables (code, docs, testing), required/suggested methodology, standards of quality, possible goal extensions beyond the main objective.

Requirements: List the requirements and level of expertise you estimate are required by the developer tackling this project will have to have: Required level of programming language(s), specific areas of RTEMS or tools, level of familiarity with RTEMS, cross-development, GNU/Linux, etx., development/documentation/testing tools, mathematical/algorithmic background, other desirable skills.

Resources: Current RTEMS developers, papers, etc that may help you in this project.


  • TBD

Other sections: If you have more to say about the project that doesn't fit in the proposed sections of this template, feel free to add other sections at will.

Ideas Needing More Details

The following ideas have been proposed but there is not enough detail written up yet on the project itself to justify a section.

RTEMS Run-Time Oriented

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

Run-Time Tracing

Status: ChrisJohns? and JoelSherrill have done initial work on adding trace points to RTEMS.

Instrument RTEMS so that a timeline visualization tool can be used to "place a scope" on a running RTEMS system. This project has multiple parts.

  • Addition of trace points to generate log entries
  • Transmission of logged data to host
  • Receipt of logged data on host
  • Decoding of logged data on host
  • GUI Timeline Visualization tool

Chris and Joel have done some initial work and prototyping has been done on the first four parts. Chris wrote the capture engine and this is currently part of RTEMS. The purpose was to look at performance issues relating to filtering, triggering, and storage of events ready for transmission to a host. Together Chris and Joel believe that the bulk of the work adding trace points can be done automatically using the GNU ld "wrap capability" given a user generated list of trace points. The first stage of this task is to extract function signatures from existing libraries then match against the requested list of trace points to generate the wrap code module for the target. The next stage is to integrate this code module with the existing capture engine to allow filtering and triggering. The implementation needs to keep overheads as low as possible and to manage the threading issues that are present in this area of the code. A key requirement is not to change any code in the libraries being traced.

In addition, we believe a simple text dump of the trace log on the host side can be derived in a highly automated manner. The code to transmit data from the RTEMS system and to receive the data on the host computer will have to be written. The design of the target transmit code needs to be flexible to allow for a wide range of possible transports. The first and most common transport will be TCP and this needs to be implemented. The target code needs to carefully consider stability issues. A tracing system such as this can generate more data than the transport can handle. The design needs to trade off an efficient protocol that minimizes the data sent against adding too much overhead compressing data. The host side to receive the data needs to be portable across all popular host operating systems. The preferred language is Python. The receive code can be a command line tool to save the data to a file or it could form part of a larger program. This code can become the glue between the target data and existing host applications designed to display trace data.

Once data has been received on the host side, the next logical step is to display the timeline of events in a graphical fashion. This may include the development of a visualization tool or the integration of an existing application that performs this task.

Greg Menke of NASA has used GNU plot to do a simple version of this and may have advice.

Implement POSIX Asynchronous and List IO

Status: No active volunteers.

RTEMS does not currently support POSIX Asynchronous IO as defined by OpenGroup?. These methods and associated constants are prototyped by the [ <aio.h>] header file which is cpukit/posix/include/aio.h in the RTEMS source tree. The following methods would have to be implemented:

All methods currently are implemented in RTEMS as stubs which return ENOSYS.

It is assumed that the implementation would have to have one or more server threads and these methods would interact with that server thread by enqueueing operation requests and checking on the completion status. The number of server threads along with characteristics such as stack size and priority would need to be application configurable.

Use Map/Hashes?

Status: No active volunteers.

Reimplement Classic API notepads and POSIX keys using code like std::map but in C. The current implementation requires that enough memory be reserved for every task to have memory for all notepads and every key whether they use them or not. This results in simple and fast array lookups to access individual values but is obviously heavy on memory. It is hoped that a hash/map algorithm can be found or designed which reduces the memory overhead without adding excessive lookup overhead or heavy handed O(n) algorithms for management of the entries. This is particularly important because tasks and keys can be dynamically created and deleted.

JoelSherrill and PavelPisa? are good resources for this. Joel can answer questions about the rationale driving this need and help evaluate algorithms. The run-time behavior of the algorithm is very important because RTEMS strives to be as predictable in run-time execution times and memory usage as possible. Pavel is very knowledgable about hash algorithms.


Status: Ongoing effort with multiple discrete projects. Much progress has made on this goal since 4.7.0 but there is more shrinking left. We are now to the point where the ARM/Thumb BSP rtl22xx_t has ~15K of code in the minimum.exe test.

Reduce footprint of minimum RTEMS application. We would like to be able to run on a CPU with only 64K ROM and 16K RAM. This level of target hardware obviously is too small to host some RTEMS features.

Currently a minimum RTEMS application assumes that you want items like a shutdown code, initialization of all Classic API Managers, and support for c. Some ideas in this area are captured at TinyRTEMS. The project would focus on breaking linkages between components so they can be configured out by the user, dropped out automatically at link time, or other mechanisms. The goal is to be able to provide the user with a full featured RTEMS library and defer as much configuration as possible to application configuration and link time.

One issue that will be an ongoing concern is that the minimum footprint varies by BSP. This is because some BSPs are structured to be lean, while others may have unintentional dependencies. One idea is a tool to assist in identifying RTEMS symbols which are not expected occur in some of the sample applications such minimum, hello, and ticker. This utility could provide guidance on the known reasons this symbol creeps in. For example, placing printk() support in the same file as the console driver will result in the entirety of the Termios subsystem being in the minimum footprint even though it is unused.

More NIC Drivers

Status: No active volunteers.

Convert more NIC drivers from FreeBSD to RTEMS. It would actually be more useful to have an semi-automated procedure to assist developers in porting individual drivers on an as needed basis than a large collection of untested drivers.

RTEMS Initialization By Constructor

Status: ChrisJohns? has filed a PR with a prototype.

Add an ordered constructor type system for automatic manager initialization. This should be general enough to support RTEMS managers, drivers and BSD sysctl type nodes. This is expected to significantly impact the TinyRTEMS effort as it would provide a central mechanism to eliminate code. If you don't reference it, the initialization code would automatically drop out.

BSPs for CPU Simulators

Status: Please ask for detailed information on the particular BSP/simulator combination you are interested in. There are lots of combinations available and the status changes frequently.

There are a variety of potential projects listed on the Emulator? and SkyEye pages. Some of these involve addressing issues in the simulator itself. Others involve developing BSPs for specific simulators. This is an important area of work since any target that can be tested easily and in an automated fashion on a simulator is always in better shape. Here is a list of BSPs on simulators that are currently thought to be of high interest because they would add significantly to our testing infrastructure:

  • a BSP for a QEMU Coldfire target
  • a BSP for a QEMU SuperH target
  • a BSP for a QEMU or SkyEye ARM PXA target.
  • a BSP for SkyEye edp9312 target configured to match the < USD200 Olimex board.

The GXEmul SkyEye project emulates a number of ARM-, PPC-, MIPS-, and SH4- based platforms, including "test-machines" SkyEye which may be good targets for RTEMS.

Where available please include support for networking and graphics. The RTEMS Project uses simulators for automated testing as well as for manual testing of features like graphics and network application behavior. Full featured simulator BSPs make this much easier. It also provides more BSPs which anyone on the project has access to free with no need for special hardware to be purchased.

JoelSherrill hopes someone will tackle RTEMS support for the ARM PXA models and edp9312 as supported by SkyEye. This would benefit RTEMS testing a lot.

RTEMS Virtual Machine Monitor

Status: No active volunteers.

RTEMS based RT-VMM (Real-Time Virtual Machine Monitor). Current RTEMS can not support to run another OS (such as Linux or uClinux). We want to add hypervisor (or Virtual Machine Monitor) function on RTEMS, then RTEMS has the power like XEN that can run Linux or other OS, but RTEMS also maintain original hard Real-Time funtions. First, we will try to make RTEMS run uClinux on ARM simulator SkyEye?( ), then we will try to make RTEMS run ARM Linux on XSCALE CPU based board or SkyEye? simulator. We consider virtualization techs on Embedded RTOS area has potential value. (from chyyuu@…)

USB Stack

Status: Ray is trying to run ohci test on QEMU with RTEMS

USB host stack for RTEMS. Port the latest FreeBSD USB stack for RTEMS.

This project is very likely beyond the scope of a Google Summer of Code project.

TCP/IP Stack Update

Status: No active volunteers.

Update current TCP/IP stack to new source base from FreeBSD.

This project is very likely beyond the scope of a Google Summer of Code project unless the student is familiar with the FreeBSD code base.

SPARC V8 Bit Scan Instruction

RTEMS currently does not take advantage of the SPARC V8 bit scan instruction. The LEON CPUs should have these instructions and will benefit from them being supported by score/cpu/sparc. It appears that using the generic bitfield code does not impact performance as much as it does memory usage since the generic code includes a 256-byte array.

Page based memory management system

Status: No active volunteers.

Page based memory system is supported by CPUs with MMU. Introducing MMU support and page based memory management systems can benefit RTEMS a lot as regarded to memory protection, reduce memory fragmentation.

Simple Line Editor

Status: No active volunteers.

The RTEMS Shell and Monitor have a simple line editor. They use a very similar implementation. One may refactor this into a common implementation which is usable in a general environment.

There are 3 parts:

  • The key definitions moved to rtems-lineeditor.h
  • The line editor function, ie rtems_shell_line_editor
  • The terminal parser, ie rtems_shell_getchar

Some notes: The shell interface and code is better than the monitor. The shell uses FILE handles and this is nice for redirection and multi-user usage (a threaded version). It also supports a command history. The caller should provide the terminal type. This could be a string or a pointer to the terminal data returned to the caller after a call to get the terminal data with a string. It is recommended to review some of the keys actions, for example C-f, to make sure they are considered standard in relation to a normal shell. One should consider cutting out the code that disables echo and obtains the password and putting it in getpass(). See the linux man page. We don't have a controlling /dev/tty so just make it work exactly like it does now.

Third Party Packages

Nano-X (formerly MicroWindows?)

Status: No active work.

Introduction: .

Goal: To provide more frame buffer drivers and examples that run on various BSPs. Frame buffers are wanted for BSPs that have simulators. In particular, we would like an appropriately licensed pc386 frame buffer driver for MicroWindows?. Any drivers that will run on Skyeye are also desired.

Requirements: The developer should be familiar with RTEMS development. Most of this work can be done outside the RTEMS source tree and treating MicroWindows? and its demos as example applications.

Resources: Microwindows port to RTEMS already exists. The Nintendo DS BSP submitter is a recent user of it so should be able to provide advice.



Status: No active volunteers.

Current Port:

Update the RTEMS port of LWIP. Provide reproducible test cases so we can be sure it stays in working condition.

A goal of this effort is to be able to use the standard TCP/IP NIC drivers already in RTEMS. If this is feasible, then a user could switch between the full-featured BSD TCP/IP stack in RTEMS or the LWIP stack to save memory at the expense of reduced functionality.

The work would have to do : 1 start with current LWIP source 2 update the port for current RTEMS and current LWIP 3 make the port portable across CPU architectures and BSPs (This is usually not as hard as it sounds.) 4 Provide documentation and examples that run on at least qemu so others can provide feedback. 5 Ideally use the standard BSD NIC drivers if at all technically possible so when you write a driver for one TCP/IP stack, you automatically get it for both stacks in RTEMS.

IDL base components model support in RTEMS

Status: No active volunteers.

Interface base development model (normal known as COM in Microsoft’s world) is very helpful for large scale software development. Major commercial RTOS like VxWorks?, LynxOS support IDL/COM. Introduce IDL and COM model need an idl compiler, and also there are lots type of COM to choose in open source world. There is support for omniORB in RTEMS, however, omniORB lack feature for recent language like JAVA. The popular COM/COBRA choices are Universal Network Objects from Sun (used in openoffice), XPIDL by mozilla and SWIG ( to name a few.

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

POSIX Timing Tests

Status: No active volunteers.

There are very few tests in the RTEMS source base which benchmark the POSIX Threading API and other POSIX services. The first step in this project would be to develop POSIX API Timing Tests which test the same logical tests cases as the existing Classic API Timing Tests. After that is complete, we would want to see Timing Tests for POSIX specific objects such as conditional variables and keys.

RTEMS does not use Timing Tests as much for comparison with other operating systems but as a ruler for self-improvement. Each RTEMS version should maintain or exceed the performance characteristics of previous versions.

Coverage Analysis

Status: JoelSherrill and JenniferAverett? have done work in this area.

This task consists of performing automated coverage testing using an open source simulator. The SkyEye project is currently adding coverage analysis capabilities per our specifications. When those are available, the person(s) undertaking this project could analysis the binary object level coverage provided by the RTEMS Test Suites on any target BSP supported by the SkyEye/RTEMS combination.

The analysis will identify a subset of RTEMS such as the SuperCore? and a single API implementation and use that as the basis for analysis. RTEMS includes a lot of source code and the coverage analysis should only focus on improving the test coverage of that code subset.

The resulting analysis is expected to provide a report on individual assembly instructions within RTEMS subsystems which are not currently exercised by existing tests. Each case has to be individually analyzed and addressed. Historically, we have identified multiple categories for code being uncovered:

  • Needs a new test case
  • Unreachable in current RTEMS configuration. For example, the SuperCore? could have a feature only exercised by a POSIX API object. It could be disabled when POSIX is not configured.
  • Debug or sanity checking code which can be placed inside an RTEMS_DEBUG conditional.
  • Unreachable paths generated by gcc for switches. Sometimes you have to restructure switches to avoid unreachable object code.
  • Critical sections which are synchronizing actions with ISRs. Most of these are very hard to hit and may require very specific support from a simulator environment. OAR has used tsim to exercise these paths but this is not reproducible in a BSP independent manner. Worse, there is often no external way to know the case in question has been hit and no way to do it in a one shot test.

There are multiple ways to measure progress on this task. In the past, we have used two metrics. The first is the reduction in the number of uncovered binary code ranges from that identified initially. The second is the percent of untested binary object code as a percentage of the total code size under analysis. Together the metrics provide useful information. Some uncovered ranges may be a single instruction so eliminating that case improves the first metric more than the second.

Add Sixty-Four Bit Timestamps

Status: Implemented. Needs evaluation on various architectures.

Prior to the RTEMS 4.8 Releases, RTEMS based all timing on clock ticks. At each clock tick, the current time of day was updated. This meant that the granularity of all time stamps and statistics on per-thread CPU usage were constrained to that of the clock tick. In RTEMS 4.8.0, the lowest level of RTEMS -- the SuperCore? (e.g. rtems/cpukit/score) was converted to use POSIX struct timespec as the format for all timestamps. In conjunction with the addition of the ability of a BSP to report "nanoseconds since last clock tick", RTEMS could now provide nanosecond accurate timestamps and CPU usage statistics.

Unfortunately, performing mathematical operations on struct timespec is painful and slow. This project will consist of the following work:

  • Baseline Testing
    • (DONE) Verify all test cases work as baseline.
    • Capture execution times of RTEMS Timing Tests on reference hardware.
    • Capture sizes of sample tests.
  • (DONE) Add a SuperCore? object "ScoreTimestamp?".
    • This is an opaque class which will be used by all SuperCore? time related functions.
    • Includes methods will be provided to convert timespec and other standard time formats to and from ScoreTimestamp?.
    • RTEMS has a class to operate upon timespec's so this will be implemented in terms of this.
    • Direct operations on timespec's will be eliminated throughout RTEMS except as necessary near API calls which operate upon struct timespec arguments.
    • Initial implementation will be using struct timespec and all methods should be simple pass throughs or wrapper of existing functionality in the Timespec math helper class. Note that by adding the class "ScoreTimestamp?", we have added a class whose implementation can be changed.
  • (DONE) Verify all existing test cases still work.
  • (DONE) Implement alternate version of SuperCore? object "ScoreTimestamp?" which uses unsigned sixty-four bit integers to represent nanoseconds since the POSIX epoch.
    • This implementation should be fairly simple as you can do direct math on 64-bit integers.
    • Do not destroy struct timespec alternative. The goal is to be able to pick the implementation is for each port to a new CPU architecture to select its preferred method.
    • Provide configuration similar to other configure/build time parameters in RTEMS to let user select implementation.
    • Make sure both implementations work. :-D
  • Post Testing
    • Verify all test cases work as they did baseline.
    • Capture execution times of RTEMS Timing Tests again on reference hardware for both implementations.
    • Capture sizes of sample tests.
  • Select proper implementation for each target architecture
  • Evaluation
    • We anticipate that most of the target architectures RTEMS supports will benefit from using the 64-bit integer version. But RTEMS supports over a dozen architectures so this is certainly not guaranteed.
    • Work with RTEMS Community to run tests on as many targets as possible to decide which is best choice on each architecture.
    • Simulators are available for most of the primary target architectures so we will be able to judge the impact of your work.

Implement POSIX FIFOs

Status: Implemented. Needs configuration support and tests.

Implement POSIX (named) FIFOs and (unnamed) Pipes. See POSIXFIFOs? for technical details.

Most of the core RTEMS developers are potential resources here. See cpukit/libfs/src/pipefs for details and contact information.

Implement Functionality Currently Missing in dup

Status: No active volunteers.

Implement missing file descriptor dup cases.

Development Environment Oriented

Remember that RTEMS is a real-time operating system targeting embedded applications. 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 are more focused on the host side of that equation. This means they will run on GNU/Linux or MS-Windows and possibly communicate with embedded hardware.

RTEMS is a free real-time operating system that must compete against commercial closed source offerings that have very impressive looking GUI oriented Development Environments. The RTEMS Project has spent years honing RTEMS and tuning it to be a competitive run-time and it certainly the technical capabilities to compete. But often RTEMS gets dinged for not having a "pretty face". Some of the projects in this category address that deficiency.

Eclipse Integration

See also: RTEMS Eclipse Page.


Status: ChrisJohns? has started this effort. Contact him for information on how you can help.

The goal of this project is to integrate CEXP into the main RTEMS Project. By integrating CEXP into the main RTEMS Project, it can more easily be updated to stay in sync with the main code base and re-released as new RTEMS versions come out.

CEXP in conjunction with GeSYS provide RTEMS with capabilities long familiar to VxWorks? users. They provide a base system and the ability to dynamically load software modules onto the embedded system. Without this system, RTEMS can only be used with statically linked executables in which the entire application is linked together with RTEMS and loaded onto the board.

Till Straumman wrote CEXP and GeSYS anbd provides instructions and a Live CD to demonstrate it running with the target environment on qemu. This would be useful to someone on this project because it provides a baseline reference for what the software does.

Application Configuration GUI

Status: No active volunteers.

The goal is to have a graphical tool to configure RTEMS for a certain Application e.g. max number of tasks, semaphores etc. It could generate a userconf.h which includes confdefs.h. The complete list of RTEMS configuration parameters for release 4.8.0 are documented in the [ Configuring a System] chapter in the User's Guide.

There are a variety of ways to approach this project.

JoelSherrill has used the GNU/Linux kernel config infrastructure for similar jobs in the past and things it is likely the best alternative as a baseline. This would certainly provide multiple interfaces on GNU/Linux hosts (e.g. X11, menu, command line). But we would like a solution that also addresses MS-Windows users. One possibility is to write a GUI program in Python which parses the same configuration information and provides a portable GUI interface. Another is to write an Eclipse plugin that supports this format.

Automated GNU Tools Testing


  • JoelSherrill is slowly building test scripts. He has reported gcc results on mulitiple targets.
  • The CVS module gcc-testing has the support infrastructure.
  • Some targets are not tested on simulators yet.
  • Skyeye has some bugs preventing testing on Coldfire and Blackfin.
  • There seem to be regression checking scripts we need to utilize to help reduce the burden of tracking results.
  • There are tests which spuriously fail due to the test infrastructure issues.
    • not knowing we add specific CPU options which prevent generating expected instructions on "scan assembly" tests
    • not generating profile files
  • Want to eventually run on multiple BSPs inside a single target architecture to cover more code generation possibilities.

This project broadly consists of doing whatever is required to automate testing of GNU tools on RTEMS targets. The first steps are to be able to automate the building of binutils, gcc/newlib, and gdb from sourcevusing either released versions of the tools or the development version checked out and updated from the source code control repositories of those projects.

Since there are approximately a dozen active RTEMS targets, this effort will have to be able to support all targets. Some of the targets have simulators. If there are executable tests, then the project will have to address being able to run those executable tests on the simulators capturing the output and verifying tests do not run too long.

The RTEMS Project hasaccess to the GCC Compile Farm for the purpose of testing GNU tools and providing automated reports. This is a collection of high power servers and our intent is to do as much of the automated tools testing as possible on those machines. But the scripting needed to drive this will be portable to other environments.

The RTEMS Project has a lab or test hardware hosted at OAR Corporation which includes multiple target boards and infrastructure to remotely access as well as power on/off each board. Once the simulator targets have been completely exercised, we will want support running executable tests on real embedded hardware targets -- with highest priority going to those with no simulator.

RTEMS Tool Support on Debian

Status: Packaging generated as a GSOC 2008 project. Needs to be "templatized" to minimize duplication and then production Debian packaging build infrastructure established similar to the one for RPMs and MinGW binaries.

Pre-compiled versions of the RTEMS tools are currently available for RPM-based GNU/Linux distributions such as Fedora, RedHat? Enterprise Linux, CentOS, and SUSE as well as MS-Windows via MinGW. This project consists of the development of comparable .deb package specifications and build scripts. The resulting packaging and infrastructure should be suitable for at least GNU/Debian and Ubuntu distributions. As the RTEMS toolset updates frequently, there must be scripting infrastructure developed to build these tools easily when updates are required.

RalfCorsepius? is the RPM builder and maintainer. He uses Mock to use a single development machine to build binaries for a variety of distributions. He is a good resource or mentor for this project.

The RTEMS Project currently does not have a computer running a Debian based GNU/Linux distribution and would have to have one before these could be supported long term.

RTEMS Tool Support on MacOS

Status: No active volunteers.

The goal of this project is to provide precompiled versions of the RTEMS tools for Mac OS X. As the RTEMS toolset updates frequently, there must be scripting infrastructure developed to build these tools easily when updates are required.

Tool distribution questions:

  • Provide Binary installers for all of the tools ( similar to the Windows MingW binaries ) ?
  • Provide Mac Ports ( ) for the tools ? ( and can these be used for BSD variants too? ) ?
  • Provide Fink .deb packages ( ) ?
  • Or just provide an easy to use shell script that can download, patch, build and install the tools?

Mac OS X version/architecture questions:

  • Does the project make a cut-off with a newer version of OS X ( say 10.4 or even 10.5 )?
  • Does the project support x86 and PPC Macs or just stick with x86?

Build questions:

  • Can the tools be built and packaged on an open source Darwin OS machine? or is a full Mac OS X machine needed to do these builds?

License questions: Little is know by those who currently build RTEMS tool binaries about the packaging and legal requirements associated with providing MacOS binaries.

The RTEMS Project currently does not have a MacOS X computer and would have to have one before these could be supported long term.

Multilib GNU Ada

Status: LaurentGuerby? has implemented the multilib'ing of the Ada run-time libraries.

  • gnatmake does not yet properly process -mcpu options like gcc so you have to use special command line options that make you way too aware of the multilib.
You have to use --RTS together with -m for gnatmake
to work for non-default multilib:

gnatmake $FLAGS --RTS=$(gcc -print-multi-directory $FLAGS)
  • There may as yet be target specific issues to work around where the same source file does not support all variants.

The goal of this project is to implement Multilib support for GNU Ada (GNAT) run-time libraries in GCC. This primary focus of this project will be to augment the existing configure and Makefile infrastructure for the GNU Ada run-time libraries in GCC to build multilib rather than a single library variant.

Multilib is a GNU term for building a single source library to be tailored for multiple CPU variants within a single architecture. This is done because even within a CPU architecture, not every CPU model is object code compatible. For example, on the RTEMS SPARC tools, we provide four libc.a versions -- SPARC V7 and V8 with and without hardware floating point support. Similarly, the m68k target supports many m680x0 and Coldfire core implementations with and without hardware floating point.

GNU Java

Status: No active volunteers.

The purpose of this project is to make the GJC (GNU Java Compiler) work with RTEMS. RTEMS is supported as a target in GCC so it is expected that the primary development focus of this project will be to adapt the run-time library to RTEMS. Since the GNU Ada and C++ run-times are already ported to RTEMS, there are examples to work from for many issues. Also if the porter assumes it is using the POSIX thread interface, it is very likely that the GNU/Linux port will be a good reference.

This project will consist of the following phases:

  • Port GJC Run-time to RTEMS. The port will be target CPU architecture independent. Just like the GNU Ada tasking support, this should be written in a processor architecture manner using portable API calls provided by RTEMS.
  • Run GJC Test Suite. We are already running the general GCC C/C++ testsuite and the Ada run-time tests. So there is precedence and help available.
  • Submit modifications to GCC and RTEMS Projects

Here is a list of technical details from Tom Tromey, the GCJ maintainer. A lot of stuff in libgcj is optional. So, a minimal port can be made pretty quickly. From memory:

  • The GC must be ported. This can be difficult but usually is not, since it has already been widely ported.

  • For a good libgcj port, libffi must be ported. It already runs on most architectures though. This would only matter if the target is a new architecture or if the target has a different ABI. A libffi port has two parts. Each is optional. First, the normal libffi API is used for reflection and one direction of JNI. Second, the libffi closure API is used for the interpreter and JNI->Java calls. libgcj will configure and build just fine if these are missing.
  • For an excellent libgcj port, you have to write code to turn a signal into an exception. This is some hairy unwinding stuff, partly in gcc and partly in libgcj. However, there is an option to have gcj add explicit checks where needed, for platforms where this is not possible. [NOTE from joel: This is the technique also used by GNU Ada so there should be existing code to leverage and share between the GNAT/RTEMS port and the GJC/RTEMS port.]
  • libgcj's thread layer must be ported. This is usually easy. The POSIX "flavor" already works in a lot of places. Note that this can affect the GC as well. This part can actually be disabled, but you can't run much java code without threads.
  • File I/O, sockets, and other stuff like that should be ported. Some of this can be disabled for less-capable targets. Again, the POSIXy code should work fine.
  • For the full pull, port AWT. This is a lot of work and, really, nobody ever bothers.

There was a previous effort to do this but it was not submitted to the GCC Maintainers. At this point, it was against such an old version of gcc that it would probably have to be used as a reference more than a code base.

This is expected to be a good Google Summer of Code project.

The contributor MUST have or file Free Software Foundation paperwork and it is assumed that this code will be contributed to GCC.

=eVisual Studio Integration =

Status: No active volunteers.

Integrate RTEMS Development Environment with [ Visual Studio 2008 Shell]. This would ideally allow project level target configuration, code development, building with GCC backend, deployment, and debugging.

ChrisJohns? is a good resource for this project because he is the maintainer for the RTEMS MinGW hosted tools

==ArgoUML for RTEMS==

Status: No active volunteers.

ArgoUML is a java base CASE tool. It can generage C++ code from UML and it is very useful in large scale firmware development. First step of integrating ArgoUML with RTEMS is converting some of the RTEMS C++ class into ArgoUML's UML.