WDH - CH340G USB UART not supported by ch341 driver in all chip revisions

[Christian Weisel]

Hi,

the USB UART chip CHG340G is used by many developer ESP2866 boards to connect to USB serial.
The standard kernel driver des support a lot of those CH340x chipset but it does currently not support the WDH CH340g with standard ch341 driver.

Nevertheless there exists a working driver from the vendor since yaers.
http://www.wch.cn/downloads/CH341PAR_LINUX_ZIP.html
https://sparks.gogo.co.nz/assets/_site_/downloads/CH340_LINUX.zip
https://sparks.gogo.co.nz/ch340.html

Is it possable to get the mainlaine driver updated to support CHG340G out of the box without patching recompiling custom kernel.

There are milions of CH340g chips on those ESP2866 boards out there.

ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: linux-image-5.8.0-43-generic 5.8.0-43.49
ProcVersionSignature: Ubuntu 5.8.0-43.49-generic 5.8.18
Uname: Linux 5.8.0-43-generic x86_64
ApportVersion: 2.20.11-0ubuntu50.5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: christian 1412 F.... pulseaudio
                      christian 1416 F.... pipewire-media-
 /dev/snd/seq: christian 1411 F.... pipewire
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Sun Feb 14 22:23:38 2021
InstallationDate: Installed on 2018-11-27 (810 days ago)
InstallationMedia: Kubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2)
MachineType: LENOVO 4349WJK
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-43-generic root=UUID=980616fe-1ce0-41c1-b148-e64e68fdcce7 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-5.8.0-43-generic N/A
 linux-backports-modules-5.8.0-43-generic N/A
 linux-firmware 1.190.3
SourcePackage: linux
UpgradeStatus: Upgraded to groovy on 2021-02-13 (1 days ago)
dmi.bios.date: 09/26/2012
dmi.bios.release: 1.82
dmi.bios.vendor: LENOVO
dmi.bios.version: 6MET92WW (1.52 )
dmi.board.name: 4349WJK
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.ec.firmware.release: 1.33
dmi.modalias: dmi:bvnLENOVO:bvr6MET92WW(1.52):bd09/26/2012:br1.82:efr1.33:svnLENOVO:pn4349WJK:pvrThinkPadT510:rvnLENOVO:rn4349WJK:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.family: ThinkPad T510
dmi.product.name: 4349WJK
dmi.product.version: ThinkPad T510
dmi.sys.vendor: LENOVO

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Christian Weisel (christian-weisel)]

Did dome more testing on a different ESP2866 board (NodeMCU Lolin V3 Module ESP8266).
With this WCH CH340G chip and Linus standard kernel driver the communication works fine.

With different ESP2866 board(AZDelivery D1 R2 ESP8266 12-F) Mac works out of the box and Linux only with driver mentioned above.

[Hui Wang (hui.wang)]

From the 'lsusb -v' in the #1, can't find that device.

Please add ch341.dyndbg=+p in the bootargs and boot up, then please plug that device and run 'lsusb -v', and upload the log of 'lsusb -v' and dmesg.

[Christian Weisel (christian-weisel)]

Added dmesg and lsusb -v output (with kernel paramter mentioned in #4).

[Hui Wang (hui.wang)]

According to the error log of #7, looks like the usb device driver (ch341.ko) is not loaded yet, the error happens ahead of ch341 driver is called.

So in theory, the driver of "https://sparks.gogo.co.nz/assets/_site_/downloads/CH340_LINUX.zip" will not help.

[Christian Weisel (christian-weisel)]

The NodeMCU Board is running without any issues using the in-kernel driver on Linux machine.
The AZ Delivery R1D2 is not Running on the same machine without any change other than changing boards.

Not sure how the unloading/reloding of the kernel driver is working; I‘m not an export on module loading. I can see that ch341 is loaded (lsmod) with NodeMCU but not with AZD R1D2 (doing a reboot of the Linux machine inbetween).

Not sure in the information is helpful but both devices run on a Mac (using same USB cables). Seems to be not a hardware issue.

If this is not an module/driver isuue not sure what the isuue is.

[Hui Wang (hui.wang)]

After a new usb device is plugged, the linux usb core will enumerate this device first, after getting all descriptors, the linux kernel will load and call device driver according to ID, Class, ...

The error happens during the enumerating, this usually means the firmware on your usb device has some problem, usually this is a non-standards-compliant device for linux usb stack. Mac could work with your device, at least the hardware has no problem. You could try it with windows, maybe windows can't enumerate it too. Or you could try it with another Linux host machine, maybe other type of USB host controller (XHCI) could support your device.

[Christian Weisel (christian-weisel)]

With the input provided above I did some more technical digging; steep learning curve so ;)

Seems like really the CH430G on the board in question has an issue with power supply. Connectivity works on a Mac perfect and on other different hardware (running Linux) it is not working.

The later varies from kernel messages like above until no information at all that the device is plugged into USB (knowing that the particular hardware is very strict on providing power via USB only within the specification; also USB-disks fail without additional power supply).

Another test with bypassing the CHG340 connecting the ESP8266 via "flying wiring" to a different UART (FT232) does work. The board (processor) itself is working fine.

This is not a prove that the CHG430 on the board is broken but it shows it is not a driver issue from my point of view.

Proposal to close this bug.