[参考译文] AM625：tispl 下载 u-boot

嗨、Huy、

下载时间不受设备类型的影响。 我目前在 EVM 上没有 GP 器件、只有 HS/EVM 器件、FS 因此无法测试 GP 构建。 我将在这里找到一个进行测试的工具。

此致、

Schuyler

嗨、Huy、

我对8.6 SDK 与我们在这里使用的9.1进行了比较。 tftpboot 过程中的版本之间存在显著差异。 自2021年版本以来、U-Boot 有两个版本、tftp 性能得到了显著提高。 以下是一些比较结果：

• 8.6.
  • 已使用基本 SDK eth 引导配置
  • 仅加载 u-boot 需要超过38秒的时间
  • 从 EVM 获取 IP 地址确认会丢失10秒以上
    • 在 tispl.bin 下载和 u-boot.img 之间的延迟是5-6秒。
  • 由于(假设)错过了数据包接收、tftp 超时丢失了几秒钟。   
• 9.1.
  • 已使用基本 SDK eth 引导配置
  • 需要13秒的时间来加载 u-boot 映像
    • 这里最大的延迟是 u-boot 花费在执行 PHY 的自动协商设置方面的时间、每次下载 tispl.bin 和 u-boot.img 映像的时间约为5秒。
  • IP 地址分配过程大约耗时一秒钟、而不是像8.6那样用5-6
  • 在我进行的有限测试运行中未看到任何数据包超时。 (这是 tftp 喂料器接收期间 T 出现的地方。)

两个 SDK 版本测试是在隔离网络上使用相同的 Ubuntu PC 和 TI EVM 完成的、它们是直接相互连接的。

我需要强调的是,这其中很大一部分取决于 tftp 服务器的反应方式。 这里的 Ubuntu 服务器是可靠的。 因此、我们建议将性能升级到最新的 U-boot。

此致、

Schuyler

您好 TI 专家、

更新到 SDK 9.x 对我们来说有风险、因为我们需要更新其他相关驱动程序。
那么、您能否创建从 SDK 9.x 更改为8.6的反向端口？

谢谢、 此致、

嗯

Unknown 说：

在修复 spl.bin 的超时后,以减少4个错误帧的超时,但它已经减慢了在 uboot 加载内核映像的速度,
因此、是否有办法可以缩短 u-boot 在 tispl.bin 处的加载时间、并且不会影响 u-boot 处的内核映像加载？

Hello Huy、您可以使用修改后的超时值构建 tispl.bin 和 u-boot.img、从而减少4个错误帧的超时、请使用从此更改构建的 tispl.bin。 然后、撤销这些更改并使用 u-boot.img build 而不进行更改、这不会影响 u-boot 上内核映像的加载。

您好 Chintan：  

我刚刚修复了 SBL 中的超时、但没有缩短下载时间、

前4个错误帧似乎会使 tftp 服务器响应缓慢、并影响 uboot 下载其他文件、因此它在 SBL 中有所改进、但在 uboot 中速度较慢、因此这个超时调整工作周期没有改进、最佳解决方案仍然是将前4个帧全部解为0x0。

我想让你们检查一下 SPL 接收到的前4个帧是否都是0x0？
由于我检查了开发套件和定制电路板、因此打印日志没有理由会影响这一点、而在 Wireshark 日志上、还有一个点是向 Devkit 请求 IP 2次、电路板没有响应、这证明电路板没有接收到帧、或者由于数据错误而跳过、这与我登录时的第一个帧0x0相一致。
我希望你们能找到原因。

下图是您的日志、红色圆圈区域是异常点。

谢谢、

嗯

Hello Huy、您能否在此处分享以下详细信息：

1.用于为所连接的 DUT 提供 IP 地址的 DHCP 配置文件

2.系统和 DUT 之间的链路速度。

3.除了您正在使用的 DUT 和系统外、是否存在其它连接？

此致、

中国。

您好  Chintan：

我在下面为您分享信息：

1.此 DHCP 配置文件 e2e.ti.com/.../dhcpd.zip

2. 设置的 ETH 速度为100Mbps。

3、不、 我使用的系统只有通过 USB 连接到 DEV-KIT-EVM 的主机 PC (Ubuntu 18.4)。

如有任何问题、请告诉我。

谢谢、

嗯

Hello Huy、速度可能是传输文件时吞吐量低的原因。 此外、它还可能导致 DHCP 请求和响应期间超时。 您能否尝试1000Mbps、看看问题是否仍然存在？

您好  Chintan：

我们使用的定制电路板是 PHY TJA1101B、仅支持100Mbit/s 因此、增加1000Mbps 之后 、我们不再起作用

我们在 tiboot3.bin 加载 tispl.bin 和 tispl.bin 加载 u-boot.img 之间进行了比较。 使用 tiboot3.bin 加载 tispl.bin 时、tispl.bin 加载 u-boot.img 的速度要慢得多。

我们在 dev-kit 和定制板上有 printf 调试日志、 两个4帧参数都是0x0。

硬静态 IP。  因此、电路板不需要要求 DHCP 提供 IP、它会请求立即加载文件。  但前4个帧仍然是0x0、这就是导致4s 超时的原因。  

您能专注于前4个帧并将其修复吗？

谢谢、

嗯

Hello Huy、您能否提供两个阶段(即 R5和 A53)的完整日志和".config"文件？

此致、

中国。

您好  Chintan：  

日志 dev-kit： /cfs-file/__key/communityserver-discussions-components-files/791/test_5F00_devkit28_5F00_2_5F00_25.zip

日志定制电路板： /cfs-file/__key/communityserver-discussions-components-files/791/12.17.24_5F00_2.zip

使用 SDK 的默认值的 dev-kit i 配置文件

定制电路板配置文件：  

您可以在本文上面的备注部分查看其他日志。

谢谢、

嗯

您好  Chintan：  

发送了错误的配置、我将在此处重新发送它

配置文件定制电路板： e2e.ti.com/.../config_5F00_custom_5F00_2.zip

谢谢、

嗯

Hello Huy、感谢您提供配置文件、但我想生成的配置文件将在构建映像后生成。 如果您按照我们按照相同的步骤构建映像、则它将位于"/output_folder/r5/.config"和"/output_folder/a53/.config"中。

此致、

中国。

您好  Chintan：  

构建 here.e2e.ti.com/.../config_5F00_custom_5F00_3.zip 后的 Image configs 文件

谢谢、

嗯

Hello Huy、感谢您提供这些文件。 我已经完成了之前的回答。 我有几件事你应该尝试:

->您可以在配置文件中将 TFTPBLOCKSIZE 值设置为1468而不是65535、还可以使用最新版本中的 am62x_evm_a53_ethboot_defconfig。

->超时值为5000UL 而非1000UL。 根据您之前的日志、我可以看到传输"u-boot.img"期间发生超时。

->尝试清除 dhcplease 文件以避免收到 由于静态 IP 分配而在您的情况下不必要的 ARP 请求。

->最后：在速度为1000Mbps 的 TI AM62板上、尝试通过以太网以相同的映像引导、因为100Mbps 比我们遵循的数据低10倍、这可能会导致超时。 虽然在您的日志中、我可以看到速度是1000、但不确定这是否正确。

此致、

中国。

您好  Chintan：

我将定制电路板的日志发送到此处：  e2e.ti.com/.../log.14_5F00_4_5F00_2025.zip

尝试将超时更改为5且值 TFTPBLOCKSIZE = 1468之后  

我认为缩短下载时间没有任何变化。

在开发套件上、抱歉 出现了速度错误。 我们尝试了速度1000Mbps、前4个帧仍然是0x0。

谢谢、 Huy

您好 Huy、

在我看到您提供的日志后、我有一些疑问：

SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.5--v09.00.05 (Kool Koala)')
Switching: UART -> ETH RMII boot...
SPL initial stack usage: 13424 bytes
Trying to boot from eth device

为什么它显示了 ETH RMII 引导、而我们通过 Foundational_Components 端口1在 AM62x 上支持以太网引导、如此处的文档：https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/latest/exports/docs/linux/RGMII/U-Boot/UG-Network-K3.html 中所述

另外、我与您提供的日志感到困惑、在 Wireshark 日志中、我无法找到使用 Ethertype 0x0的数据包、尽管可以在调试打印中看到。

此致、

中国。

您好  Chintan：

"为什么它显示的是 ETH RMII 引导、而我们通过 RGMII 端口1在 AM62x 上支持以太网引导、如此处的文档所述："

=> TI 专门设计了我们、可通过 RMII 端口1支持 AM62x 上的 ETH 引导、 我们目前正在定制电路板上使用 RMII 引导。

"另外、我与您提供的日志感到困惑、在 Wireshark 日志中、我无法找到 Ethertype 0x0的数据包、尽管在调试打印中可以看到这些数据包。"

=> 在 Wireshark 中看不到它、因为这是接收到的前4个帧、而不是发送到服务器。
因此、要查看前4个帧是0x0、您在接收帧时需要在源代码中添加日志打印。
关于 Wireshark 中的分析、请查看我以红色突出显示的帧。
当服务器查询 IP 192.168.1.2的 MAC 地址时、在第5个 ARP 请求(以蓝色突出显示)之前、它没有收到来自 AM62x 电路板的响应
这与我之前打印的日志匹配。

您应再次阅读此主题、以清楚地了解此问题。

谢谢 Huy

您好 Huy、

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index f40ee1b28bc..5aefabb2a78 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -141,7 +141,7 @@ struct am65_cpsw_priv {
 #ifdef PKTBUFSRX
 #define UDMA_RX_DESC_NUM PKTBUFSRX
 #else
-#define UDMA_RX_DESC_NUM 4
+#define UDMA_RX_DESC_NUM 1
 #endif
 
 #define mac_hi(mac)    (((mac)[0] << 0) | ((mac)[1] << 8) |    \

您能否尝试在 am65-cpsw-nuss.c 驱动程序中进行此更改、看看使用 EtherType 0x0的帧是否减少到1？

此致、

中国。

您好  Chintan：

我尝试了更改作为您的补丁。  它仍然有4个帧= 0x0。 我在下面发送了您的日志

e2e.ti.com/.../17_5F00_4_5F00_2025.zip

谢谢、Huy

您好  Chintan：

我改变跟随你的补丁. 并更新 UDMA_RX_DESC_NUM =1的所有值

与之前相比、我看到了一些差异。

突出显示内容：减少到2、 电路板无响应

e2e.ti.com/.../17_5F00_4_5F00_2025_5F00_2.zip

谢谢 Huy

您好 Huy、

我正在研究为什么我们在服务器请求时没有从主板得到任何响应。 通过以下更改、您是否看到了与 EtherType 0x0相同的四个帧、或者它是否减少到一个错误帧(EtherType 0x0)？

此致、

中国。

您好  Chintan：

我看到一个使用 EtherType 0x0的帧出现故障。  

e2e.ti.com/.../17_5F00_4_5F00_2025_5F00_3.zip

谢谢、Huy

您好 Huy、

您可以进行以下更改、而不是将"UDMA_RX_DESC_NUM"更改为1、它将耗尽 RX 缓冲区内的所有数据包、并且您不会看到任何错误的帧。

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 9b69f36d04d..ba26c861e3f 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -494,7 +494,12 @@ static int am65_cpsw_send(struct udevice *dev, void *packet, int length)
       struct am65_cpsw_priv *priv = dev_get_priv(dev);
       struct am65_cpsw_common *common = priv->cpsw_common;
       struct ti_udma_drv_packet_data packet_data;
-      int ret;
+      uchar drain_rx_buffers[1530];
+      int ret = 0;
+
+      /* Drain existing packets */
+      while (ret==0)
+              ret = dma_receive(&common->dma_rx, (void **)&drain_rx_buffers, NULL);

       if (!common->started)
               return -ENETDOWN; 

此致、

中国。

您好  Chintan：

我尝试了更改作为您的补丁。 有2个帧= 0x0。

e2e.ti.com/.../17_5F00_4_5F00_2025_5F00_4.zip

谢谢、Huy

您好 Huy、

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index f40ee1b28bc..8ee6105b0a6 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -438,13 +438,26 @@ out:
        return ret;
 }
 
+static int am65_cpsw_free_pkt(struct udevice *dev, uchar *packet, int length);
+
 static int am65_cpsw_send(struct udevice *dev, void *packet, int length)
 {
        struct am65_cpsw_priv *priv = dev_get_priv(dev);
        struct am65_cpsw_common *common = priv->cpsw_common;
        struct ti_udma_drv_packet_data packet_data;
+       uchar drain_rx_buffers[1530];
        int ret;
 
+       /* Drain existing packets. In the presence of packets, the
+        * pkt_length is returned. When there are no packets, 'zero'
+        * is returned.
+        */
+       ret = dma_receive(&common->dma_rx, (void **)&drain_rx_buffers, NULL);
+       while (ret > 0) {
+               ret = am65_cpsw_free_pkt(dev, drain_rx_buffers, ret);
+               ret = dma_receive(&common->dma_rx, (void **)&drain_rx_buffers, NULL);
+       }
+
        packet_data.pkt_type = AM65_CPSW_CPPI_PKT_TYPE;
        packet_data.dest_tag = priv->port_id;
        ret = dma_send(&common->dma_tx, packet, length, &packet_data); 

这是一个基于 SDK 8.6的差异。

此致、

中国。

您好  Chintan：

我尝试了您的补丁、但我仍然看到零帧、

请查看 下面所附日志的详细信息：

e2e.ti.com/.../4_5F00_22_5F00_2025.zip

谢谢、Huy

您好 Huy、

您能否尝试将以下内容添加到用于以太网引导的 R5和 A53 defconfig 文件中？

CONFIG_SYS_RX_ETH_BUFFER=64

您好、 Siddharth

我已尝试 对 R5和 A53 defconfig 文件进行 CONFIG_SYS_RX_ETH_BUFFER=64配置、

它 仍然是零帧

请查看 下面所附日志的详细信息：

e2e.ti.com/.../4_5F00_23_5F00_2025.zip

谢谢、

嗯

您好 Huy、

因为仍然有 4. "零帧"并考虑到更新 UDMA_RX_DESC_NUM 最终目的 1. 已将"零帧"的数量减少到 1. 我觉得这是一种设置 CONFIG_SYS_RX_ETH_BUFFER=64 未生效。 它应有效地产生于的以下部分 am65-cpsw-nuss.c 正在使用的驱动程序：
#ifdef PKTBUFSRX
#define UDMA_RX_DESC_NUM PKTBUFSRX
和 CONFIG_SYS_RX_ETH_BUFFER 用于设置的值 PKTBUFSRX 在中：
Include/net-common.h
其中：
define PKTBUFSRX CONFIG_SYS_RX_ETH_BUFFER  

或者、您可以尝试更改吗 UDMA_RX_DESC_NUM 最终目的 64 与之前设置为时所做的更改类似 1. ？ 如果您开始看到、请告诉我 64 因此、"零帧"。 我想知道数据包是否被覆盖、或者问题是否出在其他地方。

此致、
Siddharth。

您好  Siddharth、

我配置了  UDMA_RX_DESC_NUM 为64、启动失败。  

谢谢、

嗯

您好 Huy、

请恢复 UDMA_RX_DESC_NUM 返回 4. 并应用以下 diff：

@@ -460,9 +473,13 @@ static int am65_cpsw_recv(struct udevice *dev, int flags, uchar **packetp)
 {
        struct am65_cpsw_priv *priv = dev_get_priv(dev);
        struct am65_cpsw_common *common = priv->cpsw_common;
+       int ret;
 
        /* try to receive a new packet */
-       return dma_receive(&common->dma_rx, (void **)packetp, NULL);
+       ret = dma_receive(&common->dma_rx, (void **)packetp, NULL);
+       if (!ret)
+               return -ENODATA;
+       return ret;
 }
 
 static int am65_cpsw_free_pkt(struct udevice *dev, uchar *packet, int length)

您好  Siddharth、

我尝试了你的补丁程序,我给你下面的日志:

e2e.ti.com/.../4_5F00_23_5F00_2025_5F00_2.zip

谢谢、

嗯

您好 Huy、

请测试以下差异：

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index f40ee1b28bc..4f03f6c26ec 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -282,6 +282,8 @@ static void am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv *priv,
                        mode, reg);
 }
 
+static int am65_cpsw_free_pkt(struct udevice *dev, uchar *packet, int length);
+
 static int am65_cpsw_start(struct udevice *dev)
 {
        struct eth_pdata *pdata = dev_get_platdata(dev);
@@ -290,6 +292,7 @@ static int am65_cpsw_start(struct udevice *dev)
        struct am65_cpsw_port *port = &common->ports[priv->port_id];
        struct am65_cpsw_port *port0 = &common->ports[0];
        struct ti_udma_drv_chan_cfg_data *dma_rx_cfg_data;
+       uchar drain_rx_buffers[1530];
        int ret, i;
 
        ret = power_domain_on(&common->pwrdmn);
@@ -338,6 +341,12 @@ static int am65_cpsw_start(struct udevice *dev)
                goto err_dis_tx;
        }
 
+       ret = dma_receive(&common->dma_rx, (void **)&drain_rx_buffers, NULL);
+       while (ret > 0) {
+               ret = am65_cpsw_free_pkt(dev, drain_rx_buffers, ret);
+               ret = dma_receive(&common->dma_rx, (void **)&drain_rx_buffers, NULL);
+       }
+
        /* Control register */
        writel(AM65_CPSW_CTL_REG_P0_ENABLE |
               AM65_CPSW_CTL_REG_P0_TX_CRC_REMOVE |

您好  Siddharth、

我已将以下日志发送给您。 请检查它

e2e.ti.com/.../4_5F00_24_5F00_2025.zip

谢谢、

嗯

您好 Huy、

您可以在中启用调试日志吗 net/net.c 和 net/tftp.c 指定 tispl.bin 并共享日志？

此致、
Siddharth。

您好  Siddharth、

我net/net.c通过添加启用了调试日志#define DEBUG_NET_PKT 1、并net/tftp.c通过替换debug()为启用了中的调试日志printf()。

下面是完整日志：

e2e.ti.com/.../4_5F00_24_5F00_2025_5F00_2.zip

谢谢、

嗯

您好  Siddharth、

您对此问题有任何更新吗？

谢谢、

嗯

您好 Huy、

您可以尝试以下 diff 并共享与其对应的日志吗？ 以下比较将用于在配置和启用主机端口之后以及在编程了 RX Flow ID 之后将 am65_cpsw_start ()函数中的数据包溢出段移动到一个位置：

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index f40ee1b28bc..0d57dd7e82e 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -282,6 +282,8 @@ static void am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv *priv,
 			mode, reg);
 }
 
+static int am65_cpsw_free_pkt(struct udevice *dev, uchar *packet, int length);
+
 static int am65_cpsw_start(struct udevice *dev)
 {
 	struct eth_pdata *pdata = dev_get_platdata(dev);
@@ -290,6 +292,7 @@ static int am65_cpsw_start(struct udevice *dev)
 	struct am65_cpsw_port *port = &common->ports[priv->port_id];
 	struct am65_cpsw_port *port0 = &common->ports[0];
 	struct ti_udma_drv_chan_cfg_data *dma_rx_cfg_data;
+	uchar drain_rx_buffers[1530];
 	int ret, i;
 
 	ret = power_domain_on(&common->pwrdmn);
@@ -373,6 +376,13 @@ static int am65_cpsw_start(struct udevice *dev)
 	writel(AM65_CPSW_ALE_DEFTHREAD_EN,
 	       common->ale_base + AM65_CPSW_ALE_THREADMAPDEF_REG);
 
+	ret = dma_receive(&common->dma_rx, (void **)&drain_rx_buffers, NULL);
+	while (ret > 0) {
+		dev_err(dev, "draining packet\n");
+		ret = am65_cpsw_free_pkt(dev, drain_rx_buffers, ret);
+		ret = dma_receive(&common->dma_rx, (void **)&drain_rx_buffers, NULL);
+	}
+
 	/* PORT x configuration */
 
 	/* Port x Max length register */

此致、
Siddharth。

您好  Siddharth、

我看不到任何重大变化。

请查看以下日志：

e2e.ti.com/.../5_5F00_12_5F00_2025.zip

谢谢、

嗯

您好 Huy、

您能尝试启用一下吗 CONFIG_KEEP_SERVERADDR ？

此致、
Siddharth。

您好  Siddharth、

便启用了 I enabled  CONFIG_KEEP_SERVERADDR、

这是它的日志： e2e.ti.com/.../5_5F00_13_5F00_2025.zip

谢谢、

嗯

您好 Huy、

在 include/net.h 中、能否增加的值 ETH_PACKETS_BOTK_RECV 从32到36？ 此更改将帮助我们了解调用 eth_rx ()时接收的4个0x0数据包是否是来自上一个事务的数据包。 如果进行此更改、请检查并告诉我您是否仍看到4个0x0数据包。

此致、
Siddharth。

您好  Siddharth、

我仍然看到4个0x0数据包。

是否需要完整日志？

谢谢、

嗯

您好 Huy、

感谢您对其进行测试并共享日志。 您可以测试以下差异吗？

diff --git a/net/tftp.c b/net/tftp.c
index 6fdb1a821a8..cc998ee203e 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -879,6 +879,9 @@ void tftp_start(enum proto_t protocol)
        tftp_tsize_num_hash = 0;
 #endif
 
+       /* Drain existing packets */
+       eth_rx();
+
        tftp_send();
 }

上面的 diff 将让我们知道0x0帧是在响应 tftp_send ()数据包中看到的还是在 tftp 启动之前接收到的。

此致、
Siddharth。

您好  Siddharth、

这是它的日志。

谢谢、

嗯