I am wondering if anyone has a similar issue of bringing up UART D (/dev/ttyTHS3, serial@3130000) on JetPack 5.1.1
The current status is as the below:
We designed our own carrier board with UART A and UART D as RS-232
We can send and receive data via UART A on either JetPack 5.0.2, or JetPack 5.1.1
We can send and receive data via UART D on JetPack 5.0.2
We can send data, but not receiving data on UART D on JetPack 5.1.1
////
The related dmesg is like
[ 6.395815] serial-tegra 3100000.serial: Adding to iommu group 2
[ 6.402360] 3100000.serial: ttyTHS0 at MMIO 0x3100000 (irq = 24, base_baud = 0) is a TEGRA_UART
[ 6.411884] serial-tegra 3110000.serial: Adding to iommu group 2
[ 6.418252] 3110000.serial: ttyTHS1 at MMIO 0x3110000 (irq = 87, base_baud = 0) is a TEGRA_UART
[ 6.427670] serial-tegra c280000.serial: Adding to iommu group 2
[ 6.435022] c280000.serial: ttyTHS2 at MMIO 0xc280000 (irq = 88, base_baud = 0) is a TEGRA_UART
[ 6.444419] serial-tegra 3130000.serial: Adding to iommu group 2
[ 6.450828] 3130000.serial: ttyTHS3 at MMIO 0x3130000 (irq = 89, base_baud = 0) is a TEGRA_UART
[ 6.460193] serial-tegra 3140000.serial: Adding to iommu group 2
[ 6.466568] 3140000.serial: ttyTHS4 at MMIO 0x3140000 (irq = 90, base_baud = 0) is a TEGRA_UART
I’m using minicom to trasmit and receive data. When I disable hardware flow control, data can transmit but can’t receive. In contrast, data can receive but can’t transmit when hardware flow control is enable.
May 23 14:36:02 nvidia-desktop kernel: [ 7.348050] serial-tegra 3130000.serial: Adding to iommu group 1
May 23 14:36:02 nvidia-desktop kernel: [ 7.355347] 3130000.serial: ttyTHS3 at MMIO 0x3130000 (irq = 86, base_baud = 0) is a TEGRA_UART
From you flash log and pinmux, they seems all fine.
Your issue seems different as current topic, please help to file another one for tracking.