= Google Summer of Code 2018 = [[TOC(GSoC/2018, depth=2)]] 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 || [https://docs.google.com/document/d/1F5XCodvX8AYNqWX5ssu7dfjkmFT__83uf8ABKbB_Pkg/edit?usp=sharing 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 [https://docs.google.com/document/d/1F5XCodvX8AYNqWX5ssu7dfjkmFT__83uf8ABKbB_Pkg/edit?usp=sharing 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 [https://summerofcode.withgoogle.com GSoC site]. * The ''Final Submitted'' should be set to Yes when you have submitted your Final PDF proposal on the official [https://summerofcode.withgoogle.com 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 [wiki:Developer/GSoC/ProjectManagement SoC Project Management]. ||'''Student Name'''|| '''IRC Handle''' || '''Project Link''' || '''Repository Link on Github''' || '''Blog''' || '''Calendar''' ||NAME || nick on #rtems || [https://devel.rtems.org/wiki/GSoC/2018 Project Wiki] || [https://github.com/rtems/rtems Project's Github repo] || [https://www.rtems.org Blog] || [https://calender.google.com Project Schedule] ||Udit kumar agarwal||madaari|| [https://devel.rtems.org/wiki/GSoC/2018/Porting_SDIO_and_Benchmarking Wiki] ||[https://github.com/madaari/GSoC-Porting-SDIO-driver-and-benchmarking Github]||[http://uditagarwal.in/ Blog] || TBA ||Amaan Cheval||amaan|| [https://devel.rtems.org/wiki/GSoC/2018/x86_64_BSP Wiki] ||[https://github.com/AmaanC/rtems-gsoc18 Github]||[http://blog.whatthedude.com/ Blog] || [https://calendar.google.com/calendar?cid=cmNyOWhkMGp1N2kyNmE5aTFjZnRnZ2NlZW9AZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ Calendar] ||Vijay K. Banerjee||vijayk|| [https://devel.rtems.org/wiki/GSoC/2018/coverage_analysis_toolset Wiki] ||[https://github.com/thelunatic/rtems-tools Github]||[https://thelunatic.github.io/rtems_gsoc18/ Blog] || [https://calendar.google.com/calendar?cid=NTIzYWpuaWxmbnVxNzByY2NodGk4cDI5aDBAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ Calendar] ||Vidushi Vashishth||reachvidu||[https://devel.rtems.org/wiki/GSoC/2018/EnhancementRuntimeTracing Wiki]||[https://github.com/VidushiVashishth/rtems Github]||[https://vidushivashishth.github.io/ Blog]||TBA|| ||Danxue Huang||Dannie||[https://devel.rtems.org/wiki/GSoC/2018/Release_Notes_Generator_%26_POSIX_User_Guide_Generator Wiki]||[https://github.com/dh0072/ReleaseNotesGenerator Github]||[https://danxuehuang.blogspot.com/ Blog]||TBA|| ||Salil Sirotia||salil||[https://devel.rtems.org/wiki/GSoC/2018/Posixcompliance Wiki]||[https://github.com/salil0907/RTEMS Github]||[https://posixcompliance.blogspot.in/ 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 == * 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 16 * Added [https://devel.rtems.org/wiki/Developer/Simulators/QEMU#QEMUandUEFIusingOVMFEDKII instructions for running QEMU with UEFI (built using OVMF)] to the wiki * [https://github.com/AmaanC/rtems-gsoc18/tree/ac/stub-x86-link-tests-pre-bspreorg-bak Completed a compile stub which builds and links to tests] with the x86_64-tools (before the BSP source reorganization) * [https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=602fa1e9d3ea5e87d4d6e17e3e91fc2647e42da3 GCC patch] for -qrtems, -qnolinkcmds, etc. * [https://git.rtems.org/rtems-source-builder/commit/?id=defa958301215995b0fa41d8e65cb23c9a28a847 RSB patch] to backport the above GCC patch * [https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ab55f7db3694293e4799d58f7e1a556c0eae863a GCC patch] to have GCC build crti.o and crtn.o (for _fini symbol) * [https://git.rtems.org/rtems-source-builder/commit/?id=a3a6c34c150a357e57769a26a460c475e188438f RSB patch] to backport the above GCC patch * [https://github.com/AmaanC/rtems-gsoc18/tree/ac/daily-01-compile-stub Started on compile stub] after rebasing for BSP source directory reorganization * Started thinking about and discussing how the UEFI application's PE file will be generated with our build system. Options: 1. EFL to EFI/PE converter in rtems-tools 2. Generate PE headers through ASM file within rtems kernel * 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. [https://lists.rtems.org/pipermail/devel/2018-May/021601.html Looks likely!] * Research various methods possible of making an OS UEFI-aware [https://blog.whatthedude.com/post/uefi-app-options/ blog about it] * [https://www.sourceware.org/ml/binutils/2018-05/msg00197.html Make patch to binutils] to add pei-x86-64 target to tools to allow using objcopy for ELF->PE conversion * 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 ([https://lists.rtems.org/pipermail/devel/2018-May/021751.html 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_ [https://lists.rtems.org/pipermail/devel/2018-June/022019.html 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: [https://docs.google.com/spreadsheets/d/1_lf9S136z0tJyni9W3t1__Rlrkal1fd6L7-vnlmYQpc/edit?usp=sharing 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: [https://devel.rtems.org/ticket/3429 #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([https://github.com/madaari/GSoC-rtems-18/blob/master/patch/0001-Added-MMCCAM-SDIO-stack-to-freebsd-head-642b174dadd.patch 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 [https://vidushivashishth.github.io/Third-post-copy/ 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 [https://vidushivashishth.github.io/sixthpost/ 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. == 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.