Hi everyone,
I am drafting my GSoC 2026 proposal for the Controller Area Network (CAN) Stack Improvements project (Issue #5440).
One of the key challenges identified in the new CAN stack adoption is the dependency on physical hardware (e.g., BeagleBone, specialized PCI cards) for testing. This currently prevents automated regression testing in the RTEMS CI/CD pipelines.
Progress on Virtualization & CI Strategy: To address this, I have successfully established a virtualization workflow using QEMU 10.2.1 and the CTU CAN FD PCI emulation. I have verified that the ctucan_pci device can be correctly instantiated, enumerated on the PCI bus, and attached to a virtual CAN bus on the pc386 BSP.
Proof of Concept (QEMU Monitor Output):
Proposal Focus: My proposal will center on two main pillars:
- CI Infrastructure: Integrating this QEMU workflow into
rtems-test to enable “hardware-free” regression testing for the CAN stack.
- Concurrency Hardening: Addressing race conditions in the stack initialization and frame processing paths (building on my previous fix in MR !1059).
I would appreciate any feedback from the mentors (@pisa, @lenc, @gedare) on this virtualization approach. Does establishing this “Virtual Lab” align with the project’s immediate priorities?
1 Like
Hello, nice work with establishing CT CAN FD virtualization! The automated tests are indeed needed, because now CAN stack is not tested at all (apart from few the tests I perform manually when I review the patches).
As a next step, you can try to run an actual CAN application in QEMU on RTEMS. Some of those are available in this repo Files · master · Open Technologies Research Education and Exchange Services / rtems / rtems-canfd · GitLab at path * rtems_can_test.
They are with complete build system, you can either try to use it (refer to readme file, there are description and scripts for i386 QEMU build, or you can copy the files to your preferable environment, it’s up to you. You are mostly interested in can_ctucanfd_pci.c file that initializes CTU CAN FD on RTEMS over PCI and then can_test.c file - this implements one way and two way communication tests. File can_register.c takes care of the initialization based on the argument.
The test applications can be run with following commands:
# this registers two CTU CAN FD controllers under dev/can0 and dev/can1
SHLL [/] # can_register -t ctucanfd_pci
# assign dev/can0 and dev/can1 to test applications
SHLL [/] # can_set_test_dev /dev/can0 /dev/can1
# run test applications
SHLL [/] # can_1w
SHLL [/] # can_2w
My general idea is to integrate those applications to RTEMS and change them in a way they provide coverage for most of the stack functionalities. These tests could then run in QEMU in rtems-tests as you pointed out.
Feel free to let me know if you have some questions or need help.
Michal
I have successfully built and executed the rtems_can_test application using QEMU (pc386) with the virtual CTU CAN FD PCI devices.
To get this running smoothly on macOS, I implemented a few workarounds:
- Linker Resolution: The PCI registration was being stripped out during compilation, so I explicitly added
#define BSP_WITH_PCI 1 in can_ctucanfd_pci.c.
- Automated Testing: Due to a QEMU serial input bug on macOS dropping keystrokes, I bypassed the shell and automated the requested test sequence (
can_ctucanfd_pci_register(), can_set_test_dev, and can_test_1w) directly inside init.c.
Here is the terminal output proving the driver initialization and frame transmission:
--- Automating CAN Tests ---
CTU CAN FD over PCI registered at dev/can0 and dev/can1
Setting CAN paths for tests to /dev/can0 and /dev/can1
can_test_1w: params: count 2000 delay 1, burst 100
--- CAN Tests Completed! ---
1: write done
can_monitor: sqn 0: /dev/can0 received = 0, sent = 100
can_monitor: sqn 1: /dev/can1 received = 0, sent = 0
can_monitor: sqn 0: /dev/can0 received = 0, sent = 400
can_monitor: sqn 0: /dev/can0 received = 0, sent = 700
can_monitor: sqn 0: /dev/can0 received = 0, sent = 1000
can_monitor: sqn 0: /dev/can0 received = 0, sent = 1300
can_monitor: sqn 0: /dev/can0 received = 0, sent = 1600
can_monitor: sqn 0: /dev/can0 received = 0, sent = 1900
0: write done
can_monitor: sqn 0: dev = /dev/can0 received = 0, sent = 2000, took 79650266 ns
0: fd closed from monitor
(Note: /dev/can0 successfully sent 2,000 frames. /dev/can1 received 0 because my QEMU launch command assigned them to isolated virtual buses (id=bus0 and id=bus1). I will map them to the same bus for loopback testing next.)
Now that my QEMU testbed is fully operational, my immediate goal is to submit meaningful patches to the CAN stack. I want to ensure my proposal aligns perfectly with the subsystem’s roadmap.
I am reviewing the RTEMS tracker for open CAN issues, could you share what you consider the most critical missing features or bottlenecks right now? Whether it is expanding POSIX compliance, refining the virtual CAN routing, or hardening error handling, I am ready to start prototyping a solution.
I am reviewing the RTEMS tracker for open CAN issues, could you share what you consider the most critical missing features or bottlenecks right now? Whether it is expanding POSIX compliance, refining the virtual CAN routing, or hardening error handling, I am ready to start prototyping a solution.
I don’t think there are any immediate issues or missing features for CAN stack. There is one issue that needs to be addressed sooner or later CAN/CAN FD stack needs confdefs resource calculation support added (#5193) · Issues · RTEMS / RTOS / RTEMS · GitLab, but it needs a proper consideration with some stack analysis tools. Long term missing feature would be CAN XL protocol support, but that’s not the priority at the moment.
The missing part are the tests and some simple examples showing how to work with the CAN stack - I think that’s the place we should begin with. Provide proper testing as part of GSoC and then decide what needs to be changed/fixed based on those tests.
Also if you run into some troubles with CTU CAN FD communication/virtualization, you can try can_virtual.c - it’s a simple virtual controller that can be run on any RTEMS supported hardware or in QEMU for any RTEMS target - it doesn’t use some stack features that CTU CAN FD uses though, for example message abort, error filtering etc. These could be potentially simulated in the virtual controller however.
1 Like
Using can_virtual.c as you suggested, I created a minimal hello_can application and opened a Merge Request in rtems-examples here: (MR!22). It demonstrates initializing the virtual controllers, registering the buses, and executing basic POSIX I/O in QEMU. (I also patched a missing <stdlib.h> in x86_display_cpu while I was in the repo).
Hope this hello_can example aligns with what you had in your mind!
1 Like
