UART on PCIe Minicard is not working on Jetson Nano

Hi,

We are trying to use a XR17V354 based Quad Serial PCIe MiniCard (PCIe MiniCard Expansion Module with 4 High Speed Serial Ports) which provides 4 serial ports on Jetson Nano/NX.
We have tried this on Jetson Nano and Jetson NX stock BSPs L4T 32.4.3 and L4T32.5.X and above.

This minicard works fine with other devices, and also Jetson NX. But we have problem with Jetson Nano. 3 out of 4 ports are working but 4th port is not communicating in Nano.

ttyS1 is for port1
ttyS2 is for port2
ttyS3 is for port3

and port 4 is not working, may be it is mapped to ttyS0 is not working.

Here is the dmesg log for both NX and Nano. in Nano the ttyS0 is listing differently and not listing as XR17V35X port. What could be the reason? any solution you suggest?

for Nano:

nvidia@nvidia-desktop:~$ dmesg | grep tty
[ 0.000000] Kernel command line: tegraid=21.1.2.0.0 ddr_die=4096M@2048M section=512M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 console=ttyS0,115200n8 debug_uartport=lsport,4 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=0x1000@0xff780000 core_edp_mv=1075 core_edp_ma=4000 gpt earlycon=uart8250,mmio32,0x70006000 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 sdhci_tegra.en_boot_part_access=1 quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 sdhci_tegra.en_boot_part_access=1
[ 0.001754] console [tty0] enabled
[ 1.598501] console [ttyS0] disabled
[ 1.598537] 70006000.serial: ttyS0 at MMIO 0x70006000 (irq = 63, base_baud = 25500000) is a Tegra
[ 1.608745] console [ttyS0] enabled
[ 1.609480] 70006040.serial: ttyTHS1 at MMIO 0x70006040 (irq = 64, base_baud = 0) is a TEGRA_UART
[ 1.609775] 70006200.serial: ttyTHS2 at MMIO 0x70006200 (irq = 65, base_baud = 0) is a TEGRA_UART
[ 1.630173] 0000:04:00.0: ttyS1 at MMIO 0x13200000 (irq = 83, base_baud = 7812500) is a XR17V35X
[ 1.630506] 0000:04:00.0: ttyS2 at MMIO 0x13200400 (irq = 83, base_baud = 7812500) is a XR17V35X
[ 1.630837] 0000:04:00.0: ttyS3 at MMIO 0x13200800 (irq = 83, base_baud = 7812500) is a XR17V35X
nvidia@nvidia-desktop:~$

for NX:

nvidia@nvidia:~$ dmesg | grep tty
[ 0.000000] Kernel command line: console=ttyTCU0,115200 video=tegrafb no_console_suspend=1 earlycon=tegra_comb_uart,mmio32,0x0c168000 gpt usbcore.old_scheme_first=1 tegraid=19.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.4.2 vpr_resize sdhci_tegra.en_boot_part_access=1 quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0
[ 0.000585] console [tty0] enabled
[ 1.464528] 3100000.serial: ttyTHS0 at MMIO 0x3100000 (irq = 47, base_baud = 0) is a TEGRA_UART
[ 1.465909] 3110000.serial: ttyTHS1 at MMIO 0x3110000 (irq = 48, base_baud = 0) is a TEGRA_UART
[ 1.466575] 3140000.serial: ttyTHS4 at MMIO 0x3140000 (irq = 49, base_baud = 0) is a TEGRA_UART
[ 1.467536] console [ttyTCU0] enabled
[ 2.855500] 0005:04:00.0: ttyS0 at MMIO 0x1f40200000 (irq = 35, base_baud = 7812500) is a XR17V35X
[ 2.855814] 0005:04:00.0: ttyS1 at MMIO 0x1f40200400 (irq = 35, base_baud = 7812500) is a XR17V35X
[ 2.856113] 0005:04:00.0: ttyS2 at MMIO 0x1f40200800 (irq = 35, base_baud = 7812500) is a XR17V35X
[ 2.856465] 0005:04:00.0: ttyS3 at MMIO 0x1f40200c00 (irq = 35, base_baud = 7812500) is a XR17V35X
[ 5.527261] systemd[1]: Created slice system-serial\x2dgetty.slice.
nvidia@nvidia:~$


There might be a bug in their driver related to β€œhaving to have” a particular name (versus dynamically chosen name) for the device special file, or else a need for a udev edit (udev monitors plug-n-play devices which can self-describe, e.g., USB and PCI, and has triggers used for things like naming device special files as they are detected). If ttyS0 were already taken prior to another driver which works only with ttyS0, then it is conceivable this causes the failure. Note that in the kernel command line serial console is named as ttyS0, and thus the nvgetty.service was told to bind to this. If no ttyS0 is present, or if some issue exists such that the device bound to ttyS0 is unreachable at this stage, then probably tty0 would fail.

The fact that several of the ports work already says the driver is in place and succeeds. So the issue is not a missing driver, and it is not an issue of hardware failure.

I will suggest this experiment:

  • Disable serial console within the Linux environment with:
    sudo disable nvgetty.service
  • Remove this part of the β€œ/boot/extlinux/extlinux.conf” file (it is is β€œttyTCU0”, then ignore this step, but if it is β€œttyS0”, do perform this step):
    console=ttyS0,115200n8
  • Then reboot and see if it works. Verify no β€œconsole=ttyS0,115200n8” in β€œcat /proc/cmdline”.

If you want to restore defaults, then first edit to put that content back into β€œextlinux.conf”, reboot, run β€œsudo enable nvgetty.service”, followed by another reboot. You could then confirm kernel command line once more has β€œconsole=ttyS0,115200n8”.

Incidentally, when posting dmesg content, it is often better to include the entire content as a file attachment. Example:
dmesg | tee dmesg.txt
(then attach β€œdmesg.txt”)

If it turns out that interference from the integrated UART running on ttyS0 is the issue, then it might be possible to use a custom udev rule to solve this. Otherwise a temporary workaround would be to leave serial console disabled within Linux.

1 Like

Hi thank you for the info, I will try this out

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.