Version 69 (modified by Spencer Goodwin, on Jun 10, 2017 at 10:00:50 AM) (diff)


Google Summer of Code 2017

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

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)
Tanu Hari Dixit Yes tokencolour RTEMS Tester Improvements
Sichen Zhao Yes sichenzhao Beagleboard BSP projects
Sagar Gupta Yes sgmonusg Raspberry Pi Improvements
Abhimanyu Rawat Yes ABresting Memory Protection
Cillian O'Donnell Yes cpod Improve Coverage Analysis Tools
Denis Obrezkov Yes embden C6x Port
Nikolay Komashinskiy Yes nikokoma TMS570 BSP improvements
Vivek Kukreja Yes vivekk Improvements to Tracing Framework
Aditya Upadhyay Yes adityau Conversion to New Test Suite
Aditya Upadhyay Yes adityau POSIX Compliance
Faizan Khan Yes faizank SD/MMC device driver for Beagelboard
Spencer Goodwin Yes sgoodwin CTF Integration
Mikail Yayla (SOCIS) Yes myay Software-Based Fault Tolerance

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 mandatory Hello World 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
Cillian O'Donnell cpod Wiki Github Blog Project Timeline
Tanu Hari Dixit tokencolour Wiki Github Blog TBA
Sichen Zhao sichenzhao Wiki Github Blog TBA
Nikolay Komashinskiy nikokoma Wiki Github Blog TBA
Aditya Upadhyay adityau Wiki Github Blog TBA
Denis Obrezkov embden Wiki Github Blog Project Timeline
Spencer Goodwin spencergoodwin 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.


  • TBD


  • Jan 20: GSoC 2017 Page created.
  • May 24: Initial meeting held. Set meeting format and checked in with all students.
  • May 31
    • Roll call, Sichen is absent.
    • Announce one withdrawal and one pending ESA SOCIS Student.
    • Set Expectations for Successful Evaluations
      • Participating in IRC and mailing lists.
      • Attendance at weekly meetings and providing status updates.
      • Posting to Github each day of work.
    • Student updates.
  • June 7: Held Meeting.


  • TBD

Cillian O'Donnell

  • May 24:
    • So far I have made my way through 2014 SOCIS patches and have been working through python exercises to improve my skills. The next step revives the old SOCIS from 2015, which should produce a temporary setup with rtems-test using Couverture-Qemu and generating coverage reports. Currently the SOCIS 2015 patches are applied: Left to do is 8 files with 20 rejects, currently producing build errors in rtems-tools.
  • May 31:
    • All SOCIS 2014,2015 patches are now applied and I fixed the initial build errors in covoar. Fixed some runtime errors in rtem-test and got a first run though RTEMS Tester that resulted in 446 invalid tests. All switched to dry-run due to errors in qemu.cfg. That has disappeared this morning by adding --coverage as the last flag. Problems at the moment are, some coverage code seems to run with or without the flag and Invalid path errors for SymbolSets?.cfg that covoar uses.Next week I'll continue testing and fixing the runtime errors and if I get some decent test results start comparision with regular qemu for all supported bsps.
  • June 7:
    • Fixed the problem of coverage code running with or without the --coverage flag. Submitted patches updating quick-start docs for 4.12 release. Wrote a blog post. Took a detour into rtems-testing repo, tried to fix some build problems and get do_coverage running. At the moment I've started testing with no coverage. I have some reference results for xilinx_zynq_a9_qemu from the RSB built qemu and the Couverture tests all run into qemu.cfg errors. I found 2 problems causing these, there's a GLib warning 'custom memory allocation vtable not supported' that I found some patches to fix from mainline qemu. However they remove malloc tracing to solve the problem so I'm not sure if this is a good solution for our purposes. The other problem is 'qemu: hardware error: gic_cpu_write: Bad offset 100' which I'm looking into at the moment. Next week I'm continuing testing and hopefully start the RSB support.

Denis Obrezkov

  • May 24: initial meeting. I have read documents about HiFive1 board, Freedom E310 Architecture, E31 Coreplex core. For the next week I plan:
    • to read User and Priveleged mode ISA
    • to build the toolchain
    • to check the board and its peripheral
    • to build and run in SPICE simulator Hesham's port of RTEMS for RISC-V arcitecture.
  • May 31: meeting.
    • What was done:
      • I have read privileged ISA 1.10 and user ISA 2.2.
      • I have checked that examples for my hifive1 board work (built, ran and debugged through openOCD)
      • I have built a SPIKE simulator (with some issues), built RTEMS RSB but wasn't able to build RTEMS for hifive yet.
      • The blog post was written Building SPIKE
    • The current issues:
      • some .S files aren't compiled due to unrecognized opcodes.
    • Plans for the next week:
      • to build RTEMS BSP for RISC-V and launch it in SPIKE, write a blog post about it
      • to figure out, what should be done in order to make RTEMS run on HiFive1 board
      • if I have time, I will also start trying to launch RTEMS BSP on top of the board and check that Peripheral is working.
  • June 7: meeting.
    • What was done:
      • I made RTEMS riscv-generic BSP compile and pushed my changes to Hesham's repository.
      • I created a branch in my local repository, where I am trying to build rtems bsp for HiFive1
      • I created ticker application, loaded it through openocd and gdb, and can step through it (not far though)
      • The blog post was written Building a simple RTEMS binary for HiFive1
    • The current issues:
      • it is needed to create a working linkcmd and start.S files. Gdb hangs after a long jump instruction.
    • Plans for the next week:
      • to encourage the HiFive1 community to help with problem solving
      • to try to make appropriate linkcmd and start.S files
      • to discuss with Hesham what should be done with interrupt handlers.

Tanu Hari Dixit

  • May 24: Initial meeting.
    • I have gone through all the macro files in rtems-tools.git/tester/rtems/testing and we have decided to use INI files instead of YAML because we have standard support in Python for parsing INI files. PyYAML would have been a dependency which would have been difficult to handle across different hosts.
    • We have finalized on the format for the INI files. Chris already pushed "" in rtemstoolkit and this is taken out from Also the user specific configuration options--we decided we'll have a settings file that would contain user specific details.
    • I will come up with a ReST file as in an official documentation for the new macro files in ini format. I'll also start changing the .mc files.
  • May 31:
    • I had converted the documenation of rtems-tester to ReST and I had mistakenly added the rtems-logo too when it was not needed.
    • It was my first time with the Sphinx documentation of RTEMS. Though, I had worked with Sphinx before, it took me more time to come up with a suitable patch because I had to undo commits. I had less experience with that.
    • I have sent the new version of patches with the doc in line with the documentation of rtems-bsp-builder as Chris had suggested. This documentation also includes the new ini format. I would need to edit it as the format evolves in the course of the conversion.
    • Right now, I'm at converting the mc files.
    • Also I have still to ask Chris what to put on Github.
    • Chris has reviewed the changes. I need to make those changes in the doc.
    • Since the new release 4.12 is just on the horizon, I am supposed to remove the changes with INI bits and apply it as a second patch over the rest of the updated doc.

Sichen Zhao

  • May 24:Initial meeting.
    • I am working on first part of my proposal goal: i2c driver
    • So far, i have finished the i2c code, now working on create the patch and send to devel to be review.
    • I get along very well with the mentors, mentors give many advices to me during the project process, they are very enthusiastic.
    • Next week, i will focus on modify i2c patch, at the same time, i will read the USB code in FreeBSD, prepare for second part of proposal.
  • May 31.
    • Absent the meeting for the reason of focus on my paper which deadline is today.
    • I modify the i2c patch and send it to RTEMS devel.
    • I read the USB code in FreeBSD, especially the AM335x dts file which contains the IRQ vector.
    • I found the reason why my USB code can't pull the USB power pin high, and fix it. But there are a new issue occuer, the code seems stuck at somewhere, i think it should stuck at the ISR.
    • I write the blog post about my prepare works and I2C driver.
    • Next week i will try to solve the USB stuck problem, at the same time, i will keep an eye on the mailing list about my i2c patch.
  • June 7.
    • Last week, i remove the old beagle i2c file in source code, modify my i2c code and send patch to devel.
    • And i ported the AM335x USB code file(am335x_musb.c, am335x_prcm.c am335x_usbss.c etc) from FreeBSD to RTEMS-libbsd, and test it. So far the usbss and usbus has already mounted.
    • And now i have a odd problem: when the USB1 as a host and pull the USB1_DRVVBUS pin high. it generate a interrupt, but it stuck and can't go to the interrupt handler function. the interrupt is installed at am335x_musb.c. i am discuss with my mentor and maybe they can give me some advices.
    • Gedare suggested me to ask my problem on mailing list, i will do it if my mentor can fix my problem.
    • Next week, i will focus on the problem i meet, and carry on my USB work.

Aditya Upadhyay

  • May 24:Initial meeting.
    • I am have completed the implementation of inttypes library. I have made a separate test within the samples testsuites named psxinttypes01.
    • I have to port inttypes.h to newlib, i am working on it.
    • I will commit the code of inttypes library in my local github repo.
    • Now i am trying to implement maths related library and will make a test for related methods.
  • May 31.
    • I have send the patch for inttypes.h related methods and its tests named as psxinttypes01 within the samples testsuites to devel and waiting to be review.
    • After review, what they suggest, i will do the changes in my code.
    • Also i will be in touch with my mentors and read others mails on devel, so that i can learn about coding style and conventions.
    • This week, I am working on maths related library and at the same time, i will port the code of inttypes.h to newlib.
    • i was having problem with newlib, and i was trying to build it using j-newlib script, But after Gedare's suggestion, I am trying to build it using RSB.
    • I will update my blog and after building of newlib, I will write the steps to build the newlib in my blog.

Spencer Goodwin

  • May 31
    • I have built RTEMS 4.12 with a version 5.12 version of Qt to run on hardware.
    • Viewing documentation of working CTF examples.
    • Starting to code.
  • June 7
    • I've narrowed my search of files the are needed to create CTF Files.
    • Viewing documentation of working CTF examples.
    • Reviewing TDR documentation.