ch340 hardware support fails after current Tinkerboard image updated to default desktop in armbian-config

[dgw]

Armbianmonitor:

https://paste.armbian.com/valogixima

I installed Armbian 23.11 Bookworm Kernel 6.1, Size: 482Mb, Release date: Nov 30, 2023. After installation, a CH340 based board was connected to my original Tinkerboard and recognized. Subsequently, I used armbian-config to provide the default desktop (Cinnamon flavor). Thereafter, the CH340 board is incompletely recognized. Specifically, no device is presented as /dev/ttyUSB?. The device appears in the list from lsusb, the kernel module ch341.ko loads, but no device in /dev. The forum search shows a previous instance of a similar issue many years back. I attempted to build the driver from wch.cn, but the kernel sources pulled from armbian-config were for the Linux tinkerboard 6.1.63-current-rockchip kernel and,so, a mismatch for the running kernel.

uname -a
Linux tinkerboard 6.1.68-current-rockchip #1 SMP PREEMPT Wed Dec 13 17:39:30 UTC 2023 armv7l GNU/Linux

 

lsusb |grep -i ch34
Bus 001 Device 006: ID 1a86:7523 QinHeng Electronics CH340 serial converter

 

lsmod | grep -i ch34
ch341                  20480  0
usbserial              28672  1 ch341

 

[SteeMan]

Moved to correct forum

[dgw]

I'm going to try a more capable power supply as this seems to be a common contributor and expect windowing environment will increase power demands.

[Werner]

It is quite common that boards actually like slight overvoltage. This is last but not least to compensate for voltage drop across connectors, wiring and the PCB itself.

As an example the official PSU for Orange Pi 5 boards, while being marked as 5vdc output, in reality output around 5.3 volts.

Also cellphone chargers are not recommended since they are not designed to handle variable but constant charging loads. Also voltage very likely drops well below 5 volts under load.

[jock]

Very weird, if the kernel module is loaded, there should be the device under /dev too.

From dmesg I see something suspicious:

 

[ 1249.869135] usbcore: registered new interface driver ch341
[ 1249.869317] usbserial: USB Serial support registered for ch341-uart
[ 1249.869609] ch341 1-1.3:1.0: ch341-uart converter detected
[ 1249.872306] usb 1-1.3: ch341-uart converter now attached to ttyUSB0
[ 3599.906107] input: BRLTTY 6.5 Linux Screen Driver Keyboard as /devices/virtual/input/input20
[ 3599.919207] usb 1-1.3: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1
[ 3599.921891] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
[ 3599.921965] ch341 1-1.3:1.0: device disconnected

 

so perhaps brltty is clashing with the usb device. If you are not using a braille device, you can try uninstalling it

[dgw]

The power supply has been upgraded to an Argon 40 rated at 5.25V and 3.5A, but still connected by the standard micro USB.

I had a A3 SD Card and downgraded to A1. Installation is identical to that originally reported.

These USB to serial devices are recognized and have persistence in /dev/tty* and /dev/serial:
Bus 001 Device 010: ID 1a86:5523 QinHeng Electronics CH341 in serial mode, usb to serial port converter
Bus 001 Device 007: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Phone Data Cable

These devices are recognized and transiently build devices in /dev/tty* which persist for seconds, then disappear:
Bus 001 Device 011: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Bus 001 Device 014: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 001 Device 013: ID 10c4:ea60 Silicon Labs CP210x UART Bridge

Other than the built in Tinker Board USB devices, I use a Logitech receiver:
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
The devices above were plugged in and subsequently removed one at at a time with Logitech Unifying Receiver also in place.

I'm happy to test removing the Braille device. Do I remove a kernel module, or is there an app that can be used to manage assistive technologies?

[dgw]

sudo apt remove brltty

I no longer experience the issue. Research suggests a problem with Braille devices using device IDs associated with their USB to serial hardware. It looks like an attempt was made to address the problem with udev rules in the past. Regression bug? Thanks much for the suggestion!