Notice: We have migrated to GitLab launching 2024-05-01 see here:

Version 77 (modified by Wonjun Hwang, on 10/27/16 at 06:57:12) (diff)


Google Summer of Code 2016

This page captures the students who make proposals as well as those who work on projects for RTEMS as part of GSoC 2016.

Google Summer of Code 2016 Logo

Students' Proposals

Start filling in this table for yourself as soon as possible and update as needed.

Student Completed Hello IRC Handle Proposal Title Google Docs URL
NAME Yes or No nick on #rtems Project Title Link to Google Docs for proposal (shared with mentors)
Darshit Shah Yes darnir Improve SMP Scheduling using Arbitrary Processor Affinities
Vivek Kukreja Yes vivekk Improvement of Tracing Tool in RTEMS
Deval Shah Yes deval Raspberry PI USB and Ethernet Support
Punit Vara Yes punitvara Beaglebone Black BSP Improvement
Saket Sinha Yes disdi x86_64 BSP
Sambeet PanigrahiYes_sambeetPorting Rock on RTEMS
Habeeb Olufowobi Yes dipupo RTEMS Port to ARM Cortex-M4F core-based MCUs
Sane Sai Charan Yes sacha RTEMS MMU/MPU support for PowerPC
Arpit Srivastava Yes arpits ConfigurationUI
Arpit Srivastava Yes arpits Mono on RTEMS
Sane Sai Charan Yes sacha RTEMS file descriptors and LwIP integration [updated]
Wonjun Hwang Yes Wonjun RTEMS improvement for Jailhouse hypervisor
Mudit Jain Yes mudit Low Level Peripherals & SD card support

The columns are to be filled in as follows:

  • The Student column is for your name.
  • The Completed Hello column lets us all know whether or not you completed the Hello World project. Based upon our experience, students who have successfully compiled and run an RTEMS application have a MUCH MUCH higher chance of success on the proposed project.
  • The IRC Handle column is your handle on IRC. RTEMS folks hang out in #rtems on
  • The Proposal Title should be self-explanatory.
  • The Google Docs URL is your proposal in Google Docs that can be reviewed and commented on by mentors. The proposal template should be copied and used as a baseline. This can be shared with mentors for review. Mentors can insert comments for you.

WARNING: The Google Docs version of the proposal is a WORKING copy. You MUST submit the official and final proposal using the Google site. If you do not submit the final proposal via the Google site, you cannot be considered

Students' Summer of Code Tracking Table

Students whose GSoC project is accepted by RTEMS shall fill in a slot with their information in the following table, which helps to centralize SoC Project Management.

Student Name IRC Handle Project Link Repository Link Blog Calendar
NAME nick on #rtems Link to Project Wiki page Link to project's public Github repository Link to your development blog Link to Calendar with Schedule
Sambeet Panigrahi_sambeetWikiGithubBlogCalendar
Darshit Shah darnir Wiki GitHub Blog Calendar
Mudit Jain mudit1729 Wiki Github Blog Calendar
Punit Vara punitvara Wiki GitHub Blog TBA
Deval Shah deval Wiki Github Blog TBA
Habeeb Olufowobi dipupo Wiki Github Blog TBA
Wonjun Hwang Wonjun Wiki rtems-source-builder rtems jailhouse Blog TBA
Vivek Kukreja vivekk Wiki Github Blog TBA
Sai Charan Sane sacha Wiki Github Blog TBA

The columns are to be filled in as follows:

  • The Student column is for your name.
  • The IRC Handle column is your handle on IRC. RTEMS folks hang out in #rtems on
  • The Project Link is a link to the Wiki page for your project.
  • The Repository Link is a link to the github repository for your project.
  • The Blog is a link to your blog with entries about your project. It should be updated regularly during the summer.
  • The Calendar is a link to your Google Calender with milestones and deliverables identified.

Student Status Updates

Each student has a section below for putting in notes from the weekly IRC meetings.


  • Feb 10: GSoC 2016 Page created.


  • TBD


  • Feb 16: Updated proposal template to include a link to the GSoC Rules, fixed some 2015 links and added a point to state the student needs to answer the questions in the sections in the document.

Student XXX

  • TBD

Darshit Shah

  • May 25: I've been looking into the Scheduling Simulator and trying to get it to compile. However that has been a large task with a few breakages that I haven't been able to fix yet. Based on my last conversation with sebhub, it is okay to push this task to a little later since we don't need schedsim till the end of the project anyways. I've also been looking into the existing scheduler implementations and working on a draft for how I will implement the new scheduler as well. I have most of the specifics charted out now. Will start implementing the iterative MVM algorithm in the coming week.

Deval Shah

  • May 25: My first task is to add USB root hub support. For that, I need USB DWC OTG drivers and hardware specific drivers (for bcm283x) in the right place. USB DWC OTG drivers are already there in the codebase. To continue with Yurii's last year's work, I cherry picked his commits for USB roothub drivers and merged it to the current version of rtems-libbsd. Default testsuits which are related to networking are having compilation/linking errors. Later I realised that the driver (bcm283x) itself is not compiling. So I will now read the documentation regarding adding drivers in rtems-libbsd. That should help me to verify the code or if required write that from scratch. I should be able to add the hardware specific driver before the next status update.
  • June 1: I have resolved previous errors in building the drivers. So now the bcm283x_dwcotg driver compiles along with testsuits. Now I tried running the testsuits, it just shows "nexus0: <RTEMS Nexus device>" and hangs. Also, if I plug-in any usb device to Raspberry pi they are not getting powered on. I asked Yurii, he worked on the same problem last year, but he doesnt remember much about the errors or issues, however I have taken care whatever he has mentioned in his blog. RPI can't work with qemu according to this issue. So only option left is JTAG debugger. Which I have ordered but that would take about a week to get shipped to my place.
  • June 8: As per the previous update I am stuck at the point where the testsuits are compiling but not running on the raspberry pi hardware. I had a few options to proceed with JTAG debugger and QEMU. JTAG debugger which I had ordered has come today so I will start working on that asap. I built the testsuits for arm/realview-pbx-qemu and ran them on qemu. I am trying to debug the issue using other BSP which supports QEMU.
  • June 15: This week I tried to run JTAG. And came to know that there is already some problem of JTAG with raspberry pi. So I was not able to use JTAG for debugging purpose. I should have done some more research before buying the JTAG. That could have saved a lot of my time. So, now the only option left for me to debug the problem is putting printf statements in all the code which I added. Using this approach I have narrowed down the problem till some extent. The program hangs in one of the ofw bus status call. While adding the code from freebsd I had to add many files due to compilation errors. Now my plan is to add all the file one by one, analyse all the errors causing it and debug.
  • June 24: I have successfully ported the bcm283x_dwcotg driver for the Raspberry Pi. I ran init0 test on my Raspberry Pi Model 1/B+. Driver loaded successfully without hanging. Changes can be seen here. Apart from that I am getting error in mailbox functions (failed to set power state, err=-2). As far as I know Pavel and Mudit are looking into this problem. I will start working with them for the same. I can not move to next part before solving this. Also, I gave the work done till now for code review.
  • June 29: Mailbox Error resolved. bcm283x_dwcotg ported successfully.Currently I am trying to port usb_ethernet driver. Resolving errors while compiling.
  • July 13: I have added files for usb_ethernet and bcm283x_dwcotg till now. I am stuck at the point where I have to connect both of them. I have started the email thread regarding this issue. Alan and Chris are looking into the problem with me.

Wonjun Hwang

  • May 25: I am working to execute initial version of Jailhouse for x86 with instructions in Git. To install jailhouse, I am using VMware version 11 with Ubuntu 14.04.4-amd64 and QEMU.
  • June 1: This week, I built Jailhouse and executed Jailhouse demo successfully. I changed VMware to other native PC to QEMU. I also changed linux distro to lastest version of Ubuntu 16.04.4-amd64. I upated my blog about how to set environment to execute jailhouse demo.
  • June 8: I pached rtems with mentor's patch files that can make jailhouse to exectue rtems as inamte. It is involved with APIC, IOAPIC, PCI and memory etc. rtems baseline is commit f334847 and rtems-source-builder baseline is commit 04aadb6. I matched rtems and rtems-source-builder by date of commit. Date is about Jan 2014. I also updated my blog about how to build rtems for jailhouse.
  • June 15: To load rtems at jailhouse, I wrote a config file. I found that I need a loader file for rtems. So I got a loader file and a script from Jan. I have a problem in a load address.
  • July 13: I am in same situation about load problem. I have studied a jailhouse paper, documents and source codes. I have tried to load at various address and discussed with Jan. I will ask jailhouse paper author to give a advice.
  • July 20: I make a new git repository for my project. I committed patches Jan sent. There are lots of differences between rtems Jan worked and master. So I need to divide a patch issues into multiple parts.
  • July 27: I start rtems as cell on jailhouse without any errors. but I get no outputs too. So I should check whether it is working or not. patches are involved with various parts like networking, pci, ioapic etc. So I need to make simpler to execute rtems Jan sent on pc.
  • Aug 3: Because Jailhouse doesn't support lagacy pic, I should remove pic codes and add apic codes on rtems. Moreover the patched rtems is changed about clock for calibrating between Jailhouse and qemu. Next job is to remove legacy pic and add apic on rtems and execute examples on pc not jailhouse.
  • Aug 10: I tried to execute hello example to test pci. in patch file, pci functions were modified but master rtems already pci functions changed. because of this reason, I use master rtems functions at pci_io.c. moreover Previous patched rtems-4.11 uses early pritnk but I wouldn't use early printk to test easier.
  • Aug 17: I updated my blog about patching strategy. And I can execute hello example using only serial 1. I need to change jailhouse communication address from 0x100000 to 0x900000. On the other hand, I add define of IOAPIC at irq.h and add jailhouse.cfg.

Mudit Jain

  • May 25 : My first deliverable is to provide SD card support for the RPi BSP. The code has already been ported to rtems-libbsd, however it has to be tailored to RPi by adding the quirks and logics unique to the SD host controller on RPi.I have cherry picked two commits from Andre's branch and I have built rtems-libbsd using waf. I had initial errors of redefinition however they were resolved.I would be going through the present implementation of the driver in FreeBSD using the FreeBSD documentation to learn/understand what are the different APIs that are used in the driver, how it interacts with SD host controllers, and the general driver interface that is provided to the user.
  • June 1 : I have done a basic port of the SD card driver. Initially a lot of code was ported, however as per the suggestions provided I have modified the code as per the guidelines mentioned in libbsd.txt and also trimmed down on what was not required explicitly.
  • June 8 : I acquired a RPi Model B as I had a RPi 2 initially and started testing on the same. The SDHCI and DMA controllers appear on nexus0. I would be requiring a DOSFS to test the functionality of the driver. For this I was looking at the testsuites provided in both the bsd tree as well as the RTEMS tree [ /testsuites/fileio ].
  • June 15 : I have a basic application prepared which initializes a DOSFS which will be required for the testing. Presently, I am stuck at using the Mailbox code that Yang had ported for the Framebuffer Operations, I require that for setting the power state.
  • June 24 : I have used the Mailbox API that was added by Yang before to set the power for SDHCI controller. In addition to that I have also added functionality to the Mailbox interface to know the version, revision etc. This has been pushed as a patch and added into the Mainline.
  • July 6 : I have started work on another deliverable in parallel, Adding DMA access to SPI and I2C devices. There are two ways to go forward, one is by adding the DMA API, another is to specifically modify the I2C and SPI drivers to add DMA Access. I would be doing a literature study, going through the DMA controller spec in the BCM peripherals. Will also go through some of the code available on the net regarding DMA in RPi in addition to the DMA driver in FreeBSD.
  • July 13 : I have gone through the spec and some code and have developed an basic understanding how DMA takes place in RPi.Will be implementing the same in the weeks to come.
  • July 27 : I have completed writing the code, have added that to the build process, have pushed it to my github repo and have asked for review on the group. I have taken care of issues, such as cache coherency and mutex operations using the API that RTEMS provides. Have also understood where in the code for the SPI driver you would have to use the above described API for DMA Access.
  • August 6 : As per the suggestions of Pavel, I have modified the API. The code can be found at - The general use-case scenario and the flow has been told on the mailing list [ ].

Sambeet Panigrahi

  • May 25: As per my proposal the first deliverable is an easy to use Autoproj version of Rock building on RTEMS with appropriate tutorials to guide the user.I am now updating all the old scripts with newer versions of softwares.Till now I have replaced the traditional makefiles of RTEMS with building enabled by RSB. My next task is to update the Rock dependencies.I am going to cross compile OmniORB package now which is to be ported on RTEMS.
  • June 1: This week I had health issues so could not work more. I however have patched eigen and omniORB.I am not updating the other dependencies and rather using the previous version from archives to fast track my project. Once I have a working baseline then I can update the dependencies.Next in line is libxml and xerces.
  • June 8: All the dependencies are built and tested as of now.For my midterm deliverable now I have to patch rock and then do the necessary code clean up and some updating.This will be my line of work now.
  • June 15: I am patching a minimal rock configuration for rtems now .It would have rtt,typelib,orogen,and rock base packages.It is taking some time because rock is complicated and I have to reapply each and every patch again.I am now in rtt. Hopefully I will be able to finish before mid term evaluation.
  • June 22: I have started patching RTT. Majority of patches are present only to allow static building of RTT. However most of the hunks are failing.I have to rewrite and update every patch again.
  • June 29: I am still patching RTT.Thomas Roehr from Rock suggested that I reapply each and every patch again.Its taking time because the old patches are not of much help and RTT is huge.
  • July 6: I have nearly finished building RTT. There are still a few errors. Except PLuginloader.cpp of RTT all other parts could be built for RTEMS.Since it took so much time. I have decided to add a recipe to RSB as soon as I could build an executable on it.
  • July 17: The initial tests on RTT have given rise to errors.I cannot use the original code generators for it as Rock does not use I wrote a small component in C++ to test it.Also I got confused about using RTT Deployer to run my component.Deployer requires the component to be a library but I have to build an executable for RTEMS Qemu.
  • July 20: In the process of building an executable there were a lot of errors in particular linking problems.I had patched RTT for static building.The static build was successful but most of the libraries suggest a misssing DSO hand.Thomas Roehr suggested I use -static flag to build it,but to no effect.I am trying to find the reason for it.Meanwhile i have also started working on a RSB recipe for RTT.

Vivek Kukreja

  • May 25: In my first deliverable I will modify the code for capturing user extensions and trace-buffering to obtain respective traces in CTF format. For trace-buffering I've made changes to the trace linker to produce CTF metadata and buffering functions to produce CTF bitstream. I'm currently working on capture engine code to translate user extension traces to CTF.
  • June 1: Preliminary changes to rtems-tld for metadata generation and CTF tracing. Need to modify software architecture to keep existing tracing code with CTF tracing. Identified the need for sizes of user data types for metadata.
  • June 9: Focus on finding sizes of user data types. After investigation a couple of approaches, implemented a mechanism suggested by Chris. First code shared for review.

Punit Vara

  • May 25 : As per my proposal first things I have to write basic code and to build test suite for PWM. Going through TI SW code and list out function that can be used to generate appropriate PWM waveform.
  • June 1 : On June 2nd I am going to graduate.So this week I got only 3 days to work. Me and Martin worked together to test Ti starterware code successfully but yet not able to find out what is wrong with that code.
  • June 9 : Last week I able to manage blink LED with Ti SW code. Need to discuss Licence issue with Gedare.

Habeeb Olufowobi

  • May 25: Presently, I am trying to build LM3S69XX BSP but I have been having several issues getting it tested on Qemu.
  • June 1: I was able to successfully build the LM4F120 BSP and run HelloWorld? and Ticker on Qemu. Thanks to Martin for guiding me on resolving several error messages encountered. As suggested by Martin, I am currently looking into adding a proper reset routine for LM3S69XX BSP because the BSP does not have its own bsp_reset. Also, I have started working on my BSP port for the TM4C129E and I hope to resolve the build errors I have gotten so far.
  • June 8: Presently, I have successfully built my BSP (TM4C129E) and now working towards getting console working. I have flashed the board with the binary but console is not working. As pointed out in my mail to dev mailing list, I am getting an error during initialization and currently looking into resolving it. Hesham made a suggestion of rebuilding with -O0 which I'm currently on right now. I hope to get console working before the end of the week.

Attachments (1)

Download all attachments as: .zip