GSOC 2011 RTEMS Project Final Report

This was an interesting year for the RTEMS Project and the Google Summer of Code. We had eight wonderful students who challenged each of the mentors to do their best. I hope that we can keep them all involved with RTEMS in some capacity. They were all very good and highly productive. If there is any downside to this years GSOC, it was not much of one. We just have a large volume of code, tests, and bug reports which were produced and need to be digested.

[collapse collapsed title=“RTEMS Project Administor Report”] As most folks familiar with RTEMS know, I (Joel Sherrill) teach a week long class on RTEMS between four and ten times a year. Having been founded by the first head of the computer science department at University of Alabama in Huntsville, we have always been friendly to academia. Since our first year as a GSOC Organization, we have offered free tuition (USD2500) for any GSOC student who wished to attend the RTEMS Open Class in either Huntsville or Munich. The Huntsville class is webcast for those students who can’t attend in person. Initially, I was disappointed that no students could attend the Huntsville class in person even though 3-4 were on the webcast. In the middle of the week, the infamous April 2011 tornados hit and left enormous damage across the Southern U.S. OAR itself was undamaged how-ever without power for 6 days and I ended up teaching the class without power to those who attended. In retrospect, I am glad no GSOC students were in attendance.

The Munich class was held in late May and this time two GSOC students were able to attend. One even asked if they could bring a college friend along to attend. Since there was space and we had an extra copy of the class material, we were happy to let them all attend. I worked with the students who came to ensure they were building everything OK, understood their project, and had made initial steps before they left.

One thing I hope all of the GSOC students we have the privilege of mentoring have learned is that it is important to “pay it forward”. The core developers believe it is our responsibility to help the next generation of computer scientists via mentoring, recommendation letters, career advice, or just a free lunch. We needed this when we were in their position and we hope they remember to “pay it forward” when they are in a position to do so.

Now on to the good news from each of the students. [/collapsed]

[collapse collapsed title=“Hypervisor for RTEMS by Zhang Wenjie”] After almost three month work the GSOC project is going to final phase. My project Hypervisor for RTEMS completed somewhat a little different from the project original plan. Because my project is based on the work of AIR project which provides the hypervisor kernel, before the project starts i don not see any source code about it. After i got the source codes from Tobias i first study and analysis them carefully, and then discuss with Joel to determine the most important task is to merge the hypervisor code to the latest RTEMS version (hypervisor code is based on RTEMS 4.8.1).

The merge work includes two goals: first goal is to update the para-virtualized guest RTEMS and second goal is to update the host side RTEMS which is used as a BSP for hypervisor kernel. About the guest side i also implement a new BSP for all the para-virtualized SPARC architecture. During this stage i encounter a problem which troubled me for a long time. It is because of the different size of boolean type build under rtems 4.8.1 and rtems 4.11 which cause a very strange behavior under the partition OS schedule. After this problem has been solved the guest side work is done. About the host side i use the IFDEF similar skill to patch the RTEMS which mainly modify a little code about the score code and LEON3 BSP code. During this stage i also encounter a thorny problem also about the partition OS schedule. When the hypversor schedule the second cycle it will only execute each partition OS‘ idle task. This problem is caused by the wrong load and store operation of variable _Context_Switch_necessary. After it was solved the all the update work is done.

Although the GSOC project has been completed but there are a lot of work to do with this project. The most urgent thing is how to merge those code to RTEMS CVS head. And then continue to do the development about the virtualize under RTEMS. I will continue to pay attention to this work. [/collapsed]

[collapse collapsed title=“Implementation of the ISO9660 Filesystem by Christophe Huriaux”]

After a slow start due to schedule conflicts with school, the ISO9660 filesystem is almost fully implemented in RTEMS. My implementation choice was to write this filesystem from scratch, rather than porting it from an other OS.

For recall ISO9660 is a read-only filesystem used in optical devices like CD-ROM and is also used as the file format of “ISO images”. Both use-cases are implemented, one can either mount a device or an ISO file located on an other volume.

At what level is ISO9660 implemented? First of all the whole original standard describing the legacy filesystem ISO9660 (also available as ECMA-119) is working, as well as the later ISO9660:1999 revision, which means that every single ISO file should be readable in RTEMS (or at least in a degraded fashion). The major disadvantages of this filesystem are the various limitation on filenames : only uppercase characters, digits and hyphens. A mount options can tweak the way the filesystem expose the filenames : either untouched (uppercase) or lower-cased (for compatibility purpose with the default Linux implementation).

I’ve also managed to implement Joliet and Rock Ridge extensions. The first one is widely used on Windows platform to let an ISO9660 volume use a wider character set thanks to the use of UCS-2 encoded filenames. If the ISO9660 stack is compiled with iconv support (which is highly experimental ATM, I thank Ralf Corsepius for providing the iconv enabled toolchain !) it can do the character-set conversion at run-time, from Joliet’s UCS-2 to a user-defined character-set (iso-8859-15 by default).

Rock Ridge gives the most benefit to RTEMS since it brings a lot of POSIX things to the ISO9660 volume : detailed timestamps, owner’s UID and GID, POSIX file modes and others node type (device, symbolic link). Some other features are currently not implemented : deeper directory structure (ISO9660 allows only a depth of 8 directories) and sparse files support.

The filesystem implementation has been tested under the i386 platform, I’m currently fixing endianness and structure alignment issues to let the stack run well under the SPARC SIS simulator. ISO9660 records most of the multi-byte data in bi-endian format (little and big endian), it’s thus beneficial to take part of the volume ability. After consulting Chris Johns, my GSoC mentor, I will file a PR and the associated patches as soon as these issues are fixed in order to merge andhave public reviews of the ISO9660 stack. Chris also pointed me to others fields of RTEMS on which I could contribute after that. [/collapsed]

[collapse collapsed title=“Lua Scripting and Shell Support in RTEMS by Scotty Smith”] Testing of the Lua port to RTEMS has been successful. All the test cases provided with the Lua distribution execute as advertised within the Lua system. The current port should operate exactly as Lua operates on the host system. All changes made to the Lua source code were done in order to accommodate the RTEMS system. They were all minor changes, however.

As well as the normally defined API for communicating between C and Lua, I have provided functions for spawning two different types of Lua shells. The first function, _Lua_spawn_shell(), creates a shell that operates as a normal Lua shell would on the host operating system. The second function, _Lua_spawn_RTEMS_shell(), creates a Lua shell that accepts RTEMS shell commands as well. This allows user defined RTEMS commands as well. It currently does not force a log-on prompt, however.

The final part of my Google Summer of Code project was a Python to Lua translator. This part of the project ended up being much tougher that I had originally envisioned. The submitted translator works for Python code that is written with the knowledge that it will be translated to Lua. This implies that there is no exception handling code, as well as no usage of the Python standard library. It ended up being a very difficult problem to translate the entire Python standard library to include the necessary communication code for usage in Lua. To that end, it is currently not implemented.

There are currently discussions as to how to include the Lua port with the RTEMS distribution. The submitted code works for a Lua distribution contained within the cpukit directory of RTEMS. Current discussion point to this project being converted into an RTEMS add-on package. [/collapsed]

[collapse collapsed title=“Porting of resource reservation framework to RTEMS by Petr Benes”] The motivation of this project was the intention to provide hard real-time capabilities to the FRSH/FORB (http://frsh-forb.sourceforge.net/) resource reservation framework by means of porting it from Linux to RTEMS. One of the main steps to make it work is implementation of a scheduling policy enabling reservation of CPU capacity for each task with deadlines.

First of all, before writing any schedulers, it was necessary to adjust current implementation of red-black tree, which usually serves as a ready queue for EDF (Earliest Deadline First) scheduler. The red-black tree is now capable of handling multiple items with similar key (tasks with similar deadlines). Moreover, the pluggable scheduler interface needed to be extended with a few more hooks enabling other than priority schedulers.

After that, two separate schedulers were implemented, EDF and CBS (Constant Bandwidth Server). The EDF is a relatively conventional dynamic priority scheduler. The RTEMS implementation uses Rate Monotonic manager to indicate deadlines of tasks (jobs) to the scheduler. Moreover, tasks without deadlines are handled as background (low priority) task.

The CBS scheduler is mainly based on EDF, yet some additional features are applied. The aim of the scheduler is to provide temporal isolation of tasks. Each task declares not only deadline but also a computation time necessary to meet the deadline. The CBS guarantees that any behavior of a task can not cause a deadline miss of another task.

Both schedulers are ready to merge, yet still being reviewed. Tests for the schedulers are also ready. Proper documentation is missing at the moment, but will be delivered soon. My best helping hands were Gedare and Joel whom I have to thank a lot. I hope I stay involved in RTEMS scheduling in the future. It might be useful to extend the CBS with quality of service features. [/collapsed]

[collapse collapsed title=“POSIX Filesytem Compliance Test Suite by Xiang Cui”] The new test suite fstests is added in RTEMS head now. The aim of the test suite is mainly testing the implementation of differet filesystems (imfs, dosfs, and rfs) . A lot of POSIX compliance problems were found in the progress of completing the test suite. The test suite also confirmed some bugs which alreadly listed in bugzilla. The tests can’t be uesed in coverage test now, due to that some of the bugs can’t be fixed in short time.

Although interrupted by other thing in the summer, I gained a lot of knowledge during the project. I am very thankful to the community. I alreadly start to advise and help my classmates to use RTEMS. In the future I will continue helping fix bugs in tests as I become more familiar with RTEMS. [/collapsed]

[collapse collapsed title=“POSIX Timing Tests by Ricardo Aguirre”] The goal of my project was to develop timing tests for some threading and synchronization operations from the POSIX standard. For each method tested, I wrote tests for various execution paths of that routine. For example, a sleep() can be a yield or a blocking operation. I developed timing tests for the following classes of POSIX Operations:

• Threads
• Synchronization
• Interprocess Communication
• Scheduling Interface

This means I wrote timing tests for the following types of POSIX objects:

• pthread_mutex
• pthread_key
• pthread_barrier
• pthread_rwlock
• message queue
• semaphore
• sleep and nanosleep

The development plan for the POSIX Timing Tests and their current status is located in the file rtems/testsuites/psxtmtests/psxtmtests_plan.csv in the RTEMS source tree. [/collapsed]

[collapse collapsed title=“RTEMS MMU Context Support by Quanming Shi”] The MMU hardware can be used for memory protection in RTEMS running with PowerPC 6xx CPU now. As described in my proposal, I have implemented a suite of user level API for memory protection control. Users can add/delete/modify/search memory protect domain and control the access and cache attributes. I reused some hardware related part of the code of the previous GSOC 2009 RTEMS MMU Project, such as the PSIM exception handler. Thanks to the author, Aanjhan Ranganathan.

Compare to my proposal, there are several obvious change: the first is I give up to integrate my new API with the Partition or other RTEMS API. Instead, I implement the cache attribute control and several POSIX API functions. The cache attribute is also a part of the attributes can be control by the new API now. The new POSIX APIs contain mmap, munmap and mprotect. The implementation is basic and simple, and only support part of the function defined by POSIX standard now.

The project has not been merged into RTEMS yet. This will be my next work. I will continue to pay attention to the improvement in future. [Editor’s Note: His mentor is using this in his RTEMS based application. Once he is satisfied with that and his own work, it is expected to be merged.]

Anyone who are interested in my project can find my code on google code project[1]. For more details about my project, Please check my final report and the API’s user manual in the same project website.

[1] http://code.google.com/p/gsoc2011-rtems-mmu-support-project/ [/collapsed]

[collapse collapsed title=“RTEMS port of the GNU Java Compiler by Jie Liu”] This is the third report after “GCJ Porting for RTEMS Status Report”[1] and “RTEMS Port of GCJ Progress Report”[2], and it is also the final report for the open project “RTEMS port of the GNU Java Compiler”[3] which belongs to GSoC 2011. After the second report:

• bdwgc’s pthread support is available on RTEMS/i386
• bdwgc’s pthread support patch has been merged[4]
• found 3 bugs in RTEMS, bugzilla 1855, 1867, 1894, thanks Joel for fixing these bugs
• gcj patch for RTEMS/i386 has been merged into gcc[5]
• augmented scripts in rtems-testing for gcj RTEMS/i386

All the patches can be seen at google-summer-of-code-2011-rtems[6] Jie_Liu.tar.gz. So gcj is available on RTEMS/i386.

[1] http://www.rtems.org/pipermail/rtems-users/2011-June/008574.html [2] http://www.rtems.org/pipermail/rtems-users/2011-July/008657.html [3] http://www.rtems.org/wiki/index.php/GNUJavaCompiler [4] http://gcc.gnu.org/ml/java-patches/2011-q3/msg00042.html [5] http://gcc.gnu.org/ml/java-patches/2011-q3/msg00055.html [6] http://code.google.com/p/google-summer-of-code-2011-rtems/downloads/list [/collapsed]