RFE : enable CONFIG_CAN_GS_USB in package/kernel/linux/modules/can.mk?

I wonder if someone could enable CONFIG_CAN_GS_USB in package/kernel/linux/modules/can.mk ?

Maybe call the package kmod-can-usb-gs ?

I can test the build in snapshots ...

FYI, this is for the "canable" (with alternate firmware) : http://canable.io


I will try to...
In the mean time, you can have a look at http://www.netadair.de/openwrt/#can

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.

I looked into using kgdb to debug :
- http://svenschwermer.de/2016/11/02/debugging-openwrt_lede-kernel.html
- https://www.kernel.org/doc/html/latest/dev-tools/gdb-kernel-debugging.html

I like the http://www.netadair.de/openwrt/public_scripts/10-persistent_ttys script ... I'll test that out

... 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.

OK, now our symptoms match.

On the other hand, I've never had it crash on Fedora (just tested on Fedora 31 w/ Linux 5.5.5) ... so I think it's fixed at some point ...

FYI, comparing drivers/net/can/usb/gs_usb.c in Linux 4.14 to v5.5 :


Dunno if any of these differences explain the crash ...

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 ...

I fixed the script, was a bit cruffy with sed having no non-capture groups.
Can you give it a try, please?

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...


[  465.134785] gs_usb 1-1.1:1.0: Configuring for 1 interfaces
[  465.141640] usbcore: registered new interface driver gs_usb

root@xxx:~/tmp# ifconfig can0
can0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP RUNNING NOARP  MTU:16  Metric:1
          RX packets:9410 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10
          RX bytes:33756 (32.9 KiB)  TX bytes:0 (0.0 B)

1 Like

Great ! I tested the 10-persistent_ttys script, and it works great.

FYI, I tested it w/ 2 different GPS rx : ublox6 & ublox7. Tested it with kplex & gpsd as "servers". Tested with OpenCPN & cgps / xgps as clients.

Thanks !

Awesome !

Post must be at least 10 characters ...

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 saw the "Android Things" overlay stuff : https://source.android.com/devices/architecture/dto ... but didn't really try it.

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 :slight_smile: ) 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 :


Great !

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.

Thanks !

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).

Not to bug you, but I wonder if you made progress on submitting patches to enable CONFIG_CAN_GS_USB ...?

You are awesome! Is it possible to get such an amazing result on openWRT 20-23?
It still does not support gs_usb...