The final report of Google Summer of Code.
This project was continued from the project last year -- to provide a hypervisor to fit the RTEMS paravirtualization layer. The POK is an ARINC 653 compliant operating system, but not a hypervisor supported virtualization. The paravirtualization layer in RTEMS is a set of sensitive instructions that can't be execute in user space directly. To support the paravirtualization layer in RTEMS, we have to adapt the POK as a hypervisor and implement the interface defined in paravirtualization layer.

In the design phase, I think we should separate the virtualization progress from normal POK development. So first step we implement a hypercall system, and replace some virtualization-related system with new hypercall. Before the Summer began Philipp has changed the code of ocarina to support the virtualization option in ADDL.

The goal should be getting the timer sample in RTEMS running. The key problem is interrupt handling and delivery. The new structure vCPU in POK kernel which aims to management virtualization resource better is also designed for interrupt delivery.
When an interrupt happened, it should be handing in POK kernel first, and then the POK kernel check all the vCPU interrupt register information. If one vCPU is register for an interrupt, the POK kernel will mark in the vCPU.

After the interrupt hanging in the vCPU structure, when a vCPU resumes, it should deal with interrupt. This part mainly using the iret instruction to jump to user space from kernel space. In the user space, after the interrupt handler of Guest OS running, it will return to kernel space through hypercall do_iret. However, unfortunately, this return part can't work normally yet now.

In the sample testHypercall, there is an example of handler in user space. However, this never be invoked due to the failure of iret instruction.

The project aims to port RTEMS for OpenRISC architecture. Porting a well¬-known open source RTOS software like RTEMS for a big open source hardware architecture such as OpenRISC would be useful for both HW and SW communities. The new port would target a broad range of users and fields (hobbyists, digital designers, computer architecture, embedded systems, industrial applications, etc). I worked with the internals of binutils, gcc, newlib and gdb to be able to build or1k (OpenRISC 1000 architecture) toolchain for RTEMS. Other than the toolchain work, the project is mainly about porting RTEMS kernel itself to or1k. Almost all of the code I worked on during the project has been merged with different upstream repositories (binutils, newlib, gcc, and RTEMS). RTEMS now supports OpenRISC 1000 architecture.

TODO:
● Cache manager.
● MMU manager.
● Add new HW BSPs (for FPGA boards).
● Add new mor1kx CPU model support.
● TLS support.
● IRQ manager (when new HW BSP added).

The goal of this project was to make ARINC 653 compliant for RTEMS (while running on POK). ARINC 653, as described on wikipedia, is a software specification for space and time partitioning in safety-critical avionics real-time operating systems. To make that a bit more understandable: it’s a specification for an API (though it’s called APEX in ARINC 653 terms) that provides services mainly used in software for the avionics industry. It’s comparable to the POSIX in the sense that it’s an API except it has a focus on safety.

As POK is ARINC 653 compliant and has an implementation for each service I tried getting the ARINC 653 services provided by POK working on RTEMS. This would allow ARINC 653 compliance for RTEMS (as long as it runs on POK as a guest partition, of course).

At the end of GSoC 2014 it is possible to call POK’s ARINC 653 services from inside a RTEMS guest partition. It is, however, not finished yet. All the communicative ARINC 653 services (e.g. buffer, blackboard, semaphore, and buffer) currently return erroneous values and there aren’t any separate example(s) for all ARINC 653 calls. Instead, the current ARINC 653 example makes use of a modified “Hello world” example in RTEMS.

So in conclusion, all ARINC 653 services are call-able but a few services currently return errors as they’re called. Also the lack of separate examples for the ARINC 653 services on RTEMS has to be worked on. With a bit of debugging and programming I’m sure it’ll be possible to make the communicative ARINC 653 services available and have working separate examples for each ARINC 653 service call on RTEMS.

My project goal was to improve the Raspberry Pi BSP support for peripherals. By the end of the summer I have managed to add support to the Raspberry Pi GPIO hardware and to its SPI and I2C data buses.

This makes it possible to interface the raspberry pi with SPI and I2C peripheral devices and to perform digital I/O with peripheral devices and circuits, making RTEMS a more appealing option as an operating system for this popular hardware platform. This work has been tested with some peripheral devices during the summer, and will continue to be tested with more devices now that GSOC is over.

GSOC was a great learning experience, and I intend to continue working with RTEMS (and the raspberry pi) in the future.

This project is focused on making one new perfect BSP for the Ti’s TMS570LS3137. TMS570LS3137 is safety enhanced microcontroller targeting not only on automotive, industrial and medical applications. TMS570 has Cortex-R4f core which features two cores running on lockstep mode, fast interrupt interface, memory protection unit, floating point unit and much more.
Task of this summer was to run RTEMS on mentioned microcontroller. In other words, make TMS570LS31x_HDK_KIT with running RTEMS to pass as much tests as possible.
First task was to compile RTEMS for arm7-r big endian variation. This prepared base ground for other BSP featuring similar core.
Next step was to make new BSP and support of the ticker and console driver. Few times rewritten and clean drivers were created. I hope that they could serve as template for someone without experience starting his own BSP.
During the work with TMS570LS3137 there was a need to get register definition header files. Since TI’s licence prohibits us from using TI’s headers. Some minor python script has emerged. The script was used for extract necessary data from reference manual. This script is not in much useful state right now but someday it could lead for possible standardization of at least some header files. Or it could just be help for new BSP developers.

The result at the end of this summer is running RTEMS on the board. There are functional clock, console and irq drivers. Most of the tests are working.

TODO:

Parser improvements and clean up
Another “new BSP” tips (documentation)
Ethernet driver
Startup and selftest sequence for TMS570LS3137
Hardware floating point support