wiki:GSoC/2009/Wrapup

Version 9 (modified by Chris Johns, on 11/30/14 at 07:17:09) (diff)

--

GSoC 2009 Wrapup

RTEMS Google Summer of Code 2009 Wrapup Report
Author: Joel Sherrill, RTEMS Maintainer and GSoC Administrator

The RTEMS Project had 7 very good students this year. We were extremely pleased because of their results, their interaction with other projects, each other, and the community. The first three projects presented were interesting as individual efforts but there was an overlap at the end in what we called "bonus" work. We asked each student to identify pessimistic, realistic, and optimistic deliverables. The work in the optimistic phase was the "bonus" work. Software development is not always easy to predict and the lesson we wanted to impart was that a customer (e.g. us) was more likely to be happy if you told them what you thought would happen if everything went smoothly, if you got bad breaks, and if things go as you expect they will. Our bonus was seeing the cross-pollination that is common in FOSS.

Xi Yang's project was to provide more RTEMS Board Support Packages (BSPs) that run on the free Skyeye (http://www.skyeye.org/) simulator and improve testing capabilities when using Skyeye. We use Skyeye to test RTEMS as well as GCC (http://gcc.gnu.org). Another student, Santosh Vattam (blogs at: http://vattamsantosh.info), was working on improving the Object Coverage (http://code.google.com/p/rtems-coverage-analysis/) of our testsuites for a core part of RTEMS. Our initial coverage reports were generated for the SPARC/ERC32 using the closed source simulator TSIM (http://www.gaisler.com). As the coverage began to approach 100%, I began to run the coverage reports on various ARM targets using Skyeye using Xi's work. Santosh and I addressed cases which appeared to be test suite deficiencies while apparent simulator anomalies were passed on to Xi. During this, an obscure bug in RTEMS was uncovered and Xi and I worked together via chat to solve it. At the end of the summer, 3 SPARC and 2 ARM configurations were either at 100% or very close. The graph shown below is the coverage progress of sparc/erc32 through the GSoC timeline. Work has continued since GSoC concluded and current results are available at http://www.rtems.org/ftp/pub/rtems/people/joel/coverage/ for ARM, m68k, PowerPC, SPARC, and x86.

Imported from old wiki.

Xi also implemented an LCD framebuffer driver for use with RTEMS. This was a tie-in to the work of Roxana Leontie (code at http://code.google.com/p/rtems-nano-x/). Roxana was not a GSoC student but operated under GSoC rules and was funded using the Google donation to the project in conjunction with a donation from OAR Corporation. Her project was updating the Nano-X (http://www.microwindows.org/) RTEMS port and providing a new RTEMS framebuffer device interface. She targeted a standard PC and tested using QEMU (http://www.nongnu.org/qemu/). Roxana's first succesful demonstration was running the Nano-X Minesweeper program on RTEMS. Apparently neither she nor I is particularly good at Minesweeper.

Imported from old wiki.

As she progressed, Xi updated his LCD framebuffer driver to match her new interface. Although not a requirement for either student, I expect we will be running Nano-X soon on Skyeye's ARM PXA255 simulation using Xi's framebuffer driver. The following screenshot is a test screen from Roxana using Xi's framebuffer.

Imported from old wiki.

Aanjhan's project was to provide a generic interface for RTEMS applications to use the Memory Management Hardware Unit available in most recent embedded processors for memory protection. Initial prototype with a basic proof-of-concept for the PowerPC architecture and PSIM board support package is now available. Major tasks of the project included studying the PowerPC MMU hardware architecture implementation and behavior, propose a multi-level API design within the scope of RTEMS infrastructure. prototype and test on a board support package. Most of the above tasks have been accomplished successfully and tested, but a lot of scope for further work exists. Some planned enhancements are to enable cache control by the MMU, task based MMU context behavior feasibility and implementation, optimizing the code for real time performance to mention a few. Also the implementation needs to be tested on real hardware to verify and validate the work. Currently, the above work is not integrated into the RTEMS main source tree and getting this done is the next primary goal with the work needed to get this done in progress. His detailed project report can be found at http://code.google.com/p/rtems-mmu-support/wiki/GSoCFinalReport. Aanjhan also helped setup a IRC Logger for the #rtems channel on FreeNode. He blogs at http://blog.tuxmaniac.com

Josh Switnick had a project which suffered from those unexpected "challenges" that make software development interesting. His project was to port RTEMS to the 8-bit AVR. RTEMS had previously only been ported to 16 and 32 bit architectures. We worked with Josh to produce a cross-toolset built with AVR specific libc support ported from AVR-LIBC (http://www.nongnu.org/avr-libc/) to newlib (http://sourceware.org/newlib/) and to build the free AVR simulator simulavrxx (http://savannah.nongnu.org/projects/simulavr/). Due to the interesting manner in which the AVR uses 16-bits to access 128K of memory, the context switch code proved to be very difficult to get right. Also, even though the smallest statically linked executables were less than 20K, many of the existing RTEMS tests cannot fit into the 128K address space of the largest AVR CPU model. Josh produced a working port and is continuing to work to tidy up the loose ends.

Imported from old wiki.

Lucian Cocan's project was to continue the 2008 GSoC project of Real-Time trace. The 2008 GSoC project had resolved a number of the low level technical issues needed to make a successful real-time trace component for RTEMS. Lucian's initial work was to package the work into something that is suitable for a user. This required a number of factors to be brought together in a way that provided flexibility for the user yet hid the complexity of what was happening. Lucian also had to learn Python, the language used to implement the host tool. The tool was modelled on the command line tool, libtool, as it provided a simple yet consistent interface for the user. Libtool also had to deal with a number of similar issues, that is managing and interfacing to user code in libraries or at the object file level. The other aspect of the development of the tool was to create a configuration data format that allowed the RTEMS APIs to be traced, yet could be extended to allow tracing of third party libraries and user code. The final phase of the project took the tool and various sample programs and traced them. This required modification of the RTEMS capture engine code and the addition of commands. Lucian successfully produced traces for a number of the sample programs plus the example priority inheritance capture engine example. Lucian is still working to get the code in RTEMS and to provide documentation (the current documentation can be found here?).

Jisheng's project was to implement run-time dynamically loading relocatable object files or libraries into RTEMS. It was based on the IEEE Std 1003.1-2004 API <dlfcn.h>(http://www.opengroup.org/onlinepubs/000095399/basedefs/dlfcn.h.html) interface. Two hard issues of this project are elf loader which do elf sections loading, symbol resolution and relocation etc. and a tool to link symbols which may be needed in the future into the final executable for RTEMS only link the used symbols currently. At the beginning, Jisheng read the source of Cexp--the work by Till Straumann and want to base the ELF loader on Cexp, then Jisheng find that it's overqualified so Jisheng want to implement ELF loader from scratch. The functions in dlfcn.h reuse the dynamic loader's code of the android bionic libc which supply a good framework. After midterm evaluation, Jisheng have completed the basic functions of elf loader, then he worked on figuring out how to get the dependencies included in the RTEMS kernel. At then beginning, ldep was used to link what would be needed in the future into rtems kernel. Then, Jisheng's mentor Alan contributeed a project rtems-kernel-image which he have been working on. Inspired by rtems-kernel-image, Jisheng implemented a simple tool to get dependencies include in rtems kernel. The difference between this tool and ldep is that the tool only link dependencies that explicitly defined in config while ldep try to link all needed libraries except which explicitly defined in exclude files. Currently the two tools are supported in Jisheng's project. Now we only support i386 and sparc, Jisheng is continuing to work on add other architecture support such as m68k, power pc, mips, arm etc. and a detailed document will be added. Further development can be found at git://github.com/absabs/objdl.

Attachments (4)

Download all attachments as: .zip