My pi3 has 2 mcp25625 devices connected. The first is connected to spidev0.0
, the second to spidev1.2
. They both work correctly, after making an overlay (based on https://github.com/raspberrypi/linux/issues/1804) and setting the right /boot/config.txt
parameters:
dtparam=spi=on
dtoverlay=mcp2515-can0,oscillator=20000000,interrupt=5
dtoverlay=spi1-3cs,cs0_spidev=disabled,cs1_spidev=disabled
dtoverlay=mcp2515-can2,oscillator=20000000,interrupt=6
dtoverlay=spi-bcm2835
This works, but sometimes the can0
and can1
devices are mixed up:
[ 3.830843] mcp251x spi0.0 can0: MCP2515 successfully initialized.
[ 3.842469] mcp251x spi1.2 can1: MCP2515 successfully initialized.
Versus:
[ 3.799918] mcp251x spi1.2 can0: MCP2515 successfully initialized.
[ 3.811296] mcp251x spi0.0 can1: MCP2515 successfully initialized.
I was thinking that I might be able to utilize udev
for this, but as far as I know that requires an address for the can devices, which I don't seem to have. Both /sys/class/net/can0/address
and /sys/class/net/can1/address
are empty.
Is there a way to connect the correct spidev with the correct can name at all boots?
The /sys/class/net/can{0,1}/uevent
might help, there are no /dev/can{0,1}
files:
root@canpi:~# ls -al /dev/can{0,1}
ls: cannot access '/dev/can0': No such file or directory
ls: cannot access '/dev/can1': No such file or directory
root@canpi:~# cat /sys/class/net/can{0,1}/uevent
INTERFACE=can0
IFINDEX=3
INTERFACE=can1
IFINDEX=4
root@canpi:~#
The output of udevadm info /sys/class/net/can0
is even more promising:
$ udevadm info /sys/class/net/can0
P: /devices/platform/soc/3f215080.spi/spi_master/spi1/spi1.2/net/can0
E: DEVPATH=/devices/platform/soc/3f215080.spi/spi_master/spi1/spi1.2/net/can0
E: ID_NET_DRIVER=mcp251x
E: ID_PATH=platform-3f215080.spi
E: ID_PATH_TAG=platform-3f215080_spi
E: IFINDEX=4
E: INTERFACE=can0
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/can0
E: TAGS=:systemd:
E: USEC_INITIALIZED=3889130
udev monitor
to see if there is any information to hook into when they are added? PresumingcanX
refers to/dev
entries you could also checkudevadm -a -p /dev/whatever
./dev/can{0,1}
files on the pi. So I am afraid that the udev tools don't work. The/sys/class/net/can{0,1}/uevent
files do exist and contain info. I'll add the output to the question.