Version 92 (modified by aditya, on Jun 30, 2017 at 7:08:27 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.
  • 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.
  • June 21:
    • I have couverture-qemu building via the RSB minus the Gaisler patches. I manually applied those patches and some parts just needed to be moved and some had already been implemented in upstream couverture-qemu. I remade the patches so they cleanly apply and have emailed them to couverture dev Fabien Choteau who interestingly signed off on the original Gaisler patches, so was aware at some stage and possibly already implemented the solutions. Next week I'll try and implement the override option feature Chris mentioned, submit the RSB patches and I was thinking I might put the XML mockups together and leave them on devel to gather feedback for phase 3 and then get back to the RTEMS Tester work.
  • June 28:
    • I got the Gaisler patches to apply cleanly to upstream-qemu but failed to fix the compile issues. Luckily Frederic Konrad (couverture-dev) fixed these in I think a mornings work what I couldn't do for days. I'm waiting to hear back now if there is anything else to be done to help merge them. While waiting I wrote docs for RSB Couverture build in my wiki and I've gotten back to the RTEMS-TESTER work. Currently the --coverage flag triggers the coverage run in which calls and it makes it's way to the end of that and generates an empty html report (only headings, no data). In between this the covoar runs are all skipped due to invalid library paths to for example .../cpukit/score/libscore.a which matches exactly the path in my build tree. So I'm trying to figure out why path.exists(lib) returns false. Next week I'll keep trying to get a coverage report for Leon3, or if I hear back about the patches, I'll continue with that.

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.
  • June 21: meeting.
    • What was done:
      • I was going to shrink RTEMS'es workspace, but instead of this me and my mentors decided to try to use RTEMS low ticker examples
      • I was able to proceed further but discovered errors during stack initialization. The issues is that my program wants to allocate 0xab817bb3 bytes, though it should allocate only 0x200 bytes. I found out that I have some mistake during the loading: when I try to do: gdb my_application, p rtems_minimum_stack_size, I obtain the legal value of 512 bytes, but after loading to the target I am getting the value of 0xab817bb3.
    • The current issues:
      • .data section is not properly initialized
    • Plans for the next week:
      • to check that .data section is properly initialized and reimplement initialization if needed
      • to produce a new linker file from template
      • since the application doesn't work - it is still needed to write a blog post.
  • June 28: meeting at the end of Phase 1 period.
    • What was done:
      • I checked .data section initialization. It will be required to rework it in order to work right with examples-v2
      • I was able to proceed further to Console initialization
      • I tried to launch minimum example, but the thread exitted with INTERNAL_ERROR_THREAD_EXITTED error
      • summarizing blog post is written: Summarizing Phase 1 results
      • evaluation on GSoC site was completed.
    • The current issues:
      • in minimum example thread exits with the error
      • console driver should be implemented
      • interrupts should be implemented.
    • Plans for the next week:
      • to enable local interrupts
      • to implement console driver
      • to figure out why thread exits with the error.

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.
  • June 21.
    • Last week, i solved the interrupt problem on USB: The reason is bsp don't check for the valid interrupt vector range in their bsp_interrupt_vector_disable/enable functions. Every one of them will most likely have a problems if someone tries to use libbsd or the interrupt server.
    • I create a patch for solve the irq issue in BBB, Then Sebastian Huber create a patch to solve this issue for all bsps.
    • Then i ported am335x prcm(power control module), scm(system control module), usbss and musb usb control driver from FreeBSD, And now RTEMS can detect USB device on BBB.
    • At last, i add umass support in nexus-devices.h, So RTEMS can mount and read USB disk on BBB.
    • Regarding the i2c patch: has been merged.
    • Next week i will create USB patch and send it to mailing list for review. And work on USB dongle driver.
    • Joel said i need write a document for using umass support on Beaglebone Black.
  • June 28.
    • last week, i create USB patch and send it to mailing list for review. Sebastian Huber said we have to make the BBB the second BSP that uses the FDT. Its good that it works now with the primitive table based Nexus, but the next step should be to use the FDT with unmodified FreeBSD driver sources.
    • So i focus on BBB FDT support, i add "bl bsp_fdt_copy" in start.S and add bsp-fdt.c in beagle, then i write a test application to test. but when my test exe(modify the testsuites/libtests/libfdt01) boot, came out a error: data abort.
    • Boot output error info:
    • I dicussed with my mentor, tried many ways but still can't figure out. So i send email to mailing list asking for help.
    • Next week, i will focus on fix FDT support issue, wait the reply from mailing list.

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.
  • June 21.
    • Last week, I have worked on inttypes and long double complex methods. I have ported the code of ccoshl, cacoshl, csqrtl, clogl and methods related to inttypes.
    • I have finally understand the building process of newlib and knew the instruction how to generate using autoreconf.
    • In newlib, i did not see stdbool.h, used in csqrtl methods, so i have used enum for boolean values as Sebastian have suggested. I have modified the ported code again. Corinna Venschen told me to not rely on c99. But they are using stdbool.h from gcc. i have used that stdbool.h in modified patch.
    • I have checked all the dependent methods what i have ported last week. I am still trying to configure SVN Checkout for freeBSD and NetBSD.
    • As Joel have told me to use rtems_init() for all the methods tested within testsuite psxinttypes01. i am working on it and investigating the similar files in testsuites.
    • This week, I will port rest of functions from long double complex methods and will apply the whole ported function patch to RSB as well as make a test for these function in RTEMS.
  • June 28.
    • Last week, I have worked on the remaining long double complex methods. 4 methods was remaining, but now i have ported all these methods and sent the patches for these methods to newlib. They have reviewed the patchs and pushed these to newlib-cygwin/master.
    • Till now, I have completed my coding phase 1 commitment.
    • Now i am working on remaining part of inttype. which is from coding phase 3. I have made tests for inttypes methods but needs some changes.
    • Some warnings from complex methods, i am trying to fix these.
    • Simultaneously, I am updating my blog and RTEMS POSIX API sheet sent by Joel.

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.
  • June 14
    • I Learned the many tracing formats will definitely be beneficial in my final product.
    • Different formats are used for display, transport and actual tracing.
    • I've be found source files that pertain to CTF in C++ and Python.
    • BareCTF must be incorporated into my code.