Yes thanks for the updated link. I actually used the newer fork for testing, not the old one in my reply.
That is for the uefi firmware. Freebsd itself does not have drivers for the Pi5, so it is not useful I assume. I can go with native RTEMS for now and when the freebsd support comes and is stable, we can port it to libbsd if required.
That’s correct, libbsd would not be suitable at this time. Focusing on other ways to work with rpi5 would be great. If we want networking, then perhaps an RTEMS-lwip port would be appropriate goal to work toward.
Regarding SMP, I was looking over the boot logs you included with the RPi5 documentation and it appears that the board is running ATF/TF-A (ARM Trusted Firmware) which would likely allow use of PSCI to bring up additional cores. There is already support for this in RTEMS as it is used for ZynqMP and the generic QEMU targets. Even in the case that this is not possible, previous RPi BSPs have relied on simple spintables to bring up additional cores and there is enough existing code to make this a fairly quick task.
The device-tree source says that it uses PSCI with SMC. So, yes, this should be easy. Thanks!!
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a76";
reg = <0x100>;
enable-method = "psci";
d-cache-size = <0x10000>;
d-cache-line-size = <64>;
psci {
method = "smc";
compatible = "arm,psci-1.0", "arm,psci-0.2";
};
Ok, we have SMP working. Changes required were minimal but took some time to figure out. Rene over on the Circle project has been of great help.
*** BEGIN OF TEST SMP 1 ***
*** TEST VERSION: 7.0.0.7603e7303c0ca10d2f2a2ad4d32865dca8894753-modified
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API RTEMS_SMP
*** TEST TOOLS: 15.2.0 20250808 (RTEMS 7, RSB 94768365158083a6be02759c800827c0d7c60c79, Newlib 038afec1)
CPU 3 start task TA0
CPU 3 start task TA1
CPU 3 start task TA2
CPU 0 running Task TA2
CPU 1 running Task TA1
CPU 2 running Task TA0
*** END OF TEST SMP 1 ***
[ RTEMS shutdown ]
CPU: 3
RTEMS version: 7.0.0.7603e7303c0ca10d2f2a2ad4d32865dca8894753-modified
RTEMS tools: 15.2.0 20250808 (RTEMS 7, RSB 94768365158083a6be02759c800827c0d7c60c79, Newlib 038afec1)
executing thread ID: 0x0a010001
executing thread name: UI1
I also ran some of the other smptests which are available here. Will be cleaning this up and submitting an MR soon. 
Hello, I am having this build error when running
./waf configure
Unknown configuration option : RTEMS_SMP
You need to add aarch64/raspberrypi5 to spec/build/cpukit/optsmp.yml to tell the build system that the Pi5 BSP supports SMP.
The SMP code is not yet upstream. I suspect it will be merged today.
It’s merged, pull from main and try again.
Hi @gedare, just wanted to let you know I will be a little bit busy working on my thesis for a few days. I have not started writing my proposal yet, so I’ll have to figure that out too. Do we have any deadline for the proposal (before the gsoc application)?. I will submit as soon as I can and get it reviewed.
@opticron I’ll be glad if you can point me to some PCIe resources that I should look at. My major objective will be to enable PCIe support for the Pi5 in the GSOc coding period among other minor things. If you can let me know what all I should include in my proposal regarding this, that would be great too. I am thinking of looking at general documentation on how PCIe works, how to enable it in RTEMs and probably boot in Linux and figure out how PCIe is configured for the Pi5.
No internal deadline, but it’s to your benefit to get potential mentors to look at it before the official gsoc deadline. I try to look at every proposal when the application period opens, and again about a week before the deadline, to give some feedback.
I am thinking it would be best to have device tree support for the Pi5 to enable PCIe and future peripherals. I am guessing this is possible through FDT right? Some of the BSPs I see include a device-tree source file. Will I be able to use the bcm2712 dtsi directly or would it need some modifications?
We can also have the boot fw hand off the dtsi to RTEMS if it is included on the SD card, which is almost always the case unless one disables it by adding the os_check=0 option in config.txt. This might require overriding start.S to ensure proper handoff. So my question is, should we go this route? Or the previous one, which is to include it within the BSP?
Well, we can not know if the user will include the dtsi in the SD Card or no. So, we must include it in the BSP as fallback. A better question would be do we want to support boot fw dtb hand off or no? which might require overriding start.S.
Okay, I plan to work on 3 things: PCIe, SDCHI and HDMI Framebuffer. Full framebuffer support won’t be feasible right now due to its complexity. For now, a basic framebuffer using Mailbox is what I have scoped out. For SDHCI, I plan to use the generic FreeBSD SDHCI driver, which will require some glue code to work with libbsd and pi5. More information here on the proposal.
Where would you plan to get PCIe support code from? Or is it an implementation from scratch?
I plan to study the circles pcie implementation and the rpi linux implementation and port the core logic and intialization sequence required for the host-bridge driver. This driver will provide all the necessary interfaces so that libpci can take it up from there.
Those do not have a suitable license. 13. Licensing Requirements — RTEMS Software Engineering 7.1023b8c (8th January 2026) documentation
I won’t be porting the drivers 1:1… the bcm2712 does not have public documentation. I will have to look at the source code to understand the hardware, the exact initialization sequence, and related details. The driver will be written from scratch only, those will serve as documentation.
I will able to figure out more about PCIe later this week, little busy with university work. @opticron If you can share some insights on PCIe for the Pi5 it would be helpful.
Hello everyone, I have been going through the pcie implementation for the Linux kernel and circle’s project. PCIe implementation requires DMA and fdt implemented and I am working on both. @opticron @gedare Should the BSP map the entire Raspberry Pi 5 device tree, or would it be preferable to extract a minimal DT containing only the nodes required for PCIe (e.g., PCIe controller, PHY, resets, clocks, and related resources) ?
On the arm, powerpc, riscv, and microblaze we use bsp_fdt_copy to bring the FDT into memory. I’m not sure how it is on the aarch64, you probably have to dig into it a bit.