RTEMS | Controller Area Network (CAN) Stack Improvements (#5440)

[MITHILESH MATTAPALLI (@mithileshm)]

MITHILESH MATTAPALLI commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5440#note_142829


I have been analyzing this issue scope for my **GSoC 2026** proposal.

Following up on the queue initialization race conditions I investigated in **!1059**, I wanted to share my findings on the current state of the stack and validate my proposed architecture.

**Observations from Code Study:**

1. **Testing Gap:** The current regression testing relies heavily on physical hardware, which limits our ability to catch race conditions in CI.
2. **Controller Support:** As @ppisa noted, QEMU has mainline support for **SJA1000** and **CTU CAN FD**, but these are primarily exposed as PCI devices. The RTEMS Tester currently lacks a standard BSP configuration to utilize these for automated testing.
3. **Core Fragility:** The `can_queue_create` path lacks robust error handling for kernel object creation failures, leaving the stack in an undefined state during initialization faults.

**Understanding & Proposed Plan:** My proposal will focus on **'Hardening & Virtualization'** to address both the "New Controller" and "Rigorous Test Suite" requirements:

* **Virtual Lab (The "Rigorous Test Suite"):** I will integrate the **CTU CAN FD** PCI support into the RTEMS Tester. This involves configuring a generic BSP (likely `pc386` or `pc686`) to enumerate the QEMU PCI bus and load the driver, enabling a purely software-based regression suite.
* **Core Hardening:** I will refactor the `can-queue` layer to enforce atomic state transitions, ensuring that resources are cleanly rolled back if initialization fails (addressing the root cause of !1059).

**Question for Mentors (@ppisa):** Regarding the QEMU integration, would you prefer the test suite target a generic PCI-capable BSP (like `pc386`) to leverage the existing QEMU PCI support, or should we aim to extend a specific embedded BSP (like `xilinx_zynq`) to support these virtual controllers?

My assumption is that the generic PCI approach is more stable for CI purposes. I am drafting the detailed proposal based on this architecture.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5440#note_142829
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260216/afce9216/attachment.htm>