wiki:GSoC/2018

Version 106 (modified by Vidushi Vashishth, on Jul 11, 2018 at 1:19:08 PM) (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.
  • June 6: Held Meeting.
    • Connectivity troubles at start of meeting. Joel took over.
  • June 13: Held Meeting.
    • Advise students on expectations for Phase 2. I expect to see publicly useful, merged code during this phase.
    • Mention my absence in next two meetings.
    • Probably rescheduling of meeting on July 4.
    • Remind students to keep blogs up-to-date, and that a post to reflect on Phase 1 is a good idea.
    • Student Updates.

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)
  • June 20
    • Settle on (pun intended) freeloading FreeBSD's bootloader for UEFI-awareness for the port
    • Fix up stub port's cpu.h to reflect the x86_64 feature-set more closely
    • Fix up port's linker script and work on SYSINIT functions
    • Figure out how context initialization and switching ought to work (work in progress)
  • June 27
    • Complete workable context initialization and switching code (will need cleanup)
    • Reach user's Init task
    • Basic UART driver using inb and outb instructions (manual, without using NS16550 driver in libchip)
  • July 3/4
    • Rebase with master and update BSP to account for interrupt-stack changes
    • Use ns16550-context.c and console-termios.c, to support printf/printk through UART
    • Make WIP pull-request on Github for initial review and clear "cleanup plan": https://github.com/AmaanC/rtems-gsoc18/pull/1/

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
  • June 13
    • Progress so far:
      • Coverage script is running
      • Covoar is taking gcov arguments
    • Current status
      • Working on ticket #3440
      • Working on gcov support in covoar
  • June 20
    • Progress so far
      • covoar is generating gcda files
    • Blockers
      • the gcda files don't have proper data
      • gcno file reading error in covoar.
    • Current status
      • The gcda files are being written by covoar
  • June 27
    • Status
      • Working on the Gcno string reading error produced by covoar
      • Looking into GCC source for Gcov to figure out how the coverage data is dumped into gcda files
  • July 3
    • status
      • GcovData?.cc is getting segmentation fault when gcov arguments are given as it is not extracting the correct path to the source files.
      • Studying the process of gcov creation in gcc and qemu traces to replicate it in covoar.
      • experimenting with gcov options to generate reports with source and object files in different directories.

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
  • June 20
    • Current status:
      • Fio is now working and can be invoked as a shell command
      • Following IOengines are currently working: sync,psync,vsync,null,filecreate.fftruncate
      • Updated the corresponding ticket: #3429
    • Next:
      • Proceed ahead with phase 2 goals:
        • Determine the latest FreeBSD HEAD revision, stable enough for importing the MMCCAM stack
        • Understand the MMCCAM structure and list all the files/modules required to be updated for MMCCAM
        • Backport the MMCCAM stack to FreeBSD head 642b174dadd(the one used by libbsd)
  • June 27
    • Current status:
      • FreeBSD head d6756a3ac8(22/6/2018) will be used for importing the MMCCAM stack
      • Still working on backporting the latest MMCCAM stack, few kernel panics need to be resolved
      • MMCCAM stack is now ported to freebsd head 642174dadd(patch), now working on it's documentation and then porting it to RTEMS

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 like to use lowercase other than camelcase
      • 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
  • June 20
    • Current progress:
      • Solved code consistency problem following instructions
      • Finished code cleanup
    • Next:
      • Convert the output to Markdown
      • Convert the output to HTML and PDF
  • June 27
    • Current progress:
      • Converted the output to Markdown
    • Next:
      • Decide final version of Markdown
      • Convert the Markdown output to HTML and PDF
  • July 3
    • Current progress:
      • Generated the final version of release notes in Markdown
    • Next:
      • Set the width of release notes in A4 size
      • Merge code to rtems-tool
      • Start the second project

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
  • June 13:
    • Progress so far:
      • Submitted final version of the tracing documentation. It has been pushed onto the main repository.
      • Working on a function in the main_rtrace.c file which uses babaeltrace C API to convert RTEMS traces to CTF.
    • Next:
      • Finish CTF code generation and prepare mergeable code.
  • June 20:
    • Progress so far:
      • Still working on adding rtrace shell capability to convert RTEMS traces into CTF. There has been progress which I will upload on my GitHub? repository.
      • I have gone through libdebugger's abstraction of transport interfaces in preparation of the second phase. I need to deliver a transport mechanism to transfer buffers to the host in this phase.
    • Next:
      • Submit mergeable code for CTF integration
      • Setup qemu for ARM as working environment to try qemu fat files and file transfer as a method of transport.
      • Write a blog on the possible transport mechanisms to be explored
  • June 27:
    • Progress so far:
      • I am able to generate CTF traces using the babeltrace method. I saved the rtems trace output in a raw file and used babeltrace conversion graph to convert the traces into CTF format. I have documented the process in a blogpost : https://vidushivashishth.github.io/eighthpost/
      • I have written a yaml configuration file to try the barectf method of trace conversion. I will be trying this out along with my phase 2 objectives.
      • I have setup qemu for ARM machines as the working environment for testing transportation mechanisms.
    • Blockers:
      • Babeltrace calls inside the rtems shell shows no output. One way around could be to transport the traces off the target to the host and then run the conversion to CTF using babeltrace.
  • Next:
    • Try qemu fat files and file transfer protocol as a transportation mechanism from the target to the host.
  • July 3:
    • Progress so far:
      • I am able to convert RTEMS trace output to CTF using babaletrace script.
      • I am working on creating a temporary transport mechanism which parses the RTEMS trace shell output from the target to the host.
    • Next:
      • Trying both of the above steps together. Possibly automate the process.
      • Pushing this on the Tracing repository.
      • Working on sockets or a transportation API as the method of transporting traces to the host from the target instead of parsing console output.
  • July 11:
    • Progress so far:
      • Created make file to generate trace from fileio sample.
      • Tried sockets as a mode of trace transportation.
      • Working on babeltrace plugin to convert RTEMS binary format to CTF.

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.