Add SPI support for MCP2518FD from the current linux tree

[fluteze]

Would it be possible to import this part of the linux tree?

https://github.com/torvalds/linux/tree/master/drivers/net/can/spi

[Deniz-Eren]

Hello @fluteze,

Firstly, thank you for your question! Extending support to include SPI devices is definitely a great idea.

Currently, the project supports PCI and PCIe devices, and it can be extended to support SPI via the io-spi interface on QNX 8.0 and 7.1. Some implementation work will be required to achieve this.

To give some background on how PCI support was implemented: I first contributed to PCI CAN-bus support in the QEMU virtual machine project, allowing for VM-based testing and verification. This enabled me to run tests with QNX inside a VM, sending and receiving CAN-bus messages to a Linux host running a virtual CAN interface connected to the QEMU client. Our Jenkins build and test pipelines effectively utilize this setup for continuous testing.

Later, the driver was tested and verified with real PCI and PCIe hardware across multiple platforms and devices.

To extend support for SPI devices, we can follow a two-phase approach:

Phase 1: QEMU Support for MCP2518FD

• Implement MCP2518FD support in QEMU, allowing for virtualized testing. We can use the Linux driver code for this device as reference; though we're implementing the device emulation rather than the driver in the first exercise; the opposite of a driver.
• Use a QEMU Linux client with the existing Linux driver to validate the virtualized SPI interface.
• Ensure the QEMU implementation correctly emulates the MCP2518FD behavior.

Phase 2: QNX SPI Driver Implementation

• Begin porting the Linux MCP2518FD SPI driver to QNX, using the io-spi interface.
• Develop and test SPI communication with real MCP2518FD hardware.
• Validate the driver with CAN message transmission and reception.

This phased approach allows for thorough validation at each step, ensuring a stable and functional implementation.

Would you or your team be interested to work on this task and contribute to the project?

[fluteze]

Do you have a document that list the architectural changes you found necessary for the PCI/e implementation?
I'd do the port on existing hardware rather than an emulator, I am developing on a pi 4b with a waveshare 2ch FD hat.

[Deniz-Eren]

Unfortunately I don't have such a document, all documentation is added to the README.md files within the project. However, I'm happy to guide the process as we go.

If we are going to skip Phase 1 with QEmu, for the initial implementation we can rely on your hardware testing and think about QEmu at a later stage.

I would recommend the following approach:

1. Copy the Linux SPI files with the same structure preserved into the dev-can-linux/src/kernel path structure
2. Add missing definition of SPI functions into the project, within the correct Linux structure. Basically we don't want to start chopping and changing the Linux SPI driver code, we want that code to still use the same Linux SPI function definitions, but we want to re-implement the core of those functions using QNX SPI functions (io-spi) instead. So create a src/spi.c where the Linux SPI function definitions are defined, and we'll implement them using QNX SPI functions there.
3. Add the initial QNX io-spi implementation of Linux SPI functions and attempt to compile.
4. In src/main.c after the call to probe/process PCI drivers process_driver_selection, do similar probe/process of SPI drivers. Or perhaps we refactor the internals of process_driver_selection and the like, to handle both PCI and SPI drivers. The dev-can-linux should be capable of hosting multiple hardware within one instance of dev-can-linux (or the user can have the option of starting individual instances, so we don't want to limit the use-case).

This could be a good start. If you share your working branch we can review together as it goes.

You should fork the dev-can-linux repository to your github and at the end you do a creating-a-pull-request-from-a-fork to push your changes up to the root dev-can-linux project.

[Deniz-Eren]

@fluteze I created a new branch in your github dev-can-linux feature/MCP251xFD let's work in there so it's easy to rebase changes coming from dev-can-linux like 1.8.0 just released

[Deniz-Eren]

I have integrated the new SPI segment you imported to the CMake system. Now we play the game of chasing and adding all the missing files from Linux, see the first missing header on build:

# make
Consolidate compiler generated dependencies of target dev-can-linux
[  1%] Building C object CMakeFiles/dev-can-linux.dir/src/kernel/drivers/net/can/spi/hi311x.c.obj
/root/userhome/Repos/outlook/fluteze/dev-can-linux/src/kernel/drivers/net/can/spi/hi311x.c:17:10: fatal error: linux/can/core.h: No such file or directory
 #include <linux/can/core.h>
          ^~~~~~~~~~~~~~~~~~
compilation terminated.
CMakeFiles/dev-can-linux.dir/build.make:383: recipe for target 'CMakeFiles/dev-can-linux.dir/src/kernel/drivers/net/can/spi/hi311x.c.obj' failed
make[2]: *** [CMakeFiles/dev-can-linux.dir/src/kernel/drivers/net/can/spi/hi311x.c.obj] Error 1
CMakeFiles/Makefile2:328: recipe for target 'CMakeFiles/dev-can-linux.dir/all' failed
make[1]: *** [CMakeFiles/dev-can-linux.dir/all] Error 2
Makefile:165: recipe for target 'all' failed
make: *** [all] Error 2

I have taken the approach of doing one of the following when it comes to these headers or dependencies:

1. Comment out the include if it's unnecessary
2. Add the missing header and comment out all the contents within the header that isn't necessary
3. Add the missing header and leave it as-is if it does no harm

When we get to core Linux SPI functions that are missing, we must add the headers that declare those functions, but define them in src/spi.c (to be created).

[fluteze]

I've gone through the include structure and am at the asm/*.h sections. Any suggestions on a workable approach?

[Deniz-Eren]

I'm not sure what you mean. Perhaps if you push your changes to date to our dev branch feature/MCP251xFD and let me know exactly which section you are referring to?

[fluteze]

Prior to moving the relevant ones over, I'm testing basic pre-processor completeness.

The individual list of referenced header files is long and convoluted. The SPI driver appears to use many additional kernel functions and utilities/macros.

Compiled with C_INCLUDE_PATH=../../../../src/linux/include/ which points to the 6.14 linux source tree on my machine.

Produces:
In file included from ${HOME}/qnx-ide-8.0-workspace/dev-can-linux/src/kernel/drivers/net/can/spi/mcp251x.c:22:
${HOME}/src/linux/include/linux/bitfield.h:11:10: fatal error: asm/byteorder.h: No such file or directory
11 | #include <asm/byteorder.h>
| ^~~~~~~~~~~~~~~~~

[Deniz-Eren]

Just keep in mind we are going to gut all the Linux SPI function and re-implement them using QNX io-spi functions. So all you need from them is the header definition or prototypes of the Linux SPI functions, and then create a file called src/spi.c under the root dev-can-linux/src/spi.c path and put empty definitions of the Linux SPI functions there. We just want to get it compiling like that as step one.

[Deniz-Eren]

Initially I would comment out #include <asm/byteorder.h> and all others, and lets see which we really need after the SPI function body gutting.

[fluteze]

Ah, let me ask the question in a different manner.

In QNX, will there be bsp assembler specific macros/functions to be called or does the design of a resource manager element operate in an abstracted manner such that it is handled completely in C? Many of the assembler references are bitwise operations, I suspect this is being done for speed. Microchip's IDE/C has numerous macros for bitwise operations that get expanded by the soc specific preprocessor templates and result in 1 or 2 word opcodes.

The #include tree for the mcp251xfd has copious references that terminate in the asm/*.h portion of the linux kernel, beyond spi access calls. Any guidance on how to better handle bitwise in QNX is most welcome, hopefully this will give me a better idea of which re-implementation path to pursue.

[Deniz-Eren]

I see. Just port them over as-is, the QNX compiler will accept them. Are you running on x86_64 platform for your application?
We also have ARM users, but I will check that those platforms still work on my side before we merge. Just port it over making as little change as you can and making your work as easy as possible. We can always review once we have a working solution.

[Deniz-Eren]

Also, for code that runs assembly directly, you will need to wrap those functions around the following macros:

#ifdef __QNX__
#pragma GCC push_options
/*
 * Disable optimization for QNX release configuration
 */
#pragma GCC optimize ("-O0")
#endif

Your code that uses the assembly

#ifdef __QNX__
#pragma GCC pop_options
#endif