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?
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.
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”.
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.
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.
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.
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.
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 )
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.