Notice: We have migrated to GitLab launching 2024-05-01 see here:

Version 70 (modified by Prashanth S, on 09/08/22 at 13:49:44) (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.


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


  • Feb 7: Joined application as Org Admin.


  • 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
  • July 20: Coding Period 6th Meeting
    • Last week: ADC API, STM32F4 implementation
    • Obstacle: silly bugs/mistakes
    • This week's plan: ADC API improvement, midterm blog
  • July 27: Coding Period 7th Meeting
    • Last week: GPIO, ADC API, midterm deliverables
    • This week's plan: Ethernet
  • August 3: Coding Period 8th Meeting
    • Last week: compile lwIP for STM32F4, revise patches
    • Obstacle: personal stuffs
    • This week's plan: port lwIP for STM32F4
  • August 10: Coding Period 9th Meeting
    • Last week: v6 patch set, compile networking01 and telnetd01
    • Obstacle: still personal stuffs, simple console patch broken
    • This week's plan: fix simple console, lwIP
  • August 17: Coding Period 10th Meeting
    • Last week: lwIP test applications, RTEMS patches
    • Obstacle: still personal stuffs
    • This week's plan: make telnetd01 actually working
  • August 24: Coding Period 11th Meeting
    • Last week: can now ping and telnet command is acknowledged
    • Obstacle: "connection closed by foreign host" error
    • This week's plan: to be able to get a shell from telnet

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.
  • June 29: Coding period third meeting
    • Previous week's work: I had issues on my laptop (power malfunctioning) due to which I couldn't do much. Wrote a tutorial on how to use GDB and tips and tricks for that. Addressing issues on starting and restarting the kernel.
    • blockers: Laptop Malfunction
    • Next week work: Continuing from previous left behind work
  • July 6: Coding period fourth meeting
    • Previous week's work: I'm done with addressing issues. Some of the registers were failing to show their states, so in order to cross check, I'm try to use QEMU for RPi 4b (not in the official branch). Through this I'll be testing out more.
    • blockers: Registers failing to show
    • Next week work: I was earlier editing the a72 qemu bsp minimally and making it work for the RPi. Now instead of that, I'll be rewriting everything with keeping RPi in mind. That would include addresses of RAM, serials, gic, variables and everything.
  • July 13: Coding period fifth meeting
    • Previous week's work: Copied most of the files from the A72 bsp and changed the accordingly to the raspberry pi bsp.
    • blockers: Not any here
    • Next week's work: Working on headers and IRQ
  • July 20: Coding period sixth meeting
    • Previous week's work: Serial isnt working even after changing the address, So I'm guessing this is happening because of A72 doesnt requires a MMU but actual hardwares requires one. Copied arm/raspberrypi/irq.h, compared with the datasheets, it should work. Some new #defines would be required in the raspberrypi.h, i was working on that, and then got sick
    • blockers: Sickness
    • Previous week's work: I'll be completing the raspberrypi.h and the hopefully the MMU too.

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.
  • July 13th:
    • Previous Week: Worked on Chris' feedback more, finalize designs and send to mailing lists(devel, received a mail that owner must approve) & mentors
    • Next Week: Start working on second-period deliverables as well as address feedback on first-half deliverables, if any.
  • Aug 3rd:
    • Previous week: Generate ToC and top-level notes. Generate a release notes file for 5.1 which revealed many problems that I am currently fixing, and generate a small 4.11 rst file (still not working properly).
    • Next week: Continue working on the 5.1 release notes file and more rst generation utils.
  • Aug 10th:
    • Previous week: I have been working on the v5 release file, which is gigantic and made visible many problems with the generator, so I worked on that. I can also say I finished reStructuredText generation but there are a few tweaks here and there that I am still working on.
    • Next week: finalizing reSt generation
  • Aug 17th:
    • Previous week: Fix performance issues of requesting and fetching ticket data from Trac, fix numerous problems induced by updating used packages (installing new system)
    • Continue working on reStructuredText generation.

Aug 24th:

  • Previous week: Successfully generate release notes file for different milestones in reStructuredText and Markdown.
  • Next week: Use in the release generation workflow

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.
  • July 20:
    • Previous Week:
      • Posted source for review.
    • Next Week:
      • I will make changes based on the review comments. And try to post DCAN also.
  • July 27:
    • Previous Week:
      • Added blog for midterm evaluation.
      • Updated the review comments. Need to send for review request.
      • Made few changes in tx path.
      • Rewrote the files which had different license
    • Next week:
      • Get the reviews and update the changes.
      • Get reviews for dcan.
      • Need to get few suggestions for rx path.
  • Aug 3:
    • Previous Week:
      • changed, using global interrupts to CAN interrupts for concurrency.
      • sent for review and got review comments.
    • Next Week:
      • address review comments.
      • try to submit a patch.
      • send dcan for review.
  • Aug 10:
    • Previous Week:
      • Addressed review comments.
      • Trying to use nuttx for dcan.
    • Next Week:
      • will try to send dcan for review.
      • try to get CAN files ready to merge.
  • Aug 17:
    • Previous Week:
      • Addressed CAN review comments and sent for review.
      • sent DCAN for review.
    • Next Week:
      • try to submit CAN support.
    • For testing stability:
      • May I ask to use CAN support for various platforms which might help to test the stability if possible.
  • Aug 24:
    • Previous Week:
      • Got review comments. Implementing loopback driver for the test application.
      • Posted DCAN for review.
    • Next Week:
      • Complete Loopback driver and send for review.
  • Aug 31:
    • Previous Week:
      • Implemented loopback driver.
      • Addressing review comments for CAN driver and test applications.
    • Next Week:
      • Post CAN driver and try to submit.
      • Get DCAN ready for submit.
  • Sep 7:
    • Previous week:
      • I addressed the review comments and sent CAN support for review.
    • Next week:
      • Try to configure N rx buffers in rx path.
      • Try to submit DCAN.

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.