wiki:GSoC/2020

Version 67 (modified by UTKARSH RAI, on 07/01/20 at 03:00:47) (diff)

--

Google Summer of Code 2020

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

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
G. S. Niteesh Babu Yes niteesh Beagle BSP: Add a flattened device tree based initialization Beagle BSP: Add a flattened device tree based initialization Yes
Mritunjay Kumar Sharma Yes mritunjay394 BSP Buildset for EPICS BSP Buildset for EPICS Project Proposal Yes
Eshan Dhawan Yes eshandhawan51 POSIX Complience POSIX Complience Project Proposal (draft) Yes
Denil C Verghese Yes tupio[m] RTEMS Release Notes Generator Proposal Link(Draft) No
Suyash Singh Yes suyashsingh234 Clang-analyzer and LLVM sanitizer Integration Clang-analyzer and LLVM sanitizer Integration Yes
Anmol Mishra Yes anmol27katyani RTEMS Python Standardization Link to draft proposal(shared with mentors) Yes
Richi Dubey Yes richidubey Improve the SMP scheduler with arbitrary processor affinity supportGSOC2020_Dubey_ProcessorAffinityinSMP Yes
Utkarsh Rai Yes ur10 Memory Protectionhttps://docs.google.com/document/d/1AawmqbfCpRDHZ4cO5-UE1J7VacubNWmn3kae4rlPrZA/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. Email your proof to Gedare, Joel, and Chris Johns.
  • 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
Richi Dubey richidubey Wiki Github Blog Project Schedule
Niteesh Babu G S niteesh Wiki Github Blog Project Schedule
Utkarsh Rai ur10 Wiki Github Blog [TBD]
Mritunjay Kumar Sharma mritunjay394 Wiki GitHub Blog [TBD]
Eshan Dhawan eshandhawan51 Wiki Github Blog Project schedule

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 Calendar 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 3: Tracking status page created.
  • June 2: Held Initial Meeting.
    • Set format of meeting.
    • Discuss expectations:
      • Participate in IRC and mailing lists.
      • Attend weekly meetings and give status updates on wiki.
      • Post to Github each day of work.
      • Merge significant pieces of code as they are ready.
      • Provide 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 9: Held Meeting.
    • Remember to push code to personal Github repositories daily to show progress and consistent activity.
    • Before submitting patches review how to generate patches and use of version numbered patches using -v option of git-format-patch.
    • Student Updates.
  • June 17: Missed Meeting. Students gave updates by email.
  • June 23: Held Meeting.
    • Inquire about rescheduling meeting 30m sooner.
    • Reminders about Phase 1 Evaluations, and the need to start producing useful code.
    • Student updates.

Joel

  • Jan 3: Let's get started!

Richi

  • June 3: First Meeting
    • Overview of the project: Introduce strong APA scheduler implementation which would improve the current SMP scheduler in RTEMS.
    • Progress till now: I now have a clear understanding of the paper and my goals. I have some hours of experience trying to understand the RTEMS codes, so I am relatively in a better position than I was a month or two ago.
    • Blockers: Understanding RTEMS codebase is still proving to be very difficult for me. Going through each and every typedef and structure definitions that are present in different header files across different folders and linking them all together(logically in my mind) is taking up a huge amount of time.
    • Goals for the next meeting: Work on a simple scheduler(can be uniprocessor) and write a test to better understand scheduling/codebase of RTEMS.
  • June 10: Second Meeting
    • Progress till now: I have a better idea of the different structures and functions that we are using, like scheduler_context, scheduler_operations, and also how a scheduler is linked to its header file and the configuration file.
    • Goals for the next meeting: Edit the existing scheduler(Deterministic or Simple) and experiment with the existing test suites. Then add a graph structure definition(with header file and implementation) and try to be nearer to strong APA implementation by testing code related to graphs and breadth-first search. Before adding, I'd check the existing graph implementation present for deadlock detection. Also, I'd start pushing code to GitHub? as frequently as possible.
    • Blockers: None. I'd have to get more comfortable using vim and cscope(software used to search functions and macros in a big c project).
  • June 17: No meeting (Self Reflections)
    • Progress from last week:
      • Made changes to both deterministic and simple scheduler and their corresponding test suites.
    • Goals for this Week:
      • Add graph implementation with node traversal functionality and edit a test suite to check if my implementation is working
    • Blockers
      • The changes I made over the week are not working as intended. I still need to put time into figuring out what is wrong.
  • June 24: Fourth Meeting
    • Progress from last week:
      • Became more comfortable with the (old) build system and successfully debugged my changes in the sp schedulers and their corresponding test suites. Also learned a little about SMP schedulers
    • Goals for this Week:
      • Keep learning about SMP schedulers and try to run the code with tracing turned on
    • Blockers
      • Going through the vast amount of code related to SMP systems

Utkarsh

Overview of the project: Provide configurable thread-stack protection to threads in RTEMS

  • June 3: First Meeting
    • Progress:
      • Was able to startup the MMU for xilinx_zynq BSP and isolate two pieces of memory with the MMU.
    • Goals for this week:
      • Have the MMU startup along with the system initialization and isolate thread stacks from each other.
    • Blockers:
      • My understanding of the system startup code(written in assembly) is limited.
  • June 10: Second Meeting
    • Progress:
      • Was able to figure out MMU initialization at system start for Xilinx zynq BSP.
      • Provided high-level APIs for setting/unsetting of memory attributes, flag translation, and stack management.
    • Goals for this week:
      • Complete the context switching implementation for protected/shared stacks
      • Tracking of protected stacks through score objects.
    • Blockers:'
      • I have to figure out how to use score objects to track protected/shred stacks
      • Resolving ticket #3131 is an important step in that process.
  • June 17: Third Meeting
    • Progress:
      • Provided support for stack isolation and context-switch by using the score chains.
      • Improved my understanding of the score objects and formed an idea of how to track stack attributes through them (My idea may not be correct and I will discuss it on the mailing list)
    • Goals for this week:
      • Complete the low-level context switch implementation and verify that the stacks are being isolated, if this is done early start with stack sharing implementation.
      • Try to complete stack attribute tracking through score objects.
    • Blockers:'
      • When I try to include the rtems/score/stackmanagement.h header with cpu.h header it breaks the build. Figure out a way to separate asm and c code.

  • June 24: Fourth Meeting
    • Progress:
      • Understood the thread initialization, thread dispatching, context switching procedure in RTEMS.
      • Completed the low-level context switch implementation for isolating thread stacks.
    • Goals for this week:
      • Fix all the pending bugs, memory leaks, and verify that stacks are being isolated.
      • Start the stack sharing implementation.
      • If this is done early, implementation of the optimizations during context switching.
    • Blockers:
      • The implementation has some subtle bugs, most of them have been resolved but a few remain in the assembly context switching code.
      • I also suspect that my implementation is leaking memory, have to fix that.

Eshan

Project: POSIX Compliance

  • June 3: First Meeting
    • Progress:
      • Sent Patch to add fenv support for ARM.
      • Sent Patch to add fenv support for PowerPC
    • Goals for this week:
      • Send Patches for adding Fenv support for SPARC, AARCH64, MIPS .
    • Blockers:
      • Understanding and accommodating NetBSD fenv files for Newlib.
  • June 10 Second meeting
    • Progress
      • Fenv patch for PowerPc? merged in Newlib.
      • Setup autoreconf 2.68 and automake 1.11.6
      • Sent patch for fenv support for SPARC
      • Aarch64 patch is ready waiting to be tested
      • Working on adding Fenv support for MIPS
    • Goals for this Week:
      • Add MIPS fenv support
      • Add timer_create() test for CLOCK_MONOTONIC
      • Add confstr() to Rtems_libbsd
    • Blockers
      • Understanding the test structure of psxtimer.
      • Figuring out How to run tests in RTEMS-libbsd.
  • June 17 Third meeting
    • Progress
      • Fenv patch for ARM merged in Newlib
      • Sent Patch to add fenv support for MIPS and AARCH64
      • Adding confstr() to libbsd is under progress, I have added the initial files.
    • Goals for this Week:
      • Add timer_create() test for CLOCK_MONOTONIC
      • Add confstr() to Rtems_libbsd
    • Blockers
      • Understanding the test structure of psxtimer.
  • June 24 Forth meeting
    • Progress
      • ported confstr to libbsd
      • Added the initial port for ftw.h
    • Goals for this Week:
      • complete the port for ftw.h methods
      • write test for confstr()
    • Blockers
      • Understanding the test structure of psxtimer.
  • July 1 Forth meeting
    • Progress
      • completed FTW.h patch and added -D_FTW_ENABLE_ for it in configure.host in newlib
      • working on FTW testsuites (adding the file system remaining )
    • Goals for this Week:
      • complete ftw test suite
      • Add test for timer create
    • Blockers
      • Understanding and integrating file system imfs in the test suite

Niteesh

Project: Beagle BSP: Add FDT based initialization

  • June 3: First Meeting
    • Progress:
      • Imported and ported OFW functions from FreeBSD to RTEMS.
      • Sent patches to add OFW functions
    • Blockers:
      • The directory for the FreeBSD hasn't been decided properly.
    • Next up:
      • Port the pinmux driver from FreeBSD to RTEMS
  • June 10: Second Meeting
    • Progress:
      • Ported pinmux driver to Beagle BSP.
      • Integrated with libBSD.
    • Blockers:
      • Facing few issues when using with libBSD.
    • Next up:
      • Implement a generic pinmux driver into RTEMS.
  • June 17: Third Meeting
    • Progress:
      • Started implementing FreeBSD structures to make porting easier.
      • Updated blog.
    • Blockers:
      • Facing few issues with pinmux driver when used with libBSD.
    • Next up:
      • Finish implementing FreeBSD structures.
      • Fix issues in pinmux driver when used with libBSD.
      • Implement a generic pinmux driver into RTEMS.

Mritunjay

Project: BSP Buildset For EPICS

  • June 3: First Meeting
    • Progress:
      • Written .cfg and .bset files for ptp daemon in rtems/rsb to build for xilinx_zynq_a9_qemu.
      • Netinet support was worked upon.
    • Blockers:
      • Getting netinet support involved too many configure errors.
    • Next up:
      • Configuring ptpd code to add support to RTEMS RSB toolchain.
  • June 10: Second Meeting
    • Progress:
      • Modified ptpd code to add support to RTEMS RSB toolchain.
      • Problem of netinet resolved (it came because earlier I was working erc32)
      • Changes made in config files of ptpd in rsb/source-builder to tackle configure errors.
      • Parallelly worked on alternate PTP deamon (ppsi) but configure errors again occurred.
    • Blockers:
      • Facing new errors basically pointing to configure.ac file.
    • Next up:
      • Implement ptpd build by resolving issues into RTEMS.
  • June 17: Third Meeting
    • Progress:
      • Earlier errors have been resolved but a new one popped up
      • Modified source-builder/config/ptpd-2-1.cfg file again, after Googling a little and following Heinz advice
      • After this I made the local ptpd-master again a tar ball and used it,which fixed the earlier, but now another error has popped up which I am trying to fix.
    • Blockers:
      • New error, configure: not found
    • Next up:
      • Looking forward to raise this with the ptpd community and trying with the help of mentors to fix the problems as soon as possible.