Linux SocketCAN nano-howto

Contents

The generic Howto

In the kernel, enable CAN networking and your appropriate CAN hardware device driver:

Networking support -> CAN bus subsystem suport 
and the CAN device drivers also live in that menu branch (i.e. NOT under the "Device Drivers" main menu).

#modprobe <the driver for your CAN controller>
modprobe plx_pci
ip link set can0 type can bitrate 125000
ip link set can1 type can bitrate 125000
#ifconfig can0 up
#ifconfig can1 up
ip link set can0 up
ip link set can1 up

# the socketcan user-space tools have moved from SVN at Berlios to GIT at Github
aptitude install git
git clone https://github.com/linux-can/can-utils/
cd can-utils
make
make install

candump can1
# switch to another console
cansend can0 5A1#1122334455667788

All of this works "out of the box" in Debian 8.1 Jessie.
Yes, the netfilter's "ip" tool already knows about CAN.
And yes, the libc / kernheaders already contain the CAN #defines and structs.
It really all worked in Debian 6 Squeeze already.

For more information on how to use the "socket CAN" from your programs,
check out Documentation/networking/can.txt in your kernel source tree.
And, the can-utils directory is a great source of code examples.

SocketCAN driver for Advantech hardware

Long story short, being an Advantech agent, I have good access to their CAN hardware. Read the next chapter for some gory details and history.
If you are here because you need to get some CAN hardware by Advantech to work, at this time (2019) I recommend that you patch
this driver into your kernel source tree. It's an advantech-proprietary driver called AdvSocketCAN, patchified for in-tree building by me, tested against 5.2.7.

Comments on Advantech CAN hardware

By now, Advantech has quite a tradition of solid quality CAN interface cards for the PC, using the Philips SJA1000 controller chip.
It probably started with the ISA-based PCL-841 and its PC104-based equivalent called the PCM-3680 (do not confuse with the younger PCM-3680I=PCI104).
Then came the equally venerable PCI-1680, combining two pcs of the SJA1000 with a PLX PCI9030 slave bridge ASIC. And it's PCI104 sister PCM-3680I. And an onboard integrated sibling in the UNO-2052.
In the summer of 2014, PLX corp. (at the time owning Oxford Semi) got acquired by Avago, which later also acquired Broadcom but took its name... So within the resulting "new Broadcom" conglomerate, the traditional slave bridges by PLX (and UARTs by Oxford) got gradually phased out, which left Advantech (and others) with no other option, but to redesign their boards around FPGA-based PCI interfaces. Hence the birth of PCI-1680 rev.B (PCI device ID PCI-1681) and several similar design upgrades across the Advantech portfolio.

The Advantech interface card design exists in several mechanical form factors, and a particular model can apparently be known under several ordering codes... possibly depending on the accessories included?
On a recent occasion, I've tested the Advantech driver with an "iDoor module" purchased under the ordering code of MOS-1130Y. Apparently that same module is also known as the PCM-26D2CA (there's a Windows driver referring to that name). The PCB of the MiniPCI-e card has PCM-2680 etched in the copper. And, the PCI device ID of 0xC302 gets reported as MIOe-3680 by the "lspci" utility - but we know that the MIO is a different (proprietary) mechanical form factor of the expansion card... so this refers to electric compatibility. BTW, the product has a Spartan FPGA for a PCI interface.
Advantech seems to have a productive marketing dept :-)

The SJA1000 is a workhorse. If there's one thing to praise Advantech for, it's sticking to the SJA1000 in their designs. The SJA1000 is reliable, free of bugs and well documented. If you happen to know about some downsides, at least they've been known for decades = there are no bad surprises to be expected.
The SJA1000 has open-source drivers that have been stable for years - including a driver core in the vanilla Linux kernel, which is wrapped in ISA-based and PCI-based driver modules. Other CAN interfaces may be more efficient in terms of CPU load (on part of interrupts and polling), PCB real estate or power consumption, but the SJA1000 is excellent in that it pretty much "works out of the box".

The old ISA-based cards by Advantech are IOMEM-mapped, which may present a bit of a challenge to configure in some modern PC's = get an ISA IOMEM window reserved / working. (Hint: try ICOP motherboards if this is a problem.) These ISA-based interfaces would probably work with the stock/vanilla sja1000_isa.ko driver (apparently each SJA1000 can have its own IRQ). You just need to specify the two IOMEM bases and the two IRQ's as insmod arguments.

The PCI-based SJA1000 interfaces by Advantech need a little more work to get going.
The original designs with PLX slave bridges would almost work with the stock/vanilla plx_pci.ko . For some reason, the vanilla driver did need a
tiny patch to modify some timeout during chip init - after that, it worked just fine.
With the demise of the PLX bridges, and the corresponding rise of the custom FPGA-bridges, sadly it makes less sense to keep all the "SJA1000 on PCI" card models, from different vendors, in one vanilla driver.
In that context, years ago, Advantech have published their own driver called "advsocketcan" (= another factor to its release was the standardization of SocketCAN support in Linux.)

The original Advantech download of AdvSocketCAN is accompanied by a Makefile for the "out of tree" build method. Unfortunately, this build method (once officially recommended) is now deprecated, and causes a "kernel tainted" on insmod. Perhaps the intended message here is, "get your open-source driver accepted upstream" (with all the rigorous collective nitpicking that involves). If for some reason this route proves unfruitful ;-) , you need to patch the driver into your vanilla kernel source tree. I have turned the AdvSocketCAN into that format - along with a few cosmetic additions. See the download link in the previous chapter.

The Advantech driver contains its own copy of the sja1000.c.
This clearly originated as a copy of the same file in the vanilla Linux, at some past point in time. And, the file present in the original Advantech download would clash with the vanilla sja1000.c in that it exports about 5 functions with overlapping names.
I have worked around the problem by renaming those functions in the Advantech version of the file, so that both the vanilla sja1000.ko and the Advantech sja1000.ko can be present in the kernel at the same time.
Still, perhaps it would be more appropriate to make the advsocketcan driver work with the vanilla version of sja1000.ko. If I take a diff, there are some differences - clearly each version has slightly evolved in its own direction, since the fork. Yet nearly all the differences feel perfectly cosmetic (macro names modified, without a change in their functioning, and the like). Maybe I should just try... maybe later.

The Advantech hardware is good quality. It would be nice if Advantech worked to push its wrapper driver around SJA1000 upstream, but perhaps this is too much to hope for. Even the way it is, the Advantech CAN interfaces are much more useful in Linux, compared to various proprietary CAN ports included in competitors' industrial PC hardware (some MCU with proprietary firmware, attached to the host PC via RS232 or USB, hardly even documented...) The SJA1000 on PCIe is a safe bet.


blurted by: Frank Rysanek [ rysanek AT fccps DOT cz ]