[参考译文] AM625SIP：尝试从 eth 器件引导

你好、Marcin、  

您使用的是哪个 TI Linux SDK 版本？

Unknown 说：

但是、SPL 在尝试从 eth 设备引导时挂起。 我在 Wireshark 中看不到任何 BOOTP 请求。 eth 或 MDIO 驱动程序似乎出现问题：

您能否共享整个 Wireshark 捕获？

我认为我们以前没有在 SK-AM62-SIP EVM 上测试过以太网启动；我认为它仅在 SK-AM62B-P1 EVM 上进行了测试。 但是、当 DDR 大小从2GB 更改为更小的大小(512MB 或1GB)时、我看到了这种类型的问题、即"尝试从 eth 器件引导"。 由于 AM62SIP 具有512MB 的 DDR 大小、因此我怀疑以太网引导会挂起、原因与我们在 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1497680/am625-reducing-ddr-size-causes-u-boot-r5-spl-to-crash-during-ethernet-boot 中试图揭示的原因相同 

这是一个问题尚未解决、但我建议您尝试在我链接的这个其他主题中尝试到目前为止所做的更改、看看这是否有助于解决您看到的以太网引导问题。

如果您有后续问题、敬请告知。

-道林

尊敬的 Daolin：

我附上 Wireshark 捕获文件。

我使用 SDK  11.00.09.

e2e.ti.com/.../am62xxsip_2D00_wireshark.zip

U-Boot SPL 2025.01-00406-gcd91d7360181 (2025年4月22日- 11：59：01 +0000)
SYSFW ABI：4.0 (固件版本0x000b'11.0.7--v11.00.07 (Fancy Rat)')
将 DT 中的 A53 CPU 频率更改为1250000000Hz (T 级
SPL 初始栈使用量：13424字节

此致、

Marcin

尊敬的 Marcin：

您的 Wireshark 捕获似乎与其他 E2E 主题中的相同症状匹配。  

您是否已经尝试过 在另一个线程中进行描述的修改？  https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1497680/am625-reducing-ddr-size-causes-u-boot-r5-spl-to-crash-during-ethernet-boot 

此外、您是否可以尝试将以下内容添加到您用于构建 U-boot 二进制文件的 A53 defconfig 中(对于 SK-AM62B EVM、这将是 am62x_evm_a53_ethboot_defconfig)

CONFIG_SYS_MEM_TOP_HIDE = 0x4000000

-道林

你好、Marcin、

我们尚未在 SDK 11.x 中添加对 AM62 SIP 的支持、您可以对 SDK 10.x 进行类似的配置、并为 AM62x-SIP 启用以太网引导。

此致、
中国。

您好 Chintan：

感谢您的关注！ 我会尝试一下、看看效果如何。

此致、

Marcin

我切换到了 TI SDK  10.00.07.04。

我尝试了 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1497680/am625-reducing-ddr-size-causes-u-boot-r5-spl-to-crash-during-ethernet-boot 的修改 没有成功。

这是 R5生成的.config e2e.ti.com/.../6646.config.txt

尊敬的 Marcin：

我最近了解到、在 SDK 11.x 中、 除了添加 CONFIG_SYS_MEM_TOP_HIDE=0x4000000之外、以太网引导当 RAM 大小减小时所面临的问题已得到修复。 我还没有机会在我的测试设置中验证此项(我希望明天进行测试)。

同时、您可以尝试使用之前使用的11.x 版本、而不是运行 SDK 10.00.07.04、并启用 CONFIG_SYS_MEM_TOP_HIDE = 0x4000000。

-道林

你好、Marcin、

在 SDK 10.x 中、我们有一个用于"am62x-sip"的特定器件树文件、只有特定于 SIP 的更改是内存。 您可以使用"am62xsip"作为默认配置的基础文件、在该配置中、我们已经启用了配置"CONFIG_SYS_MEM_TOP_HIDE"。 您可以尝试此 defconfig、其中再次包含"am62x_evm_*" defconfig。 我怀疑它可以解决您所面临的问题、但它可能会导致 DMA 和 LMB 出现问题、因为您可以阅读以下主题： https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1497680/am625-reducing-ddr-size-causes-u-boot-r5-spl-to-crash-during-ethernet-boot/。 我还怀疑 AM62x-SIP 会询问一些特定的 VCI 字符串、这些字符串可能与我们提供的 am62x 不同。

请告诉我上面的内容是否适合您、如果不适合、我将需要以太网引导日志以及完整的 Wireshark 日志来进一步调试。

此致、

中国。

我切换回 SDK  11.00.09.04.
我配置了： CONFIG_SYS_MEM_TOP_HIDE = 0x4000000 (对于 A53)。

尽管如此、R5 SPL 看起来仍然挂起。 我没有看到来自 SPL 的任何 BOOTP 请求。

尊敬的 Chintan：

" 我也怀疑 AM62x-SIP 会要求提供一些特定的 VCI 字符串、这些可能与我们提供的 am62x 不同。"

您能否确认 VCI 字符串应该是什么？ 谢谢你。

这是 Wireshark 跟踪和控制台输出。 与之前的没有太大的差异

e2e.ti.com/.../am62xxsip_2D00_wireshark_5F00_2.zip

U-Boot SPL 2025.01-00406-gcd91d7360181-脏(2025年4月24日- 12：05：59 +0000)
SYSFW ABI：4.0 (固件版本0x000b'11.0.7--v11.00.07 (Fancy Rat)')
将 DT 中的 A53 CPU 频率更改为1250000000Hz (T 级
SPL 初始栈使用量：13424字节

尊敬的 Marcin：  

Unknown 说：

我已切换回 SDK  11.00.09.04.
我配置了： CONFIG_SYS_MEM_TOP_HIDE = 0x4000000 (对于 A53)。

测试我在 SK-AM62B-P1 EVM 上建议的更改后、我能够成功通过以太网引导。 但是、在我能够获得的 SK-AM62-SIP EVM 上、相同的更改会导致 tiboot3.bin 传输结束时挂起。 这向我表明、SK-AM62-SIP 和 SK-AM62B-P1之间还有一些不同、导致以太网引导出现问题。 我使用"am62x_evm_a53_ethboot_defconfig"测试了 SK-AM62B-P1和 SK-AM62-SIP EVM。

测试时、您是使用"am62x_evm_a53_ethboot_defconfig"构建 U-boot 二进制文件、还是根据 SDK 10.x 中的"am62xsip_evm_a53_defconfig"创建了自定义的 defconfig？

[引述 userid="638871" url="~/support/processors-group/processors/f/processors-forum/1498498/am625sip-trying-to-boot-from-eth-device/5787620 #5787620"]

" 我也怀疑 AM62x-SIP 会要求提供一些特定的 VCI 字符串、这些可能与我们提供的 am62x 不同。"

您能否确认 VCI 字符串应该是什么？ 谢谢你。

[/报价]

我将让 Chintan 对此进行正式评论、但我相信我们没有专用的 AM62x SIP 以太网引导 defconfig、以及我看到为 AM62x SIP 使用"am62x_evm_a53_ethboot_defconfig"时出现问题、这表明 AM62x SIP 的 VCI 字符串可能与为 AM62x 提供的 VCI 字符串不同。 AM62x SIP 可能没有专用的 VCI 字符串、在这种情况下、AM62x SIP 根本不支持以太网引导。

-道林

尊敬的 Daolin：

感谢您的确认。

我使用了  am62x_evm_a53_ethboot_defconfig、并添加了"CONFIG_SYS_MEM_TOP_HIDE=0x4000000"。

BTW ：已经做了一些与 AM62Ax + phyCORE-AM62 SoM 的 eth 引导支持相关的工作：

https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?id=cb7555e93075114fe4af0adb806877ac4d4ef80d

-- Marcin

尊敬的 Marcin：

下周我将详细介绍 AM62 SoM 的工作原理。 如果您在星期二之前没有收到回复、请再次 ping 此主题。

-道林

尊敬的 Marcin：

[引述 userid="638871" url="~/support/processors-group/processors/f/processors-forum/1498498/am625sip-trying-to-boot-from-eth-device/5785145 #5785145"]

我切换到了 TI SDK  10.00.07.04。

我尝试了 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1497680/am625-reducing-ddr-size-causes-u-boot-r5-spl-to-crash-during-ethernet-boot 的修改 没有成功。

这是 R5生成的.config  

[/报价]

当您使用 SDK 10.00.07.04时、您使用了哪个 A53和 R5 defconfig？ 我看到您共享了"r5生成的.config"、但具体来说、您使用了哪个 defconfig？  

理想情况下、如果我们可以让 AM62-SIP 使用以太网引导、则有两种测试方法(中国的反馈)

1.在 SDK 10.00.07.04上、使用"am62x_evm_r5_ethboot_defconfig"和"am62x_evm_a53_ethboot_defconfig"、但确保"#include……" 两个文件的顶部都替换为"am62xsip_evm_*"等效文件。  

使用此方法,您可能会遇到与另一个线程中提到的相同问题,作为临时黑客,请在另一个线程中对 DMA 和 LMB 使用相同的黑客来查看是否有效。

2.在 SDK 11.00.09.04上、首先使用 SD 卡引导进行测试、方法是从10.x 开始获取 AM62-SIP 的器件树和 defconfig (如11.x 中所述、目前不支持 AM62-SIP)、一旦通过采用10.x 中的相同 defconfig 和器件树证明 SD 卡引导工作正常、然后尝试使用以太网引导。  

这种方法的好处是、可能不需要黑客来解决另一个线程中出现的 DMA 和 LMB 问题。

[引述 userid="638871" url="~/support/processors-group/processors/f/processors-forum/1498498/am625sip-trying-to-boot-from-eth-device/5790111 #5790111"]

BTW ：已经做了一些与 AM62Ax + phyCORE-AM62 SoM 的 eth 引导支持相关的工作：

https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?id=cb7555e93075114fe4af0adb806877ac4d4ef80d

[/报价]

据我所知、我们没有具体的开发计划来调整 AM62-SIP EVM、使其与以太网引导兼容。 我们提供的建议(上述两种方法)只是有关如何尝试以及是否在 AM62-SIP 上启用以太网引导的建议。 可能需要进行其他未知的软件更改。 根据我的理解、即使我要申请调整 AM62-SIP 来实现以太网启动、内部团队也不太可能优先考虑调整 AM62-SIP EVM 来实现以太网启动。 此外、还有一个关于 MDIO 损坏的勘误表、使以太网引导不是最可靠的引导方法： i2329 - MDIO：MDIO 接口损坏(CPSW 和 PRU-ICSS)   

-道林

尊敬的 Daolin：

1.我 在 am62x_evm_r5_ethboot_defconfig" 和"am62x_evm_a53_ethboot_defconfig"中 相应地包含了"am62xsip_evm_*"、并使用了 DMA 黑客。 这是我现在看到的：

U-Boot SPL 2024.04-ti-gfda88f8bcea3 (2025年4月30日- 12：13：18 +0000)
SYSFW ABI：4.0 (固件版本0x000a '10.0.8--v10.00.08 (Fiery Fox)')
SPL 初始栈使用量：13392字节
尝试从 eth 器件引导
eth0：以太网@8000000port@1
TI_sci system-controller@44043000：TI_sci_get_response：message receive failed。 RET =-110
TI_sci system-controller@44043000：消息未确认
TI_sci system-controller@44043000：TI_sci_get_response：message receive failed。 RET =-110
TI_sci system-controller@44043000：消息未确认
TI_sci system-controller@44043000：TI_sci_get_response：message receive failed。 RET =-110
TI_sci system-controller@44043000：消息未确认
TI_sci system-controller@44043000：TI_sci_get_response：message receive failed。 RET =-110
TI_sci system-controller@44043000：消息未确认
TI_sci system-controller@44043000：TI_sci_get_response：message receive failed。 RET =-110
TI_sci system-controller@44043000：消息未确认
TI_sci system-controller@44043000：TI_sci_get_response：message receive failed。 RET =-110
TI_sci system-controller@44043000：消息未确认
TI_sci system-controller@44043000：TI_sci_get_response：message receive failed。 RET =-110
TI_sci system-controller@44043000：消息未确认
TI_sci system-controller@44043000：TI_sci_get_response：message receive failed。 RET =-110
TI_sci system-controller@44043000：消息未确认
TI_sci system-controller@44043000：TI_sci_get_response：message receive failed。 RET =-110
TI_sci system-controller@44043000：消息未确认
TI_sci system-controller@44043000：TI_sci_get_response：message receive failed。 RET =-110
TI_sci system-controller@44043000：消息未确认
TI_sci system-controller@44043000：TI_sci_get_response：message receive failed。 RET =-110
TI_sci system-controller@44043000：消息未确认
k3-secure-proxy mailbox@4d000000：k3_sec_proxy_send：Thread1验证失败。 RET =-61
TI_sci system-controller@44043000：TI_sci_do_xfer：消息发送失败。 RET =-61
k3-secure-proxy mailbox@4d000000：k3_sec_proxy_send：Thread1验证失败。 RET =-61
TI_sci system-controller@44043000：TI_sci_do_xfer：消息发送失败。 RET =-61
k3-secure-proxy mailbox@4d000000：k3_sec_proxy_send：Thread1验证失败。 RET =-61
TI_sci system-controller@44043000：TI_sci_do_xfer：消息发送失败。 RET =-61
k3-secure-proxy mailbox@4d000000：k3_sec_proxy_send：Thread1验证失败。 RET =-61
TI_sci system-controller@44043000：TI_sci_do_xfer：消息发送失败。 RET =-61
k3-secure-proxy mailbox@4d000000：k3_sec_proxy_send：Thread1验证失败。 RET =-61
TI_sci system-controller@44043000：TI_sci_do_xfer：消息发送失败。 RET =-61
k3-secure-proxy mailbox@4d000000：k3_sec_proxy_send：Thread1验证失败。 RET =-61
TI_sci system-controller@44043000：TI_sci_do_xfer：消息发送失败。 RET =-61
k3-secure-proxy mailbox@4d000000：k3_sec_proxy_send：Thread1验证失败。 RET =-61
TI_sci system-controller@44043000：TI_sci_do_xfer：消息发送失败。 RET =-61
k3-secure-proxy mailbox@4d000000：k3_sec_proxy_send：Thread1验证失败。 RET =-61
TI_sci system-controller@44043000：TI_sci_do_xfer：消息发送失败。 RET =-61
TI-UDMA DMA DMA DMA 控制器@485c0000：TISCI 配置环失败(-61) ring_idx 19
TI-UDMA DMA-controller@485c0000：Alloc DMA res failed -61
am65_cpsw_Nuss_port 以太网@8000000port@1：TX DMA 获取失败-22
am65_cpsw_Nuss_port 以太网@8000000port@1：am65_cpsw_start 结束错误
使用 BOOTP 引导时出现问题
SPL：无法从所有引导设备引导
###错误###请重置主板###

2.目前无法启动 SD 卡。 尝试 在未来几天更新该线程。

此致、

Marcin

2.我看到使用 SDK 11进行 eth 引导时也有同样的行为。

-- Marcin

尊敬的 Marcin：  

让我明天再仔细看看。

-道林

尊敬的 Marcin：  

Unknown 说：

据我所知、我们没有调整 AM62-SIP EVM 以兼容以太网引导的具体开发计划。 我们提供的建议(上述两种方法)只是有关如何尝试以及是否在 AM62-SIP 上启用以太网引导的建议。 可能需要进行其他未知的软件更改。 根据我的理解、即使我要申请调整 AM62-SIP 来实现以太网启动、内部团队也不太可能优先考虑调整 AM62-SIP EVM 来实现以太网启动。 此外、还有一个关于 MDIO 损坏的勘误表、使以太网引导不是最可靠的引导方法： i2329 - MDIO：MDIO 接口损坏(CPSW 和 PRU-ICSS) [报价]

正如我提到的、我们只能提供建议、但可能还需要进行其他未知的软件更改、以太网引导才能完全与 AM62-SIP 配合使用。 内部团队不太可能优先考虑使 AM62-SIP 实现以太网引导功能、因为我们通常不建议使用以太网引导、除非由于 MDIO 损坏勘误表而仅用于开发目的。  

我想问一下、您 AM62-SIP 上的以太网引导预期用例是什么？ 它是必须位于 AM62-SIP 上、还是 AM62x 是您的另一种选择？

如果您想获得有关如何调试您看到的问题的其他建议、下面提供了一些建议。 请注意、这些只是建议、据我所知、AM62-SIP 上的以太网引导之前尚未经过测试、因此可能需要进一步开发才能实现这一点。

Unknown 说：

1. 我 在 am62x_evm_r5_ethboot_defconfig" 和"am62x_evm_a53_ethboot_defconfig"中 相应地包含了"am62xsip_evm_*"、并使用了 DMA 黑客。 这是我现在看到的：

在应用 DMA 破解之前、但替换为"am62xsip_evm_*"后、以太网引导的结果是什么？ 它是否与之前挂起时的"尝试从 eth 设备引导"相同？  

此外、检查是否输入了此 if 条件： https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/drivers/dma/ti/k3-udma-u-boot.c?h=ti-u-boot-2025.01#n138。 我在想" uc->config.dir == DMA_MEM_TO_MEM" is not satisfied, hence the "rxcq_num = k3_nav_ringacc_get_ring_id(uc->tchan->tc_ring);" is not set.

虽然我不是 U-boot 专家、但可能有一种方法可以查看崩溃呼叫跟踪、以具体跟踪导致挂起的原因。 研究如何实现这一点可能是值得的。 具体而言、我是指在应用 AM62x 上使用的 DMA 破解之前跟踪挂起行为。

Unknown 说：

2. 目前、我无法进行 SD 卡引导。  在接下来的几天内尝试更新该线程。

Unknown 说：

2. 我看到使用 SDK 11进行 eth 引导时出现了相同的行为。

您提到的不是为了验证 SD 卡引导。 在使用此方法测试 SDK 11.0上的以太网引导之前、您是否能够验证 SD 卡引导是否正常工作？

如果您有后续问题、请告知我们。

-道林

[/quote]