[参考译文] AM625：以太网备用引导模式

我应该提到,我使用 am62x_evm_r5_ethboot_defconfig& am62x_evm_a53_ethboot_defconfig 与改变使用米雷尔 Phys.

我还phy-mode=rmii 根据电路板布线修改了 DTS/DTSI 文件、将和 phy 地址设置为1和3。

您好 Neil、

主题所有者在接下来的几天内不在办公室。 如果您在下周中未收到回复、请随时 ping 通该问题。

此致、

Nick

Unknown 说：

开机时、我可以看到 tiboot.bin 的初始 TFTP 工作、SPL 会执行。

因此 tiboot3.bin 加载成功、u-boot 运行后、BOOTP 广播就不起作用了？ 我还假设以太网端口工作正常、如果您以其他方式引导。  

能否附加 Wireshark 数据包捕获流量？ 要么是 Wireshark、tcpdump、要么是更好的丝锥、如 Profishark。 tiboot3.bin 加载是否成功。

您使用哪个软件作为 DHCP 和 BOOTP 服务器？

 Pekka

嗨、Pekka、

谢谢。 如果我从 SD 或 eMMC 引导、以太网工作正常。

我正在使用标准 Ubuntu DHCP/BOOTP 安装。

当我在论坛上确定如何执行此操作时、我会附上 Wireshark 捕获。

嗨、Pekka、

PCAP 已连接。

e2e.ti.com/.../5460.AM62x_2D00_tftp1.pcapng.zip

谢谢,所以您的服务器是 IP 地址10.0.0.1, MAC 地址  C8:A3:62:2c:3D:8c。 AM625的 IP 地址为10.0.0.5、MAC 地址为 04：25：e8：3d：9d：15
快速浏览一下、ROM 器件可以正确加载 tiboot3.bin、而不会出现任何问题：

在大约一秒钟内完成后、 5秒内没有帧、6秒时、C8：A3：62：2c：3D：8c 会发送 ARP 请求以询问 IP 地址10.0.0.5在哪里

从一开始、 C8：A3：62：2c：3D  ：8c 给出04:25：e8：3D：9d：15 IP 地址10.0.0.5、但6秒后的第1215帧发出 ARP 请求、要求谁拥有10.0.0.5 (复制如下)、即使前一帧刚刚发送到10.0.0.5。

1215 6.011378538 C8：A3：62：2c：3D：8c 广播 ARP 42谁拥有10.0.0.5？ 告诉10.0.0.1

我没有看到来自04:25:e8:3D:9d:15的 BOOTP 消息,因此不清楚 Ubuntu 机器为什么会尝试向10.0.0.5发送内容。 但是、它应该已经有 MAC 地址、所以它为什么要发送 ARP 请求。

您是如何捕获瓶盖的？ 我想有些帧没有显示？ 还要检查的是 MAC 地址 04：25：e8：3d：9d：15 是一个 TI OUI 编号(由 ROM 使用)、您是否在 u-boot 中使用自己的 AM625重新编程 MAC 地址？

 Pekka

 04：25：e8是 TI OUI、我们不会对地址进行重新编程。

我假设服务器是 ARPing、因为最后一个 TFTP 数据包未被 ROM 代码删除。

我将重点介绍第1214帧之后的情况、到目前为止一切似乎都很好、包括交付的最后一个帧。 我同意在最后一个帧的捕获中没有确认、这似乎很奇怪。 控制台打印输出看起来像是 u-boot 仍然能够启动。 您总是看不到、而是盯着最后一帧。 从 ROM 中的确认应在 u-boot 启动之前发出。 因此、在 ACK 退出之前、tiboot3.bin 会进行身份验证并以某种方式运行、包括 PHY 自动协商、从而阻止任何以太网正常工作(包括 tiboot3.bin 甚至开始运行之前由 ROM 发送的确认)。

是使用有线分路器捕获、还是使用 tcpdump 从 Ubuntu 计算机捕获？

接口中是否有任何错误计数器？

 Pekka

数据包捕获来自服务器上的 Wireshark。

在多次下电上电后、我未看到 AM62对最后一个 TFTP 数据包进行 ACK。

该接口没有显示以太网错误计数。

您通过以太网加载的 tiboot3.bin 文件、它是否与您在 SD 卡引导中使用的文件完全相同？ 一种理论是,它不是正确的版本,如果签名验证失败,它看起来似乎什么也没有发生。

 Pekka

它与用于生成它的 defconfig 不完全相同、它是  am62x_evm_r5_ethboot_defconfig

SD 卡引导使用 am62x_evm_r5_defconfig 生成 tiboot3.bin 文件

为什么最后一个 TFTP 数据包未被确认是我认为第一件事情出错了。 TFTP 服务器发送数据包后、似乎没有任何以太网帧。 这将是很好的验证与网络线缆抽头,如 Profishark。

tiboot3.bin 文件看起来确实很大>1200个大小为~500Bytes 的数据包、因此大约有600kB 的数据包。 我检查了一个与 AM62x 配合使用的 tiboot3.bin、看起来像~290kB。 我想知道这是否会导致一些问题、并且不适合引导 ROM 放置它的位置。 您能否确认 tiboot3.bin 的大小与此相符？

最后一个角度是 RMII 与 RGMII、在 TI EVM 上、我们始终使用基于 RGMII 的 PHY (使用特殊的限量板对 RMII 进行验证)、因此 RMII 和引导 ROM 必须有某种独特的功能、以某种方式显示为最后一个数据包没有 ACK。

您能否确认此打印输出来自您生成的文件、并且必须通过 TFTP 进行？ 因此必须位于未发送确认的 tiboot3.bin 文件中？

分配到该区域的专家将在星期一回来,所以预计几天的延迟,因为她上升.

 Pekka

Hi Pekka,

tiboot3.bin is approx 309KB

ll /tftpboot/tiboot3.bin
-rw-rw-r-- 1 neil neil 309342 Mar 28 13:26 /tftpboot/tiboot3.bin

The file (I rebuilt it) today contains that string:

strings /tftpboot/tiboot3.bin | rg dirty
U-Boot SPL 2024.04-00002-gbaa288e477f-dirty (Mar 28 2025 - 13:26:11 +0000)

RMII is listed as one of the backup ethernet boot modes in the AM62x TRM.

Thanks.

Neil

您好、是否对此问题进行了更新？

谢谢

您好 Neil、

Unknown 说：

我正在使用标准 Ubuntu DHCP/BOOTP 安装。

您正在使用哪个 TFTP 服务器(例如 xinetd、tftp-hpa 等)？

您能否分享 ISC-DHCP-server /etc/dhcp/dhcpd.conf 文件包含的内容？ 具体而言、我想检查您是否为每个 U-boot 二进制文件输入了正确的供应商类标识符。

此外、您能否说明这是否是使用 SDK 10.1进行的测试？ 您是否能够测试以太网引导以便在 AM62x TI EVM 上正常工作？

-道林

尊敬的 Daolin：

1.我使用 xinetd

2. DHCP 配置如下,但我在以太网输出上看不到 BOOTP :  

subnet 10.0.0.0 netmask 255.0.0.0
{
range dynamic-bootp 10.0.0.2 10.0.0.16;
if substring (option vendor-class-identifier, 0, 16) = "TI K3 Bootp Boot"
{
filename "tiboot3.bin";
} elsif substring (option vendor-class-identifier, 0, 24) = "AM62X U-Boot R5 SPL"
{
filename "tispl.bin";
} elsif substring (option vendor-class-identifier, 0, 25) = "AM62X U-Boot A53 SPL"
{
filename "u-boot.img";
}

range 10.0.0.17 10.0.0.25;
default-lease-time 60000;
max-lease-time 720000;
next-server 10.0.0.1;
}

3.我目前使用的是 SDK 版本10.0.07.04  

4.我使用 SK-AM62-LP EVM 将以太网引导视为主引导工作

我现在在我们自己的套件中看到的这个问题是针对以太网备用引导。

此致

Neil

您好 Neil、

感谢您分享这些详细信息。

我注意到您的 DHCP 配置似乎没有任何具体问题。  

您是否还能分享您的" am62x_evm_r5_ethboot_defconfig" and "am62x_evm_a53_ethboot_defconfig" are?

Unknown 说：

我现在在我们自己的套件中看到的这个问题是用于以太网备份引导。

您提到了当以太网用作定制电路板的备用引导时会观察到此问题、当以太网用于主引导模式时、您是否会看到同样的问题？

-道林

尊敬的 Daolin：

defconfig 已连接-我将 EVM 用作基础。

我看到为以太网配置的电路板与主引导模式具有相同的行为。

此致

Neil

e2e.ti.com/.../8080.Archive.zip

我将尝试另一个电路板、这样我就可以更轻松地到达引导模式电阻器。

由于我下周要到办公室工作、 我的答复将被推迟。

您好 Neil、

我有两个建议：

1.将"AM62X U-Boot R5 SPL"字符串的 DHCP 配置供应商类标识符从"24"更改为"19"、将"AM62X U-Boot A53 SPL"字符串的 DHCP 配置从"25"更改为"20"、类似于下面的 DHCP 配置。

2.增加 DHCP 配置中列出的 IP 地址范围,您可以使用下面的 DHCP 配置作为参考。

subnet 192.168.0.0 netmask 255.255.255.0
{
range dynamic-bootp 192.168.0.2 192.168.0.30;
if substring (option vendor-class-identifier, 0, 16) = "TI K3 Bootp Boot"
{
filename "tiboot3.bin";
} elsif substring (option vendor-class-identifier, 0, 19) = "AM69 U-Boot R5 SPL"
{
filename "tispl.bin";
} elsif substring (option vendor-class-identifier, 0, 20) = "AM69 U-Boot A72 SPL"
{
filename "u-boot.img";
}
range 192.168.0.31 192.168.0.63;
default-lease-time 60000;
max-lease-time 30;
next-server 192.168.0.1;
}

此外、您能否分享 AM625芯片上刻录的确切器件型号？ 我想检查这是 GP 还是 FS 器件。

-道林

尊敬的 Daolin：

AM6232A SCGHAALW 45P053S

您好 Neil、

感谢您很快分享、这似乎是 FS 器件。 在构建 U-Boot 二进制文件(tiboot3.bin、tispl.bin、u-boot.img)时、您是否确保使用 hs-fs 版本而不是 gp 版本？

Unknown 说：

1.将"AM62X U-Boot R5 SPL"字符串的 DHCP 配置供应商类标识符从"24"更改为"19"、将"AM62X U-Boot A53 SPL"字符串的 DHCP 配置从"25"更改为"20"、类似于下面的 DHCP 配置。

2.增加 DHCP 配置中列出的 IP 地址范围,您可以使用下面的 DHCP 配置作为参考。

[/报价]

当您有机会时、请告诉我这是否会改变您观察到的问题。

-道林

尊敬的 Daolin：

我很抱歉,由于英国的假期,在回答这一问题时出现了延误。

如上所建议的 DHCP 配置更改不会导致任何不同的行为。

我设法修改了电路板上的引导电阻器、使以太网作为主引导模式、我看到的行为与备用引导模式相同。

我恢复了 DHCP 配置更改并重新验证了 SK-AM62-LP 评估板可以使用我的 DHCP/TFTP 服务器正确引导。

您能否通过 AM62x 确认 TI 是否能够将 RMII 用作主引导模式或备用引导模式的 PHY 类型？

此致

Neil

您好 Neil、

Unknown 说：

您能否确认 TI 是否能够将 RMII 用作 AM62x 的主引导或备用引导模式的 PHY 类型？

尽管 TRM 中将带 RMII 的以太网引导列为引导选项、但据我所知、我们还没有专门测试 RMII 以太网引导、因为我们的 AM62x SK-EVM 默认都使用 RGMII 接口模式。  

Unknown 说：

我已恢复 DHCP 配置更改并重新验证 SK-AM62-LP 评估板是否可以使用我的 DHCP/TFTP 服务器正确引导。

据我了解、SK-AM62-LP 默认使用 RGMII。  

user4068379 说：

i not view the BOOTP messages from 04:25:e8:3d：9d：15

U-Boot SPL 2024.04-00002-gbaa288e477f-dirty (Mar 27 2025 - 09:38:30 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
SPL initial stack usage: 13392 bytes
Trying to boot from eth device
ethernet@8000000port@1 connected to Micrel KSZ804 mode rmii
eth0: ethernet@8000000port@1
ethernet@8000000port@1 Waiting for PHY auto negotiation to complete..... done
link up on port 1, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17

Retry time exceeded; starting again
udma_stop_mem2dev: peer not stopped TIMEOUT !
Problem booting with BOOTP
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

回顾 Wireshark 捕获和控制台日志、我看到您的电路板看起来正在发送 BOOTP 请求、但 Wireshark 不会在主机 PC 端显示接收到这些请求。 您是否能够通过常规传输测试来测试您的 RMII 接口？ 即、没有以太网引导、只需完全启动您的器件、通过以太网连接到主机、然后进行 ping 或 iperf 测试(如果使用 Linux)并查看主机上是否没有收到损坏的数据包？ 如果主机是 Linux PC、则可以在主机上使用"ethtool -S <interface name"进行检查。

-道林

您好 Neil、

我可以从日志中看到、您的主板无法从 DHCP 服务器获取 IP 地址。 您能否将 DHCP 配置保留为原始配置并清除 dhcp.relates 文件中阻止了之前分配的 IP 地址的所有条目、然后重新启动 DHCP 服务器并重试。 如果您不想清除 dhcp.reactions 文件,您可以将"range dynamic-BOOTP 10.0.0.2 10.0.0.0.0.0.16"行更新为"range dynamic-BOOTP 10.0.0.2 10.0.0.0.60",再次重启您的 DHCP 服务器并尝试引导,同时为了避免此问题在将来更新"最大租赁时间"值为较低值时,我保留"10"用于我的 DHCP 服务器。

此致、

中国。

当我将电路板从 SD 卡引导到 u-boot 或 Linux 时、我可以顺利地使用以太网接口。

SSH、TFTP 等均按预期工作。

我只是在 RMII 中看到了这些问题的引导模式。

尊敬的 Chintan：DHCP 没有故障、BOOTP 数据包没有在以太网上生成。

tiboot3.bin 的 TFTP 访问可以从 ROM 正常工作、但随后访问 tispl.bin 的 BOOTP 无法传输。

您好 Neil、
以太网在 SD 引导中工作正常、因为在 SD 引导的 SPL 阶段未启用 CPSW、但如果我们要通过以太网引导、则需要在 SPL 阶段初始化 CPSW。

此致、
中国。

您好 Neil、

若要在 tiboot3.bin 成功执行后下载 tispl.bin、我们需要再次从 DHCP 服务器获取 IP 地址、这就是电路板向服务器请求 IP 地址的原因。 在 Wireshark 日志中、我们可以看到服务器正在广播"谁有192.168.0.5"、这是在获取 tiboot3.bin 文件时被董事会获取的、此后未发布。此外、我怀疑您提供的范围内的所有 IP 地址都是获取的、而不是发布的、这就是为什么 DHCP 服务器不提供 BOOTP 请求的原因。 你能尝试一下我问的是什么吗?

此致、
中国。

你好、Chintan、没有任何区别。

我认为问题不在于服务器。

我认为来自服务器的 ARP 是因为最后一个 TFTP 数据包没有被 ROM 代码占用。

这使得服务器认为客户端已消失、并尝试再次找到它。

tiboot3输出：

U-Boot SPL 2024.04-00002-gbaa288e477f-dirty (2025年3月28日- 16：05：56 +0000)
SYSFW ABI：4.0 (固件版本0x000a '10.0.8--v10.00.08 (Fiery Fox)')
尝试从 eth 器件引导
以太网@8000000port@1连接至通用 PHY 模式 RMII
eth0：以太网@8000000port@1
以太网@8000000port@1等待 PHY 自动协商完成… 已完成
在端口1、速度100、全双工上建立链路
BOOTP 广播1
BOOTP 广播2.
BOOTP 广播3.
BOOTP 广播4.
BOOTP 广播5.
BOOTP 广播6.
BOOTP 广播7.
BOOTP 广播8.
BOOTP 广播9.
BOOTP 广播10.

您好 Neil、

您能否以 zip 格式提供以下文件：

1) DHCP 配置文件：dhcpd.conf

2)您的 DHCP 租约文件：dhcpd.relatives

此致、

中国。

e2e.ti.com/.../3757.Archive.zip

您好、chintan、附件 zip 文件。 谢谢

您好 Neil、

感谢您分享附加的文件。 Chintan 下周将不在办公室、因此我将支持这一问题。  

我查看了工作正常的以太网引导(使用 RGMII)的 Wireshark 和控制台日志、以与您共享的 Wireshark 和控制台日志进行比较。  

1.您的 AM625板无法绑定到 DHCP 分配的地址。 请参阅下面的控制台日志、比较"BOOTP 广播"消息之后的预期内容

eth0: ethernet@8000000port@1
ethernet@8000000port@1 Waiting for PHY auto negotiation to complete....... done
link up on port 1, speed 1000, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
DHCP client bound to address 172.168.1.170 (1760 ms)
Using ethernet@8000000port@1 device
TFTP from server 172.168.1.1; our IP address is 172.168.1.170

2.类似 tiboot3.bin 最后一个数据包之后预期出现的数据包是 DHCP 数据包、根据我从工作中的以太网引导 Wireshark 捕获中看到的数据为 AM625板获取 IP 地址(如下所示)。  

您能否分享 问题发生后(在 tiboot3.bin 的最后一个数据包之后) ISC-DHCP-server 的状态？ 您可以使用"systemctl status isc-dhcp-server"。

-道林

尊敬的 Daolin：

问题  不在于 DHCP 请求失败、而是 BOOTP 数据包未在 RMII 上传输。

可以在控制台跟踪中看到 、但在 Wireshark 上看不到。

我一直在问- TI 是否证明了 RMII 引导模式可以与 AM62X ROM 正常工作？

我认为、我们一直在讨论服务器响应/配置的相同问题、但没有回答为什么 tiboot3.bin 的初始 TFTP 没有得到来自服务器的最后一个数据包的确认、以及为什么 BOOTP 帧没有被传输。

此致

Neil

Unknown 说：

我一直在问- TI 是否证明 RMII 引导模式可以与 AM62X ROM 正常配合使用？

RMII 已经过测试、但由于它未在任何评估板中使用、因此未在常规夜间测试或 SDK 版本中进行测试。 但从您的日志中、我们可以看到 ROM 部分已完成、tiboot3.bin 是使用 RMII 加载的。 问题是 ROM 后映像(tiboot3.bin)开始运行时。 在此阶段、AM625上的软件不会重复使用 ROM 代码执行的任何操作。

 Pekka

您好 Neil、

Unknown 说：

我认为我们一直在处理关于服务器响应/配置的相同问题、但没有回答为什么 tiboot3.bin 的初始 TFTP 对于来自服务器的最后一个数据包没有得到确认、以及为什么没有传输 BOOTP 帧。

正如我在上一个响应中所指出的、从以太网引导 Wireshark 捕获的正常运行来看、当控制台显示"BOOTP 广播"消息时、Wireshark 显示 DHCP 数据包。 我观察到 BOOTP 数据包仅在加载 tiboot3.bin 之前显示在 Wireshark 上。 之后、在加载 tispl.bin 之前、来自 DUT 的 BOOTP 请求不会显示(即使在进行正常的以太网引导 Wireshark 捕获时也是如此)。 相反、根据观察结果、应该在 Wireshark 上看到 DHCP 数据包、以获取 DUT 上的 IP 地址。 有关以太网引导 Wireshark 捕获的示例、请参阅下面的。  

此外、我观察到、即使在工作示例中、tiboot3.bin 的最终数据包也没有 TFTP 确认。

工作以太网引导 Wireshark 捕获： e2e.ti.com/.../am62x_5F00_working_5F00_eth_5F00_boot.pcapng

-道林

我发现 phy 上电后复位存在一个硬件问题- 我们的电路未实施推荐的方法、我现在已经解决了。

我确认 ROM + RMIItiboot3.bin 正在加载和执行中。

关于无法从传输任何数据包的问题、我应该寻找什么 tiboot3.bin？

我在 SPL 中放置了一些调试打印、可以看到这些打印 am65_cpsw_send udma_send内容并被调用。

数据看起来 合理：

ff ff ff ff ff ff 04 25 e8 3d 9d 0b 08 00 45 00 01 78 00 00 40 00 ff 11 7a 75 00 00 00 00 ff ff ff ff 00 44 00 43 01 64 00 00 01 01 06 00 e8 3d a4 f6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 25 e8 3d 9d 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 82 53 63 3c 13 41 4d 36 32 58 20 55 2d 42 6f 6f 74 20 52 35 20 53 50 4c 01 04 00 00 00 00 03 04 00 00 00 00 06 04 00 00 00 00 0c 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 

我应该寻找什么来帮助调试为什么没有发生传输？

谢谢你。

您好 Neil、

Unknown 说：

您能否分享  ISC-DHCP-server 在问题发生后(在 tiboot3.bin 的最后一个数据包之后)的状态？ 您可以使用"systemctl status isc-dhcp-server"。

根据与正常工作的以太网引导 Wireshark 捕获和引导日志的比较、似乎需要在发送 tispl.bin 数据包之前获取 IP 地址。 从您的 Wireshark 日志和控制台日志中、似乎没有为您的电路板分配 IP 地址。 我们首先要确保您的主机 PC 上的 DHCP 服务器工作正常。 如果您正在使用 isc-dhcp-server、是否可以检查"systemctl status isc-dhcp-server"？

-道林

尊敬的 Daolin：

systemctl status isc-dhcp-server
● isc-dhcp-server.service - ISC DHCP IPv4 server
Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2025-05-06 09:14:41 BST; 1min 19s ago
Docs: man:dhcpd(8)
Main PID: 2712 (dhcpd)
Tasks: 4 (limit: 76506)
Memory: 4.6M
CPU: 23ms
CGroup: /system.slice/isc-dhcp-server.service
└─2712 dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf enxc8a3622c3d8c

May 06 09:14:41 caprica dhcpd[2712]: Wrote 0 leases to leases file.
May 06 09:14:41 caprica dhcpd[2712]: Listening on LPF/enxc8a3622c3d8c/c8:a3:62:2c:3d:8c/10.0.0.0/8
May 06 09:14:41 caprica sh[2712]: Listening on LPF/enxc8a3622c3d8c/c8:a3:62:2c:3d:8c/10.0.0.0/8
May 06 09:14:41 caprica sh[2712]: Sending on LPF/enxc8a3622c3d8c/c8:a3:62:2c:3d:8c/10.0.0.0/8
May 06 09:14:41 caprica sh[2712]: Sending on Socket/fallback/fallback-net
May 06 09:14:41 caprica dhcpd[2712]: Sending on LPF/enxc8a3622c3d8c/c8:a3:62:2c:3d:8c/10.0.0.0/8
May 06 09:14:41 caprica dhcpd[2712]: Sending on Socket/fallback/fallback-net
May 06 09:14:41 caprica dhcpd[2712]: Server starting service.
May 06 09:15:12 caprica dhcpd[2712]: BOOTREQUEST from 04:25:e8:3d:9d:0b via enxc8a3622c3d8c
May 06 09:15:12 caprica dhcpd[2712]: BOOTREPLY on 10.0.0.2 to 04:25:e8:3d:9d:0b via enxc8a3622c3d8c

我还journalctl -fu isc-dhcp-server -fu xinetd在重新启动电路板时运行：

May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/discard-udp [file=/etc/xinetd.d/discard-udp] [line=25]
May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/echo [file=/etc/xinetd.d/echo] [line=14]
May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/echo-udp [file=/etc/xinetd.d/echo-udp] [line=26]
May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/servers [file=/etc/xinetd.d/servers] [line=14]
May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/services [file=/etc/xinetd.d/services] [line=13]
May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/tftp [file=/etc/xinetd.d/tftp] [line=13]
May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/time [file=/etc/xinetd.d/time] [line=12]
May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/time-udp [file=/etc/xinetd.d/time-udp] [line=28]
May 06 09:14:42 caprica xinetd[2756]: 2.3.15.3 started with libwrap loadavg labeled-networking options compiled in.
May 06 09:14:42 caprica xinetd[2756]: Started working: 1 available service
May 06 09:15:12 caprica dhcpd[2712]: BOOTREQUEST from 04:25:e8:3d:9d:0b via enxc8a3622c3d8c
May 06 09:15:12 caprica dhcpd[2712]: BOOTREPLY on 10.0.0.2 to 04:25:e8:3d:9d:0b via enxc8a3622c3d8c
May 06 09:15:12 caprica tftpd[2760]: tftpd: trying to get file: tiboot3.bin
May 06 09:15:12 caprica tftpd[2760]: tftpd: serving file from /tftpboot

据我所知、DHCP 工作正常、地址被分配给 tiboot3.bin 的初始 TFTP  

此致

Neil

从我可以看到的情况来看、DHCP/TFTP 服务器在传输 tiboot3.bin 时工作正常-在 Wireshark 上可以看到

然后我看到 tiboot3.bin 正在执行、它应该加载 tispl.bin？

我没有看到 tispl.bin 上的任何以太网数据包退出电路板、但是我添加了调试打印、其中显示数据包正在内部创建到 AM62X、但未在传输。

我不认为这是一个问题与服务器,因为他们没有看到任何数据包,即从 tiboot3.bin 的 BOOTP

我应该在哪里寻找新的调试来帮助了解数据包为何不被传输？

谢谢你

您好 Neil、

Unknown 说：

只要我可以告诉 DHCP 工作正常、为 tiboot3.bin 的初始 TFTP 分配地址

Unknown 说：

要在 tiboot3.bin 成功执行后下载 tispl.bin、我们需要再次从 DHCP 服务器的 IP 地址中获取 IP 地址并请求该 IP 地址。 [/报价]

尽管在 tiboot3.bin 之前获取 IP 地址、但为了获取 tispl.bin、需要获取 IP 地址 所有信息 。 在 DHCP 状态日志中、我没有看到在 tispl.bin 之前获取 IP 地址的任何 DHCP 请求或提供。

我期望看到的内容：

$ sudo systemctl status isc-dhcp-server
● isc-dhcp-server.service - ISC DHCP IPv4 server
    Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; vendor preset: enabled)
    Active: active (running) since Tue 2025-05-06 11:33:35 CDT; 2min 20s ago
      Docs: man:dhcpd(8)
  Main PID: 86889 (dhcpd)
     Tasks: 4 (limit: 18644)
    Memory: 4.7M
       CPU: 26ms
    CGroup: /system.slice/isc-dhcp-server.service
            └─86889 dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf enp3s0

May 06 11:35:35 a0500327ws dhcpd[86889]: DHCPOFFER on 172.168.1.170 to 1c:63:49:0f:61:14 () via enp3s0
May 06 11:35:35 a0500327ws dhcpd[86889]: reuse_lease: lease age 1026369 (secs) under 25% threshold, reply with unaltered, existing lease for 172.168.1.170
May 06 11:35:35 a0500327ws dhcpd[86889]: DHCPDISCOVER from 1c:63:49:0f:61:14 () via enp3s0
May 06 11:35:35 a0500327ws dhcpd[86889]: DHCPOFFER on 172.168.1.170 to 1c:63:49:0f:61:14 () via enp3s0
May 06 11:35:36 a0500327ws dhcpd[86889]: reuse_lease: lease age 1026370 (secs) under 25% threshold, reply with unaltered, existing lease for 172.168.1.170
May 06 11:35:36 a0500327ws dhcpd[86889]: DHCPDISCOVER from 1c:63:49:0f:61:14 () via enp3s0
May 06 11:35:36 a0500327ws dhcpd[86889]: DHCPOFFER on 172.168.1.170 to 1c:63:49:0f:61:14 () via enp3s0
May 06 11:35:36 a0500327ws dhcpd[86889]: reuse_lease: lease age 1026370 (secs) under 25% threshold, reply with unaltered, existing lease for 172.168.1.170
May 06 11:35:36 a0500327ws dhcpd[86889]: DHCPREQUEST for 172.168.1.170 (172.168.1.1) from 1c:63:49:0f:61:14 () via enp3s0
May 06 11:35:36 a0500327ws dhcpd[86889]: DHCPACK on 172.168.1.170 to 1c:63:49:0f:61:14 () via enp3s0

Unknown 说：

运行以太网引导 Wireshark 捕获：am62x_working_eth_boot.pcapng

 

此外、如果您查看工作中的 Wireshark 捕获、在能够使用 TFTP tispl.bin 之前、需要使用 DHCP 数据包(不是 BOOTP)来获取 IP 地址 所有信息 。 
在此特定示例中、IP 地址从 TFTP tiboot3.bin 时的172.168.1.169更改为 TFTP tispl.bin 时的172.168.1.170。 

Unknown 说：

然后看到 tiboot3.bin 执行、然后应该加载 tispl.bin？

Unknown 说：

我认为这不是服务器的问题、因为服务器没有看到任何数据包、即 tiboot3.bin

中的 BOOTP

从 https://lore.kernel.org/all/20240112064759.1801600-1-s-vadapalli@ti.com/、tiboot3.bin 负责传输 VCI 字符串。 
tiboot3.bin 使用了不正确的 VCI 字符串(只要使用由 am62x_evm_r5_ethboot_defconfig 提供的默认 SDK、就不应该这样做)、或者 DHCP 或 TFTP 服务器无法正常工作。 
6."tiboot3.bin"配置为将"AM62X U-Boot R5 SPL"作为其
NET_VCI_STRING 传输、这意味着
需要配置 DHCP 服务器和 TFTP 服务器以将"tispl.bin"传输到器件。
7."tiboot3.bin"加载并执行 TFTP
服务器提供的"tispl.bin"。 

通常、tiboot3.bin 似乎负责获取 tispl.bin、并应传输该 VCI 字符串。 
我想知道您的 tiboot3.bin 是否在构建时缺少一些内容。 
您能否给这个 tiboot3.bin 一个尝试看看它是否改变了行为? 这个 tiboot3.bin (从 SDK 10.0.07.04版本构建)正在开发我的 SK-AM62B-P1电路板(具有 RGMII 以太网引导)。 

e2e.ti.com/.../1376.tiboot3.bin

-道林 

"虽然在 tiboot3.bin 之前获取了 IP 地址、但为了获取 tispl.bin、需要获取 IP 地址  所有信息 。 从 DHCP 状态日志中、我没有看到在 tispl.bin 之前获取 IP 地址的任何 DHCP 请求或优惠。"

我同意-因为没有从 tiboot3.bin 传输以太网、因此没有重新请求 DHCP 地址。

我不知道怎么说这个问题-我应该在调试 tiboot3.bin 中寻找什么 来找出为什么不传输以太网流量？

我认为此问题与服务器或 VCI 字符串无关-基本问题是在执行 tiboot3.bin 时不从主板传输以太网。

您的 tiboot3不起作用、未找到 phy -可能是因为我有 RMII

此致

Neil

您好 Neil、

我不知道怎么说这个问题-我应该在调试 tiboot3.bin 中寻找什么 来找出为什么不传输以太网流量？

我认为此问题与服务器或 VCI 字符串无关-基本问题是在执行 tiboot3.bin 时不从主板传输以太网。

Unknown 说：

tiboot3.bin 中使用了不正确的 VCI 字符串(只要使用由 am62x_evm_r5_ethboot_defconfig 提供的默认 SDK、情况就不应该如此)

您能否分享用于构建 tiboot3.bin 的 defconfig？

-道林

尊敬的 Daolin：

R5配置已连接。

但是、由于电路板上的 tiboot3.bin 不传输以太网数据包、因此 VCI 字符串无关紧要。

此致

Neil

e2e.ti.com/.../r5_5F00_ethboot_5F00_defconfig.zip

您好 Neil、

Unknown 说：

但是、由于主板上的 tiboot3.bin 正在传输零个以太网数据包、因此 VCI 字符串无关紧要。

我对 R5 ethboot defconfig 与 SDK 提供的 am62x_evm_r5_ethboot_defconfig 进行了粗略比较、似乎您的 defconfig 与 SDK 提供的 defconfig 之间存在一些差异(不计数由于使用了不同的 PHY 以及针对 RMII (而不是 RGMII)进行配置而导致的不同差异)。 由于 tiboot3.bin 本身是使用 R5 ethboot defconfig 构建的、因此值得跟踪 R5 ethboot defconfig 中哪个 config/组合的配置可能会导致该问题。

我的想法(但可能不是最有效的方法)是对导致问题的配置进行强力跟踪、首先使用 SDK 提供的 R5 ethboot defconfig (我们知道这适用于 RGMII)、仅应用定制电路板所需的配置(不同的 PHY 和 RMII 模式)、使其他一切保持不变、然后查看问题是否仍然存在。 如果您没有看到问题、您可以尝试应用每个额外的配置(一次一个)、并测试以查看是否存在导致问题出现的配置/组合。

-道林

 使用以下模块从 ti-processor-sdk-linux-am62xx-evm-10.01.10.04构建：

diff --git a/configs/am62x_evm_r5_ethboot_defconfig b/configs/am62x_evm_r5_ethboot_defconfig
index 853e5176..2719fdc4 100644
--- a/configs/am62x_evm_r5_ethboot_defconfig
+++ b/configs/am62x_evm_r5_ethboot_defconfig
@@ -14,7 +14,10 @@ CONFIG_SPL_SYSCON=y
CONFIG_DMA_CHANNELS=y
CONFIG_TI_K3_NAVSS_UDMA=y
CONFIG_DM_I2C=y
-CONFIG_PHY_TI_DP83867=y
+CONFIG_PHY_TI_DP83867=n
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ8XXX=y
+CONFIG_RMII=y
CONFIG_TI_AM65_CPSW_NUSS=y
CONFIG_MMC=n
CONFIG_SPL_MMC=n

diff --git a/arch/arm/dts/k3-am62x-sk-common.dtsi b/arch/arm/dts/k3-am62x-sk-common.dtsi
index 59ee4961..2351f104 100644
--- a/arch/arm/dts/k3-am62x-sk-common.dtsi
+++ b/arch/arm/dts/k3-am62x-sk-common.dtsi
@@ -478,7 +478,7 @@

&cpsw_port1 {
bootph-all;
- phy-mode = "rgmii-rxid";
+ phy-mode = "rmii";
phy-handle = <&cpsw3g_phy0>;
};

@@ -488,9 +488,9 @@
pinctrl-names = "default";
pinctrl-0 = <&main_mdio1_pins_default>;

- cpsw3g_phy0: ethernet-phy@0 {
+ cpsw3g_phy0: ethernet-phy@1 {
bootph-all;
- reg = <0>;
+ reg = <1>;
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
ti,min-output-impedance;

U-Boot SPL 2024.04-dirty (May 08 2025 - 10:18:42 +0100)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.8--v10.01.08 (Fiery Fox)')
SPL initial stack usage: 13392 bytes
Trying to boot from eth device
eth0: ethernet@8000000port@1
ethernet@8000000port@1 Waiting for PHY auto negotiation to complete.... done
link up on port 1, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17

Retry time exceeded; starting again
udma_stop_mem2dev: peer not stopped TIMEOUT !
Problem booting with BOOTP
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

我仍然看到没有从下载的 tiboot3.bin 传输以太网数据包

此致

Neil

您好 Neil、

您能尝试使用 SDK 10.00.07.04吗？ 在过去的一些测试中、我使用 SDK 10.01.10.04进行了一些测试、我看到了以太网启动的一些问题、但我知道使用 SDK 10.00.07.04时、以太网启动在 TI AM62x EVM 上有效。  

另一个想法是尝试使用 SDK 11.0  

-道林

您好 Neil、

我需要一些时间在内部进行检查、了解我们是否有关于启用 RMII 以太网引导的任何信息。 如前所述、虽然 AM62x TRM 中列出了 RMII 以太网引导模式、但据我所知、RMII 以太网引导模式之前尚未经过正式测试、因此我猜测构建启动 DHCP 消息的 tiboot3.bin 时需要一些缺少的配置。  

您是否还可以尝试启用 CONFIG_CMD_DHCP 以查看行为是否发生变化。 虽然 SDK 提供的 ethboot R5 defconfig 禁用了 CONFIG_CMD_DHCP、但我想知道是否需要启用 RMII 模式？

-道林

您好 Neil、

此外、由于您不使用 DP83867 PHY、因此我认为您不应该在器件树中配置上述器件。 不确定这是否会改变问题、但仍有需要解决的问题。

-道林