Hmm, the module compiled, but crashes the kernel immediately after a canable adapter is plugged in. Some is still wrong...
Some with other modules loaded successfully from a distinct build into the official kernel, but as soon as they are supposed to do something, crash. Something with kernel versions wrong?!
Yeah ... I've seen something similiar before (but mine was when I did "ip link set can0 type can bitrate 250000") ... in LEDE ... but that was Linux 4.4.120 and I heard this was a bug in the driver that was fixed.
From my notes, OpenWRT w/ Linux 4.9.58 (OpenWrt 18.06 ?) also crashed.
... and post it to the kplex (google groups) forum : I proposed an "autobaud" for USB ports, but your 10-persistent_ttys script is a better solution ...
I reverted to the original config.buildinfo and now another module (vxcan) works, also the custom-build vcan and slcan.
Only the gs_usb still crashes, however now when setting up the interface and not when plugging in the adapter.
Regarding the 10-persistent_ttys script ... I tested it and it works great on ftdi_sio & pl2303 devices, but doesn't work with cdc_acm (ttyACM0) devices (a ublox GPS).
Eg, I got this message :
Symlink to /dev/ttyACM0 from /dev/serial/by-port//sys/devices/platform/ehci-platform/usb1/1-1/1-1:1.0/tty/ttyACM0 created
... looks like the sed regex didn't return the right USBPORT ...
But back to the topic:
I'm pretty sure the problem with gs_usb is a endianess problem!
I added lots of debug info, but when the kernel crashed (without any notice), it didn't invoke any of the modules' functions. So it's merely a resource-hogging endless loop that is triggered by the module.
A quick glance at the candlelight firmware shows the endianess id is not evaluated, so anything processed is little endian as it's the stm32f042c6's native byte order.
That explains why it runs without problem on my beaglebone black, or mipsel platforms, also probably with any x86-based system as well. It just crashes/loops till death with ar71xx resp mips_24kc architecture like my router ...
I made some quick changes to force the module send/expect little endian data during setup and it does not crash. Now add the user data and I expect it to work...
Off topic, but have got the native CAN device working on the beaglebone black ?
FYI, I've tried, but haven't figured out the "device tree" voodoo ... I run Fedora, so it doesn't have the RPi DT hacks. I fiddled with uEnv.txt and the uboot "fdt apply" command for a while, but never figured out the pinctrl stuff.
I have to dig into how to create and submit patches, but for those who want to try, you find config, patch and pre-build ar71xx module at http://www.netadair.de/openwrt/#can .
Regarding native CAN on BBB, yes, I am running also the native CAN interfaces (both ) using waveshare can/rs485 capes (ie transceivers) and some patch cables for dcan0 because the capes don't allow the pins for that on port selection jumpers (loosing cape i2c capabilies though).
Amend /boot/uEnv.txt to :
I tested kmod-can-usb-gs-usb_4.14.167-1_mips_24kc.ipk , and it works (on a Carambola2) ...
At least up to "ip link set can0 up type can bitrate 250000 sample-point 0.875". If I can get to the boat, I can test it on a "NMEA 2000" network (w/ gpsd). If not, maybe I can make a test canbus network.
Regarding native CAN on BBB, what OS are you running ? Are those overlay files part of the OS, or where did you get them ?
I'll try that on my BBB (and Udoo Neo). FYI, I have the CBB-Serial cape (with CAN bus, RS232 / RS485 transceivers (and a small waveshare transceiver for the Udoo Neo).