hi nvidia:
我对ttyAMA10做回环测试,发现当我发送超过7个字符时就会报错,比如我发送 字符串 1234567 不会报错,但是当我发送12345678时就会报错, 串口配置如下
uart10: serial@810c540000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x81 0x0c540000 0x0 0x10000>;
interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&bpmp TEGRA264_CLK_UART10>,
<&bpmp TEGRA264_CLK_PLLP_OUT0>;
clock-names = "uartclk", "apb_pclk";
assigned-clocks = <&bpmp TEGRA264_CLK_UART10>;
assigned-clock-parents = <&bpmp TEGRA264_CLK_PLLP_OUT0>;
dmas = <&gpcdma 12 12 TEGRA_SID_GPCDMA>,
<&gpcdma 12 22 TEGRA_SID_GPCDMA>;
dma-names = "rx", "tx";
iommus = <&smmu1_mmu TEGRA264_GPCDMA_SID_UART10>;
dma-coherent;
arm,primecell-periphid = <0x00051011>;
resets = <&bpmp TEGRA264_RESET_UART10>;
reset-names = "serial";
status = "disabled";
};
错误信息
[ 48.394330] [TS:58296278136] uart-pl011 810c540000.serial: DMA channel TX dma0chan21
[ 48.395110] [TS:58297058099] uart-pl011 810c540000.serial: DMA channel RX dma0chan11
[ 69.077850] [TS:78979797355] pps-gpio: ts need to resync ts_offset:450425712 temp64:213325 resync_ts_offset:30 real_ts_gap:999786675 real_ts:1785242144450425712
[ 82.793434] [TS:92695381713] arm-smmu-v3 8105000000.iommu: event 0x10 received:
[ 82.793436] [TS:92695383648] tegra-mc 8108020000.memory-controller: ptcr: @0x0000000000000000 : Read response with poison bit error status:0
[ 82.793440] [TS:92695388056] arm-smmu-v3 8105000000.iommu: 0x0000080000000010
[ 82.793442] [TS:92695390065] arm-smmu-v3 8105000000.iommu: 0x0000020800000000
[ 82.793443] [TS:92695391000] arm-smmu-v3 8105000000.iommu: 0x00000000fffff000
[ 82.793444] [TS:92695392083] arm-smmu-v3 8105000000.iommu: 0x0000000000000000
[ 82.793444] [TS:92695391889] tegra-mc 8108020000.memory-controller: No interrupt in HUB/HUBC
[ 82.793451] [TS:92695398907] tegra-gpcdma 8400000.dma-controller: GPCDMA CH22 mc slave error
[ 82.793557] [TS:92695504454] tegra-mc 8108020000.memory-controller: gpcdmar: non-secure read @0x0000fffffffff000 : EMEM address decode error (EMEM decode error)
[ 99.070810] [TS:108972758025] pps-gpio: ts need to resync ts_offset:444742688 temp64:172785 resync_ts_offset:30 real_ts_gap:999827215 real_ts:1785242174444742688
[ 99.071006] [TS:108972953562] pegasus_cdi_monitor processing events:2 ts:99070093077 last_ts:99070093077
[ 99.071013] [TS:108972961219] pegasus_cdi_monitor kfifo_out event:20 data:1e ts:69075579681
[ 100.045266] [TS:109947214145] pegasus_cdi_event event:13 data:0 ts:100042986972 triger done not restart hrtimer
[ 100.047107] [TS:109949055191] pegasus_cdi_event event:13 data:0 ts:0 start hrtimer 100ms later
[ 100.047114] [TS:109949061543] pegasus_cdi_event event:13 data:1 ts:0 set_camera_triger_cmd
[ 100.047116] [TS:109949064080] pegasus_cdi_monitor kfifo_out event:20 data:1e ts:99068539907
[ 100.047118] [TS:109949065941] desert_mipi_reset:0 0 0 0
[ 101.626151] [TS:111528099200] pps-gpio: real_ts_gap:2555380655 real_ts:1785242177000123343 last_index0_real_ts:1785242174444742688
[ 102.625882] [TS:112527829598] pps-gpio: time is resync ts_offset:-131254 temp64:254597
[ 116.529598] [TS:126431545531] arm-smmu-v3 8105000000.iommu: event 0x10 received:
[ 116.529603] [TS:126431551031] arm-smmu-v3 8105000000.iommu: 0x0000080000000010
[ 116.529605] [TS:126431552475] arm-smmu-v3 8105000000.iommu: 0x0000020800000000
[ 116.529605] [TS:126431553253] arm-smmu-v3 8105000000.iommu: 0x00000000fffff000
[ 116.529607] [TS:126431554475] arm-smmu-v3 8105000000.iommu: 0x0000000000000000
[ 116.529723] [TS:126431670864] tegra-mc 8108020000.memory-controller: gpcdmar: non-secure read @0x0000fffffffff000 : EMEM address decode error (EMEM decode error)
[ 116.529724] [TS:126431672234] tegra-mc 8108020000.memory-controller: ptcr: @0x0000000000000000 : Read response with poison bit error status:0
[ 116.529733] [TS:126431680734] tegra-mc 8108020000.memory-controller: No interrupt in HUB/HUBC
[ 141.113333] [TS:151015281109] arm-smmu-v3 8105000000.iommu: event 0x10 received:
[ 141.113339] [TS:151015286304] arm-smmu-v3 8105000000.iommu: 0x0000080000000010
[ 141.113340] [TS:151015287711] arm-smmu-v3 8105000000.iommu: 0x0000020800000000
[ 141.113341] [TS:151015289044] arm-smmu-v3 8105000000.iommu: 0x00000000fffff000
[ 141.113342] [TS:151015290128] arm-smmu-v3 8105000000.iommu: 0x0000000000000000
[ 141.113465] [TS:151015412331] tegra-mc 8108020000.memory-controller: ptcr: @0x0000000000000000 : Read response with poison bit error status:0
[ 141.113465] [TS:151015413239] tegra-mc 8108020000.memory-controller: gpcdmar: non-secure read @0x0000fffffffff000 : EMEM address decode error (EMEM decode error)
[ 141.113473] [TS:151015420452] tegra-mc 8108020000.memory-controller: No interrupt in HUB/HUBC
[ 170.000834] [TS:179902781576] arm-smmu-v3 8105000000.iommu: event 0x10 received:
[ 170.000833] [TS:179902781131] tegra-mc 8108020000.memory-controller: gpcdmar: non-secure read @0x0000fffffffff000 : EMEM address decode error (EMEM decode error)
[ 170.000838] [TS:179902785354] tegra-mc 8108020000.memory-controller: ptcr: @0x0000000000000000 : Read response with poison bit error status:0
[ 170.000839] [TS:179902787261] arm-smmu-v3 8105000000.iommu: 0x0000080000000010
[ 170.000842] [TS:179902789752] arm-smmu-v3 8105000000.iommu: 0x0000020800000000
[ 170.000843] [TS:179902790928] arm-smmu-v3 8105000000.iommu: 0x00000000fffff000
[ 170.000844] [TS:179902791909] arm-smmu-v3 8105000000.iommu: 0x0000000000000000
[ 170.000846] [TS:179902793955] tegra-mc 8108020000.memory-controller: No interrupt in HUB/HUBC
[ 182.009437] [TS:191911384407] tegra-mc 8108020000.memory-controller: gpcdmar: non-secure read @0x0000fffffffff000 : EMEM address decode error (EMEM decode error)
[ 182.009438] [TS:191911386259] arm-smmu-v3 8105000000.iommu: event 0x10 received:
[ 182.009444] [TS:191911391481] arm-smmu-v3 8105000000.iommu: 0x0000080000000010
[ 182.009446] [TS:191911393398] arm-smmu-v3 8105000000.iommu: 0x0000020800000000
[ 182.009446] [TS:191911394268] arm-smmu-v3 8105000000.iommu: 0x00000000fffff000
[ 182.009447] [TS:191911395222] arm-smmu-v3 8105000000.iommu: 0x0000000000000000
[ 182.009560] [TS:191911507462] tegra-mc 8108020000.memory-controller: ptcr: @0x0000000000000000 : Read response with poison bit error status:0
[ 182.009568] [TS:191911515555] tegra-mc 8108020000.memory-controller: No interrupt in HUB/HUBC
Hi helianyi1,
Could you update the following lines in device tree to check if it could help for your case?
[/quote]
- dmas = <&gpcdma 12 12 TEGRA_SID_GPCDMA>,
- <&gpcdma 12 22 TEGRA_SID_GPCDMA>;
+ dmas = <&gpcdma 12 12 TEGRA264_GPCDMA_SID_UART10>,
+ <&gpcdma 12 22 TEGRA264_GPCDMA_SID_UART10>;
dma-names = "rx", "tx";
iommus = <&smmu1_mmu TEGRA264_GPCDMA_SID_UART10>;
ok , the patch fix this issue
SamM11
July 29, 2026, 8:57am
5
Hi @KevinFFF ,
I faced the same issue here at JP7.2 , but I use uart5: serial@810c510000(ttyAMA5) and uart9: serial@810c530000(ttyAMA9). and I using the custom board.
In JetPack 7.1, I only needed to change the status property of UART5 and UART9 to "okay" in tegra264.dtsi, and both UARTs worked correctly.
However, in JetPack 7.2, applying the same modification only enables UART5 to function properly, while UART9 still does not work.
I then applied the patch you provided to UART9 , but it still does not function correctly.
Below are dmesg about tty:
sudo dmesg | grep tty
[ 0.000000] Kernel command line: root=PARTUUID=46ceeaef-cd2f-4fd7-9bfd-48585f7e5b10 rw rootwait rootfstype=ext4 mminit_loglevel=4 earlycon=tegra_utc,mmio32,0xc5a0000 console=ttyUTC0,115200 clk_ignore_unused firmware_class.path=/etc/firmware fbcon=map:0 efi=runtime audit_backlog_limit=8192 video=efifb:off console=tty0 bl_prof_dataptr=6225920@0x2004010000 bl_prof_ro_ptr=65536@0x2004000000
[ 0.012575] printk: legacy console [tty0] enabled
[ 0.113166] printk: legacy console [ttyUTC0] enabled
[ 5.185317] 810c510000.serial: ttyAMA5 at MMIO 0x810c510000 (irq = 124, base_baud = 0) is a PL011 rev0
[ 5.186988] 810c530000.serial: ttyAMA9 at MMIO 0x810c530000 (irq = 125, base_baud = 0) is a PL011 rev0
[ 5.193654] 810c540000.serial: ttyAMA10 at MMIO 0x810c540000 (irq = 126, base_baud = 0) is a PL011 rev0
[ 8.819737] systemd[1]: Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty.
[ 8.870888] systemd[1]: Expecting device dev-ttyGS0.device - /dev/ttyGS0...
[ 8.877859] systemd[1]: Expecting device dev-ttyUTC0.device - /dev/ttyUTC0...
Thanks!!
Please share the full dmesg and device tree in your case for further check.
For UART9, you need to update the following lines:
- dmas = <&gpcdma 10 10 TEGRA_SID_GPCDMA>,
- <&gpcdma 10 20 TEGRA_SID_GPCDMA>;
+ dmas = <&gpcdma 10 10 TEGRA264_GPCDMA_SID_UART9>,
+ <&gpcdma 10 20 TEGRA264_GPCDMA_SID_UART9>;
dma-names = "rx", "tx";
iommus = <&smmu1_mmu TEGRA264_GPCDMA_SID_UART9>;
SamM11
July 30, 2026, 5:38am
8
Hi @KevinFFF ,
below are my dtsi setting:
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 TEGRA264_GPCDMA_SID_UART5>,
<&gpcdma 11 21 TEGRA264_GPCDMA_SID_UART5>;
dma-names = "rx", "tx";
iommus = <&smmu1_mmu TEGRA264_GPCDMA_SID_UART5>;
dma-coherent;
arm,primecell-periphid = <0x00051011>;
resets = <&bpmp TEGRA264_RESET_UART5>;
reset-names = "serial";
status = "disabled";
};
uart9: serial@810c530000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x81 0x0c530000 0x0 0x10000>;
interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&bpmp TEGRA264_CLK_UART9>,
<&bpmp TEGRA264_CLK_PLLP_OUT0>;
clock-names = "uartclk", "apb_pclk";
assigned-clocks = <&bpmp TEGRA264_CLK_UART9>;
assigned-clock-parents = <&bpmp TEGRA264_CLK_PLLP_OUT0>;
dmas = <&gpcdma 10 10 TEGRA264_GPCDMA_SID_UART9>,
<&gpcdma 10 20 TEGRA264_GPCDMA_SID_UART9>;
dma-names = "rx", "tx";
iommus = <&smmu1_mmu TEGRA264_GPCDMA_SID_UART9>;
dma-coherent;
arm,primecell-periphid = <0x00051011>;
resets = <&bpmp TEGRA264_RESET_UART9>;
reset-names = "serial";
status = "disabled";
};
dmesg.txt (130.1 KB)
Thanks!!
Your device tree configurations for UART5/UART9 look good to me.
[ 142.613801] uart-pl011 810c530000.serial: DMA channel TX dma0chan19
[ 142.613831] uart-pl011 810c530000.serial: DMA channel RX dma0chan9
[ 171.366592] uart-pl011 810c510000.serial: DMA channel TX dma0chan20
[ 171.366625] uart-pl011 810c510000.serial: DMA channel RX dma0chan10
Do you run any command so that it prints above messages?
Could you verify UART loopback test before connecting with other UART device?
SamM11
July 31, 2026, 5:27am
11
Hi @KevinFFF ,
I used a UART loopback tool for testing, and the message appeared when I used PuTTY.
Thanks!!
Do you mean the issue is specific to the serial application you are using?
(i.e. there’s no issue when you use PuTTY?)
SamM11
August 6, 2026, 5:35am
14
Hi @KevinFFF ,
Sorry, I may not have explained the issue clearly. Let me describe the situation again.
I am currently using a custom carrier board with JetPack 7.2 . I found that UART5 (serial@810c510000, ttyAMA5) and UART9 (serial@810c530000, ttyAMA9) cannot be used properly.
My test method is as follows:
I connect UART5 to a UART loopback fixture.
I use PuTTY to perform a loopback test.
The characters I type on the keyboard should be echoed back and displayed in the PuTTY terminal.
After testing UART5, I repeat exactly the same procedure with UART9 .
With this test method, both UART5 and UART9 work correctly on JetPack 7.1 , and the characters I type are echoed back as expected.
However, on JetPack 7.2, neither UART works correctly by default .
then I found this discussion and applied the modification you previously suggested. After applying the patch, UART5 works correctly , but UART9 still does not function .
The following dmesg messages appear when I connect to the UART using PuTTY:
[ 142.613801] uart-pl011 810c530000.serial: DMA channel TX dma0chan19
[ 142.613831] uart-pl011 810c530000.serial: DMA channel RX dma0chan9
[ 171.366592] uart-pl011 810c510000.serial: DMA channel TX dma0chan20
[ 171.366625] uart-pl011 810c510000.serial: DMA channel RX dma0chan10
Could you let me know whether these dmesg messages are expected, or if they indicate any issue with the UART or DMA configuration on JetPack 7.2?
Thanks!!
SamM11:
With this test method, both UART5 and UART9 work correctly on JetPack 7.1 , and the characters I type are echoed back as expected.
However, on JetPack 7.2, neither UART works correctly by default .
As there’s no issue with JP7.1, could you share the full device tree and dmesg for both releases?
SamM11
August 7, 2026, 9:34am
16
The uart-pl011 … DMA channel TX/RX … messages are expected and only indicate that the UART driver successfully allocated DMA channels, so they do not by themselves imply a UART or DMA failure.
The more likely issue is that UART9 on JetPack 7.2 still needs the same SID/device-tree fix as UART5, so it is expected that UART5 works after the patch while UART9 still does not.
uart9: serial@810c530000 {
dmas = <&gpcdma 10 10 TEGRA264_GPCDMA_SID_UART9>,
<&gpcdma 10 20 TEGRA264_GPCDMA_SID_UART9>;
dma-names = "rx", "tx";
iommus = <&smmu1_mmu TEGRA264_GPCDMA_SID_UART9>;
};
SamM11
August 13, 2026, 1:48am
18
Hi @KevinFFF ,
Thanks for reply,
Sorry, I realized that the UART 9 device tree configuration in the tegra264.dtsi_jp72.txt file I uploaded previously was incorrect. The actual image I flashed was indeed modified according to your suggested approach, but UART 9 is still not functioning properly.
I also provided the device tree that I modified for JP7.2 earlier in this discussion.
Hi @KevinFFF ,
below are my dtsi setting:
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 TEGRA264_GPCDMA_SID_UART5>,…
And I found a discussion where someone face the same issue with the UART 9 loopback test.
[Link ]
Thanks!!
Hi SamM11,
Could you create a new topic or move to another thread as the current one is specific to UART10(/dev/ttyAMA10)?
All the UARTs should work pretty much the same since they use similar drivers.