Google Summer of Code 2023

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

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
Vihas Makwana	Yes	bitXh#7676	multiple kernel-level medium projects	​Proposal	Yes
Mohd Noor Aman	Yes	katana-flinger	Ethernet and SMP support for Raspberry Pi 4B AArch64	​Ethernet and SMP support for Raspberry Pi 4B AArch64	Yes
Amna Mannan	Yes	amna_mannan	Sifive Hifive Unleashed RISC-V port for RTEMS	​SiFive HiFive Unleashed RISC-V port for RTEMS	Yes
Abhimanyu Raghuvanshi	Yes	ABR#9429	Build List Visualization	​Build List Visualization	Yes
Muhammad Sulthan Mazaya	Yes	Mazaya#5546	Add support for renode.io Simulator	​Add support for renode.io Simulator	Yes
Siddharth Khattar	Yes	Siddharth#0632	Improving support for amd64 BSP	​Improving support for amd64 BSP	Yes
Ruturaj Nanoti	Yes	Ruturaj#6398	Addition of BSP-specific post link details to pkg-config Files	​Capturing BSP specific Post Link Details in .pc files	Yes
Noriyuki Kurosu	Yes	Toson#8089	Add support for Address Sanitizer	​Add support for Adress Sanitizer	Yes
Hardik Sethi	Yes	Hardik444#0244	Code Formatting for RTEMS score and Third-Party File Organisation	​Code Formatting for RTEMS score and Third-Party File Organisation	Yes
Utkarsh Verma	Yes	Barusu	Improve the Raspberry Pi 4 BSP	​Improve the Raspberry Pi 4 BSP	Yes
Aryan Karawale	Yes	Aryan_Karawale#1731	Add a flattened device tree-based initialization for Beagle BSP	​Add a flattened device tree-based initialization for Beagle BSP	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
Muhammad Sulthan Mazaya	Mazaya#5546	​Project Wiki	​Project's Github repo (rtems-tools) and ​Project's Github repo (rsb)	​Blog	​Project Schedule
Mohd Noor Aman	katana-flinger	​Project Wiki	​Project's Github repo	​Blog	​Project Schedule
Amna Mannan	amna_mannan	​Project Wiki	​Project's Github repo	​Blog	​Project Schedule
Abhimanyu Raghuvanshi	ABR#9429	​Project Wiki	​Project's Github Repo	​Blog	​Project Schedule
Aryan Karawale	Aryan_Karawale#1731	​Project Wiki	​Project's Github Repo	​Blog	​Project Schedule
Utkarsh Verma	Barusu#4230	​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 23: Tracking status page created. Org Application Submitted.
• May 8: Intro email sent and Discord meetings scheduled.

Mohd Noor Aman

• May 31: Coding Period first meeting
  • Last week's work: Introduction to community, discussions about starting the project, Initial blog for GSoC 2023
  • Blocker: Understanding how drivers are imported from Freebsd in RTEMS-LIBBSD
  • Next week's plan: Try to import genet drivers from the freebsd tree
• June 7: Coding period second meeting
  • Last week's work: Disccusion over on how to import drivers from the newer Freebsd release into the old branch on ML and Discord
  • Blocker: RTEMS-LIBBSD requires an update from 12.x to 13.x in order to import the drivers
  • Next week's plan: Try to backport the drivers from the 13.x to 12.x branch

Amna Mannan

• May 31: Coding Period first meeting
  • Last week's work: tested out riscv64 BSP on the sifive QEMU machine. It didnt worked, there were some memory overlapping issue and more to count.
  • Blocker: Very less knowledge about the peripherals in Sifive BSP
  • Next week's plan: learn how to use GDB for figuring out errors
• June 7: Coding period second meeting
  • Last week's work: Tried to learn how to use GDB, tried to build a basic BSP
  • Blocker: The registers info dump is still nowhere understandable to me, will try to further dig into this
  • Next week's plan: I will try to create a new BSP for Sifive instead of a generic one, Will write a blog for gdb lessons

Abhimanyu Raghuvanshi

• May 31: Coding Period First Meeting
  • Last weeks' work: Brushed up Typescript and Python which will be used for the project.
  • Blocker: Build List Archives contain different types of results which are hard to parse.
  • Next week's plan: Getting Familiar with the Parsing Python Script and the Build List structures.

• June 7 : Coding Period Second Meeting
  • Last week's work : Forked the rtems-admin repo created by Chris. Added the changes made to the builds.py file locally to parse more details. Started looking for suitable Mockups for the front end.
  • Blocker : The complexity of lists
  • Next week's plan: Create a UI Prototype on Figma for the visualization frontend and get it approved before starting the development.

• June 14 : Coding period third meeting
  • Last week's work: Added the function to Calculate Pass/Fail? counts for each month. Converted the data into Summary Table and write that into JSON File. Converted the data into Summary Table and write that into JSON File
  • Blockers : Parsing OS out of the reports
  • Next week's plan: Creating the Monthly Build Page and Monthly Test Page. Getting the UI Prototype validated

Muhammad Sulthan Mazaya

• May 31: Coding Period first meeting
  • Last week's work: Worked on the first implementation of renode on rtems-test
  • Blocker: Can't kill renode after the test is done, therefore blocking the next test
  • Next week's plan: Trying to figure out a hack to kill renode via renode itself, not depending on the rtems timeout
• June 7: Coding period second meeting
  • Last week's work: Tried to use renode uart line hook to kill renode via monitor.Parse('q')
  • Blocker: Does not work with --disable-xwt turned on + turns out I can't use the tty console for the renode testing
  • Next week's plan: Look for another hack that is viable to be implemented
• June 14: Coding period third meeting
  • Last week's work: Filed an issue to renode, working on another hack to make renode work. Probably going to implement a socket server as a reader thread and send a socket message using uart line hook of renode
  • Blocker: Understanding the source code took a while
  • Next week's plan: Implement the socket server as reader thread
• June 21: Coding period fourth meeting
  • Last week's work: Tried implementing a socket server as a reader thread, will pivot and try another approach.
  • Blocker: Implementing a socket server as a reader thread is too hacky. This involves the need to terminate renode process after the socket message is complete, which is not trivia.
  • Next week's plan: Try implementing it using LoggingUartAnalyzer.
• June 28: Coding period fifth meeting
  • Last week's work: Added pipe operation implementation + submit the first patch of renode's implementation
  • Blocker: -
  • Next week's plan: Implementing rsb patch for rtems-tools update on pipe operation.
• July 5: Coding period sixth meeting
  • Last week's work: Worked on rsb recipe
  • Blocker: Understanding the way rsb work is quite hard, following the rtems tutorial on docs but it crashes
  • Next week's plan: Do an daily update email to Gedare and Chris so they can help me.
• July 12: Coding period seventh meeting
  • Last week's work: Renode rsb recipe patch submitted
  • Blocker: -
  • Next week's plan: Work on the revision of patch + make a midterm blog
• July 19: Coding period eigthth meeting
  • Last week's work: Revision patch of rsb submitted and start coding to enable testing Leon3 using renode via rtems-test. I have also written ​a blog for testing Kendryte K210 using rtems-test.
  • Blocker: Have a problem where leon3 .resc file from the official repository example need a prom image from gaisler, discussing how to handle that.
  • Next week's plan: Continue working on renode

Aryan Karawale

*May 31: Coding Period first meeting

• last week's work: Read about the working of FDT
• Blocker: Roadblocks in building and setting up the beaglebsp
• Next week's work: Complete the setup and start reading about the methods to refactor the GPIO driver

*June 7: Coding Period second meeting

• last week's work: Completed the setup and read about the GPIO driver
• Blocker: Tried to build the rtems-test but failed to do so
• Next week's work: Build a simple application, Start the work on GPIO driver

Utkarsh Verma

• June 7: Coding Period Week #2
  • Last week's work: Read about the existing GPIO driver in the arm/raspberrypi BSP and explored the RTEMS codebase.
  • Blocker: The codebase is a bit big and there is vagueness in the approach to take for the driver implementation.
  • Next week: Implementing the driver and looking into FDTs
• June 14: Coding Period Week #3
  • Last week's work:
    • Found a BSP lookup bug in rtems_waf and raised a ticket (#4917) proposing a fix.
    • Fixed the RTEMS docs build system for newer versions of Sphinx.
    • Tested and validated a basic hardware setup to build upon. Created a new ​repository to contain examples for showcasing peripheral usage as the BSP support improves.
    • Discussed possible approaches to implement the GPIO driver with mentors.
  • Blocker: Getting used to the RTEMS codebase and understanding the principles before implementing the driver.
  • Next week: Start with the GPIO driver implementation around the GPIO2 interface.
• June 21: Coding Period Week #4
  • Last week's work:
    • Discussed with mentors how to proceed with the firmware development. Seems that UARTs will be an easier target.
    • Looked into PL011 initialization routines through datasheets, other drivers and bare metal projects.
  • Blocker: N/A
  • Next week: Flesh out drivers for UARTs in bare metal.
• June 28: Coding Period Week #5
  • Last week's work:
    • Implemented GPIO support in bare metal.
    • Implemented support for all five UARTs in bare metal.
    • Read the RPi 4B BSP source code and explored how it utilizes RTEMS' APIs.
  • Blocker: UART drivers depend on GPIO functionality, which is not present in the BSP. For implementing GPIO, the API has to be chosen.
  • Next week: Discuss the GPIO API with the community and implement support for all five UARTs.
• July 5: Coding Period Week #6
  • Last week's work:
    • Wrote a new poll-based driver for ARM PL011 for the RPi.
    • Wrote a new poll-based driver for RPi's MiniUART peripheral.
    • Implemented support for all six UART ports on the RPi with configurable baudrates.
  • Next week: Start documenting work for mid-review and continue community discussion on the GPIO API.
• July 12: Coding Period Week #7
  • Last week's work:
    • Wrote blog posts for ongoing work.
    • Researched ways to automate the kernel flashing process for the RPi, to allow faster iterations.
  • Next week: Document the BSP progress in blog posts and start work on the Mailbox peripheral.
• July 19: Coding Period Week #8
  • Last week's work:
    • Researched the mailbox API and plan to implement the new property channel interface.
    • Could not make much progress as I had to travel for a few days.
  • Blocker: The mailbox API is not well-documented, so I have to read up on other open-source implementations.
  • Next week: Add support for the mailbox API
• July 26: Coding Period Week #9
  • Last week's work:
    • Got the mailbox API to work in my bare-metal playground project.
  • Next week: Port the mailbox API to RTEMS with framebuffer support.