Linux Ch340 Driver

[Sherley]

Idont think that is the issue as my ch340 device was not even getting recognized as a device plugged in, anyways I fixed it by switching to kernel version 5.10 from 5.14 and then building the drivers myself, I had to go to the older kernel because for some reason the build was failing on the newer kernels.

I do not have a RPi, so I used KIAUH and my Ubuntu 22.04.04 LTS Desktop laptop to use it instead of the RPi and connect it to my Ender 3 Neo printer. In the KIAUH, I have 3 options to select from [Get MCU ID], 1) USB, 2) UART, 3) USB (DFU mode) instead of 2 as I usually see from other posts.

Thank you @theophile for your answer! It works but unfortunately only when safe boot is turned of, because the CH340 drivers were unsigned. I try to sign them so to solve the problem. I tried openssl and creat a signature, but I cannot find a way to sign the already uploaded ch340.

Do you have any idea how to do so?

If you have this driver, then the driver can work with that UART. If you have the driver, but it fails to associate, then probably you need a udev rule (though not necessarily the brltty-udev.service).

If you want to remove yourself from a group, for example, remove from tty, it can be more difficult because the commands are not uniform across distributions for removal. You can list your current groups like this:

groups

That JetsonHacks article is trying to give you a simplified install, but it will work only with L4T R28.1. That module is built against the wrong kernel version and wrong kernel configuration. Unless of course you have R28.1, which is extraordinarily out of date.

And yes, you need a version of the driver compatible with your kernel. That driver is from L4T R28.1, which is extraordinarily out of date. This is from a time nearly a decade before Orin was even invented. The source code version is wrong, and so is the configuration. As soon as you use a different kernel source, the driver is no longer valid. As soon as you some configuration changes, even if using the same kernel, the driver once again becomes invalid.

Official documents usually center on setting up the flash software with a new kernel, but this is rarely required. If you build something in the form of a module (and not all drivers can be a module, but most can), then it is a simple file copy after you build it. Some file with a .ko name extension becomes a dynamically loadable driver.

I usually recommend that if one is updating the Image to keep the original in place, and simply add an alternate boot entry to some modified Image. Then you can pick the original kernel if there is a failure of the new Image.

I am wondering what does toolchain-path refer to? Could you please clarify on this? Also, how can I build the tegra_defconfig target as mentioned by you in the post Enable CONFIG_USB_SERIAL_PL2303 on kernel - #12 by linuxdev Specifically, what is the command that I have to execute to perform the build task? Thanks in advance.

In JetPack 6.x/L4T R36.x this might just be a mainline kernel, but you must still use the same source code release as that which runs on your system. The L4T release URL should be able to get to the kernel source.

All of that is nearly the same in a cross compile. However, in a cross compile you need to set up a slight change to environment to use the cross tools and name the architecture. If you have cross tools, then those can be named in an environment variable.

Cross tools generally get prefixed in their names based on the target output. A kernel compile would require gcc, and so it is likely that the cross-gcc is named aarch64-linux-gnu-gcc, although there are variations on that too. Kernel build is rather nicely set up, and so there are simple ways to add this information.

I want to work with usb serial converter that uses driver ch341 and depends on usbserial module. In desktop linux it is present in /lib/modules/4.10.0-28-generic/kernel/drivers/usb/serial/. However in ResinOS 2.2.0 the folder does not exist. That I assume is that by choice those modules were not built in into kernel. What is the idea on how to add them / load them into kernel? Of course to load them correctly they should be compiled with the kernel version of ResinOS.

We are also working on a quite different approach to add kernel modules, will keep everyone posted here in the forums, that should fix a lot of these more complicated issues by a much more powerful solution.

I am trying to connect it all (by the way I am trying to build module that in standard is in kernel tree, wouldnt it be easier for me just to compile the exact same kernel as I am using intel? Can you provide the link to the kernel you are using?).

Thank you @alanb128 seems to work (the build). they both posted the solutions without this command before the run, i think the docker-compose works different.

Btw, the module now use the serial and its loaded but my app (johnny-five app) cant comunicate with the board as the module wont exist in the container or something like that.

Im using a Pi 3 with an usb cable to an arduino nano clone (i need the ch34 driver for that reason) and im controlling the board with the firmata protocol. Without the balenaOS system and Pi3 it works perfectly in both windows and ubuntu OS.

Its the same as described here @tomasmigone/interfacing-raspberry-pi-3-and-arduino-with-remote-monitoring-and-upgradeability-eec512ad3dc2 but with a clone board.

Just wanted to leave instructions here for the community, since it took me a while to figure this out myself.

Initially Ultimaker would not recognize my SV06 connected via USB on Ubuntu 22.04 linux. I had to build and install drivers for the CH340 serial converter for it to work. The driver and instructions are available on GitHub: GitHub - juliagoda/CH341SER: CH341SER driver with fixed bug

Drivers should be built into your Linux kernel already, and it should work as soon as you plug it in. If not you can download the Linux CH340 Driver (updating your linux install, so the driver is included is suggested).

Tiny Machines 3D is a Houston, TX based company aiming to provide great working 3D printers, upgrades and filament to new and old printing enthusiasts. All 3D printers, excluding DIY versions, are tested before shipping.

3a8082e126