[参考译文] AM6442：通过以太网引导 (BOOTP)-卡在 DHCP 响应处

因此、将文件的权限更改为 644 — 我可以看到 TFTP 从现在开始、但只能传输一个字节。

您好、

指定的专家今天已离职。 请在接下来的 2/3 天内回复。

此致、
Ritapravo

在这段时间里、我会不断地对问题进行锤击、并更新相关内容。

所以,我不能（还没有）可靠地达到这一点。 为了消除可能出现的问题、我设置了另一台具有内部以太网端口（而不是 USB 转换器）的笔记本电脑 — 旧版 T580、现在被称为 实验 2. 。 到目前为止、可以看到引导请求和响应、但不会启动 tftp 传输。 我已经确认该文件也可以通过 labtop2 上的 tftp 拉取。

我可能会尝试明天拔出一个愚蠢的开关,看看问题是否是直接连接这些设备。

请注意、我能够通过 UART 加载 tiboot3.bin、tispl.bin、u-boot.img 所有内容；在 u-boot 中也能够检测到 eth。

我可能只是尝试通过 UART 加载到 u-boot、然后看看是否可以通过网络加载映像/dtb。  

根据其他答案、我会考虑使用 SK 评估套件进行尝试、以及将备份模式设置为以太网而不是 UART。

因此、使用了针对的 SK 评估套件 实验 2. 、引导模式引脚为 B15->B0：0001 0000 1010 0011、我可以看到 tiboot3.bin 开始下载：

但完成后、似乎不会转到任何其他文件。 UART 控制台上没有输出（主端口或调试端口；ttyUSB0/1 或 ttyACM0/1）

我建议这里的有限成功表明至少 dhcp/tftp 设置（至少）部分正常工作、并且在定制电路板上可能不是很好。

使用 SK 评估和确认相同的行为 labtop  -加载到块 965（最后一个）,没有进展到下一个文件。

为方便起见、以下是与以太网相关的原理图区域、从处理器开始、一直到 phy。 相关项应为 RGMII2 (eth0)

两个以太网端口都显示在 u-boot（通过 UART 加载）中；链路检测正常工作（移动电缆会更改活动端口）、但从 u-boot 提示符使用 dhcp 命令不会启动任何 DHCP/BOOTP 流量。

您好、James：  

首先、要了解您的设置、您能否澄清以下问题？

1.您使用的是哪个 SDK 版本？

2.您使用的是哪种以太网？ PRU-ICSSG 还是 CPSW？

3.澄清,以太网启动的问题是 tiboot3.bin 已完全加载,但 tispl.bin 不开始加载?

两个以太网端口都显示在 u-boot 中（通过 UART 加载）；链路检测正常工作（移动电缆会更改活动端口）、但从 u-boot 提示符使用 dhcp 命令不会启动任何 DHCP/BOOTP 流量。

我相信这取决于您连接的以太网端口。 您能否说明哪个以太网端口（以太网-PRU-ICSSG 与 CPSW 的类型以及哪个接口名称 — eth0、eth1 等）？

理想情况下、您首先能够重现 SK-AM64B EVM 的问题。 另请注意、我们不支持通过 PRU-ICSSG 以太网端口进行以太网引导。

-道林

你好道林,你方面到目前为止有什么想法吗?

请注意、此处列出的补丁程序  是 www.mail-archive.com/.../msg531978.html 到 ti_phy_init.c

---
 drivers/net/phy/ti_phy_init.c | 48 ++++++++++++++++++++++++++++++++++-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/ti_phy_init.c b/drivers/net/phy/ti_phy_init.c
index a0878193ac0..850c0cbec96 100644
--- a/drivers/net/phy/ti_phy_init.c
+++ b/drivers/net/phy/ti_phy_init.c
@@ -10,12 +10,58 @@
 #include <phy.h>
 #include "ti_phy_init.h"
 
+#define DP83822_DEVADDR                0x1f
+
+#define MII_DP83822_RCSR       0x17
+
+/* RCSR bits */
+#define DP83822_RX_CLK_SHIFT   BIT(12)
+#define DP83822_TX_CLK_SHIFT   BIT(11)
+
+/* DP83822 specific RGMII RX/TX delay configuration. */
+static int dp83822_config(struct phy_device *phydev)
+{
+       ofnode node = phy_get_ofnode(phydev);
+       u32 rgmii_delay = 0;
+       u32 rx_delay = 0;
+       u32 tx_delay = 0;
+       int ret;
+
+       ret = ofnode_read_u32(node, "rx-internal-delay-ps", &rx_delay);
+       if (ret) {
+               rx_delay = phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+                          phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID;
+       }
+
+       ret = ofnode_read_u32(node, "tx-internal-delay-ps", &tx_delay);
+       if (ret) {
+               tx_delay = phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+                          phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID;
+       }
+
+       /* Bit set means Receive path internal clock shift is ENABLED */
+       if (rx_delay)
+               rgmii_delay |= DP83822_RX_CLK_SHIFT;
+
+       /* Bit set means Transmit path internal clock shift is DISABLED */
+       if (!tx_delay)
+               rgmii_delay |= DP83822_TX_CLK_SHIFT;
+
+       ret = phy_modify_mmd(phydev, DP83822_DEVADDR, MII_DP83822_RCSR,
+                            DP83822_RX_CLK_SHIFT | DP83822_TX_CLK_SHIFT,
+                            rgmii_delay);
+       if (ret)
+               return ret;
+
+       return genphy_config_aneg(phydev);
+}
+
 U_BOOT_PHY_DRIVER(dp83822) = {
        .name = "TI DP83822",
        .uid = 0x2000a240,
        .mask = 0xfffffff0,
        .features = PHY_BASIC_FEATURES,
-       .config = &genphy_config_aneg,
+       .config = &dp83822_config,
        .startup = &genphy_startup,
        .shutdown = &genphy_shutdown,
 };
-- 

是否考虑识别 PHY（而不仅仅是通用 PHY）：

=> mdio list
mdio@f00:
9 - TI DP83822 <--> ethernet@8000000port@2
11 - TI DP83822 <--> ethernet@8000000port@1
mdio@32400:
=> 

当前 DTS 部分：

* CPSW core */
&cpsw3g {
	bootph-all;
	pinctrl-names = "default";
	pinctrl-0 = <&mycpsw1_pins_default>; /* use the defined group */
	/* Map HW8_TS_PUSH to GENF1 */
	cpts@3d000 { ti,pps = <7 1>; };
};

/* CPSW ports: RGMII with PHY-provided RX delay only */
&cpsw_port1 { phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy11>; };
&cpsw_port2 { phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy9>; };

/* CPSW MDIO + DP83822 PHYs (with resets and IRQs) */
&cpsw3g_mdio {
	bootph-all;
	status = "okay";
	pinctrl-names = "default";
	pinctrl-0 = <&mymdio1_pins_default>;

	/* MDIO address 11 (RGMII1) — reset on P20 -> GPIO0_6 */
	cpsw3g_phy9: ethernet-phy@9 {
		reg = <0x09>;
		/* compatible = "ti,dp83822,ethernet-phy-ieee802.3-c22"; */
		rx-internal-delay-ps = <1>;         /* enable RX delay (fixed by driver) */
		reset-gpios = <&main_gpio0 8 GPIO_ACTIVE_LOW>;    /* P20 RESET_PHY_0 */
		interrupt-parent = <&main_gpio1>;
		interrupts = <39 IRQ_TYPE_LEVEL_LOW>;              /* N16 INT_PWDN_N.0 */
		 reset-assert-us = <1000>; 
		 reset-deassert-us = <1000>;
	};

	/* MDIO address 9 (RGMII2) — reset on N18 -> GPIO0_7 */
	cpsw3g_phy11: ethernet-phy@11 {
		reg = <0x11>;
		/* compatible = "ti,dp83822,ethernet-phy-ieee802.3-c22"; */
		rx-internal-delay-ps = <1>;         /* enable RX delay */
		reset-gpios = <&main_gpio0 9 GPIO_ACTIVE_LOW>;    /* N18 RESET_PHY_1 */
		interrupt-parent = <&main_gpio1>;
		interrupts = <40 IRQ_TYPE_LEVEL_LOW>;             /* N17 INT_PWDN_N.1 */
		reset-assert-us = <1000>; 
		reset-deassert-us = <1000>;
	};
};

据我所知、“rgmii-rxid"应该“应该是 DP83822I PHY 的正确设置、并且基于上面具有非零值的补丁  RX 内部延迟 ps  是否应该导致对 MAC 应用了正确的设置？
到目前为止、尝试时在获取任何网络流量方面都没有变化 DHCP u-boot 中的命令。

您好、James：  

对延迟的回复表示歉意。

1) 如果使用 SK-AM64B、在执行以太网引导（通过主引导或辅助引导模式设置）时、tiboot3.bin 传输似乎不会结束并继续移至 tispl.bin（注意：看不到 UART 输出）。

我们首先关注测试 SK-AM64B EVM 时发现的问题。

以下是我们要检查的有关您的设置的一些项目。

1.您可以共享 TFTP 和 DHCP 服务器配置文件吗?

2.您是否对 SDK 之上 u-boot 中的配置文件有任何更改？

3.在测试 U-boot 文件（tiboot3.bin 等）的 TFTP 传输时、是否可以显示 U-boot 日志？

4.是否使用 https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/11_02_08_02/exports/docs/linux/Foundational_Components /U-Boot/UG-Network-K3.html 中的指南 设置以太网引导？

2) 对于定制电路板、DHCP 请求会作出响应、但（一次除外）tiboot3.bin 传输不会开始。

如果在 TFTP 读取请求时出现以下情况、则可能会被防火墙阻止。 如果是、请尝试运行“sudo ufw allow“ /udp“、然后重新运行 DHCP 和 tftp 服务器

• 例如：“sudo ufw allow 69/udp“
• 

-道林

1.在这里粘贴内容
dhcpd：

# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
#
# Attention: If /etc/ltsp/dhcpd.conf exists, that will be used as
# configuration file instead of this file.
#

# option definitions common to all supported networks...
option domain-name "example.org";
option domain-name-servers ns1.example.org, ns2.example.org;

default-lease-time 600;
max-lease-time 7200;

ddns-update-style none;

authoritative;

option subnet-mask 255.255.255.0;
option broadcast-address 10.0.0.255;
option routers 10.0.0.1;


subnet 10.0.0.0 netmask 255.255.255.0
{
   allow bootp;
   range dynamic-bootp 10.0.0.2 10.0.0.16;
   range 10.0.0.17 10.0.0.100;
   default-lease-time 60000;
   max-lease-time 720000;
   next-server 10.0.0.1;
   always-broadcast on;

   if substring (option vendor-class-identifier, 0, 16) = "TI K3 Bootp Boot"
   {
      filename "tiboot3.bin";
   } elsif substring (option vendor-class-identifier, 0, 19) = "AM64X U-Boot R5 SPL"
   {
      filename "tispl.bin";
   } elsif substring (option vendor-class-identifier, 0, 20) = "AM64X U-Boot A53 SPL"
   {
      filename "u-boot.img";
   }

}

TFTP-HPA：

# /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure"

2.我仅使用重建.bin 和.img 文件  am64x_evm_r5_defconfigam64x_evm_a53_defconfig (removing the .config with custom configuration for the custom board). These match the defconfigs as of october 2025, from what I can see.

3. Yep - with the binaries above, I can see output after the tiboot3.bin finishes loading.

Welcome to minicom 2.8

OPTIONS: I18n                                                                
Port /dev/ttyUSB1, 13:14:34                                                  
                                                                             
Press CTRL-A Z for help on special keys                                      
                                                                             
                                                                             
U-Boot SPL 2025.01-g53c3fc94ae63-dirty (Feb 05 2026 - 12:41:46 +0100)        
Resetting on cold boot to workaround ErrataID:i2331                          
Please resend tiboot3.bin in case of UART/DFU boot                           
resetting ...                                                                
                                                                             
U-Boot SPL 2025.01-g53c3fc94ae63-dirty (Feb 05 2026 - 12:41:46 +0100)        
SYSFW ABI: 4.0 (firmware rev 0x000b '11.1.2--v11.01.02 (Fancy Rat)')         
EEPROM not available at 0x50, trying to read at 0x51                         
=== About to init DDR via UCLASS_RAM ===                                     
=== DDR init returned success ===                                            
=== Comprehensive DDR Test ===                                               
  @0x80000000: wrote 0xa5a50000, read 0xa5a50000 PASS                        
  @0x81000000: wrote 0xa5a50001, read 0xa5a50001 PASS
  @0x82000000: wrote 0xa5a50002, read 0xa5a50002 PASS
  @0x84000000: wrote 0xa5a50003, read 0xa5a50003 PASS                           
  @0x88000000: wrote 0xa5a50004, read 0xa5a50004 PASS                           
=== Walking bits test @0x82000000 ===                                           
  Walking bits PASS                                                             
=== Address uniqueness test ===                                                 
=== Cache coherency test ===                                                    
  After cache activity: read 0xdeadbeef PASS                                    
=== All DDR tests DONE ===                                                      
JGU get_boot_device: devstat = 0x10a3 bootmedia = 0x4 bootmode = 0              
=== [1] spl_relocate_stack_gd: Entry ===                                        
=== [2] CONFIG_SPL_STACK_R_ADDR = 0x82000000 ===                                
JGU: SPL initial stack usage: 13520 bytes                                       
=== [3] After stack check ===                                                   
SPL malloc() before relocation used 0x4248 bytes (16 KB)                        
=== [4] After malloc debug ===                                                  
=== [5] After malloc setup ===                                                  
=== Testing DDR at 0x81c00000 ===                                               
=== DDR test: wrote 0xDEADBEEF, read 0xdeadbeef PASS ===                        
=== [6] new ptr = 0x81ffff30 ===                                                
=== [7] About to memcpy ===                                                     
=== [8] After memcpy ===                                                        
=== [9] About to dm_fixup_for_gd_move ===                                       
=== [DM1] dm_fixup_for_gd_move entry ===                                        
=== [DM1a] gd=0x7011b730 new_gd=0x81ffff30 ===                                  
=== [DM1b] gd->dm_root=0x7011d95c ===                                           
=== [DM2] entered if: gd->dm_root exists ===                                    
=== [DM2a] new_gd->uclass_root=0x7011b7dc ===                                   
=== [DM2b] new_gd->uclass_root->next=0x7011f9d0 ===                             
=== [DM2c] About to write to next->prev ===                                     
=== [DM3] after next->prev before prev->next ===                                
=== [DM3a] new_gd->uclass_root->prev=0x7011d954 ===                             
=== [DM3b] About to write to prev->next ===                                     
=== [DM4] after prev->next  ===                                                 
=== [DM5] dm_fixup_for_gd_move exit ===                                         
=== [10] After dm_fixup_for_gd_move ===                                         
=== BOARD_INIT_R called (call #1) sp= gd= ===                                   
>>SPL: board_init_r()                                                           
spl_init                                                                        
JGU get_boot_device: devstat = 0x10a3 bootmedia = 0x4 bootmode = 0              
=== BOOT_FROM_DEVICES: count=5 ===                                              
=== Trying bootdev[0]=0x4 ===                                                   
=== Found loader for 0x4 ===                                                    
Trying to boot from eth device                                                  
Loading Environment from nowhere... OK                                          
                                                                                
Error: ethernet@8000000port@2 No valid MAC address found.                       
No ethernet found.                                                              
                                                                                
No Ethernet devices found                                                       
=== BOOT FAILED from 0x4 ===                                                    
SPL: failed to boot from all boot devices                                       
### ERROR ### Please RESET the board ###  

4.通常是（对于评估板）；b9->b0：00 1010 0011；对于定制板 — 关于搭接，DP83822 没有链路搭接。

防火墙 — 防火墙已禁用。

以下是 SK 评估板的照片、带有网络电缆、引导引脚、电源和控制台电缆：

您好、James：  

对延迟的回复表示歉意。  

我们的开发人员已了解该问题、他建议您看到的问题可能与 MAC 地址有关。 能否在 U-boot 中启用 CONFIG_NET_RANDOM_ETHADDR 配置选项以查看这是否会改变行为？

-道林

嗨、Daolin — 我已经尝试将 CONFIG_NET_Random_ETHADDR=y 添加到 R5 配置文件中；行为似乎没有任何变化。

进一步看看 表 1-1 (www.ti.com/.../snla450.pdf 中的内容 — 我是否应该期待这在进入 ts 之前应该有效？

您好、James：  

我将尝试在我的终端星期一上的 SK-AM64B 板上测试以太网启动、看看我是否遇到您的问题。 在过去的 SDK 版本中、只要使用 CPSW 以太网端口、以太网引导是主要引导模式、并且不对 SRAM 大小进行任何更改、SK-AM64B 以太网引导就可以正常工作。 因为它在过去是有效的、所以我假设 PHY U-boot 驱动程序也可以正常工作。 但是、可能已经对 U-boot 配置进行了更改、这些配置是在 SDK/U-boot 版本之间启用以太网引导所需的、因此我怀疑这一点、但首先我需要确认是否可以重现问题。

如果您没有收到任何更新的星期二、请通过 ping 通该主题。

-道林

您好、James：  

在使用 SDK 11.2 的 SK-AM64B 板上、我能够使用 SDK 中的默认 R5 defconfig 重现错误。

我 向 R5 defconfig 添加了 CONFIG_NET_Random_ETHADDR=y、重新构建 U-boot 二进制文件、并可以看到引导至 U-boot 正常工作。 我注意到您正在使用 SDK 11.1 进行测试、是否可以使用 SDK 11.2 进行测试？

U-Boot SPL 2025.01-g7493977a537f-dirty (Feb 23 2026 - 12:18:38 -0600)
Resetting on cold boot to workaround ErrataID:i2331
Please resend tiboot3.bin in case of UART/DFU boot
resetting ...

U-Boot SPL 2025.01-g7493977a537f-dirty (Feb 23 2026 - 12:18:38 -0600)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)')
EEPROM not available at 0x50, trying to read at 0x51
Set clock rates for '/a53@0', CPU: 1000MHz at Speed Grade 'S'
SPL initial stack usage: 13536 bytes
Trying to boot from eth device
Loading Environment from nowhere... OK

Warning: ethernet@8000000port@2 (eth1) using random MAC address - 32:ab:f3:7b:50:b4
eth1: ethernet@8000000port@2
ethernet@8000000port@2 Waiting for PHY auto negotiation to complete....... done
link up on port 2, speed 1000, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 172.168.1.51 (1267 ms)
Using ethernet@8000000port@2 device
TFTP from server 172.168.1.1; our IP address is 172.168.1.51
Filename 'tispl-am64x.bin'.
Load address: 0x82000000
Loading: ##################################################  1.1 MiB
         5.3 MiB/s
done
Bytes transferred = 1141355 (116a6b hex)
Authentication passed
Authentication passed
Loading Environment from nowhere... OK
init_env from device 4 not supported!
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.13.0(release):v2.13.0-259-ge0c4d3903b-dirty
NOTICE:  BL31: Built : 07:01:36, Jul  1 2025
I/TC: 
I/TC: OP-TEE version: 4.7.0-47-ga9690ae39 (gcc version 13.4.0 (GCC)) #1 Thu Aug  7 15:25:10 UTC 24
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check optee.readthedocs.io/.../porting_guidelinel
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)')
I/TC: Activated SA2UL device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: EIP76D TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: HUK Initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2025.01-g7493977a537f-dirty (Feb 23 2026 - 12:18:56 -0600)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5--v11.02.05 (Fancy Rat)')
Trying to boot from eth device
Loading Environment from nowhere... OK

Warning: ethernet@8000000port@2 (eth1) using random MAC address - 92:07:10:dc:93:8e
eth1: ethernet@8000000port@2
ethernet@8000000port@2 Waiting for PHY auto negotiation to complete....... done
link up on port 2, speed 1000, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 172.168.1.52 (1305 ms)
Using ethernet@8000000port@2 device
TFTP from server 172.168.1.1; our IP address is 172.168.1.52
Filename 'u-boot-am64x.img'.
Load address: 0x82000000
Loading: ##################################################  1.4 MiB
         1.1 MiB/s
done
Bytes transferred = 1507243 (16ffab hex)
Authentication passed
Authentication passed


U-Boot 2025.01-g7493977a537f-dirty (Feb 23 2026 - 12:18:56 -0600)

SoC:   AM64X SR2.0 HS-FS
Model: Texas Instruments AM642 SK
Board: AM64B-SKEVM rev A
DRAM:  2 GiB
Core:  102 devices, 34 uclasses, devicetree: separate
MMC:   mmc@fa00000: 1
Loading Environment from nowhere... OK
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Failed to probe prueth driver
Net:   eth0: ethernet@8000000port@1, eth1: ethernet@8000000port@2
Hit any key to stop autoboot:  0 
=> 

-道林

你好道林 — 我会试着看看我能做什么;现在我试图追逐一些其他错误,所以可能是一些时间.
也就是说、这是版本 11.02.08.02 吗？

您好、James：  

是的、这正是要尝试的版本（我使用 SDK 11.2 作为参考 SDK 11.02.08.02 的捷径）

-道林