Dear all,
As topic , I need build a system have eight RS-232 port on Jetson nano.
So I choose use maxlinear XR17V358, and it was success compiled by reference
Application Note AN-225. https://assets.maxlinear.com/web/documents/an-225.pdf
but I still can’t find devices in the /dev/.
Does any one know how to install this driver or better idea for eight rs-232 port?
material list:
M.2 key A/E/A+E to Mini PCI-E
MINI PCIe to eight RS-232
In theory a PCI device should be detected, and the driver loaded if it is present. With this card connected, what do you see from these two (one brief, one verbose):
lspci
sudo lspci -vvv
Also, if you can, attach a serial console boot log. If that isn’t possible, then attach the dmesg.
Dear all,
when I check dmesg LOG. I finding this.
It seem like error when booting.
[ 1.611566] pcieport 0000:00:01.0: Signaling PME through PCIe PME interrupt
[ 1.611575] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[ 1.611585] pcie_pme 0000:00:01.0:pcie001: service driver pcie_pme loaded
[ 1.611731] aer 0000:00:01.0:pcie002: service driver aer loaded
[ 1.612034] pcieport 0000:00:02.0: Signaling PME through PCIe PME interrupt
[ 1.612041] pci 0000:02:00.0: Signaling PME through PCIe PME interrupt
[ 1.612048] pcie_pme 0000:00:02.0:pcie001: service driver pcie_pme loaded
[ 1.612179] aer 0000:00:02.0:pcie002: service driver aer loaded
> [ 1.612348] serial 0000:01:00.0: enabling device (0000 → 0002)
> [ 1.613174] 0000:01:00.0: ttyS1 at MMIO 0x13000000 (irq = 84, base_baud = 7812500) is a XR17V35X
> [ 1.613807] 0000:01:00.0: ttyS2 at MMIO 0x13000400 (irq = 84, base_baud = 7812500) is a XR17V35X
> [ 1.614273] 0000:01:00.0: ttyS3 at MMIO 0x13000800 (irq = 84, base_baud = 7812500) is a XR17V35X
> [ 1.614515] serial 0000:01:00.0: Couldn’t register serial port 0, irq 84, type 2, error -28
[ 1.619247] brd: module loaded
[ 1.624807] loop: module loaded
[ 1.624912] tegra_profiler: version: 1.145, samples/io: 49/28
[ 1.625023] tegra_profiler: auth: init
[ 1.626440] THERMAL EST: found 2 subdevs
[ 1.626449] THERMAL EST num_resources: 0
Regarding the “lspci”, other than the bridges (part of the Jetson) I see both a serial device and an ethernet device are found on PCI. The serial device is in slot “01:00.0”. This so far seems normal.
The verbose lspci is cut off, I’ll need to see the entire response. Instead of a screenshot you could create a log of the command like this:
sudo lspci -s 01:00.0 -vvv 2>&1 | tee log_lspci.txt
…then attach the file “log_lspci.txt” to the forum thread so it can be searched.
I don’t know yet about this:
(in part because I want to see the error reporting section of the lspci verbose log)
Once the PCI error reporting and driver status part of the verbose log is visible it might be possible to say more about the dmesg log.
Hi linuxdev,
thanks for advice. and I already updated file for reference.
dmesg.txt (55.1 KB)
log_lspci.txt (2.3 KB)
Unfortunately the PCI card does not have advanced error reporting, but from what I can tell it is functioning correctly for the PCI bus. It is a gen. 1 device, and PCI likes it.
It does say that the kernel driver is “serial”, so whatever driver that actually corresponds to, it does load. Any device special file is not a real file, but is instead the driver in RAM pretending to be a file. Whatever file is generated is up to that particular driver. Perhaps this driver does not provide the expected file naming convention in “/dev”. Also, the udev system is often used to rename the original device special file name, and having udev set up can change what you expect (as well as missing a udev rule which can also change what file name you actually see).
I don’t know if this log is for your device or not, but I am going to guess it is:
[ 0.411871] Serial: AMBA PL011 UART driver
Would you be able to find any documentation on the driver which is intended for this device? I believe it is functioning, but it might be necessary to know details about the driver to see just what it is actually creating.
Also, what do you see from:
ls -l /dev/ttyS* /dev/ttyTHS*
Note that the ttyTHS* will be from the Jetson itself when using the “tegra high speed” DMA-capable driver, but there will often be a “ttyS*” matching the ttyTHS entry (same hardware but legacy driver). I’m curious if there is something in there that sticks out as 8 of “something not normally there”.
Hi linuxdev,
ls -l /dev/ttyS* /dev/ttyTHS*
the command show as below :
crw–w---- 1 root tty 4, 64 三 21 16:06 /dev/ttyS0
crw-rw---- 1 root dialout 4, 65 三 21 16:06 /dev/ttyS1
crw-rw---- 1 root dialout 4, 66 三 21 16:06 /dev/ttyS2
crw-rw---- 1 root dialout 4, 67 三 21 16:06 /dev/ttyS3
crw–w---- 1 root tty 238, 1 三 21 16:06 /dev/ttyTHS1
crw-rw---- 1 root dialout 238, 2 三 21 16:06 /dev/ttyTHS2
and also following the document Application Note AN-225. https://assets.maxlinear.com/web/documents/an-225.pdf
If drive is successfully install the ttyXRx should be show in the /dev.
so I think something wrong when driver startup but compile is no error…
Attached driver files for reference
xr17-lnx2.6.32-and-newer-pak_ver2.6.zip (20.1 KB)
All of the devices with group “tty” are for console, and would be native to the Jetson. All of the devices with the Tegra High Speed driver (the “/dev/ttyTHS#”) are native to the Jetson. Typically, if the ttyTHS# and ttyS# have the same number, then it is the same port, but is being made available with two different drivers. It isn’t guaranteed, but it is very highly likely that all of those listed devices are native to the Jetson.
Keep in mind that I don’t actually have this hardware to test with, so a lot of what follows is speculation.
I see in their instructions they want to unbind native drivers. I’m not sure this is needed on a Jetson, especially for the Tegra High Speed (THS) driver which would never conflict. The legacy serial driver is for any typical 16550A UART (or variations), and perhaps it could be disabled, but this too is problematic since the boot stages prior to Linux use this for serial console (boot stages don’t have the THS driver, so they must use the legacy driver). I recommend avoiding any “unbinding” of old drivers, at least for this step. However, there is a suggestion to look at the output of:
lspci -vd 13a8:*
…what does that show if nothing has been “unbound”?
Also, would you post the entire serial console boot log (not just dmesg)? This should indicate messages related to which device is bound to which UART. Just make sure to save the boot log to a file and then attach the file to the forum so that it can be searched through with an editor.
I try to install driver again and also post dmesg log before insmod.
step 1 check ttyXR*
user@user-desktop:/$ ls /dev/ttyXR*
ls: cannot access ‘/dev/ttyXR*’: No such file or directory
before_insmod.txt (55.1 KB)
Step 2 make driver and insmod xr17v35x.ko
root@user-desktop:/home/user/xr17-lnx2.6.32-and-newer-pak_ver2.6# make
make -C /lib/modules/uname -r/build SUBDIRS=/home/user/xr17-lnx2.6.32-and-newer-pak_ver2.6 modules
make[1]: Entering directory ‘/usr/src/linux-headers-4.9.253-tegra-ubuntu18.04_aarch64/kernel-4.9’
CC [M] /home/user/xr17-lnx2.6.32-and-newer-pak_ver2.6/xr17v35x.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/user/xr17-lnx2.6.32-and-newer-pak_ver2.6/xr17v35x.mod.o
LD [M] /home/user/xr17-lnx2.6.32-and-newer-pak_ver2.6/xr17v35x.ko
make[1]: Leaving directory ‘/usr/src/linux-headers-4.9.253-tegra-ubuntu18.04_aarch64/kernel-4.9’
root@user-desktop:/home/user/xr17-lnx2.6.32-and-newer-pak_ver2.6# insmod xr17v35x.ko
also monitor “dmesg – follow” when insmod it shwo
[ 1028.237574] xr17v35x: loading out-of-tree module taints kernel.
[ 1028.247194] Exar PCIe (XR17V35x) serial driver Revision: 2.6
step 3 reboot and check ttyXR also post dmesg log
user@user-desktop:~$ ls /dev/ttyXR*
ls: cannot access ‘/dev/ttyXR*’: No such file or directory
after_insmod.txt (55.2 KB)
It is interesting that the driver is accepted via insmod, but it did not indicate a related trigger of creating any device special file. It is up to the driver, but I am wondering if this is actually the correct driver, or if there is perhaps some additional software required.
Is the x417v35x.ko still present after reboot? If, after reboot this is still present, try “sudo depmod -a”, and then use “sudo modprobe <module name>” while again monitoring “dmesg --follow”, and again checking “ls /dev/ttyXR*”. I’m curious if some secondary requirement is needed in addition to the kernel module.
Incidentally, what is the output of “uname -r”?
Hi Linuxdev,
This RS232 eight port module use XR17V358 this chip.
So I download the driver from official website
I think might be correct.
https://www.maxlinear.com/support/design-tools/software-drivers
I try sudo depmod -a and sudo modprobe
user@user-desktop:~$ sudo depmod -a
user@user-desktop:~$ sudo modprobe xr17v35x
““dmesg --follow””
[ 64.551782] xr17v35x: loading out-of-tree module taints kernel.
[ 64.558467] Exar PCIe (XR17V35x) serial driver Revision: 2.6
““ls /dev/ttyXR*””
user@user-desktop:~$ ls /dev/ttyXR*
ls: cannot access ‘/dev/ttyXR*’: No such file or directory
as those command show I think module was been success import.
I am not sure why the ttyXR node not show in /dev.
by the way uname -r output :
user@user-desktop:~$ uname -r
4.9.253-tegra
It is odd that the hardware does not pick up and use the driver after insmod. Or during normal boot since the driver is there. It is as if the driver does not know it can work for this board. There are some cases where a chipset can be run by a given driver, but it won’t trigger without an alias in “/etc/modprobe.d/”. So is it correct that although this driver is intended to work with this chipset, that the driver is not shipped with that particular hardware? Or is that driver considered as intended for this particular 8-port board?
If there is some official site for the chipset, but not the specific board, perhaps something related to the specific board would provide an alias file. I’m kind of guessing, but since the insmod does as expected and without error, yet nothing happens for the particular board, the odds go up it is something surrounding the driver which is missing, rather than the driver itself.
Hi Linuxdev,
I ask my board Vander about the driver and they give me a same web link to download.
Is it possible that the linux kernel doesn’t know that the correct driver is installed (perhaps a wrong product ID or serial number mismatch)? ?
Maybe need force the driver running on this module??
or any idea for next step.
We know the driver loads into the kernel due to (A) insmod success, and (B) dmesg logs. What we lack is any indication that the driver knows the hardware is to be paired with that hardware, so indeed this is what I’m thinking: The software’s method of identifying the card is perhaps broken.
We do see the hardware in lspci, and so in theory any lack of pairing between this driver and the hardware is not for hardware reasons. I’m not sure, but sometimes some variation on a device (e.g., for mini-PCI versus full socket PCI) might fool the driver.
I know I have asked for lspci output many times, but I’m going to ask for one last log of this to verify. Prior to running lspci manually insmod the driver. Then run fully verbose (I am adding log option, but you could for example log from serial console instead):
sudo lspci -vvv 2>&1 | tee log_lspci.txt
The very end of a fully verbose log will always show any driver bindings, and I want to verify that even after insmod this still shows no driver. If it shows a driver, then we need to find out why the device special file is missing; if instead the driver is missing, then we need to find out why the driver is not identifying itself as compatible with that hardware.
Hi,
I am not sure what kind of lspci log do you want so I remove xr17v35x.ko by use rmmod and get all log for reference.
step 1. check lsmod and dmesg make sure no xr17v35x.ko module (attachment log file more detail)
step_1_lsmod.txt (1.0 KB)
step_1_lspci.txt (13.2 KB)
step_1_dmesg.txt (55.2 KB)
step 2. insmod xr17v35x.ko and check lsmod log and dmesgalso ouput lspci l
step_2_lsmod.txt (1.0 KB)
step_1_lspci.txt (13.2 KB)
step_2_dmesg.txt (55.3 KB)
thanks for your help
Yes, those logs are useful. Looks like the particular device is:
01:00.0 Serial controller: Exar Corp. Device 0358 (rev 03) (prog-if 02 [16550])
So the slot is 01:00.0 (the command “lspci -s 01:00.0” would then show only for that slot).
The interesting detail is that despite not loading xr driver I still see:
Kernel driver in use: serial
So this is why other instructions were suggesting steps to disable that driver (the driver needs to be loaded for other serial hardware, but not for this).
Once the wrong driver loads the right one will not. Both would likely show as “serial”, but the fact that one loaded when the xr driver was unloaded says that the native driver is in use. I’m not where I can test anything, but the driver docs URL you gave has a PDF file describing unbinding the default driver. See if you can get it to work like that. If it does work, then also verify the serial console and any other serial port you use still works. If not, then one can selectively unbind the default for just that slot.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.