wiki:GSoC/2022

Version 55 (modified by Prashanth S, on 07/14/22 at 14:02:54) (diff)

--

Google Summer of Code 2022

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

Contributors' Proposals

Start filling in this table for yourself as soon as possible and update as needed.

Contributor Name Completed Hello Discord Handle Proposal Title Google Docs URL Final Submitted
Mohd Noor Aman Yes katana-flinger RTEMS port for Raspberry pi 4 AArch64 RTEMS port for RPi 4B AArch64 Proposal Yes
Prashanth S Yes Prashanth S BeagleBoard? BSP Projects CAN and ADC Peripheral Support for BBB Yes
Mahmoud Abumandour Yes NRG-500 RTEMS Release Notes Generator Release Notes Generator Yes
Kamlesh Bharodiya Yes curious R5 BSP on Qemu Proposal Yes
Duc Doan Yes duk3 STM32F4 BSP Project STM32F4 BSP Project Proposal Yes

The columns are to be filled in as follows:

  • The Contributor 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 nick on Discord column is your handle on Discord. RTEMS folks hang out there with best-effort service.
  • 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!

Contributors' Summer of Code Tracking Table

Contributors 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.

Contributor Name Handle Project Link Repository Link on Github Blog Calendar
NAME nick on Discord Project Wiki Project's Github repo Blog Project Schedule
Duc Doan duk3 Project Wiki Project's Github repo Blog Project Schedule
Mohd Noor Aman katana-flinger Project Wiki Project's Github repo Blog Project Schedule
Mahmoud Abumandour NRG-500 Project Wiki Project's Github repo Blog Project Schedule
Prashanth S S Prashanth Project Wiki Project's Github repo Blog Project Schedule
Kamlesh Bharodiya curious Project Wiki Project's Github repo Blog Project Schedule

The columns are to be filled in as follows:

  • The Contributor Name column is for your name.
  • The Handle column is your nickname on Discord.
  • 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.

Contributor Status Updates

Each contributor has a section below for putting in notes from the weekly Discord meetings.

Gedare

  • Jan 5: Tracking status page created.
  • Feb 7: Org Application submitted.
  • May 25: Held Initial Meeting.
    • Set format of meeting.
    • Discuss expectations.
    • Student Updates

Joel

  • Feb 7: Joined application as Org Admin.

Duc

  • June 1: Second Meeting
    • Last week: introduction, blog, tracking table, setting up environment.
    • Obstacle: VM and WSL problems
    • This week's plan: test hardware, check STM32H7 tree for idea about BSP, mailing list re: STM32F4
  • June 8: Third Meeting
    • Last week: tested and got the bare-metal demos working on my F4 boards, read the H7 BSP and got some direction of how to implement the F4 BSP.
    • Obstacle: cannot make Ethernet work
    • This week's plan: try to make Ethernet work, figure out clearly how to implement the peripherals
  • June 15: Coding Period First Meeting
    • Last week: included HAL, wrote GPIO API & implemented and tested on STM32F4 Discovery
    • Obstacle: cannot make Ethernet work, unsure if modifications to shared libraries will break other BSPs
    • This week's plan: continue with GPIO code and documentation
  • June 22: Coding Period Second Meeting
    • Last week: worked on the GPIO API and implementation for the STM32F4 BSP
    • Obstacle: thinking of a portable GPIO API is time consuming
    • This week's plan: finish GPIO API and STM32F4 code, documentation and test
  • June 29: Coding Period Third Meeting
    • Last week: improving GPIO API based on discussion on devel mailing list
    • Obstacle: portability of API is hard, covid-19
    • This week's plan: continue fixing bugs of GPIO, write documentation
  • July 6: Coding Period 4th Meeting
    • Last week: testing, fixing bugs, writing documentation, git rebase and patch
    • This week's plan: keep improving GPIO API, add remaining features to STM32F4 GPIO, start ADC
  • July 13: Coding Period 5th Meeting
    • Last week: revised GPIO API, added missing STM32F4 GPIO features, wrote wiki for GPIO API
    • Obstacle: personal problems, struggling to start ADC API, project change
    • This week's plan: keep improving GPIO API, write ADC API

Mohd Noor Aman

  • June 1: Community bonding second meeting
    • Last week's work: Introduction to community, discussions, blog writing, bought FT232H adapter, tested serial communication using PL011 (Raspbian bullseye arm64 and alpine 3.15.4 aarch64)
    • Blocker: Very less documentation about FT232H and raspberry pi 4 JTAG
    • Next week's plan: Mid-term exams, testing JTAG + serial with OpenOCD and GDB, and blog about it.
  • June 8: Community bonding third meeting
    • Last week's work: Couldn't do much because of exams, tested JTAG + serial with OpenOCD and OCD, made sure how to troubleshoot common problems while setting it up, wrote an extensive blog about it. Tested out bare metal example, They worked fine.
    • blockers: wires sometimes really mess up the connection while debugging, they need to be stable. My exams were going on too.
    • Next week's plan: Clearing all exams, working on waf for the new BSP in order to build the minimal BSP.
  • June 15: Coding period first meeting
    • Last week's work: Started to create an entry for Raspberry pi 4b in the spec/build. Side by side I'm copying basic files which are needed for the basic bsp build
    • Blockers: not any yet, mentors are present for help
    • Next week's plan: Complete building the spec/build files and work on the linkercmds compatible for the RPi4b
  • June 22: Coding period second meeting
    • Previous week's work: completed the spec/build files for the minimal RPi4b. Started testing the A72 qemu build on the the raspberry pi and making changes to the relevant part of the kernel
    • blockers: Using GDB is new to me so it's taking some time to understand, although using gdb is fun.
    • Next week work: I'll be still working on the kernel using the gdb and based on that , i'll be doing the relevant work needed. I'll be writing about all the things i've learned in the upcoming blog.

Mahmoud Abumandour

  • June 1: Community bonding period second meeting
    • Last week's work: Fixing glaring issues with the current ReleaseNotesGenerator? repository, learning about reStructuredText, generating an overall summary before detailed descriptions of individual tickets, and investigating performance issues with fetching and processing tickets sequentially.
    • Blocker: Profiling shows that most time is spent fetching the tickets from trac, which means an internet speed limitation and not bottlenecked by data processing.
    • Next week's plan: Going through final exams and taking care of my graduation thesis, I don't expect to be able to put much effort. I will start a blog for the project and include manually-written pre-existing top-level notes to the new generator, like in the rtems-release workflow.
  • June 8: Community bonding third meeting
    • Going through final exams and thesis preparation, I couldn't allocate much time for the project. Wrote a starting blog post and added an initial calendar.
    • Next week: Still going through with exams and thesis defense; I am pretty confident I can delve directly into the coding and hopefully there won't be so many blockers. As stated in my proposal, the division between the community bonding and midterm deliverables isn't sharp, and with roughly all the community bonding deliverables done, I will try to squeeze as much work as I can in the interim but will concentrate more on the project when I am done with the semester.
  • June 15: Coding period first meeting
    • Previous week: More Markdown fixes, RNG improvements, and adaptations to WebKit? HTML to PDF conversion.
    • Next Week: Exploring the performance issue in more depth and finalizing the PDF conversion prototype.
    • Challenging: Was super busy with exams and thesis defense, so didn't allocate much time to the project.
  • June 22: Coding period second meeting
    • Previous week: In-depth analysis of the performance issues in RNG; finalized the Markdown to PDF conversion using WebKit? wkhtml2pdf (and pdfkit Python package). Produced an adequate PDF for the release notes.
    • Next Week: Addressing feedback on the format of the release notes generation and discussing further decisions about the second half of GSoC deliverables.
    • Challenging: RNG has to send two requests to the Trac API to fetch all the needed information, which is detrimental to the performance. I couldn't find any way to reduce them to one API call that has all the information related to a certain ticket. Hence, I suggest concentrating on the Markdown-to-PDF solution and figuring out a better approach to fetch ticket data than issuing calls to the Trac API for the second half of GSoC.
  • June 29
    • Previous week: Generated a full PDF trac-styled release notes and sent out for feedback
    • Next week: Address feedback on the generated PDF as well as other suggestions from Chris (generate a Markdown-styled PDF).
    • Challenging: Our generated Markdown crashes Pandoc, which probably means we have some issues in our Markdown generation.
  • July 6th
    • Previous week: Correct our Markdown generation and generate a Markdown-styled release notes PDF file.
    • Next week: Finalize the first half deliverables, and potentially start implementing ReST generation

Prashanth S

  • June 1: Community Bonding Period second meeting
    • Previous Week: I am going through AM335x starterware and reference manual for CAN hardware Initialization sequence.
    • Next Week: I am planning to try Tx and Rx in loop back mode.
    • Challenging: Designing or choosing the appropriate stack.
  • June 8: Community Bonding Period third meeting
    • Previous Week: Porting the minimal requirements(tx and rx) for CAN driver from Am335x starterware and wrote a blog post
    • Next week: Planning to complete the porting.
  • June 15: Coding Period
    • Previous Week: Ported the dcan driver from Am335x starterware and tested tx and rx in loopback mode.
    • Next Week: Test the CAN tx and rx by connecting to another CAN node running linux.
  • June 22:
    • Previous Week: Verified the CAN tx by connecting to a CAN node running Linux (Could see CAN tx messages in Linux using candump <node-name> util). I Need to see rx. Added a test application
    • Next Week: Add tx path in the CAN stack.
  • June 29:
    • Previous Week:
      • Adding tx path, Need to add few functions (can_txdone etc) and test.
      • Added a blog on how to send message between two Beaglebone Black through CAN bus.
    • Next Week:
      • Will try to continue adding functions and test tx path and add test application.
  • July 6:
    • Previous Week: Tested the tx path and added a test application with n threads.
    • Next Week: Do changes based on suggestions given by Pavel and send for review.
  • July 13:
    • Previous Week:
      • Added a bug fix in tx path.
      • Added minimal rx path.
    • Next Week:
      • Get suggestions on the rx path.
      • Review for tx path.

Kamlesh Bharodiya

  • June 1: Community Bonding Period (2nd Meeting)
    • Previous Week: Built BSP for Xilinx_zynq_a9, setup Qemu environment, tested the BSP tests on Qemu, read and did some exercises on embedded basics like linking, locating, compiler and makefiles. Started Blog.
      • challenges: Stuck at compiling Xilinx_zynq_a9 kernels on qemu-arm.
    • Next Week: With suggestions from the meeting, plan is to run R5 bare metal examples on Qemu. Explore Xilinx Wiki and aarch64 A53 and A72 BSPs for building the R5 BSP. Continue to work upon embedded basics. Blogging.
  • June 8: Community Bonding Period (3rd Meeting)
    • Previous Week: Able to run R5 Bare metal examples on Xilinx Fork of Qemu, Explored A53 and A72 BSPs - Built and Run the tests on Qemu
      • Challenges: Virtual Machine Issue
    • Next Week: Plan on how to go about the R5 BSP, Explore Vanila Qemu for Running Bare Metal Examples for Cortex R5
  • June 15: Coding Period
    • Previous week: VM issue resolved, Explored the BSP build system, compared A53 and A72 BSPs to build R5 BSP
      • Challenges: Facing issues in identifying Qemu fork which support R5. Lack of clarity on How ot go about it
    • Next Week: Working on the suggestions - building Qemu from source, Learning debugging guest and Qemu, "Hopefully" building a virt machine on Qemu, Updating the obstacles on Blog.