wiki:GSoC/2019

Version 68 (modified by Gedare Bloom, on Aug 7, 2019 at 4:13:08 PM) (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.
  • July 3: Missed meeting, Independence Day.
  • July 10: Held Meeting, Status Updates.
  • July 17: Held Meeting.
    • Remind Students of Phase 2 Evaluation next week.
    • Status Updates.
  • July 24: No Meeting. Status Updates by Email.
  • July 31: Held Meeting. Status Updates.
  • August 7: Held Meeting.
    • Suggest students write a blog report as their final deliverable/submission. Encourage them to share/work with their mentor on it.
    • Instruct students to focus on high priority items and documentation for future improvement and involvement.
    • Status 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.
  • July 3: Held Meeting, Status Updates.

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).
  • July 3
    • Progress so far :
      • Record a raw record item stream produced by the Qemu target via the nc tool in a file (not more than 100KiB) and add this file to rtems-tools.
      • Modify the record-client program to read from a file if a --input=<FILE> command line option is given.
      • Opened event stream file for each processor.
      • Write events of CPU to the corresponding file opened for the above task.
    • Next :
      • Modify the previous metadata to tell the consumers of the streams which file is for which CPU.
  • July 17
    • Progress so far :
      • Improved metadata. Now, multiple binary stream file can be read by babeltrace with just one single metadata and one stream_id.
      • Added packet.header in both client-side and CTF metadata.
      • Added packet.context in both client-side and CTF metadata.
      • Imported trace in Trace Compass. Trace compass is able to read the values.
    • Blocker :
      • Add event_header_compact on client-side.
    • Next :
      • Add event_header_compact on client-side.
  • July 24
    • Progress so far :
      • Added compact header in both client-side and metadata.
      • Imported trace in Trace Compass with the updated event.header in the metadata. Trace Compass can still read the values.
      • Added sched_switch in the metadata.
    • Next :
      • Currently working on adding sched_switch in client-side.
  • July 31
    • Progress so far :
      • Added sched_switch event in both metadata and client-side.
      • Detected prev_state of thread in client-side.
    • Next :
      • Implement mapping in C and store the thread_id and thread_name in map. eg. [thread_id]->[thread_name].
  • August 7
    • Progress so far :
      • Retrieved thread id and thread names from RTEMS target and stored in the table.
      • Populated the table to sched_switch event in client-side so that thread can have the name.
      • Detected the IDLE/RUNNING state of thread and set the value according to thread state(IDLE/RUNNING).
      • Did some code cleanup in both metadata and client-side.
    • Next :
      • Generate metadata from client-side.
      • Produce documentation.
      • Code Optimization.

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.
  • July 3
    • Progress so far :
      • Debugging enabled on BBB.
      • Driver is failing to open PRU.
    • Blockers:
      • Is FDT overlay working?.
    • Information :
      • Christian Mauderer told me to use BSD dtb and not Linux ones.
    • Next :
      • Check FDT overlay for pruss with BSD device tree.
  • July 10
    • Progress so far :
      • Still Problems with FDT.
      • Checked again with Linux and the files /dev/uio[0-7] have to exist, to represent the pru.
    • Blockers:
      • FDT is still not working.
    • Next :
      • Double check Linux and BSD FDT regarding pruss overlay.
  • July 17
    • Progress so far :
      • Changed From Linux driver to BSD driver after discussion on devel, rendering some of my work useless. :(
      • Got BSD driver to compile without errors and warnings.
    • Blockers/Questions?:
      • Differences between RTEMS and BSD driver initialization.
    • Next :
      • Initializing driver in sample App.
      • Loading first code to PRU.
  • July 24
    • Progress so far :
      • Ported the BSD pruss driver over to rtems-libbsd.
      • Moved the driver from my application to the rtems-libbsd repository, it makes more sense to develop it there, I think.
    • Blockers/Questions?:
      • I have got the solution to the clock driver module not loading just today, device tree again. However prcm still loads after the ti_pruss module.
    • Next :
      • Investigating FreeBSD init process in rtems.
  • July 31
    • Progress so far :
      • Investigated libBSD init process in rtems
    • Blockers/Questions?:
      • Need to figure out if it is fdt related or init process related.
      • It seems like libbsd-rtems only iterates one time over the fdt.

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.

  • July 3
    • Progress so far :
      • Ported all the display drivers to RTEMS
      • Ported fbd dirver and it's attaching with the fb0
      • fb0 device is getting registered and can be found from ls /dev
    • Blockers:
      • The fb_read and fb_write are empty and hence mmap is needed for it to work.
    • Next up:
      • Add mmap to libbsd and fbd and use it with a sample app to test the fb0 device.
  • July 10
    • Progress:
      • FBD ported to libbsd
      • fb0 device created and visible with ls
      • mmap added to libbsd
      • Made sample app for simple polygon drawing.
      • Ported VT driver
    • Blocker:
      • The screen isn't powering on during the initialization of VT
    • Next :
      • Figure out the documented ways of initializing the graphics core in the Chip and follow it up in Libbsd to ensure proper initialization.
  • July 17
    • Progress :
      • Prepared final patch for mmap with test added
      • Ported am335x_lcd_syscons
      • Ported the syscons driver
    • Blocker :
      • The screen initialization doesn't power up the screen
    • Next:
      • Debug the driver and fix the init sequence.
  • July 24
    • Progress:
      • Got mmap merged to upstream.
      • Added documentation for Beagle BSP.
      • Added documentation for device tree.
    • Blocker:
      • Pins are not initialized properly
    • Next:
      • Add pinmux from freeBSD to initilze the pins.
  • July 31
    • Progress:
      • The Framebuffer driver is working!
    • Blocker:
      • The blocker to getting it merged is a (possible) memory caching issue that's causing a discrepancy in the produced image.
    • Next:
      • Port RTEMS graphics toolkit.

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.
  • July 3
  • July 10
    • Progress so far:
      • Wrote a shell script to add lib_a-ndbm.o manually to libc.a in RTEMS Toolchain, to start the work with testsuite.
      • Started working on Testsuite.
      • Working on fenv sources.
    • Blocker:
      • Need to find a successful way to generate lib_a-ndbm.o during build of RTEMS Toolchain
    • Next Up:
      • Complete NDBM Testsuite.
      • Enable fenv for SPARC
  • July 17
    • Progress so far:
      • RSB Patch successfully generating lib_a-ndbm.o during build of RTEMS Toolchain.
      • Submitted first version of NDBM Testsuite.
    • Next up:
      • Make required changes in Testsuite
      • Enable fenv for SPARC.
  • July 24
    • Progress so far:
      • NDBM patch is pushed by newlib.
      • NDBM Testsuite is sent to devel ([PATCH V6] ndbm test suite), its execution will be verified once newlib has required files. Although I have tested it by manually generating required file using 'autoreconf -fvi' on my local system.
    • Blocker:
      • My pace got slow last week as my college started, I informed about it on devel.
    • Next:
      • Implement fenv for SPARC first, then move on to ARM, PPC and others.
  • July 31
    • Progress so far:
      • Plan Shifted to first make a testsuite for fenv for RISC-V architecture.
      • Working on Testsuite.
    • Blocker
      • Code structure to be finally verified for fenv by Newlib community.
    • Next
      • After developing testsuite, implement fenv for SPARC.