Final update

As August draws to a close, so does my adventure with GSoC. The aarch64/raspberrypi4b BSP has come a long way and is now primed to make its way into the upstream sources. Let’s kick back and take a look at the cool new features and the awesome progress we’ve made up to this point.

Project description #

At the time of writing, the existing support for Raspberry Pi SBCs in RTEMS is operational, but it lacks essential functionalities such as graphics support, USB, SD card, UART, I2C and SPI functionality, which are necessary for basic user requirements. To address this gap, this project aims to incorporate these controllers into the Raspberry Pi 4 (Model B) board-specific package within RTEMS.

Repositories #

All the work related to this project lies in the following repostories:

• rtems kernel: contains driver and BSP changes
• rtems-on-rpi4b : contains example RTEMS applications using the BSP

Current status #

Throughout GSoC, my main aim was to improve the usability of the BSP which involved the following:

• Adding support for basic GPIO operations
• Writing drivers to allows using any of the six UARTs
• Refactoring the BSP to make it more configurable by the user
• Making IO interrupt-driven for more efficent operation
• Writing driver for the mailbox to allow the CPU to talk to the GPU
• Adding I2C support

All these changes reside on my fork in separate branches. Since the diffs are huge, I am submitting patches in an incremental fashion. Currently, the patch for GPIO and UART is under review.

What’s left? #

Although my initial proposal mentioned support for SPI, framebuffer, and SD card functionalities, things didn’t exactly sail as smoothly as planned. The mailbox peripheral turned out to be a huge time sink as it was not well-documented. However, its utility warranted the investment, so I kept pushing further.

Apart from that, I could have totally rushed and crammed in all those flashy drivers I pitched. However, instead of going feature-crazy, I decided to go for the gold – drivers that could hold their own in the wild world of embedded use. So, for people who might want to pick up where I left off, here’s a brief rundown of potential features for the BSP:

• Proposing a new GPIO API for RTEMS, and implementing it in the BSP
• SPI support
• DMA support for I/O
• Framebuffer support
• SD card driver with R/W access

Challenges faced and takeaways #

This project was a deep dive into the world of embedded systems, even for someone like me with prior experience. The experience was a masterclass in OS driver development and got me familiar with working on large codebases. I dived into memory manipulation, linker intricacies, and the whole suite of embedded tools.

Among the challenges, the mailbox peripheral took the cake. It demanded meticulous memory placement. Sometimes, even the compiler’s optimizations were too obtrusive and I had to look at the dissassembly to figure out the bug. Debugging these intricacies became my most valuable lesson.

Moreover, enabling interrupt support for the I/O posed its own puzzle due to the complex flow of control. RTEMS has a lot of moving parts and adapting to its flow and architecture was time-consuming, yet rewarding. Crafting drivers that meshed well demanded multiple iterations, each refining my prowess in structured C coding.

Conclusion #

Summing it up, my GSoC experience has left me genuinely content. I got to dive into a project I was passionate about, surrounded by experienced mentors who were there to help me. It was like a passion project, if we disregard the moments where fixing one bug mysteriously stretched into hours.

This marked my first foray into OS driver development, and truth be told, I’ve taken a liking to it. There’s a good chance I’ll keep chipping away at the remaining drivers in my leisure time, steering at my own pace. GSoC did get a tad crazy at times, after all.

Well, that’s the lowdown for this update. Thanks a bunch for checking it out!