GSOC 2013 RTEMS Project Final Report

GSOC 2013 RTEMS Project Final Report

  • Joel Sherrill
  • October 11, 2013

The RTEMS Project had another great Google Summer of Code! Eight students successfully completed projects spanning the range of RTEMS. Good news from each of the students, in their own words, is included here.

[collapsed title=“Application Configuration GUI for RTEMS by Shubham Somani”] Shubham Somani’s Blog

The goal of my GSoC project was to create an Application Configuration Tool for RTEMS. It would help for an application specific configuration of RTEMS. The UI (GUI and TUI) are created dynamically from conf.t to reduce maintenance effort. So my first task was to make the root file conf.t more uniform. Then the UI’s were programmed and tested. There are functions of saving and loading back the values, checking if the values are entered in a correct format (with help of regular expressions) and generating the header file. The tool was also packaged into an executable so that all the dependencies of the UI can be downloaded by the user in a single click. Now the work of merging the tool in the codebase and further testing the tool remains. I will always be available to fix any issues that may surface in this tool.

Remaining items:

  • To merge the tool into the main code base.
  • To change some more parameters like CONFIGURE_MAXIMUM_DRIVERS in conf.t to make it definitions more clearer.
  • To further test the tool on package it on platforms left like Mac, FreeBSD etc.
  • To stay active in RTEMS and further contribute to this tool and other areas.

[/collapsed]

[collapsed title=“Atomic Operations and SMP lock debug tool for RTEMS by Deng Hengyi”] Deng Hengyi’s Blog

This project is continuation of last year GSOC project. In the last year the architecture-independent atomic API has been developed and the implementation of X86 and PowerPC has been completed. So in this year the project’ goal is to support all other architectures. The task includes that a general atomic ops should be defined to support all the architectures which do not support SMP mode. And now the gcc and newlib have supported C11 features so the work also include adopt the atomic ops to the latest C11 atomic API. In this summer i have completed update the atomic API to C11 atomic standard(test cases is also updated). The another part of work is to develop a phase-fair read-write lock and according test case. The patch has submitted and lots of work should to be done.

Remaining items:

  • merge all the code to mainline.
  • make phase-fair rw lock more mature and add test case.
  • write more doc for the atomic and phase-fair rw lock.

[/collapsed]

[collapsed title=“Enhance low-level API of libmm for Memory Protection and Caches by Hesham Moustafa AL-matary”] Hesham Moustafa AL-matary’s Blog

libmm is memory management library for RTEMS. libmm aims is to centralize different memory management techniques supported by HW targets including MMU, MPU and Caches. The goal of this year project was to enhance the previous work by eliminating duplicated code, support more BSPs and boost the process of merging libmm framework to rtems upstream. Currently BSPs use libmm to initialize memory management hardware at startup as well as dynamically set memory attributes for memory regions. Some applications may need to set memory attributes for a specific area of memory dynamically (within application phase). Examples of these applications are dynamic linker/loader and POSIX mman.h API.

Remaining items:

  • Merge PowerPc MMU code.
  • port mman.h (POSIX API) for RTEMS.
  • Unify Caches with libmm.

[/collapsed]

[collapsed title=“Paravirtualization layer in RTEMS by Phillip Eppelt”] Philipp Eppelt’s Blog

The goal of the project was to design and implement an abstraction layer, to ease virtualization of RTEMS across different hypervisors. As a proof-of-concept POK was chosen as a host OS. The virtualization layer is a set of functions a virtualized system cannot execute on its own and therefore needs support by the host OS. This is for example interrupt handling or hardware interaction. As POK is not a hypervisor, it does not provide abstractions common hypervisors have, like a vbus or a vCPU.

The design phase showed the necessity to split up the i386 CPU model, as virtualization sensitive instructions need to be replaced by virt.layer calls. The split introduced two new CPU models in libcpu, native and virtual. The native model is the one for real hardware and the virtual one is for the use with the virt.layer. The CPU model is chosen by the BSP. So we get a new BSP called virtualpok. As a starting point for the BSP I used last years results. The POK world was not this simple, as I had no experience with POK and the code generation process makes it difficult to find the right point to interfere with the system.

The goal was to get RTEMS sample suite running. Starting off with hello world. The implementation of the layer in POK was straightforward, the only addition was in a Makefile to build a library consisting of the layer implementation and all partition functionality. The linking process of RTEMS requires this library to solve the undefined references to the layer functions. The hello world binary is then copied to POK, the kernel including the partitions must be rebuild and then “Hello World” showed up on the screen.

In the second part of the project I worked mainly on POK to change the interrupt handling, so it can forward interrupts to partitions. The partition aka RTEMS has to register a handler for the interrupt and after it finished processing it, it needs to acknowledge it at the host. The still unsolved problem is the switch from kernel to user space, when an interrupt occurs.

RTEMS’s virtualpok BSP implements a clock driver, interrupt handling and console functionality. But I could not reliably test it, due to the host OS problems. In the future this problem must be solved and virtualpok needs to be tested on other (real) hypervisors. [/collapsed]

[collapsed title=“Porting CAN driver, LinCAN, to RTEMS by Jin Yang”] Jin Yang’s Blog

Actually the title is my original idea. This means I prepared to port a CAN (Controller Area Network) driver, LinCAN, to RTEMS. However when I discuss this with the mentors, how to test the driver when the porting work done become a problem. So we decide to build a simulation environment based on QEMU at first and then port the driver to RTEMS. Building the simulation environment become the main work for GSoC2013.

After some discussion with the mentors, we plan to build a pci-can device and simulate the SJA1000, a common stand-alone CAN controller, on QEMU. Since the linux is much familiar for me, to reduce the difficulty we decide using linux and also SocketCAN, a CAN driver maintained by linux mainline, to test the device we developed.

At first, we build a minimal linux environment from scratch including a minimal linux kernel, a basic root filesystem, starting from NFS etc. Then we start to build the SJA1000 device on QEMU. This is a complicated and bored work :) At the same time we build a new character device driver for this device on QEMU and we use SocketCAN on host. Until now we can send and receive the CAN message through the QEMU and host. The main goal for this project has accomplished.

Of course, there are still a lot work we should do after this project.

Remaining items:

  • the device only has sending and receiving routine now, another functions should be added.
  • upload the code to QEMU.
  • test the device to see if there are still some bugs.

[/collapsed]

[collapsed title=“RTEMS Runtime Loader by Peng Fan”] Peng Fan’s Blog

The objective of this project is to provide dynamic object file support for more architectures based on the current RTL framework.And extending RTL linker to collect object files from archives into a new archive and implement a new too to convert elf archives into rap archives.The key point to the target side is to study the ABI mannual of different architectures and also the asm language.According to the ABI, the relocation code can be implemented and then debug and debug to make it run using simulators. To the host side, several new options for rtems-ld are added and a new tool names rtems-ra is implemented.The host part needs a knowledge of STL C++ and GDB debugging. There are also two additional tasks, GDB support for dynamically loaded files and Python rtems.The GDB part now is basically implemented, breakpoint can be set, other commands can also be used using the GDB for RTL.The python rtems is to implement python support for rtems.As we all know that, python provides a lot of libs, and we can use the libs to facilitate development. Although the GSoC project has beed completed, there is still a lot work to be done and I will continue to work on these three projects.

Remaining items:

  • Implement large rap file support for RTL.This part is just like PLT of elf file.
  • Implement python rtems.This part is still in heavy hacking.
  • Improve the GDB implementation.GDB is a huge project. It needs more hacking.

[/collapsed]

[collapsed title=“SMP Aware Scheduler by Sree Harsha Konduri”] Sree Harsha Konduri’s Blog

The goal for me in GSOC 2013 was to add a new SMP Scheduler to RTEMS. I was provided with the Simple SMP Scheduler to examine and was given the choice of implementing a Global EDF Scheduler. I had the Uniprocessor EDF Scheduler and the Simple SMP Scheduler in RTEMS, to study and understand how scheduling was done. During the design phase making the choice of data structures was made cognizant of the available data structures used for EDF and Simple SMP Schedulers. I chose the RBTree and Chain_Control structures to store my ready (ready to run) and scheduled (allocated to cores) threads/tasks. I provided a description of the entry points for my Scheduler, and the choice of data structures used. The immediate goal then was to make sure i implement the entry points and can run the helloworld example with my scheduler. Once i got that to work, i made sure i had the smp tests working with the developed scheduler. Once i had the initial implementation ready i added the smplock to my ready queue data structure.

There is still a lot of work to be done in this scheduler and i am working on making it better even after GSOC

Remaining items:

  • Add support for periodic tests using the rate monotonic manager.
  • Improve the locking mechanism on the ready queue and in general provide a fine grained locking strategy for the Chain_Control and RBTree data structures.

[/collapsed]

[collapsed title=“Unified APIs by Vipul Nayyar”] Vipul Nayyar’s Blog

The broad aim of the Unified APIs project was to identify standard patterns of code implementation and file inclusion so that all BSPs follow the one true way of doing work and including proper components for it. To identify this one true way, a specific BSP needed to rise and be recognized as a model for other BSPs. Hence, the arm lpc24xx was chosen as a good reference to observe and write down rules for.

Based on my observations from model BSP lpc24xx, rules were compiled based on an ongoing discussion in the community on how BSP support files are included and compiled. These rules specify which set of files are a must to be used by a BSPand in which directory they all must lie. These rules will in future help in maintaining a unified pattern for BSP file organization. Since the above rules are very difficult to check manually for each BSP, so a bash script was written, merging the functionality of check_submission from rtems-testing. This script is supposed to be a final test for any BSP developer before his code is accepted into RTEMS, so as to check whether that the BSP code submitted follows this unified pattern of file organization and formatting or not.

A subtask observed during the coding period by me was that since we need all BSPs to follow a one unified way of doing things, so we cannot allow any legacy code that is deprecated to exist in the RTEMS bsp tree. This required killing all legacy implementations of interrupt handling in bsps & updating this portion with the new generic interrupt framework. Since more than about 100 BSPs are a part of RTEMS, so completing the work of removing legacy code is quite long, hence guided instructions and rules for continuing this work have been written and can be found through the RTEMS wiki page for this project.

Remaining items:

  • Continue working with the RTEMS community to strengthen the unified way rules and include more checks in it as suggested.
  • Increase code coverage for removing legacy support from bsps by converting them to PIC interrupt support model.
  • Submit regular patches so as to correct the warnings flagged by the new check_submission script in rtems-testing.

[/collapsed]