[RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch (LinCAN inspired)

[Pavel Pisa]

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 <pisa at 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:     pisa at 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