Hello Gedare On Tuesday 27 of February 2024 22:27:43 Gedare Bloom wrote: > On Mon, Feb 12, 2024 at 8:03 AM Pavel Pisa <p...@fel.cvut.cz> wrote: > > Michal Lenc works on a new generic CAN/CAN FD subsystem for RTEMS under > > my supervision. The project has reached a phase where we will be very > > grateful for the review and pointing to required changes to start a > > discussion of possible inclusion into the RTEMS mainline. The project is > > currently being developed as a separate RTEMS application based on the > > OMK build > > > > https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd > > > > But long-term intention is to move > > > > > > https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/tree/master/lib/can > >drv > > > > directory into RTEMS cpukit/dev/can directory and corresponding include > > files into cpukit/include/dev/can directory. > > Thanks. I will review this design and code, but it will be a few weeks > before I can do that. The directory location is a suitable choice.
Thanks. I consider critical to discuse if queues access protection by rtems_interrupt_lock_acquire is appropriate etc. I.e., I see rtems_semaphore_obtain problematic because it would exhaust fixed configures resources easily. I am not sure, if there is rtems core / "kernel" equivalent to contained objects as are used for "userspace" pthread_mutex_lock etc... There are more such architectural questions where feedback from you, Joel, Sebastian and or Chis with deeper knowledge would help. This discussion should continue in public list or as issues setup for RTEMS CAN FD subsystem. > > We have reached a state where the virtual interface has been tested on an > > MZ_APO Xilinx/AMD Zynq-based board and an LX_CPU/LX_RoCoN NXP > > LPC4088-based board. The communication with a complete CAN interface has > > been successfully tested on the MZ_APO Xilinx/AMD Zynq board with CTU CAN > > FD IP cores implemented in FPGA. > > > > Building on other RTEMS BSP should be possible by changing a single > > definition in the config.target file > > > > RTEMS_MAKEFILE_PATH=/opt/rtems/6/arm-rtems6/xilinx_zynq_zedboard > > When ported to cpukit, this would become part of the spec/build opts. For sure, but we want to have easy way to build code against different targets when it is still standalone. > > Michal Lenc will submit work as his Master's Thesis this May > > so I hope that Gedare would be willing to take the thesis > > reviewer role as we have already discussed. > > Indeed I will. I think this work is exciting and needed. Thanks for confirmation. There is limited time window when we can steer his work direction. When he finishes then I hope that he will be helpfull and I want to keep an eye on the project and maintain it as I have done 20 years with LinCAN and helped SocketCAN etc., but the resources for deeper redesign will be limited until some another studnet is found or me or some company has funded project which would be willing to invest even into infrastructural work. You have asked bout XCAN in an another thread, so I reply there even to inform the public. XCAN is AMD/XilinX controller integrated onto Zynq chips. I remember that there has been invested into the driver at German Aerospace Center. Carlo Brokering has worked on it based on the Prashanth S work on Beagle Bone in the frame of GSoC. But the work on infrastructure and FIFOs was not finished from any side even that I have provided our LinCAN sources etc. and later the result has be removed as broken from mainline. https://lists.rtems.org/pipermail/devel/2023-March/074504.html We have XCAN on our Zynq board routed to CTU CAN FD, so it can be tested but porting to new infrastructure hardly fits to Michal Lenc's thesis plan. Another interesting platform and controllers would be xilinx-zynqmp and xilinx-versal. These have advantage that CAN FD controller emulation is included in QEMU mainline. For our project testing for developers without HW, we plan to add support for PCI mapped CTU CAN FD on some x86 RTEMS BSP, because we have that support included in QEMU mainline. I have tried to provide even platform bus (AMBA) mapping for Xilinx Zynq as an experimental patch for QEMU https://github.com/ppisa/qemu/commit/2bcfd7b8dfd7d657ada2f8ec2b972f6469b33c94 Mmaped IO works but interrupt mapping is not working and I am not sure how it should be done correctly for dynamically plugable sysbus device yet. Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: p...@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa social: https://social.kernel.org/ppisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ RISC-V education: https://comparch.edu.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel