[参考译文] AM625：同时运行多个串行端口并切换有线 NIC 以引入干扰。

尊敬的 Fuyi：

我们首先在以下主题中等待测试结果、然后评估此测试用例。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1472428/am625-uart-with-dma-takes-longer-in-continues-sending/5780427#5780427

1. 应用了以下补丁。

   diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
   index 0b9c47172bc8..0952f08622c9 100644
   --- a/drivers/tty/serial/8250/8250_omap.c
   +++ b/drivers/tty/serial/8250/8250_omap.c
   @@ -1042,6 +1042,10 @@ static int omap_8250_tx_dma(struct uart_8250_port *p)
           unsigned int    skip_byte = 0;
           int ret;
    
   +       /* HACK: do not use DMA for TX */
   +       ret = -EINVAL;
   +       goto err;
   +
           if (dma->tx_running)
                   return 0;
           if (uart_tx_stopped(&p->port) || uart_circ_empty(xmit)) {

   
   
   

2. 已使用测试串行端口  序列检查  指定  DMA 模式 。
   
   

3. 测试结果：  所有五个序列检查实例均已损毁 。

   类似的错误如下所示：
   

   timeout, RX/TX: 9856/10000
   Needed 4 reads 1 writes Oh oh, inconsistency at pos 9856 (0x2680).
   
   Original sample:
   00002650: 62 60 f6 f1 ec 97 70 fe  32 b7 a0 14 32 e1 19 57   b`....p.2...2..W
   00002660: 14 60 e0 c3 44 ea 7a 9c  ce 1c 6f 54 e4 1f ef 89   .`..D.z...oT....
   00002670: f5 27 54 35 1d 57 b3 15  a4 c2 ed 79 da 8d 8e c6   .'T5.W.....y....
   00002680: e8 96 98 ef 5f 7b b9 12  a2 87 fc 53 50 35 7b da   ...._{.....SP5{.
   00002690: e7 8c c9 46 59 15 42 84  a3 22 0f b8 19 a9 a7 60   ...FY.B..".....`
   000026a0: dc cf a0 47 e8 b1 38 78  94 b7 fe 61 4d 30 64 74   ...G..8x...aM0dt
   
   Received sample:
   00002650: 62 60 f6 f1 ec 97 70 fe  32 b7 a0 14 32 e1 19 57   b`....p.2...2..W
   00002660: 14 60 e0 c3 44 ea 7a 9c  ce 1c 6f 54 e4 1f ef 89   .`..D.z...oT....
   00002670: f5 27 54 35 1d 57 b3 1

尊敬的 Fuyi：

请附加您捕获的其他控制台日志。 我想看看消息是否有任何模式。

您能提醒一下我您使用的是哪个 SDK 或内核版本吗？

尊敬的 Fuyi：

请应用以下 3 个内核补丁并再次进行测试。

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/drivers/tty/serial/8250/8250_omap.c?h=ti-linux-6.12.y&id=9d141c1e615795eeb93cd35501ad144ee997a826

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/drivers/tty/serial/8250/8250_omap.c?h=ti-linux-6.12.y&id=c128a1b0523b685c8856ddc0ac0e1caef1fdeee5

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/drivers/tty/serial/8250/8250_omap.c?h=ti-linux-6.12.y&id=ac0e4f5f7690088c9ec5e7d822cd0dda12a722a1

尊敬的 Bin：

客户忘记更新测试结果：

应用的上层补丁、使用 DMA 进行测试（应用的补丁可禁用 Tx DMA）、甚至不会向上/向下切换以太网、串行检查也会同时在多个实例测试时挂起。

尊敬的 Tony：

感谢您的更新。

我将看看是否可以在 EVM 上重现问题并进行研究。

嗨、Bin

第一个和第二个补丁已包含在内核 6.6.32 中、因此我只需要应用第三个补丁进行修改。 我目前正在测试它。

嗨、Bin

应用补丁后、所有序列检查测试均已停止。

尊敬的 Fuyi：

您是说测试因 RX 数据不随 TX 数据补丁而过早停止吗？ 请附上测试日志。

好的、这看起来与应用第三个补丁之前的误差相同。

您使用哪种 AM625 器件型号？ 我想知道它有多少个 A53 内核。

它是双核 AM6252。

感谢您提供的所有详细信息。 我将尝试在 EVM 上重现问题并进行研究。

我将在接下来的几周内离任。 到目前为止、我在 EVM 上的测试中有 3 个 UART 同时运行、没有 DMA 以及以太网链路建立/断开、我看到一个 UART 存在 RX 溢出问题。 回到办公室后、我将启用 UART DMA 并继续测试。

尊敬的 Fuyi：

我仍在调试我的 EVM（没有 DMA）上的问题、此时我会看到 UART 行为不一致、因此尝试了解故障的确切原因。

但我看到您使用带有参数'-m d'的 serialcheck 程序的方式可能不正确。 以下 SDK 文档显示不支持双工模式。 我猜原因是、串行检查不是一个多线程程序、在执行 TX 时、RX 被阻止、这可能会导致 TTY RX 缓冲区溢出、从而导致数据丢失。

https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/11_00_09_04/exports/docs/linux/Foundational_Components kilers/kernel/uart/html#basic-external-loopback-testing Kernel_Drivers

因此、请在每个 UART 上运行两次序列检查、一个使用“-m r“、另一个使用“-m t“。 这就是我的测试方式。

serialcheck -b 115200 -d /dev/ttyS3 -f ./binary_1W_ttyS3 -l 696729 -m d &
serialcheck -b 460800 -d /dev/ttyS4 -f ./binary_1W_ttyS4 -l 2786918 -m d &
serialcheck -b 460800 -d /dev/ttyS6 -f ./binary_1W_ttyS6 -l 2786918 -m d &
serialcheck -b 460800 -d /dev/ttyS7 -f ./binary_1W_ttyS7 -l 2786918 -m d &
serialcheck -b 460800 -d /dev/ttyS8 -f ./binary_1W_ttyS8 -l 2786918 -m d &

以及文件大小是多少 binary_1W_ttySx 该怎么办？

10,000 字节

好的、我认为 10K 字节应该可以。 我在 3 个 UART 上同时测试了一个 350KB 的文件,没有发现任何数据丢失问题（与网卡上/下）。 但是,如果数据文件太大,它可能会导致数据丢失,因为 RX 被阻止时,整个文件被接收和比较数据不匹配。 如果 RX 被阻止的时间过长、则 RX 缓冲区会溢出、然后会发生数据丢失。

您是否在 serialcheck 参数中使用了'-m r'和'-m t'而不是'-m d'进行了测试、以查看您的电路板上是否仍然出现数据丢失？

您好、bin

我将接管这个问题。 我们在 serialcheck 参数中使用'-m r'和'-m t' 来代替'-m d'、但仍会发生数据包丢失。

./serialcheck_comen -b 115200 -d /dev/ttyS3 -f ./binary_1w_ttyS3 -l 696729 -m r &
./serialcheck_comen -b 460800 -d /dev/ttyS4 -f ./binary_1w_ttyS4 -l 2786918 -m r &
./serialcheck_comen -b 460800 -d /dev/ttyS6 -f ./binary_1w_ttyS6 -l 2786918 -m r &
./serialcheck_comen -b 460800 -d /dev/ttyS7 -f ./binary_1w_ttyS7 -l 2786918 -m r &
./serialcheck_comen -b 460800 -d /dev/ttyS8 -f ./binary_1w_ttyS8 -l 2786918 -m r & 

./serialcheck_comen -b 115200 -d /dev/ttyS3 -f ./binary_1w_ttyS3 -l 696729 -m t &
./serialcheck_comen -b 460800 -d /dev/ttyS4 -f ./binary_1w_ttyS4 -l 2786918 -m t &
./serialcheck_comen -b 460800 -d /dev/ttyS6 -f ./binary_1w_ttyS6 -l 2786918 -m t &
./serialcheck_comen -b 460800 -d /dev/ttyS7 -f ./binary_1w_ttyS7 -l 2786918 -m t &
./serialcheck_comen -b 460800 -d /dev/ttyS8 -f ./binary_1w_ttyS8 -l 2786918 -m t &

我同时在没有 DMA 的情况下测试五个端口。  

Needed 153 reads 0 writes Oh oh, inconsistency at pos 9918 (0x26be).

Original sample:
00002680: e8 96 98 ef 5f 7b b9 12  a2 87 fc 53 50 35 7b da   ...._{.....SP5{.
00002690: e7 8c c9 46 59 15 42 84  a3 22 0f b8 19 a9 a7 60   ...FY.B..".....`
000026a0: dc cf a0 47 e8 b1 38 78  94 b7 fe 61 4d 30 64 74   ...G..8x...aM0dt
000026b0: 97 d4 cb 67 13 1f 83 a2  88 1f 2b b3 b8 67 90 04   ...g......+..g..
000026c0: 5d 34 09 1b c5 fd 10 00  fc 46 51 54 3b 92 70 1b   ]4.......FQT;.p.
000026d0: b6 a3 43 44 f3 2f df af  09 f8 33 dc c0 2e 7f 6e   ..CD./....3....n

Received sample:
00002680: e8 96 98 ef 5f 7b b9 12  a2 87 fc 53 50 35 7b da   ...._{.....SP5{.
00002690: e7 8c c9 46 59 15 42 84  a3 22 0f b8 19 a9 a7 60   ...FY.B..".....`
000026a0: dc cf a0 47 e8 b1 38 78  94 b7 fe 61 4d 30 64 74   ...G..8x...aM0dt
000026b0: 97 d4 cb 67 13 1f 83 a2  88 1f 2b b3 b8 67 04 5d   ...g......+..g.]
000026c0: 34 09 1b c5 fd 10 00 fc  46 51 54 3b 92 70 1b b6   4.......FQT;.p..
000026d0: a3 43 44 f3 2f df af 09  f8 33 dc c0 2e 7f 6e a8   .CD./....3....n.
loops 3991 / 2786918

spend 913 s
Needed 157 reads 0 writes loops 3994 / 2786918
[  987.251592] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:00] driver [SMSC LAN8710/LAN8720] (irq=POLL)
Needed 155 reads 0 writes loops 4004 / 2786918
[  989.367907] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:00] driver [SMSC LAN8710/LAN8720] (irq=POLL)

尊敬的 Jie：

代码块似乎不知何故弄错了、但我可以看到 RX 在日志第 4 行中丢失了一个字节。

这是我在测试中看到的完全相同的问题,原因是 serialcheck.cc 中的设计缺陷 它使用单个线程执行 RX 和 TX（但我们的解决方法是分别在仅 Rx 和仅 TX 模式下并行运行两次）、但 RX 例程仍然会接收整个数据文件（在测试中的 binary_1W_ttySx）、并与原始文件进行数据不匹配比较。 在比较期间、RX 被阻止、可能会发生数据丢失。

在实际情况下、不应出现这种情况。 UART 用户空间应用应设计为能够足够快地使用 RX 数据、以便内核 TTY 层中的 RX 缓冲区不会溢出。

为避免此序列检查测试中的数据丢失、您可以执行以下操作

-减小数据文件的大小,使 RX 数据比较花费很少的时间;

-或者暂停 TX 一小段时间,给 RX 时间进行数据比较。 我使用以下补丁进行了测试、它还解决了数据丢失问题。 不过、您可能必须调整测试的暂停时间。

diff --git a/serialcheck.c b/serialcheck.c
index f3161cc26a3d..32f596d0965b 100644
--- a/serialcheck.c
+++ b/serialcheck.c
@@ -389,6 +389,10 @@ static int stress_test_uart_once(struct g_opt *opts, int fd, unsigned char *data
                print_hex_dump(cmp_data + min_pos, max_pos - min_pos, min_pos);
                return -1;
        }
+
+       /* pause TX for 100ms waiting for RX to finish memcmp() */
+       if (opts->mode & MODE_TX_ONLY)
+               usleep(100000);
        return 0;
 }

您好、bin

尊敬的 Jie：

如上所述、在传输整个数据文件后添加暂停是解决 RX 路径上串行检查程序中设计缺陷的方法之一。 在您的实际场景中、由于所有 UART 都没有硬件流控制、因此 RX 例程必须确保足够快地从 TTY 缓冲区读取数据、以避免数据溢出。

我将减小数据文件的大小以进行测试。

是的、这应该是更好的测试方法、因为在实际情况下、TX 可能不会停止传输。

您好 Bin、

	if (atomic_read(&port->buf.mem_used) > port->buf.mem_limit) { 
		WARN_ONCE(1, "Memory limit exceeded: used=%d, limit=%d\n",
              atomic_read(&port->buf.mem_used), port->buf.mem_limit);
		return NULL;
	}

尊敬的 Jie：

您能否应用以下内核补丁来减少 RX FIFO 水线、看看它是否解决了数据丢失问题？

diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 0dd68bdbfbcf..a9306c5fedf7 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -87,7 +87,7 @@
 #define OMAP_UART_TX_WAKEUP_EN (1 << 7)
 
 #define TX_TRIGGER     1
-#define RX_TRIGGER     48
+#define RX_TRIGGER     32
 
 #define OMAP_UART_TCR_RESTORE(x)       ((x / 4) << 4)

我将查看是否可以在 SK 上启用更多 UART 端口来进行测试。 我现在启用了 3 个 UART。

修改 RX FIFO 阈值也可能导致数据包丢失

尊敬的 Jie：

感谢您的更新。

我将调试 EVM 上的问题以了解一个字节如何丢失。 我会让你保持发布。

尊敬的 Jie：

您是否仍在测试中使用 RT Linux？ 之前的 e2e 线程提到 RT Linux 对该问题没有帮助、但之前的测试 在序列检查程序中使用了'-m d'。 现在、由于测试已经使用两个单独的 seriallcheck 程序（分别用于 TX 和 RX）进行了更新、因此我想检查您是否仍使用 RT Linux 进行测试。

当使用串行检查或任何其他程序进行 UART 外部环回测试时、在同一 UART 端口上发送和接收相同数量的数据。  但在实际用例中、UART 通常仅在其中一个方向 (RX 或 TX) 上有大量数据。 您项目中的 UART 是发送和接收相似数量的数据、还是仅在一个方向上？ 我想知道您在工程中看到了什么确切的 UART 问题、而不是序列检查环回测试。

尊敬的 Jie：

您能否回答 Bin 的查询?

此致

Ashwani

尊敬的 Jie：

您是否仍在测试中使用 RT Linux？ 之前的 e2e 线程提到 RT Linux 对该问题没有帮助、但之前的测试 在序列检查程序中使用了'-m d'。 现在、由于测试已经使用两个单独的 seriallcheck 程序（分别用于 TX 和 RX）进行了更新、因此我想检查您是否仍使用 RT Linux 进行测试。

当使用串行检查或任何其他程序进行 UART 外部环回测试时、在同一 UART 端口上发送和接收相同数量的数据。  但在实际用例中、UART 通常仅在其中一个方向 (RX 或 TX) 上有大量数据。 您项目中的 UART 是发送和接收相似数量的数据、还是仅在一个方向上？ 我想知道您在工程中看到了什么确切的 UART 问题、而不是序列检查环回测试。

我已解锁此主题、因此您可以回答我的问题。

尊敬的 Bin：
在不使用-m d 选项的情况下、在 RT 内核上执行 serialcheck 程序时会出现数据包丢失。  结果甚至比使用 Linux 测试更糟糕, 在更短的时间内丢失数据,并导致序列检查崩溃。

./serialcheck_comen -b 115200 -d /dev/ttyS3 -f ./binary_1w_ttyS3 -l 696729 -m r &
./serialcheck_comen -b 460800 -d /dev/ttyS4 -f ./binary_1w_ttyS4 -l 2786918 -m r &
./serialcheck_comen -b 460800 -d /dev/ttyS6 -f ./binary_1w_ttyS6 -l 2786918 -m r &
./serialcheck_comen -b 460800 -d /dev/ttyS7 -f ./binary_1w_ttyS7 -l 2786918 -m r &
./serialcheck_comen -b 460800 -d /dev/ttyS8 -f ./binary_1w_ttyS8 -l 2786918 -m r & 

./serialcheck_comen -b 115200 -d /dev/ttyS3 -f ./binary_1w_ttyS3 -l 696729 -m t &
./serialcheck_comen -b 460800 -d /dev/ttyS4 -f ./binary_1w_ttyS4 -l 2786918 -m t &
./serialcheck_comen -b 460800 -d /dev/ttyS6 -f ./binary_1w_ttyS6 -l 2786918 -m t &
./serialcheck_comen -b 460800 -d /dev/ttyS7 -f ./binary_1w_ttyS7 -l 2786918 -m t &
./serialcheck_comen -b 460800 -d /dev/ttyS8 -f ./binary_1w_ttyS8 -l 2786918 -m t & 

您好 Joe、

在不使用-m d 选项的情况下、在 RT 内核上执行序列检查程序时、会出现数据包丢失的情况。

您能否分享数据丢失的日志？

此外、我还尝试从 AM62 上的其他平台运行串行端口应力测试程序、并且还会发生数据包丢失的情况。

AM62 上的其他平台意味着什么？ 不同的 AM62 板？

timeout, RX/TX: 9999/10000
Needed 39 reads 1 writes Oh oh, inconsistency at pos 5759 (0x167f).

Original sample:
00001640: db f3 47 95 05 ff fc 57  0f 1f fd b6 93 a0 7f 19   ..G....W........
00001650: 6c 9e 6a 44 cc 80 66 d7  24 5c 4e f0 05 d1 3e a1   l.jD..f.$\N...>.
00001660: a5 f2 f8 c3 ed d4 6f 8d  64 c2 54 94 cb ca 8d c7   ......o.d.T.....
00001670: 78 81 b3 ee ed 87 c5 78  36 3e dd 57 1f 6b 85 3f   x......x6>.W.k.?
00001680: 12 be c9 33 de 09 dc 77  dd b8 ee 84 3e e5 93 32   ...3...w....>..2
00001690: 9d 29 bb 1f 8e 68 aa f5  27 60 cb d4 80 b0 7a 01   .)...h..'`....z.

Received sample:
00001640: db f3 47 95 05 ff fc 57  0f 1f fd b6 93 a0 7f 19   ..G....W........
00001650: 6c 9e 6a 44 cc 80 66 d7  24 5c 4e f0 05 d1 3e a1   l.jD..f.$\N...>.
00001660: a5 f2 f8 c3 ed d4 6f 8d  64 c2 54 94 cb ca 8d c7   ......o.d.T.....
00001670: 78 81 b3 ee ed 87 c5 78  36 3e dd 57 1f 6b 85 12   x......x6>.W.k..
00001680: be c9 33 de 09 dc 77 dd  b8 ee 84 3e e5 93 32 9d   ..3...w....>..2.
00001690: 29 bb 1f 8e 68 aa f5 27  60 cb d4 80 b0 7a 01 3f   )...h..'`....z.?
loops 9832 / 2786918

spend 2265 s