wiki:GSoC/2018

Version 119 (modified by Amaan Cheval, on 08/01/18 at 13:33:21) (diff)

--

Google Summer of Code 2018

Table of Contents

  1. Google Summer of Code 2018
  2. Students' Proposals
  3. Students' Summer of Code Tracking Table
  4. Student Status Updates
    1. Gedare
    2. Joel
    3. Amaan Cheval
    4. Vijay Kumar Banerjee
    5. Udit kumar Agarwal
    6. Danxue (Dannie) Huang
    7. Vidushi Vashishth
    8. Salil Sirotia

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 ​Github​Blog TBA
Amaan Chevalamaan ​Wiki ​Github​Blog ​Calendar
Vijay K. Banerjeevijayk ​Wiki ​Github​Blog ​Calendar
Vidushi Vashishthreachvidu​Wiki​Github​BlogTBA
Danxue HuangDannie​Wiki​Github​BlogTBA
Salil Sirotiasalil​Wiki​Github​BlogTBA

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.
  • July 18: Held Meeting.

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/
  • July 25
    • Determine method to use to detect presence of APIC (MSR, not CPUID), to find its physical address (MSR, not MADT or other ACPI tables)
    • WIP code to initialize the APIC
  • August 1
    • Relocate APIC base to account for FreeBSD's paging limitation (they map every 1 GiB of virtual memory to the first 1 GiB of physical memory, making the default APIC address 0xfee00000 inaccessible by default)
    • Setup code to build Interrupt Descriptor Table, and call lidt with this table in C (confirmed working by hooking IRQ0 for exception #de)
    • WIP: Work on gluing together processor-specific interrupt management code with RTEMS' interrupt manager, to allow for automagical thread-dispatch after interrupts and for nested interrupt support

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.
  • July 11
    • Progress so far
      • Getting correct source file for respective gcno files in covoar
      • using -o option to run gcov for the source and notes files.
    • Blockers
      • Seg fault due to resource leak in readString()
      • gcno file is not being parsed properly.
    • Status
      • Debugging the segmentation fault.
      • Working on getting a gcno dumper to understand the gcno file.
  • July 18
    • Progress so far
      • Made a gcno dumper to dump the contents of the gcno file into a human-readable txt file.
    • Status
      • Working on a wrap-up of the non-gcov reports.
      • Working on completion of the gcno dumper.
  • July 25
    • Status
      • Completed the work on coverage script which now is able to generate complete report by invoking covoar separately for each symbol-set.
      • Verifying the generated reports by comparing them against the old reports.

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
  • July 3
    • status
      • Backported the SDIO driver and documented the procedure with way arounds
      • Setup the build set for MMCCAM and started porting the driver to RTEMS
    • next
      • Replace the BIO/GEOM part of the driver with our libblock API
      • Resolve all linker dependencies associated with the driver
  • July 11
    • status
      • All dependencies are now resolved and have substituted the GEOM/BIO part
      • Currently working on getting the CAM XPT layer to work and then pass the CCB's to the SIM(SDIO stack here)
  • July 18
    • status
      • Driver is currently able to correctly distinguish between SDIO/MMC/SD cards
      • Further, After initializing the card, it's able to read/set it's registers and calculate the capacity along with the partitions
      • Currently, i'm working on the part concerned with mounting the partitions using rtems block device API

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
  • July 11
    • Current progress:
      • Generated Markdown version of release notes supported by Python 2 and Python 3
      • Did research on Newlib
    • Next:
      • Set the width of release notes in standard size
      • Merge code of release notes to rtems-tool
      • Work on conversion of Newlib to Sphinx
  • July 18
    • Current progress:
      • Fixed problem for release notes to fit in A4 size
    • Next:
      • Merge code of release notes to rtems-tree
      • Work on conversion of Newlib Markup to Sphinx
  • July 25
    • Current progress:
      • Tested Newlib files by using RST editor
    • Next:
      • Fix bugs for makedocbook.py
      • Transform .c files to .rst files

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.