Pavel Pisa created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1578
Project:Branches: ppisa/rtems:i386-pc386-pci-can to rtems/rtos/rtems:main Author: Pavel Pisa ## Summary bsps/i386/pc386: add probe for Kvaser PCICan4,2,1 and CTU CA FD CAN CAN controllers This is draft for discussion. The PCI support in core RTEMS usable without LibBSD is minimal. I/O and memory mapped registers portable access primitives are missing and mechanism, how to properly specify that application requests to pull PCI CAN controller scans into linking from the library should be discussed. May it be something like `RTEMS_LINKER_ROSET_ITEM_REFERENCE` can be used in some macros like `CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER`. The unconditional `RTEMS_SYSINIT_ITEM` in pc386 `bspstart.c` is used to enforce probe for PCI device. The probe code uses loops which attempt to register can channels under next available "/dev/canX" node. The symbols used to pull object file with scan functions should be declared in some headers files, for example: - `bsps/include/dev/can/ctucanfd_pci.h` - `bsps/include/dev/can/sja1000_kvpcican.h` may it be together with some macros to request pull of the library archive member to the final linking. So the code is dirty at this form and does not meet criteria for merge. It intended as the base for discussion what is proper and preferred approach. But on the other hand, this experiment finishes loop started by Jin Yang's 2013 GSoC "Porting CAN driver, LinCAN, to RTEMS" which has been altered to provide CAN test environment available to everybody by extending QEMU (see [CAN Bus Emulation Support](https://www.qemu.org/docs/master/system/devices/can.html)). This work has grownup and is used by multiple RTOSes and for GNU/Linux development. We have added CTU CAN FD to original basic SJA1000 support, AMD/XilinX has added [Zynq UltraScale+ MPSoC and Versal CAN FD emulation](https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/863043713/Using+CAN+CAN+FD+with+AMD+QEMU), Matyáš Bobek's [theis](https://dspace.cvut.cz/bitstream/handle/10467/122654/F3-BP-2025-Bobek-Matyas-BP_Bobek_FlexCAN_final_4.pdf) added FlexCAN (non-FD for now) emulation. The [CAN/CAN FD subsystem](https://docs.rtems.org/docs/main/bsp-howto/can.html) based on original LinCAN ideas is part of RTEMS now. When these PCI mapping are included in mainline RTEMS, then the RTEMS CAN/CAN FD subsystem can be tested by every developer without requirement of specific physical hardware. ## Generative AI Only my head, hands and git clang-format has been used. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1578 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/6-b1ty6zdmx5889iz9n6mffot4g-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
