Thor Jetpack 7.1 Jetson Linux 38.4 uart5 rz Bad CRC

Hi NVIDIA Team,

I am encountering an issue when attempting to receive files over UART5 (/dev/ttyAMA5) using the ZMODEM protocol (rz) on the Jetson AGX Thor platform with customer board.

While basic character transmission works without any issues, the failure specifically occurs when Thor acts as the receiver using rz. fails with repeated CRC errors and timeouts.

Test Steps & Commands

  1. Target Side (Thor): Set UART parameters to Raw mode and start rz:
stty -F /dev/ttyAMA5 115200 cs8 -cstopb -parenb raw -echo
rz -E -b < /dev/ttyAMA5 > /dev/ttyAMA5
  1. Host PC Side: Set /dev/ttyUSB0 to Raw mode and send file via sz:
sudo stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb raw -echo
sz -E -b jetson-agx-thor-devkit_decompiled.dts < /dev/ttyUSB0 > /dev/ttyUSB0

Error Log

During transmission, rz continuously throws CRC errors, timeouts, and fails to receive the data properly:

root@tegra-ubuntu:/home/nvidia# rz -E -b < /dev/ttyAMA5 > /dev/ttyAMA5
rz waiting to receive.Retry 0: Got ERROR
Retry 0: Got ERROR
Retry 0: TIMEOUT
Retry 0: Bad CRC
Retry 0: Bad CRC
Retry 0: Bad CRC
Retry 0: Got ERROR
Retry 0: Bad CRC
Retry 0: Bad CRC
Retry 0: Bad CRC
Retry 0: Got ERROR
^Crz: caught signal 2; exiting

uart5 device-tree setting

decompile

serial@810c510000 {
			compatible = "arm,pl011\0arm,primecell";
			reg = <0x81 0xc510000 0x00 0x10000>;
			interrupts = <0x00 0xab 0x04>;
			clocks = <0x02 0x36 0x02 0x16>;
			clock-names = "uartclk\0apb_pclk";
			assigned-clocks = <0x02 0x36>;
			assigned-clock-parents = <0x02 0x16>;
			dmas = <0x133 0x0b 0x0b 0x800 0x133 0x0b 0x15 0x800>;
			dma-names = "rx\0tx";
			dma-coherent;
			arm,primecell-periphid = <0x51011>;
			resets = <0x02 0x51>;
			reset-names = "serial";
			status = "okay";
			iommus = <0x05 0x80b>;
			phandle = <0x290>;
		};
--------------------------------------------------------------------------
tegra264.dtsi

uart5: serial@810c510000 {
			compatible = "arm,pl011", "arm,primecell";
			reg = <0x81 0x0c510000 0x0 0x10000>;
			interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>;
			clocks = <&bpmp TEGRA264_CLK_UART5>,
				 <&bpmp TEGRA264_CLK_PLLP_OUT0>;
			clock-names = "uartclk", "apb_pclk";
			assigned-clocks = <&bpmp TEGRA264_CLK_UART5>;
			assigned-clock-parents = <&bpmp TEGRA264_CLK_PLLP_OUT0>;
			dmas = <&gpcdma 11 11 TEGRA_SID_GPCDMA>,
			       <&gpcdma 11 21 TEGRA_SID_GPCDMA>;
			dma-names = "rx", "tx";
			dma-coherent;
			arm,primecell-periphid = <0x00051011>;
			resets = <&bpmp TEGRA264_RESET_UART5>;
			reset-names = "serial";
			status = "disabled";
		};

customer board
bus@0 {
    serial@810c510000 {
            status = "okay";
			iommus = <&smmu1_mmu TEGRA264_GPCDMA_SID_UART5>;
        };
}

Pinmux setting

uart5_tx_pj3 {
				nvidia,pins = "uart5_tx_pj3";
				nvidia,function = "uartf_txd";
				nvidia,pull = <TEGRA_PIN_PULL_NONE>;
				nvidia,tristate = <TEGRA_PIN_DISABLE>;
				nvidia,enable-input = <TEGRA_PIN_DISABLE>;
				nvidia,drv-type = <TEGRA_PIN_1X_DRIVER>;
				nvidia,e-io-od = <TEGRA_PIN_DISABLE>;
				nvidia,e-lpbk = <TEGRA_PIN_DISABLE>;
			};

			uart5_rx_pj4 {
				nvidia,pins = "uart5_rx_pj4";
				nvidia,function = "uartf_rxd";
				nvidia,pull = <TEGRA_PIN_PULL_UP>;
				nvidia,tristate = <TEGRA_PIN_ENABLE>;
				nvidia,enable-input = <TEGRA_PIN_ENABLE>;
				nvidia,drv-type = <TEGRA_PIN_1X_DRIVER>;
				nvidia,e-io-od = <TEGRA_PIN_DISABLE>;
				nvidia,e-lpbk = <TEGRA_PIN_DISABLE>;
			};

dmsg as attached

Any suggestions or pointers on how to resolve or debug this issue would be greatly appreciated.

Thanks!

dmesg.log (1.1 MB)

Please check if you hit the similar issue as 7.2 uart5 issue - #13 by KevinFFF.

You can try updating the following lines to verify.

-			dmas = <&gpcdma 11 11 TEGRA_SID_GPCDMA>,
-			       <&gpcdma 11 21 TEGRA_SID_GPCDMA>;
+			dmas = <&gpcdma 11 11 TEGRA264_GPCDMA_SID_UART5>,
+			       <&gpcdma 11 21 TEGRA264_GPCDMA_SID_UART5>;

Hello KevinFFF

I referenced the solution from JetPack 7.2 for the uart5 issue and modified the dmas properties on JetPack 7.1 as shown below:

		serial@810c510000 {
			status = "okay";
			dmas = <&gpcdma 11 11 TEGRA264_GPCDMA_SID_UART5>,
			       <&gpcdma 11 21 TEGRA264_GPCDMA_SID_UART5>;
			iommus = <&smmu1_mmu TEGRA264_GPCDMA_SID_UART5>;
        };

However, I encountered the following error messages

[  143.786258] uart-pl011 810c510000.serial: DMA channel TX dma0chan20
[  143.786284] uart-pl011 810c510000.serial: DMA channel RX dma0chan10
[  175.252634] tegra-mc 8108020000.memory-controller: ptcr: @0x0000000000000000: Read response with poison bit error status:0
[  175.252674] tegra-mc 8108020000.memory-controller: gpcdmar: non-secure read @0x0000fffffffff000: EMEM address decode error (EMEM decode error)
[  175.262788] tegra-gpcdma 8400000.dma-controller: GPCDMA CH21 mc slave error
[  175.269828] arm-smmu-v3 8105000000.iommu: event 0x10 received:
[  175.269830] arm-smmu-v3 8105000000.iommu:    0x0000080b00000010
[  175.269832] arm-smmu-v3 8105000000.iommu:    0x0000020800000000
[  175.269834] arm-smmu-v3 8105000000.iommu:    0x00000000ffffd000
[  175.269836] arm-smmu-v3 8105000000.iommu:    0x0000000000000000
[  175.269838] arm-smmu-v3 8105000000.iommu: event 0x10 received:
[  175.269840] arm-smmu-v3 8105000000.iommu:    0x0000080b00000010
[  175.269842] arm-smmu-v3 8105000000.iommu:    0x0000020800000000
[  175.269843] arm-smmu-v3 8105000000.iommu:    0x00000000ffffd000
[  175.269845] arm-smmu-v3 8105000000.iommu:    0x0000000000000000
[  177.115666] tegra-gpcdma 8400000.dma-controller: GPCDMA CH11 mc slave error
[  177.115711] tegra-mc 8108020000.memory-controller: gpcdmaw: non-secure write @0x0000fffffffff000: EMEM address decode error (EMEM decode error)
[  177.121636] uart-pl011 810c510000.serial: unable to pause DMA transfer
[  177.128000] arm-smmu-v3 8105000000.iommu: event 0x10 received:
[  177.128003] arm-smmu-v3 8105000000.iommu:    0x0000080b00000010
[  177.128005] arm-smmu-v3 8105000000.iommu:    0x0000020000000000
[  177.128007] arm-smmu-v3 8105000000.iommu:    0x00000000fffff000
[  177.128009] arm-smmu-v3 8105000000.iommu:    0x0000000000000000
[  197.116351] tegra-mc 8108020000.memory-controller: gpcdmaw: non-secure write @0x0000fffffffff000: EMEM address decode error (EMEM decode error)
[  197.116444] arm-smmu-v3 8105000000.iommu: event 0x10 received:
[  197.116447] arm-smmu-v3 8105000000.iommu:    0x0000080b00000010
[  197.116450] arm-smmu-v3 8105000000.iommu:    0x0000020000000000
[  197.116451] arm-smmu-v3 8105000000.iommu:    0x00000000fffff000
[  197.116453] arm-smmu-v3 8105000000.iommu:    0x0000000000000000
[  207.117699] tegra-mc 8108020000.memory-controller: gpcdmaw: non-secure write @0x0000fffffffff000: EMEM address decode error (EMEM decode error)
[  207.117816] arm-smmu-v3 8105000000.iommu: event 0x10 received:
[  207.117820] arm-smmu-v3 8105000000.iommu:    0x0000080b00000010
[  207.117822] arm-smmu-v3 8105000000.iommu:    0x0000020000000000
[  207.117824] arm-smmu-v3 8105000000.iommu:    0x00000000ffffe000
[  207.117826] arm-smmu-v3 8105000000.iommu:    0x0000000000000000
nvidia@tegra-ubuntu:~$

I then tried backporting amba-pl011.c from JetPack 7.2. The EMEM address decode error no longer occurs; however, file transfers via rz still fail with CRC errors.

On the other hand, I tried uart9 and it worked properly—both sending and receiving files without any issues.

serial@810c510000 {
            status = "okay";
			dmas = <&gpcdma 11 11 TEGRA264_GPCDMA_SID_UART5>,
			       <&gpcdma 11 21 TEGRA264_GPCDMA_SID_UART5>;
			iommus = <&smmu1_mmu TEGRA264_GPCDMA_SID_UART5>;
        };

		serial@810c530000 {
			status = "okay";
			dmas = <&gpcdma 10 10 TEGRA264_GPCDMA_SID_UART9>,
			       <&gpcdma 10 20 TEGRA264_GPCDMA_SID_UART9>;
			iommus = <&smmu1_mmu TEGRA264_GPCDMA_SID_UART9>;
		};

dmsg as attached

dmesg_uart-pl011.txt (129.1 KB)

Do you mean the issue is specific to UART5 but not for UART9?
Please also share the full device tree for further check.

Could you just try updating to the latest JP7.2(r39.2) to verify in case you miss some changes during porting?

Hello KevinFFF

Do you mean the issue is specific to UART5 but not for UART9?

Yes, exactly. This issue is specific to UART5 and does not happen on UART9.

I have verified this behavior on UART5 across both JetPack 7.1 and JetPack 7.2 (amba-pl011.c), and the “Bad CRC” errors occur in both cases.

Could you just try updating to the latest JP7.2(r39.2) to verify in case you miss some changes during porting?

Could you please share some advice or debugging steps for the “Bad CRC” issue on UART5 specifically for JetPack 7.1? I am rolling back amba-pl011.c to the JP7.1 version.

Full device-tree please check as attached

thor-t4000_decompiled.dts.txt (330.9 KB)

Why I don’t see iommus property for UART interface in this device tree?

Porting amba-pl011.c driver from JP7.2 to JP7.1 is not a validated case.

We wish to debug with the latest release with all possible fixes included.
Could you help to verify with JP7.2?

Hello KevienFFF

Why I don’t see iommus property for UART interface in this device tree?

The iommus property is not included in tegra264.dtsi by default. I have tried manually adding this property to the device tree, but it didn’t make any difference.

We wish to debug with the latest release with all possible fixes included.
Could you help to verify with JP7.2?

I will try to verify this on JP7.2 as requested. However, since our custom board is verified based on JetPack 7.1, if you have any advice regarding this issue under JP7.1, please let me know. Thank you very much for your help!

We should first confirm whether this issue is isolated to JP7.1 and if it has been resolved in JP7.2.

Please share the full device tree configuration captured in runtime.

$ sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree