Re: MCP2518FD Drivers Rarely Working with Custom Kernel 5.10.Y

[Patrick Menschel <menschel.p@posteo.de>]

Am 23.06.21 um 19:34 schrieb Joshua Quesenberry:
> Hey!
> 
> I have attached config.txt so you all can see what I'm doing.
> 
> I added printing the error number as Marc suggested and the number appears to be -110 every time.
> 
> [   25.660006] CAN device driver interface
> [   25.668720] spi_master spi0: will run message pump with realtime priority
> [   25.676697] mcp251xfd spi0.1 can0: MCP2518FD rev0.0 (-RX_INT -MAB_NO_WARN +CRC_REG +CRC_RX +CRC_TX +ECC -HD c:40.00MHz m:20.00MHz r:17.00MHz e:16.66MHz) successfully initialized.
> [   25.684900] mcp251xfd spi0.0 can1: MCP2518FD rev0.0 (-RX_INT -MAB_NO_WARN +CRC_REG +CRC_RX +CRC_TX +ECC -HD c:40.00MHz m:20.00MHz r:17.00MHz e:16.66MHz) successfully initialized.
> [   28.098033] mcp251xfd spi0.1 rename4: renamed from can0
> [   28.175644] mcp251xfd spi0.0 can0: renamed from can1
> [   28.225891] mcp251xfd spi0.1 can1: renamed from rename4
> [  146.964971] mcp251xfd spi0.0: SPI transfer timed out
> [  146.965023] spi_master spi0: failed to transfer one message from queue (ret=-110)
> [  146.965216] mcp251xfd spi0.0 can0: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying.
> [  146.965247] mcp251xfd spi0.0 can0: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying.
> [  146.965277] mcp251xfd spi0.0 can0: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying.
> [  146.965286] mcp251xfd spi0.0 can0: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000).
> [  146.965331] mcp251xfd spi0.0 can0: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000) retrying.
> [  146.965360] mcp251xfd spi0.0 can0: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000) retrying.
> [  146.965389] mcp251xfd spi0.0 can0: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000) retrying.
> [  146.965397] mcp251xfd spi0.0 can0: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000).
> [  146.965413] A link change request failed with some changes committed already. Interface can0 may have been left with an inconsistent configuration, please check.
> 
> Regarding the discussion about Kconfig flags, I went ahead and rebuilt kernel 5.10.44 using a config that was essentially arch/arm/configs/bcm2711_defconfig with these additions needed to get our I2S working. This should have undone the switch to ONDEMAND governor and enabling 1000 Hz clock.
> 
> 1030a1031
>> CONFIG_SND_RPI_I2S_AUDIO_WM8782=m
> 1040a1042
>> CONFIG_SND_SOC_WM8782=m
> 
> My RPi and HAT have worked very reliably with the older buster image and customized (same tweaks as mentioned in last email) kernel 4.19.73, in that kernel I'm using MCP25XXFD driver from msperl which under 5.10.Y kernel is having issues too. I only upgraded everything on my system at the end of last week, so hardware has been OK very recently.
> 
> Keep in mind I'm not seeing a total failure, I do occasionally see everything work correctly and I can run the ip link setup command without issue, it's just not common and it seems fully removing power from the system and reapplying seems to help, but not every time, so maybe it's a coincidence. It could be an issue of subsequent configurations of the controller after the initial setup on power application, but I'd expect it work after every power yank I think.
> 
> I wouldn't feel comfortable reverting my /boot/config.txt to a stock one and a default setup of the 40-pin header, at least not with my HAT attached which includes the CAN controllers AND circuitry to supply power to RPi from a 12V rail.

OK,

one general advice.

Check if you can merge your HAT into a complete overlay with ovmerge
tool like I did in
https://github.com/raspberrypi/linux/issues/4032
https://github.com/raspberrypi/linux/pull/4034

This should clean up your config.txt quite a bit.

I compare against the seeed can fd hat v2 which also has i2c1 and both
can on spi0.

I'm not sure about the PI4 but these 3 items usually all go on i2c1
which may be problematic.

# typical combination out of raspi-config
dtparam=i2c_arm=on
dtparam=i2s=on

# some manual entry, check if it can be removed
dtoverlay=i2c1


The CAN related stuff looks ok, but you can omit the
oscillator=40000000,speed=20000000
Those are the standard values afaik.

# CAN 0/1
dtoverlay=spi0-cs
dtparam=cs0_pin=8
dtparam=cs1_pin=7

# CAN 0
dtoverlay=mcp251xfd,spi0-0,interrupt=24

# CAN 1
dtoverlay=mcp251xfd,spi0-1,interrupt=25


Concerning the naming, I also used generic names can0, can1 at first but
was advised to use best practice and to rename to mcp0, mcp1 instead. I
believe Marc mentioned that this causes some kind of problem.

This is my udev rule content.
SUBSYSTEM=="net", ACTION=="add",
DEVPATH=="/devices/platform/soc/*/*/*/spi0.0/net/can?", NAME="mcp0"
SUBSYSTEM=="net", ACTION=="add",
DEVPATH=="/devices/platform/soc/*/*/*/spi0.1/net/can?", NAME="mcp1"


Regards,
Patrick