[GSOC26] Fully Porting NuttX to the Raspberry Pi 4B

[linguini1]

Fully Porting NuttX to the Raspberry Pi 4B

Matteo Golin, matteo.golin@gmail.com, linguini@apache.org

A GSoC 2026 Proposal to Apache NuttX

March 7th, 2026

This document serves as Matteo Golin's proposal to Apache NuttX for the 2026 Google Summer of Code. The Raspberry Pi 4B is a powerful SoC-based board running on the ARM64 architecture. Its wide variety of on-board peripherals and position as a popular hobbyist device makes it an ideal board for the NuttX RTOS to both attract new users and showcase its capabilities and scalability. This project will build on top of the initial port of NuttX to the Raspberry Pi 4B to add support for more peripherals, stabilize existing support and begin an initiative of comprehensive demo configurations that showcase NuttX's abilities on a flagship hobbyist device.

Motivation

The Raspberry Pi 4B (and really, all of the Raspberry Pi line-up) is quite a popular device amongst hobbyists. It is versatile in the sense that it may be used as a full "personal computer" running Linux, and also has the ability to interface with typical MCU peripherals/breakouts via SPI, I2C and UART interfaces. This versatility is a large contributor to its popularity among a wide range of hobbyists for robotics, cloud projects, and more. In fact, the Raspberry Pi 4B (and recently the Pi 5) has been a device of focus for Blackberry QNX as part of the QNX Everywhere initiative [1]. The Pi acts as an accessible device to attract developers capable of working with the QNX RTOS.

Ideally, the Raspberry Pi 4B will play a similar role for NuttX: a ubiquitous hobbyist device which has a number of interesting peripherals to showcase NuttX's capability as an RTOS. In addition, it is an example of one of the "extremes" that NuttX is capable of operating in: a large memory, multi-core, powerful 64-bit SoC (in contrast to the wide array of supported microcontrollers). This makes it an ideal candidate device for attracting new contributors and reaching more users. It can also serve as a good testing target for regression testing due to its ability to test multiple peripheral drivers and OS functionality in a single, fully-featured image.

Contributor Qualifications

Matteo Golin is currently a student at Waterloo University in Canada, where he is enrolled in an MASc of electrical & computer engineering with a focus in aeronautics. He holds a B.Eng in computer systems from Carleton University. Matteo has a passionate interest in embedded systems, encompassing both firmware, software and hardware design.

Matteo is a long-time contributor to the Apache NuttX RTOS, of which he is now a member of the PMC, with 91 patches (and counting) to the kernel [2]. Many of Matteo's contributions to NuttX stem from his rocketry projects, where he has designed and manufactured multiple open-source flight computers (including Pygmy [3], [4], [5]) based on the NuttX RTOS. These contributions have included bug fixes, documentation patches, sensor drivers and a few initial ports to different boards (the Xiao Seeduino [6], the Elegoo Mega2560r3 [7], etc.).

Matteo is responsible for all of the existing NuttX support for the BCM2711/Raspberry Pi 4B, which he has worked on prior to becoming a committer/PMC on the project [8], [9]. As such, he is uniquely positioned to continue this port as he already has an intimate working knowledge of the existing work.

Proposed Timeline & Work

An existing tracker of work to be completed for the Raspberry Pi 4B port can be found under the nuttx repository's "RPi4B" milestone. [10] Most of these issues are tracked by Matteo already. There are anticipated challenges for this proposal as described in the challenges section to be aware of.

The anticipated project size is 350 hours (large).

The timeline is:

• Stabilizing Existing Support: May 1 - May 14
• SMP Support: May 15 - May 21
• Full UART Support: May 22 - June 7
• Networking Support: June 14 - July 24
• Audio Output: July 25 - Aug 7
• User Demos: Aug 8 - Aug 24

Stabilizing Existing Support

This task will tackle stability challenges of existing support and some of the low-hanging fruit remaining for the port:

• Patch existing I2C driver to properly support I2C_M_NOSTOP, I2C_M_NOSTART flags which are needed to allow the full set of NuttX-supported I2C devices to interface with the Raspberry Pi

• Patch existing EMMC2 interface driver to support $>1023$ byte write operations, which will fix the failing sdstress program and stabilize SD card storage support

• Configurable frame buffer video resolution

SMP Support

This task is a working SMP implementation on the Pi 4B so that users can leverage the full compute power of all four ARM cores in their applications.

This task will be completed when the smp test passes and indicates that all four cores are in use.

Full UART Support

This task delivers (in the form of drivers) support for all PL011 UART interfaces on the Raspberry Pi 4B will be added. This will allow users to connect a wider array of peripherals.

This task is complete when each PL011 UART interface can TX/RX properly.

Networking Support

This portion of the timeline will be exclusively dedicated to implementing networking support on the Raspberry Pi 4B. It is anticipated that this will be the largest challenge due to vague documentation (see Anticipated Challenges) and the complexity of networking interfaces.

The network support will be added for either WiFi or Ethernet, but likely not both. Which one is implemented will depend on which has more available resources (in terms of documentation), and the first few days of this time chunk will be dedicated to making that determination.

The goal of this portion of the project is to have the full NuttX networking stack function on the Pi. This will be verified with the existing NuttX networking applications:

• ping tests pass
• A RPi4B hosted web server can be accessed from another network device
• TCP/UDP client/server tests pass
• Telnet tests pass

Audio Output

This portion of the port will be dedicated to achieving functional audio support on the Raspberry Pi 4B's audio jack. The PCM/I2S audio interface is actually documented in the BCM2711 data sheet [13].

This task is completed when:

• NuttX audio player applications function correctly on the RPi4B

User Demos

This portion of the project is dedicated to creating a number of user demo configurations. These demos are intended to attract new contributors and users to NuttX by putting the capability of the RTOS on display and leveraging the peripherals of the Raspberry Pi 4B. All demo configurations will come with documentation so new users can easily set them up and try it for themselves.

Proposed demos (each one is a deliverable):

• Telnet demonstration of networking support

• DOOM port using doomgeneric [11] with HDMI video display and audio output

• LVGL dashboard app that monitors pressure and temperature from a barometer (BMP280 will be used for testing, but will support any generic uORB barometer) to demonstrate video output capabilities meshed with embedded applications

Matteo has already carried out a port of Doom to the Pi 4B running QNX using doomgeneric [11] as a starting point, so he is familiar with the basic requirements/porting process. This application should attract a number of new users, as DOOM is a popular benchmark for embedded systems and is a "fun" application to play with.

Figure 1: An example of how running DOOM on the RPi4B would look [12]

If the Dropbear/SSH client port to NuttX goes well (another GSoC project), that will be included as a demo configuration as well to showcase how the system can be interacted with remotely for completing tasks (i.e. checking logs).

Anticipated Challenges

The BCM2711 SoC, used by the Raspberry Pi 4B, is quite poorly documented. The board itself and some peripherals (such as the Ethernet chip and USB hub) are also similarly obfuscated. Not all interfaces are described in sufficient detail in the datasheet to complete a fully-featured driver implementation for all interfaces [13]. Some interfaces, like the EMMC interface, needed consultation with the BCM2835 datasheet to get a working implementation [9]. It is anticipated that much of the proposed functionality will require consultation with existing hobby projects, "ancestral" chipsets (like the BCM2835), the Linux kernel and online forums in order to figure out implementation details (what registers exist, which interfaces peripherals are accessible from, etc). The tasks laid out in this proposal are possible, as open-source projects which support these peripherals do exist, but will be challenging to reverse-engineer.

As a result of these difficulties, there is a chance that some difficult features will only receive partial implementation as part of this project. If these challenges inhibit the tasks in this proposal, Matteo's intention is accumulate as much useful information/resources as possible on the interfaces and document them under the respective issue trackers. He will also provide as much of the implementation as possible to be extended in the future. The hope is that this will significantly reduce the burden for future contributor(s) and allow the work to be completed (likely also by Matteo) after the official GSoC project period ends.

Potential Benefits

By the end of this port, NuttX will have a fully-featured Raspberry Pi 4B port complete with demo configurations (not least of which will be DOOM) to demonstrate its scalability to large, powerful systems and to attract new hobbyists to the RTOS. However, the potential benefits extend beyond just that:

• The RPi4B will be a graphics capable embedded device, which can be used for displaying GUIs, dashboards and taking user input in a public-facing embedded system while still leveraging NuttX's RTOS features. The Pi's powerful SoC would allow it to handle heavier workloads in embedded contexts such as networked kiosk/terminal-like devices.

• Since the Raspberry Pi 4B encompasses a large subset of NuttX's feature set (Ethernet/WiFi networking, Bluetooth, video, audio, USB, I2C, SPI, UART, EMMC, SMP, etc.) and also has a large memory capacity (up to 8GB), it is a perfect target for testing NuttX with single builds in systems like NXDART. Jumbo configurations could be made for this device which encompass all of these features and test them comprehensively in a single image, reducing test infrastructure workload. NuttX would have a commercially available and widely owned flagship board for testing requirements.

• The Rasbperry Pi 4B opens the door for robust industrial applications that aren't achievable for the NuttX supported MCU lineup, such as drone controllers, rocket ground systems with video output, industrial control applications, multimedia systems, etc. A completely novel field for NuttX would be machine-learning based applications that require a combination of RTOS features and a large RAM bank for on-device models. NuttX could become a viable choice for SLAM robotics, machine vision projects, cube satellites, etc. with this ability.

All in all, having a complete port of NuttX on the Raspberry Pi 4B as proposed in this project would push the boundaries of the systems which NuttX typically operates on. It would unlock a new frontier of applications and potential user-base via a capable SoC and an already popular board. This project is the perfect way to demonstrate what NuttX is capable of, how well it scales from small to large systems, and push NuttX into new markets.

Bonus

There are many peripherals on the Raspberry Pi 4B. It would be great to have them all working, but due to the aforementioned challenges, it is not realistic to achieve support for every peripheral in the GSoC timeline. This section serves as possible bonus tasks to be completed if the project is ahead of schedule, or if it becomes necessary to pivot from an officially planned task due to challenges.

• Bluetooth support (NimBLE works as expected on the Pi)
• Full USB support allowing HID devices (keyboard, mouse) to be used as input
• WiFi support/Ethernet support (opposite of whichever is decided on for Networking Support)
• DMA implementation

References

[1] “Quick start target image (qsti),” Accessed: Mar. 5, 2026. [Online].
Available:
https://www.qnx.com/developers/docs/qnxeverywhere/com.qnx.doc.target_images/topic/qsti/intro.html

[2] Accessed: Mar. 5, 2026. [Online]. Available:
https://github.com/apache/nuttx/pulls?q=is%3Apr+is%3Amerged+author%3Alinguini1+

[3] M. Golin, Pygmy, Nov. 11, 2024. Accessed: Mar. 5, 2026. [Online]. Available:
https://github.com/linguini1/pygmy

[4] M. Golin, Pygmy-nx, Jan. 2, 2025. Accessed: Mar. 5, 2026. [Online].
Available: https://github.com/linguini1/pygmy-nx

[5] M. Golin, Pygmy-telem, Feb. 13, 2025. Accessed: Mar. 5, 2026. [Online].
Available: https://github.com/linguini1/pygmy-telem

[6] M. Golin, Support for the Seeed Studio XIAO SAMD21, Nov. 6, 2024. Accessed:
Mar. 5, 2026. [Online]. Available: #14678

[7] M. Golin, boards/avr/atmega: Added Elegoo Mega2560r3 board support, May 25,
2025. Accessed: Mar. 5, 2026. [Online]. Available:
#16443

[8] M. Golin, Add support for the BCM2711, Dec. 17, 2024. Accessed: Mar. 5, 2026.
[Online]. Available: #15188

[9] M. Golin, bcm2711/sdio: Support for EMMC interfaces on the BCM2711, Oct. 28,
2025. Accessed: Mar. 5, 2026. [Online]. Available: #17245

[10] RPi4B Milestone. Accessed: Mar. 5, 2026. [Online]. Available:
https://github.com/apache/nuttx/milestone/7

[11] ozkl. Accessed: Mar. 5, 2026. [Online]. Available: https://github.com/ozkl/doomgeneric

[12] J. Gloor, “How to Run DOOM on Your Raspberry Pi,” Oct. 22, 2025. Accessed:
Mar. 7, 2026. [Online]. Available:
https://www.howtogeek.com/how-to-run-doom-on-your-raspberry-pi/

[13] “Raspberry Pi BCM2711 ARM Peripherals,” Feb. 5, 2020. Accessed: Mar. 5, 2026.
[Online]. Available: https://pip-assets.raspberrypi.com/categories/545-raspberry-pi-4-model-b/documents/RP-008248-DS-1-bcm2711-peripherals.pdf?disposition=inline

[raiden00pl]

I think you're being overly optimistic about the scope of work in such a short time. :) For example, supporting peripherals like USB is quite complex task and might not be possible without additional hardware like a USB analyzer. Doing it for a chip with incomplete documentation is a whole other level of difficulty. My advice: double the planned time for each of the complex peripherals and reduce the scope of work.

[linguini1]

I think you're right; the simpler tasks will be the first milestone, the LVGL demo and possibly the last milestone, but I have no idea how difficult it will be to find information about a few of these interfaces.

I suppose networking support is the most important over USB. I'll revise this and update it, thanks!

[raiden00pl]

In my experience, writing USB drivers is the most annoying type of work for osdev. The USB protocol is complex, prone to timing problems and it's not easy to debug without expensive hardware. ETH drivers, while also complex, are much easier to develop, and you can debug ETH packets without additional hardware. In addition, networking seems to be more useful for users as you said, so I would give priority to ETH over USB.

[linguini1]

Thanks for the tips @raiden00pl !

[cederom]

Very cool thank you @linguini1 fingers crossed :-)

[linguini1]

Okay @cederom and @raiden00pl, I have updated the proposal based on the suggestions.

Changes:

• No more USB support planned
• No more kernel mode planned
• More time allotted for networking support (1.5 months)
• More time allotted for UART support (2 weeks)

I think it should be possible to complete the audio output based on the fact that it's actually documented (unusual for a BCM2711 peripheral haha).

Let me know what you think.

[cederom]

But without USB we won't be able to play Doom multiplayer :D

I would add this as Side Quest for extra Mana, XP, and Glamour potion :-)

I agree these tasks are super hard and complex and many monsters will jump out every corner.. on the other hand it may be a good "optional bonus challenge" marked "will try and see how it ends but it may fail in this short time window". Up to you @linguini1 :-)

[FelipeMouraOliveira]

Very nice "Documentation" @linguini1 , I will use some of the way you organized it to improve my proposal.

[linguini1]

But without USB we won't be able to play Doom multiplayer :D

I know :( but maybe there is some hack I can add to take input over serial or GPIO connected buttons instead.

I would add this as Side Quest for extra Mana, XP, and Glamour potion :-)

I agree these tasks are super hard and complex and many monsters will jump out every corner.. on the other hand it may be a good "optional bonus challenge" marked "will try and see how it ends but it may fail in this short time window". Up to you @linguini1 :-)

That's fine by me, I was actually considering doing a similar thing for Bluetooth or WiFi. Because some of these peripherals are such a toss up in terms of documentation, the idea was to have "back ups" in case one of them falls through for an unexpected reason. I can definitely add this "side quest" section.

[cederom]

For sure it will be a fun and very useful project @linguini1 and I have the boards already! :-)

USB is not that hard when you understand it, except host may be mess, but Linux has source code for that so we have a reference point, my friend did LibUSB compliant USB stack on FreeBSD so we have a reference point here too. I have this low cost Beagle USB 480 Protocol Analyzer just in case [1]. Some time ago while working at corpo I had some Ellisys [2] tools but these are currently above my paygrid and very closed source ;-)

Bluetooth may be easy if it implements HCI then you send commands over that channel, otherwise extremely hard if possible at all. Here we may encounter some binary blobs, but it can be "just" a "hci black box" when all goes smooth. For the Bluetooth HID we may use ProtoArc XK01 TP [2] or something like that? Except as @raiden00pl noted things rarely go smooth so it is good to have some backup time :D

I have no experience with low level WiFi implementation. It may use RMII or something like that would be best. And some binary blobs here too.

All formal projects require timeline, milestones, and deliverables, so we should have them doable and measurable. I also put some side quests as optional bonus tasks, no one ever complained :-P

[1] https://www.totalphase.com/products/beagle-usb480/
[2] https://www.ellysis.com/products/
[3] https://www.protoarc.com/products/xk01-tp-foldable-keyboard-with-touchpad

[linguini1]

I think we should keep the currently proposed timeline and add these extras as a "bonus" section without a timeline. I hadn't thought of Bluetooth HCI, that could be a good workaround! I do believe the WiFi chip needs a firmware blob based on what I've seen so far, yes. Also, do note that whatever isn't completed by me in the GSoC time frame is still going to be worked on beyond August :) I am very set on getting the RPi4B fully supported, and one of my Community over Code proposals is a discussion of this port anyways!