wiki:GSoC/2020

Version 81 (modified by eshan dhawan, on Jul 26, 2020 at 6:46:23 AM) (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.
  • June 30: Held Meeting.
    • Remind students to complete Phase 1 Eval and to remind their mentors.
    • Announce RTEMS-5 release.
    • Student updates.
  • July 7: Held Meeting.
    • Phase 1 eval complete.
    • Check for areas to improve.
    • Talk to mentors about whether to stick to master branch or both 5 and master
    • Remember to update this page!
    • Student updates.
  • July 14: Held Meeting. Student Updates.
  • July 21: Held Meeting.
    • Reminder about phase 2 evaluation.
    • Reminder to update tracking page.
    • 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
  • 1st July 2020: Fifth Meeting
    • Progress from last week:
      • Kept working on smp schedulers. Tried making few changes but to no avail. Set up the debug environment with realview-arm bsp and Qemu.
    • Goals for this Week:
      • Keep making changes in different parts of the scheduler framework like threads, schedulernode, edfsmp to name a few.
    • Blockers:
      • I am taking too much time on SMP schedulers. Maybe with the Qemu set up, my pace should increase.
  • 8th July 2020: Sixth Meeting
    • Progress from last week:
      • Started working on the APA code. I feel comfortable with the SMP codes and know how to interpret a lot of things, like the inline functions and the C codes related to bit operations and typedef pointers.
    • Goals for this Week:
      • Make a documentation of the code I intend to add, get it reviewed on the ML, and start working on it by this Saturday 11th.
    • Blockers:
      • Writing code compatible with the existing SMP Scheduler Framework i.e. reusing the SMP codes.
  • 15th July 2020: Seventh Meeting
    • Progress from last week:
      • Submitted the first draft for review
    • Goals for this Week:
      • Submit Strong APA test cases and the second draft that has no pseudo-code and which actually compiles properly on RTEMS.
    • Blockers:
      • Trying to achieve too much in a little time. Not scheduling my time efficiently :p.
  • 22nd July 2020: Eigth Meeting: Phase 2 : Week 3
    • Progress from last week:
      • Found out how the entry point functions work and how they’re called when a system/task starts.
      • Learnt how to use gdb for multi-threaded systems.
    • Goals for this Week:
      • Submit a draft with all my intended changes and no pseudo code whatsoever
      • Learn the new build system for an smp architecture.
    • Blockers:
      • Sometimes debugging with gdb isn’t perfect. So learning how to use gdb properly.

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.
  • July 1: Fifth Meeting
    • Progress:
      • Managed to completely isolate POSIX thread stacks.
      • Improved my understanding of RTEMS score objects, and figured out how to refactor that into my existing code.
      • Started with stack sharing implementation.
    • Goals for this week:
      • I will be relatively inactive this week as I am appearing for my end semester examinations.
      • As and when I get the time, continue with stack sharing implementation.
    • Blockers:
      • Right now, I don't see any blockers, maybe when I start refactoring the code with score objects I will face some issues.
  • July 8: Sixth Meeting
    • Progress:
      • Due to my end-semester examinations, my progress for this week was fairly small.
      • I did manage to complete the shared-stack tracking mechanism.
    • Goals for this week:
      • To work on POSIX APIs, mmap() and shm_open(), to provide high-level APIs for stack-sharing.
    • Blockers:
      • I am not sure as to how to 'convert' the stack address to a shared memory object name

  • July 15: Seventh Meeting
    • Progress:
      • Completed stack-sharing mechanism, I will hopefully send the patch today.
      • Started with the implementation of High-level API for stack sharing.
    • Goals for this week:
      • Complete the implementation of the High-level POSIX APIs.
      • Write a test which demonstrates strict thread-stack isolation and stack-sharing of the isolated stacks.
    • Blockers:
      • I plane to rectify the patches that I sent before continuing with my implementation and this can take a day or two before I get my code perfect
  • July 22: Eighth Meeting
    • Progress:
      • Completed stack_address naming mechanism.
      • Completed High-level API for stack sharing.
      • Changed the protected stack tracking mechanism, integrated it with thread control block and simplified the stack tracking mechanism.
    • Blockers:
      • While writing tests for stack-isolation and sharing I realized a very major flaw in my implementation.
      • Currently, the translation table for the complete stack-space is set in a single level (i.e. sections), this means that the second-level table is not set initially. Now when I try to change the memory entries of the alllocated stacks dynamically in page format, it sets invalid entries as the entries were not previously set for the second level table
    • Goals for this week:
      • Resolve the above-mentioned issue.
      • Get feedback on my implementation and make changes accordingly.
      • Complete the test for stack-isolation and sharing by using the high-level APIs

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
  • July 8 Fifth Meeting
    • Progress
      • Completed FTW Testsuite
    • Goals for current week :
      • add tests for confstr to libbsd
      • Start working on adding file descriptor methods
    • Blockers :
      • Not much
  • 15 July Sixth Meeting
    • Current progress:
      • Submitted the FTW.h methods patch with test
      • Submitted the Confstr patch with test
      • Submitted test for Pthread_getcpuclockid
      • Rework of FENV support for ARM almost completed
    • Plans for next week:
      • Start working on file descriptor methods
    • Blockers:
      • Understanding File workings as well as finding generic implementations
  • 22 July Seventh Meeting
    • Progress :
      • Submitted The ARM Fenv patch
      • Sent the MIPS Fenv Patch removing the Soft Float
      • Worked on making the list about various missing *at methoda
    • Plans for the week
      • Write Tests for some *at methods in Libbsd to check if they are present there
      • Make arrangements to port various *at methods
    • Blockers
      • No significant blockers that I currently know of

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.
  • June 24: Fourth Meeting
    • Progress:
      • Finished implementing FreeBSD structures into RTEMS.
      • Started rebasing old patches to the new build system.
    • Blockers:
      • Unfamiliarity with the new build system.
    • Next up:
      • Finish rebasing old patches to the new build system.
      • Fix issues between the pinmux driver and libBSD.
  • July 1: Fifth Meeting
    • Progress:
      • Finished rebasing the old patches and made sure they work with RTEMS.
      • Fixed few bugs in FreeBSD structures in RTEMS.
    • Blockers:
      • libBSD does not build with the new build system.
    • Next up:
      • Test the pinmux driver with libBSD once the issue with the new build system gets resolved.
      • Start implementing the generic pinmux driver.
  • July 8: Sixth Meeting
    • Progress:
      • Fixed the issue with libBSD and the new build system
      • Fixed few bugs in the FreeBSD structures implemented in RTEMS.
      • Imported clock driver for Beagle BSP
      • Posted previous patches to the mailing list
    • Blockers:
      • Waiting for the community to provide their feedback on the patches.
    • Next up:
      • Test the ported drivers with libBSD and new build system
      • Start refactoring the drivers.
      • Implement the generic pinmux driver
  • July 15: Seventh Meeting
    • Progress:
      • Successfully tested pinmux driver with libBSD
      • Cleaned up patches to make them merge ready
    • Blockers:
      • Nothing as of now
    • Next Up:
      • Port and test the clock driver with libBSD
      • Implement the generic pinmux driver
  • July 22: Eighth Meeting
    • Progress:
      • Ported clock driver and is ready for testing with libBSD
    • Blockers:
      • My patches need to be reviewed by the community other than that no blockers as of now.
    • Next up:
      • Start working on the generic pinmux driver
      • Start refactoring the drivers

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.
  • June 24 Fourth meeting
    • Progress:
      • Tried to build ptpd by hand, the configure ran properly, however, build again failed with different errors
      • Halted the work on RSB because it is important to build the packages by hand first.
      • Revisited the epics-base code to study and make note of things where the change is required.
    • Blockers:
      • No Blockers as such
    • Next up:
      • Start the work back on EPICS community codebase first. Working on files mentioned below will be a priority to get things worked. epics7/modules/libcom/RTEMS/posix/rtems_init.c epics7/modules/libcom/RTEMS/posix/rtems_netconfig.c