Hello Andrew and others, we have ongoing discussion about use of Czech Technical University CTU CAN FD IP core for FPGA use together with NuttX and other RTOSes. The project VHDL sources and documentation is available there
https://canbus.pages.fel.cvut.cz/ Linux kernel driver documentation there https://docs.kernel.org/networking/device_drivers/can/ctu/ctucanfd-driver.html Driver code is under our control and it is agreed to use Linux independent part for NuttX and RTEMS.org in the next steps. We have agreemet of all contributors to extend license to Apache and RTEMS specific one. In longer term, we aim for full integration into mainlines and I suggest not to use adaption layers for different kernels even that it means some code duplication and additional effort... Driver is not so complex and I have experience with portability of single driver source between bare metal, Linux, Windows and NuttX, but redability is problematic and inclusion into mainline impossible... Replies to ongoing discussion in the text On Thursday 14 of September 2023 12:53:04 Andrew Dennison wrote: > On Thu, Sep 14, 2023, 12:27 AM Pavel Pisa <p...@fel.cvut.cz> wrote: > > We have consesnus of all driver authors, Martin Jerabek, Ondrej Ille > > and me that the license can be change to Apache, BSD or other > > permissive license where authors and CTU university are listed > > in source form... So generally we can provide copies for each > > system according to maintainers will. Keeping some mechanism > > to allow sharing of updates from other future contributors > > is preferred.. > > Some nuttx features (eg libcxx and littlefs) are managed by the build > process downloading the appropriate release from the upstream site, > patching if required, then compiling with any nuttx specific files that > complete the integration. This approach may also be the best solution for > ctucanfd to achieve the above objective. I already have some driver fixes > from my last lunux testing, so it would be good to get them merged into a > common location. > > When would it be practical to update the licence information in the common > driver code? As I have concluded earlier, we need to fork. I am not sure, if to complicate license and sync it to Linux kernel mainline... and there are some Linux kernel specific and derived parts. So I would prefer to start with some RTEMS or NuttX variant which is cleaned from Linux specific parts and clarify broader license on it from our side. We have RTEMS work negotiated with Michal Lenc in the frame of his diploma theses. The there will be RTOS matching code base which could be easier to use for NuttX than actual Linux kernel code... But I am not sure how fast it goes, so this can be reason to reconsider alternatives. > > As for the start, we have plan to work with Michal Lenc on RTEMS version > > derived from Linux driver specific part and LinCAN queues, but there is > > another chipmaker who would like NuttX driver for CTU CAN FD probably > > and may be their own development environment version. If there is some > > funding available, I try to find some additional studnet for NuttX. > > It would be great to share the effort/cost with another organisation. When > would it be feasible for a student to start and what timeframe is > realistic? > > Given our timeframe (this year roughly) > we are starting to get to the point where we may need to consider an > alternate strategy to get this done in time. Yes, I understand. We can discuss funding options off-list. We can try to add some rough code into one of NuttX personal forks https://github.com/michallenc/incubator-nuttx https://github.com/ppisa/nuttx-nuttx for RTEMS, we have discussed if use OMK and develop out of source at the start but Michal Lenc tends more for direct development in RTEMS mainline GIT fork as well.. For RTEMS, we have clear strategy, how to develop. We have AMD/Xilinx Zynq based educational kits https://cw.fel.cvut.cz/wiki/courses/b35apo/en/documentation/mz_apo/start which is our main platform for continuous integration including automatic FPGA configuration build and daily Linux kernel latency testing https://canbus.pages.fel.cvut.cz/can-latester/ Michal Lenc has tested and RTEMS on the target, so the porting from the Linux is straightforward. I am not sure, what would be best environment for NuttX. Ideal is some SoC with NuttX ported and CTU CAN FD synthesis realized. There is some chance, that there would be COTS silicon with CTU CAN FD available next year so it would be ideal for NuttX development too. Or use some bigger FPGA with some processor soft-core is option. CTU CAN FD has advantage, that functional HW emulation is included in QEMU mainline https://www.qemu.org/docs/master/system/devices/can.html But we emulate only PCIe CTU CAN FD integration https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd This means that it is easy to insert CTU CAN FD to any platform which is PCIe equipped. But I am not sure if there is some good NuttX target with PCIe support. I have never tested NuttX on x86, only ARM and RISC-V. Other option is to implement mapping of CTU CAN FD emulation into address space of some target through device tree support in QEMU. I have not done that earlier and it would be some additional effort. For RTEMS, Zynq is ideal gain. But that has no prospect for NuttX, as it does not support Zynq. There s overlap with NuttX in PolarFire MPFS250T. This would be interesting target for us even with option for final testing and tuning real bitrates etc... But we do not have experience with this platform and do not own any kit. PolarFire SoC Icicle Kit emulation is already available in QEMU... so doable but again needs preparatory steps. We can learn how to map CTU CAN FD emulation in QEMU into address space of "random" MCU supported well by NuttX and start developmet by this sidestep... Andrew: What is planned target architecture for your application, ARM 32/64-bit, RISC-V? SoC or FPGA soft core? You have informed that you have tested CTU CAN FD on ECPIX5 with GNU/Linux. Is it the same platform planned for NuttX or do you have tested something other? Have you some HW to offer or setup for full remote access and JTAG debugging? I am open and will be happy to hear what is reasonable combination for this development on real HW or with QEMU. As for NuttX, we have experience with LPC17xx, LPC408x, imxRT, SAMV71 and ESP32C3... In theory, I have interesting target for testing, our LX_CPU board NXP LPC4088 (Cortex-M3/M4F) + Xilinx XC6SLX9 CPU which is fully publicly documented, has NuttX mainline support and ARM 32-bit bus is routed into motion control FPGA engine https://www.pikron.com/pages/products/cpu_boards/lx_cpu.html So it would be nice platform to debug CTU CAN FD. But porting of the core to that platform from Zynq would be considerable effort too and I am not sure if two cores fit into this cheap and small FPGA. Best wishes, Pavel PS: CTU CAN FD is mainly my university and spare time activity, but because university does not allow emails forwarding to external servers, I use my personal/company SMTP infrastructure for list activities. -- 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 company: https://pikron.com/ PiKRON s.r.o. Kankovskeho 1235, 182 00 Praha 8, Czech Republic projects: https://www.openhub.net/accounts/ppisa social: https://social.kernel.org/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
