Version 75 (modified by Denis Obrezkov, on Jun 17, 2017 at 11:31:46 PM) (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.
  • June 14: Held Meeting. Reminded students of expectations for first phase evaluation, and the need to be posting to github and blog.


  • 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.
  • June 14:
    • I got talking to one of the Couverture devs and he pointed me towards a newer stable release that solved all the problems I was talking about last week, so none of the patches are needed now. I was then able to test all 9 common qemu machines that have rtems bsps. Good results for 3 that can be used for RTEMS Tester work and I filed tickets detailing the faults with the others. Wrote a blog post. Read the configuration section of the RSB docs, submitted some fixes. Have a fairly good idea of how the RSB builds work now and I'm starting the RSB qemu switch today.

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.
  • June 14: meeting.
    • What was done:
      • I figured out how interrupts in RISC-V are handled, particularly in my SoC.
      • I changed linkcmd file, so, now programs are running and gdb doesn't hang.
      • I found out how to run gdb: available gdb doesn't provide continue and until commands, so I have to use stepi command. (remark from 18.06: the continue command works.)
      • I found out that RTEMS'es workspace doesn't fit into the space allocated in linkcmd file.
    • The current issues:
      • implementation of interrupts handling is outdated (Hesham reimplements it)
      • RTEMS'es workspace doesn't fit into memory
    • Plans for the next week:
      • to shrink RTEMS'es workspace and make applications fit into memory
      • to write a summary 2-week blog post which will describe how to configure and run RTEMS on top of a HiFive1 board.

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.
  • Jun 7:
    • Reported that I got stuck for a long time in figuring out where the changes should be so as to load a ini file.
    • Converted a few mc files to ini files
    • Reported partial success in loading defaults.ini
    • Still to put up blog posts
    • The next week to be spent on debugging

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.
  • June 14.
    • Last week, i focus on the USB problem i faced: it generate a interrupt, but it stuck and can't go to the interrupt handler function.
    • I discussed with my mentor, fisrtly, we analysis the FreeBSD device tree file: dts, we think the interrupt vector 17 is not used, so we modified the the interrupt resources in nexus-devices.h, But didn't solve the problem.
    • Secondly, we modified the interrupt resource allocate function in AM335x_musb.c, the original function is bus_alloc_resource_any, i replaced it with bus_alloc_resources, but still not worked.
    • Then, i debugged the code and found the interrupt vector 19 is always occur, but we tried may ways just can't figure out the problem. I also asked in mailing list but no one responded to me.
    • So now i wanna separate the USB driver, and ported usb module one by one. i created a roadmap docs and start to implement step by step.
    • Regarding the i2c patch: my mentor Christian Mauderer had review it and the patch work fine. Now i still waiting for others to review.
    • Next week i will focus on my roadmap about USB driver, i will ported usbss driver and prcm driver to RTEMS, and create a clean patch.

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.
  • June 7.
    • i have sent the patch for inttypes to devel and wait for review again after modification suggested by Joel.
    • i am working on libm and trying to use the object file of libm in rtems and will make a test within the testsuites in rtems. But i am not sure libm.a will be accessable in rtems4.12.
    • I am having problem in building the newlib, so I have used another approach. I will apply the patches directly to RSB.
    • Next week, I will work on long double complex methods which are not in newlib and rtems.
  • June 14.
    • So far i have completed inttypes.h related methods and made a testsuite named "psxinttypes01" and it is working for rtems.
    • As Joel's suggestion, i have to use rtems_init() for all the methods in init.c file resided within psxinttypes01 testsuite.
    • I am porting the code of inttypes.h to newlib and need some reformatting, since it is third party code and sent the patches for same to newlib mailing list and need some cross checking.
    • I have ported the code of ccoshl.c from freebsd to newlib. patch has been varified and i will push it to my git repo.
    • I have to use SVN checkout for each function while porting the code from either freeBSD or netBSD.
    • This week, i will work on remaining methods from long double complex library and will port the code and send the patch.

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.