I have tried a couple of different vendor cables, and the PL-2303 and while the part is noticed by dmesg, there is device showing up in /dev or any other commend in
[34944.599954] usb 1-2.3: new full-speed USB device number 6 using tegra-xusb
[35797.371281] usb 1-2.3: USB disconnect, device number 6
[35803.997353] usb 1-2.3: new full-speed USB device number 7 using tegra-xusb
I do not decode the journal ell yet, but it seems to be a mismatch on device function
[34944.599954] usb 1-2.3: new full-speed USB device number 6 using tegra-xusb
[35406.253021] audit: type=1326 audit(1756399720.378:8): auid=1000 uid=1000 gid=1000 ses=3 subj=? pid=8196 comm=“chrome” exe=“/snap/chromium/3219/usr/lib/chromium-browser/chrome” sig=0 arch=c00000b7 syscall=444 compat=0 ip=0xffff969d1c28 code=0x50000
[35797.371281] usb 1-2.3: USB disconnect, device number 6
[35803.997353] usb 1-2.3: new full-speed USB device number 7 using tegra-xusb
lsusb identifies it as
Bus 001 Device 007: ID 067b:23a3 Prolific Technology, Inc. USB-Serial Controller
I have seen a post about not seeing output from a USB to serial, In this case I do not have a system device to connect to, or ask STTY for parameters.
Another post mentions a long process to include the PL-2303 device by pre-processor command and then rebuild the kernel. And also recommends against doing so.
I would think that the tegra release should be able to match what my PC version of 22.04 does and use this device.
Just to make sure I am looking at the right question, is this case one of plugging the USB into the Jetson and looking for the device special file existence as a result of that specific PL-2303 device? This is what I’m going to base my answer on.
On the Jetson in question, what do you see from: zcat /proc/config.gz | grep -i 'pl2303'
The simplest thing would be to create a kernel module and then copy that file into place. What do you see from “uname -r”? It should be something ending in “-tegra”. Also, what is your current L4T release from “head -n 1 /etc/nv_tegra_release”?
Instructions for building this depend on whether you’ll be building natively on the Jetson, versus building on a Linux host PC. Both work fine, but the disk space required sometimes exceeds what people have on their Nano. For the Nano, what is the output from “df -H -T”? If you paste that into the forum thread and then highlight it and mark it as code (the “</>” icon), then it’ll preserve formatting.
Then note the URL this points for for your L4T release: https://developer.nvidia.com/linux-tegra
(this is the best place to download any source for the kernel, but it depends on release)
R36 (release), REVISION: 4.4, GCID: 41062509, BOARD: generic, EABI: aarch64, DATE: Mon Jun 16 16:07:13 UTC 2025
From what I infer, the only solution is to rebuild the system with the 2303 enabled.
I have on occasion built a couple of yocto images and decades ago I build the slackware 2.4 system for a junkyard box I found. The support tools have changed a bit over the years.
Since your version is 5.15.148-tegra, then keep in mind that for any kernel build, if you use the same source code release and same base configuration, then you would be able to build a module which loads correctly on that running kernel. The configuration consists of any integrated feature (“=y” in a configuration), and CONFIG_LOCALVERSION is also considered. If those parts of a build do not match, then you can expect problems loading modules you’ve built separately. Restated, if you start with the original kernel configuration which is currently running, including setting “CONFIG_LOCALVERSION” to “-tegra” (which is what “uname -r” output was for determining), then you can add a module (such as “CONFIG_USB_SERIAL_PL2303”) and that module should work in the existing kernel without need to install everything. That’s basically a simple file copy to the right location.
For kernels prior to the one in L4T R36.x a default config of “make tegra_defconfig” is the start point; for your kernel in R36.x a default config is “make defconfig” (these are kernel make arguments); one would then use something like “make nconfig” or “make menuconfig” to change the symbol CONFIG_LOCALVERSION to “-tegra”, and add “CONFIG_USB_SERIAL_PL2303=m”. Or you could copy and decompress “/proc/config.gz” and use that as the starting config (which works even if you are not using the default config). Lots of ways to do this, just ask which method you want to use.
Download the sources for that L4T release, get all of the kernel related sources within that group of sources (it is a tar archive within a tar archive, and there may be more than one kernel source whereby one is the public main source, and other out of tree source could be in a separate package). You can build natively since your NVMe has a lot of spare space, but do not install with any make install type of command. Or cross compile on your host PC.
More specifically, to extract just the kernel packages:
To see kernel packages: tar -jtvf ./public_sources.tbz2 | grep kernel
To extract a specific source within the sources (example for Linux_for_Tegra/source/kernel_src.tbz2): tar xjf public_sources.tbz2 Linux_for_Tegra/source/kernel_src.tbz2
Then extract kernel_src.tbz2: tar xvf public_sources.tbz2
You might be extracting others as well, e.g., Linux_for_Tegra/source/kernel_oot_modules_src.tbz2. Each will unpack into a “Linux_for_Tegra/source/...” subdirectory. The flash software (if you are compiling on the host PC and not on the Jetson) is actually all in a “~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/” subdirectory, and so if you extract with Linux_for_Tegra/ as a child directory, then the content will “just be in the right place” for any documented cross compile information. You won’t care about this if you build directly on your Jetson; you’ll still end up extracting yet more files from “Linux_for_Tegra/sources/” (do this for any “kernel” file that isn’t a sha1sum):
tar xvf kernel_src.tbz2
(it is yet another tar archive within an archive)
You now have “Linux_for_Tegra/source/kernel/kernel-jammy-src/”, and this is where most work will be from.
More specifically for actual build configuration (after configuration actual build changes depending on where you compile from: natively on the Jetson versus PC cross compile). Assuming you have all of the build requirements in place, then this sets default configuration (there may be variations depending on build platform, so this is just a summary…add in this thread if you want to compile from Jetson versus from PC to get proper details, this is just to get an idea of steps):
make defconfig (if you were using L4T R35.x or earlier it would be tegra_defconfig)
make nconfig, search for symbol (F8 searches when using nconfig build target) “CONFIG_LOCALVERSION” or “LOCALVERSION”, which shows it is in “General Setup”, then hit the enter key for () Local version - append to kernel release, and set it to “-tegra”.
Now search for symbol CONFIG_USB_SERIAL_PL2303. You will find it here (IMPORTANT: The manufacturer of this serial UART is Prolific; the name within this configuration to look for is “USB Prolific 2303 Single Port Serial Driver”:
-> Device Drivers
-> USB support (USB_SUPPORT [=y])
-> USB Serial Converter support (USB_SERIAL [=m])
Use the “m” key to enable this as a module.
Configuration is now complete if Save. There will be a .config file generated, you can keep this somewhere safe, maybe rename the copy to “config-5.15.148-tegra-pl2303”. Depending on where you plan to compile this file can simply be dropped in place and used as your config without going through all of the above steps. If you do this once it is actually far more simple than this explanation, and having the config already makes it even simpler.
Where will you compile from, native or cross compile?
For some reason running the script relocate-sdk.sh doe not seem to have any useful effect.
The active image is built with 11.3, my sysem has 11.4. Downloading the tarball and unpacking gives me executable that identify as 11.03 with –version. After the script, I am getting a can of link spaghetti that reports Exec format error when commanding aarch64–glibc–stable-2022-08-1/usr/bin/aarch64-linux-gcc –version.
Cross compiling requires some environment setup, it isn’t just a case of using a different compiler. I have not used that script though, I suppose it is probably part of the shell scripts NVIDIA provides with the source for convenience. Do you want to cross compile from the host PC, or natively on the Jetson? Also, do you want to set up for some removable media, or just from some available location? It is quite difficult to give advice for all cases. If you want to have something like a thumb drive or external USB drive which can be moved around among the different Jetsons the answer would be different than building directly on them without removable media, and also different from cross compile on the host PC.
It is my intent to compile on the Jetson. The compiler question is because you told me the R36.4.4 build was crated with 11.3.0 and I should use the same compiler if it is to be a drop in replacement.
I suceeded in creating an image last night, ~40 MB and when I dropped it into the Boot directory and booted I did not get any activity at all. rebooting with the SD card and copying the image from it to my NVMe will get me back to trying to get a working build
All of that is for setting up a thumb drive or other external drive someone expects to use on different Jetsons.
The really big question is how did you configure? You should start with an unconfigured kernel, and choose an empty location for all temporary output. That is what a lot of the above URL is about, although it is way more detailed than just basic instructions. Keep in mind that if you build the kernel Image itself, and if that Image has any change in integrated features (a change to an “=y”), then most likely you’ve invalidated all modules, including those in the initrd. The install procedure for that is far different than the simple file copy of building a module intended to load into the original kernel.
If you have already replaced your kernel with one which did not exactly match the earlier kernel’s integrated features, then you probably have to start over.
Note that it is almost always safer to add a boot entry for a new kernel with a new name and other details, and leave the old kernel in place. If the new one fails, then you have a backup boot plan. If the system fails now, then you might need to flash again (you could clone first, or if it is on an SD card, simply fix it on a host PC by putting the original kernel back in place).
Also, booting from SD card on a dev kit Orin Nano is quite different than booting from an NVMe. The boot chain is somewhat custom, and so you can’t just interchange bootable devices the same way you could on a computer which has an actual hardware BIOS.