wiki:GSoC/2019

Version 44 (modified by Vaibhav Gupta, on Jul 1, 2019 at 7:37:18 AM) (diff)

--

Google Summer of Code 2019

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

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 Final Submitted
NAME Yes or No nick on #rtems Project Title Link to Google Docs for proposal (shared with mentors) Yes or No
Vaibhav Gupta Yes varodek POSIX Compliance https://docs.google.com/document/d/1NLbcFdHwWTEAismvz0E_C07Oos_4p6Y3IRGcE8fugSg/edit?usp=sharing Yes
Ravindra Kumar Meena Yes rmeena840 on #rtems Basic Support for Trace Compass(ticket: #3696) https://docs.google.com/document/d/1G6ISV_vIYLKl5Em2lwF8W91YrHWkve2KRSPOolerjTg/edit?usp=sharing Yes
Vijay K. Banerjee Yes vijayk Beagle Board BSP : Add Framebuffer Driver Beagleboard BSP project: Adding Framebuffer driver Yes
Nils Hölscher Yes nilshoel Add PRU-ICSS loader/driver to RTEMS https://docs.google.com/document/d/1AfmTx-btjrEM1QsuxTWbnC-wTctltEhqY138mTSxGOk/edit?usp=sharing Yes

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 freenode.net.
  • 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. You can use this as your Draft Proposal in the GSoC site.
  • The Final Submitted should be set to Yes when you have submitted your Final PDF proposal on the official GSoC 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 on Github Blog Calendar
NAME nick on #rtems Project Wiki Project's Github repo Blog Project Schedule
Nils Hölscher nilshoel PRU Project Wiki Github Blog PRU Project Calendar
Ravindra Kumar Meenarmeea840Wikirtems-docs rtems-toolsBlogTBA
Vaibhav Gupta varodek Wiki Github Blog Calendar
Vijay Kumar Banerjee vijayk 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 freenode.net.
  • The Project Link is a link to the Wiki page for your project.
  • The Repository Link on Github is a link to the github repository for your project. It should be a specific repository, not just your github account!
  • 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.

Gedare

  • Feb 5: GSoC 2019 application submitted and tracking status page created.
  • June 5: Held Initial Meeting.
    • Set format of meeting.
    • Discuss expectations:
      • Participating in IRC and mailing lists.
      • Attendance at weekly meetings and giving status updates on wiki.
      • Posting to Github each day of work.
      • Merging significant pieces of code as they are ready.
      • Providing blog posts every week as you learn new things and achieve milestones.
      • Frequent interaction with your mentor.
      • Maintain documentation as needed for your project, and update any relevant tickets.
      • Do not let yourself be stuck for more than a day on something.
    • Student Updates.
  • June 12: Held Meeting.
    • Remind students to push their code to personal Github repositories daily to show progress and consistent activity.
    • Ask students to review how to generate version numbered patches using -v option of git-format-patch.
    • Student Updates.
  • June 19: Held Meeting.
    • Remind students about upcoming evaluation, and the need to start producing useful code.
    • Student Updates.
  • June 26: Held Meeting.
    • Thanked students for completing their Phase 1 Evaluations.
    • Remind everyone to discuss problems openly with mentors or the org admins.
    • Note that patches submitted to ML should not contain any obvious problems such as compiler warnings/errors, and that versioned patches should be submitted in their entirety, not as a patch made on top of the previous version.
    • Student Updates.

Joel

  • Feb 5: Asked Gedare to start the tracking page.
  • June 5: Missed meeting, conducting RTEMS Training at OAR.
  • June 12: Missed meeting, attending the GCI Trip.

Ravindra Kumar Meena

  • June 5
    • Progress so far :
      • Successfully tried Babeltrace small example which prints CTF into text format.
      • Figured out that current stable version 1.5.6 of Babeltrace does not have a feature to convert live traces stream into CTF. This feature is currently under development and is available in the master branch of Babeltrace 2.0 but it is in pre-stage.
      • Figured out that Trace Compass does not support live monitoring.
    • Blocker:
      • Figuring out how to create decoder(source plugin) for conversion from existing format to CTF.
    • Next:
      • Build custom converter that can transform TCP streams and files with record items into CTF.
      • Update the Event Recording documentation
  • June 12
    • Progress so far :
      • Sent the patches for event recording docs.
      • Sent the patch of a working example of TCP stream received from QEMU target.
    • Blockers :
      • To figure out how to write decoder(source plugin) for conversion from rtems trace data to CTF
    • Next :
      • Write decoder(source plugin) for conversion from rtems trace data to CTF.
      • Send the patches for changes required in event recording documentation.
  • June 19
    • Progress so far :
      • I wrote CTF TSDL metadata file and sent the patch for the same.
      • Tried barectf example and found that metadata file can directly be generated from YAML configuration file.
    • Next :
      • Improve the CTF metadata file.
      • Figure out how babeltrace reads an arbitrary CTF session(CTF+event stream).

Nils Hölscher

  • June 5
    • Progress so far :
      • Coded and tested examples for PRU on Linux.
      • Added PRU UIO driver to bsps/arm/beagle/pruss and compiled them.
    • Blocker:
      • Device tree overly on Linux, I haven't been able to route the GPIO pins to PRU.
    • Next:
      • Run RTEMS on BBB.
      • Check weather everything is alright with the drivers I located in my repo so far.
  • June 12
    • Progress so far :
      • Device tree overlay has been fixed(should work with rtems).
      • Added rtems defines to changes to the original linux drivers in rtems (convention described in rtems-libbsd).
    • Blocker:
      • Running SD-Card image.
    • Next:
      • define/refine new milestones regarding PRU drivers with my mentors.
      • Get SD-Card to work and test PRU-driver.
  • June 19
    • Progress so far :
      • Defined new second milestone with chris.
      • Started writing shell wrapper for TI-PRU drivers.
    • Question:
      • One more example for an shell command in RTEMS?
      • Dr. Joel pointed me to samples/fileio.
    • Next :
      • Discuss TI license on devel.
      • Run example of TI drivers on rtems with BBB.
  • June 26
    • Progress so far :
      • Applied fdt overlay via u-boot.
      • Written first test application for TI drivers.
    • Blockers:
      • TI drivers are not working.
      • No debugging at the moment
    • Next :
      • Set up debugging.
      • Start debugging the TI drivers.

Vijay Kumar Banerjee

  • June 5
    • Progress so far:
      • Completed the I2C adaptation layer work and submitted to devel. The aim was to get the libbsd apps use the RTEMS I2C stack as RTEMS already has the I2C driver nicely supported in the BBB.
      • I made a sample application outside of libbsd that uses the RTEMS API to register the '/dev/i2c-0' bus and then use the FreeBSD ioctl call to read from EEPROM. https://github.com/thelunatic/rtems-bbb/tree/master/apps/i2c-adaptation-sample
    • Questions:
    • Next up:
      • For now I'm waiting for reviews on the submitted patch and will clean up or modify as needed until it gets merged.
      • After it's merged, I'll start with porting the lcd drivers from the FreeBSD.
  • June 12
    • Progress so far:
      • Refactored the submitted patches after review to make the I2C adaptation layer patcher mergeable.
      • Sent patches for documenting Beagle build process and I2C driver.
    • Next up:
      • Porting the am335x_lcd and tda19988 drivers from FreeBSD.
  • June 19
    • Progress so far:
      • Ported TDA driver on the BSD ti_i2c driver to test EDID reading.
      • Successfully tested the EDID reading.
    • Next up:
      • Write and test a sample application in FreeBSD that writes directly to the framebuffer.
  • June 26
    • Progress so far:
      • Modified the rtems-i2c adaptation layer to adapt the message address and flags in FreeBSD. The driver is mergeable now and is giving same values on i2c read as the original FreeBSD i2c driver.
      • Ported the TDA drivers over the adaptation layer and testing them.
      • Ported the lcd driver and the attach is successful.
    • Next up:
      • Check the EDID reading after the tda drivers are ported over the adaptation layer.
    • Blockers:
      • The fbd driver needs to be ported and it uses a lot of PROC and mem calls from the FreeBSD that's not supported in RTEMS and portions of it might need to be rewritten.

Vaibhav Gupta

  • June 5
    • Progress so far:
      • Build Newlib for SPARC and ARM architecture.
      • Made several attempts to port ndbm.h.
      • Made arrangements for porting ftw.h.
    • Blocker:
      • Figuring correct way to place/modify files to successfully compile ndbm.
    • Next up:
      • Try putting ndbm.c in newlib/libc/search directory and compile it.
      • Debug the testsuite for inttypes.h
  • June 12
    • Progress so far:
      • Modified the Testsuite for PSXINTTYPES01
      • Mentioned about updating newlib/libc/search directory on newlib-devel.
      • prepared ftw for porting.
    • Blocker
      • Waiting for views of newlib admins for updating search directory
    • Next up
      • Build Testsuite for ndbm
      • Port ftw
  • June 19
    • Progress so far:
    • Blockers:
      • While updating newlib/libc/search directory, updating hash.h, creates need for several other headers to be updated. Those updated headers now require new headers, so a chain of dependencies is formed.
      • While porting ftw, it requires fts.h, the functions of fts.h are defined in fts.c which requires mount.h, again this header requires multiple other headers, and dependency chain is formed.
    • Next up:
      • Port ftw.
      • Make testsuite for ndbm and ftw.
  • June 26
    • Progress so far:
      • Started preparation for writing memcpy for sparc and arm.
      • RSB patch for ndbm - newlib applied.
    • Blockers:
      • ndbm library is not generated by RSB.
    • Next up:
      • Generate successful library for ndbm and write testsuite.
      • write memcpy() for sparc and arm.