Pavel Pisa commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5440#note_143373 I hope that Michal Lenc's SJA100 code in his experimental is near finalization and we find time for its finishing soon. There are more obstacles cause by OpenCores and our derived sja1000fdtol HDL design problems and these have to be figured out together with deep HDL design and platform knowledge. So I would suggest not to spend time on this by others at this moment. On the other hand, if you have some other SJA1000 compatible HW then it would worth to start prepare for testing on such target. As for the coordination, it seems that @River plans to work on D-CAN on BeagleBoneBlack (which is good target with broad community), see the Discourse [thread](https://users.rtems.org/t/controller-area-network-can-stack-improvement-beaglebone-black-d-can-driver-implementation-gsoc-2026/477). If that project is selected than it would be better (for the CAN related GSoC) to choose other controller or work on testing framework. The basic initial testing code should provide some basic examples and tests which can be integrated into [testsuites/samples](https://gitlab.rtems.org/rtems/rtos/rtems/-/tree/main/testsuites/samples) and peer test directory. The base should target `rtems_can_virtual_initialize` to be usable for all targets then there should be optional test for platforms with PCIe support where CTU CAN FD and (hopefully soon) SJA1000 can be tested with QEMU. When two channels are initialized during QEMU invocation with connection to the single CAN bus then data exchange between these two interfaces can be tested from RTEMS test image without need of any support on the QEMU host side system. Problem is, that CAN bus on the host side of QEMU is supported only by SocketCAN access support which is specific for QEMU running on Linux and setup of virtual CAN bus on Linux side requires administrator privileges. So it is not portable to other host systems and would be problematic in CI setups. But tests with two controllers emulated by QEMU and connected through QEMU CAN bus would be fully portable and useful solution. On the other hand, when the host system is narrowed to Linux with SocketCAN then there are options to connect two and more different emulated systems (i.e. GNU/Linux, NuttX, RTEMS, ..) though host side CAN bus, you can find some inspiration in the the post by Mateusz Szafoni which is mainly focused on his NuttX work, [Host-Based Development with Apache NuttX – CAN Network Simulation](https://railab.me/posts/2025/5/host-based-dev-with-nuttx-can-network/). -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5440#note_143373 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
