wiki:GSoC/2018

Version 88 (modified by Danxue Huang, on 06/13/18 at 16:17:17) (diff)

--

Google Summer of Code 2018

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

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
Braden Elliott Yes braden on #rtems STM32F446RE BSP https://docs.google.com/document/d/1nUlxKEiiW19ZxnN1Zn_ZLNP4R30kSAMXEF9VwQizq3w/edit?usp=sharing Yes
ANSHUMAN CHHABRA Yes anshuman23 on #rtems TBD TBD TBD
Amaan Cheval Yes Amaan x86_64 port and BSP https://docs.google.com/document/d/1X79Yj0DNqvaDFqpJMUX4gF3WC550GDvVDS5QufvAnFE/edit?usp=sharing Yes
Vidushi Vashishth Yes reachvidu on #rtems Runtime tracing https://docs.google.com/document/d/1M7IUGsK3J6zqsNmyDhWKuRT69m4_SWqjftczrJKgHPM/edit?usp=sharing TBD
Vijay K. Banerjee Yes vijayk on #rtems Improve Coverage Analysis Toolset https://docs.google.com/document/d/1UjCWE1ojrpDQLQ2fQqxHU0SCrLETlerxD6t0SOcQNLQ/edit?usp=sharing Yes
Udit kumar Agarwal Yes madaari on #rtems Porting SDIO driver and benchmarking https://docs.google.com/document/d/15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtReF_P-wNR861NMo/edit?usp=sharing Yes
Salil Sirotia Yes salil on #rtems Posix Compliance https://docs.google.com/document/d/15aUQShwRzIOQQoNAGV9jjeJ1Q2CHLcv_icamEqrTORE/edit?usp=sharing Yes
Danxue Huang Yes Dannie on #rtems RTEMS Release Notes Generator (ticket: #3314) & RTEMS POSIX User Guide Generator (ticket: #3333) https://docs.google.com/document/d/1cHFxkgv9VjDV0UrVAOaDyeE3XqnAXHQo70ciVpUSG58/edit 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
Udit kumar agarwalmadaari Wiki GithubBlog TBA
Amaan Chevalamaan Wiki GithubBlog Calendar
Vijay K. Banerjeevijayk Wiki GithubBlog Calendar
Vidushi VashishthreachviduWikiGithubBlogTBA
Danxue HuangDannieWikiGithubBlogTBA
Salil SirotiasalilWikiGithubBlogTBA

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

  • Jan 5: GSoC 2018 application submitted and tracking status page created.
  • May 16: 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
  • May 23: Missed Meeting.
  • May 30: Held Meeting.
    • Remind students to merge code and make progress. We are halfway through Phase 1.
    • Student Updates.
    • Ask students to review how to generate version numbered patches using -v option of git-format-patch.
    • Remind students to push their code to personal Github repositories daily to show progress and consistent activity.

Joel

  • Jan 5: Signed up as an Org Admin.

Amaan Cheval

  • May 23
    • Complete compile stub after BSP reorg rebase
    • Investigate possbility of updating GCC to have an empty bsp_specs file for the new port. Looks likely!
    • Research various methods possible of making an OS UEFI-aware blog about it
    • Next: Investigate how FreeBSD builds and links to gnu-efi (potentially problematic for us since initial research suggests the need for -fpic -shared code)
  • May 30
    • Understand how FreeBSD becomes UEFI-aware (summarized on the mailing list - tl;dr: they use an ELF loader to boot the kernel which is compiled as an ELF image)
    • Investigate how relocation works and what gnu-efi's runtime "self-relocator" is meant for (spoilers: for load-time / runtime relocations for a specific subset of relocations since the dynamic shared library is meant to be a fully resolved one)
    • Make a minimal project to play with gnu-efi and the different ways in which we may be able to integrate it into RTEMS (to reproduce RTEMS' structure with librtems*.a, gnu-efi, and user applications)
  • June 6
    • Add crtbeginS and crtendS targets for GCC to build and use when the -shared flag is used
    • Configure GCC to use -fPIC by default to compile Newlib as PIC
    • Compile all of RTEMS as a shared library
  • June 13
    • Integrate gnu-efi into build system and have efi_main (UEFI entry point) call bsp_start as a POC demo
    • Carry out discussions about possibly _not_ using this kernel.so method
    • Work on a PoC to have FreeBSD's loader.efi's ELF loader load RTEMS' static binaries (building PoCs? for both methods, effectively) (involves installing FreeBSD and replacing its kernel with our RTEMS ELF)

Vijay Kumar Banerjee

  • May 16
    • Progress so far :
      • The configuration files for coverage analysis are added.
      • The Coverage analysis is running from the top of the build tree.
      • txt coverage reports show good data .
    • Blockers:
      • The html reports don't show any data.
      • The coverage can't be run from out of the the build treee (the address in score-symbol.ini needs to be updated for that)
    • Current status:
      • working on the gcov support in covoar. currently producing the gcno file by changing the GCC flag and then feeding that to covoar is the next milestone.
  • May 23
    • Progress so far :
      • The --coverage is showing html report
      • The build path generator has been added to script
    • Blockers :
      • Generating gcov report from the .gcno files
    • Current status :
      • Working on adding support in coverage to let the user select symbols for coverage analysis
      • Working on generating .gcno file and generating gcov report.
  • May 30
    • Progress so far:
      • Added support for letting users run coverage on specific symbol/subsystems
      • The tester doesn't need to be run from top of build directory.
    • Blockers:
      • Covoar stores the coverage reports of all the subsystems into one directory which needs to be separate in order to make the report reliable and to get better idea of coverage of each subsystem.
      • The coverage script is hard coded to run for sparc-rtems5, which needs to be changed. One solution could be to include target in the ini config file for the bsp
    • Current status:
      • Working on producing separate coverage reports for each subsystems.
  • June 6
    • Progress so far:
      • Coverage script is now merged with the master repo.
      • Generated .gcno files by changing the gcc flags in config file
    • Current status:
      • Working on ticket #3440
      • Working on gcov arguments of covoar to get an output

Udit kumar Agarwal

  • May 16
    • Progress so far :
      • Comparison and testing of different benchmarks on FreeBSD
      • Carried out performance analysis of SDHCI and SDIO driver on FreeBSD: Results
    • Blockers:
      • IO Benchmark to be used, is yet to be finalized, before starting with the porting process.
    • Current status:
      • Understanding the internal working of IOZONE to see if most of its features are supported on RTEMS
  • May 23
    • Progress so far :
      • IO Benchmark finalized - FIO, to be imported
    • Blockers:
      • None
    • Current status:
      • Started with resolving FIO's dependencies
  • May 30
    • Current status:
      • Working on FIO's port, resolved most of the dependencies
    • Next:
      • Test most of the working features and determine the necessary ones
      • Finalize the ioengines to be used
  • June 6
    • Current status:
      • Compiler/linker errors are all resolved
      • Fio has been configured to run as a shell command after mounting the sd card and some of it's features are even working.
    • Next:
      • Replace excessive use of mmap() with malloc/calloc
      • Debug option parsing
      • Implement memory cleanup after fio exits
  • June 13
    • Current status:
      • Fio configuration/job file is now properly loading
      • Memory cleanup has been implemented upto a large extent.however, some memory leakages still exists.
    • Next:
      • Solve problem with ioengine loading

Danxue (Dannie) Huang

  • May 16
    • Topic discussed:
      • Introduction about two tickets I am going to work on: RTEMS Release Notes Generator & Automate Conversion of Newlib Markup to Sphinx
      • Adjustment on process for generating the release notes
    • Current progress:
      • Fetch all the information and generate report from Trac
      • Refactor RSS page by using Python script
  • May 23
    • Topic discussed:
      • Progress and goal about the final version of release report
    • Completed:
      • Generated the current version of release report from Trac
    • Next:
      • Fix problems like formatting issues on the current generated report
  • May 30
    • Topic discussed:
      • Blockers in writing Python class for getting data
      • Push and merge codes on github
    • Progress so far:
      • Almost finish writing Python class for getting data
      • Push codes to personal github repository
      • Update blog about using search method beautifulsoup to parse HTML page
    • Next:
      • Solve problems in writing Python class for getting data
      • Clean up codes
      • Get mentors to review codes and finally merge codes
  • June 6
    • Topic discussed:
      • Phase 1 evaluation
      • Code review
    • Current progress:
      • Finish writing Python class for getting data from a milestone’s page and a ticket’s page
      • Set up test cases
      • Add logging to show progress
    • Next:
      • Use Sphnix to create HTML and PDF output
      • Update blog about using logging instead of print to output a message
  • June 13
    • Topic discussed:
      • Phase 1 evaluation
      • Phase 2 work period
    • Current progress:
      • Tested the program and fixed some small bugs
      • Solved code consistency problem, for example, to use lowercase other than camel case.
      • Used built-in python package instead of external python package
    • Next:
      • Finish code cleanup
      • Convert the output to Markdown
      • Package code and then merge it to public RTEMS repo

Vidushi Vashishth

  • May 16
    • Progress so far:
      • In the middle of developing use cases for the tracing framework
      • Working on setting up CTF traces on MacOS, and improving barectf
    • Current blockers:
      • Building difficulties due to extensive dependencies on numerous libraries that might not be compatible with MacOS
      • Will try changing development environment to Linux and duplicating the efforts
  • May 23
    • Progress so far:
      • Documented the first idea for trace linker's use cases Use Cases
      • Installed and understood the working of babeltrace
      • Identified problems with the current trace-linker
    • Next:
      • Working on a patch to fix the rtems-trace linker
      • Once this works I will document the method of CTF trace generation
      • Will begin working on integrating barectf with trace linker as the next step
  • May 30:
    • Progress so far:
      • Submitted a patch to fix rtems-trace linker for successfully generating trace buffers
      • Writing a blog to explain the process of CTF trace generation
      • Writing a CTF mode trace configuration to be used in CTF trace generation by the trace linker
    • Next:
      • Begin working on user manual documentation for the tracing system
      • Submit patches for the progress in CTF trace generation
  • June 6:
    • Progress so far:
      • Submitted preliminary trace documentation patches
      • Proposed two methods of CTF trace generation using 1) barectf and 2) babeltrace
      • Documented these approaches in blog
    • Next:
      • Decide on one approach and work on a use case using it.
      • Finish work on the documentation

Salil Sirotia

  • May 16
    • Progress so far:
      • Working on memcpy method and license issues to port the code in Newlib.
  • May 23
    • Topic discussed:
      • Progress and ways to add memcpy in Newlib.
    • Current Blockers:
      • How to make autoreconf 2.64 as a default.
      • Updation in makefile.in
    • Next:
      • Adding dirfd method in dirent.h in Newlib.