SPRADD1B August 2023 – September 2026 AM620-Q1 , AM623 , AM625 , AM625-Q1 , AM625SIP , AM62A1-Q1 , AM62A3 , AM62A3-Q1 , AM62A7 , AM62A7-Q1 , AM62P , AM62P-Q1
Suppose U-Boot has been built with no errors, and the resulting binaries are boot-tested after updating the Ethernet configuration. After transferring u-boot.img over UART, the U-Boot console output displays as shown below when any key is pressed to abort autoboot:
U-Boot 2024.04-00007-g344db2cf625-dirty (Jul 23 2024 - 09:05:14 -0500)
SoC: AM62X SR1.0 HS-FS
Model: Texas Instruments AM625 SK
EEPROM not available at 0x50, trying to read at 0x51
Reading on-board EEPROM at 0x51 failed -121
DRAM: 2 GiB
Core: 40 devices, 22 uclasses, devicetree: separate
MMC: mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from nowhere... OK
In: serial
Out: serial
Err: serial
EEPROM not available at 0x50, trying to read at 0x51
Net: am65_cpsw_nuss_port ethernet@8000000port@1: Invalid PHY mode, port 1
No ethernet found.
Hit any key to stop autoboot: 0
=> The Net field indicates the runtime status of the Ethernet configuration. In this scenario, the error log reveals that the Ethernet Port 1 PHY is operating in an invalid mode. This behavior typically points to a device tree configuration issue, indicating that the PHY is configured in the incorrect or unsupported mode.
To resolve this error, inspect both the PHY and Ethernet MAC port nodes as potential root causes. In the reference EVM device tree, the port node contains a phy-mode property set to "rgmii-rxid". Searching for this value points us to $TI_U_BOOT/dts/upstream/Bindings/net/ethernet-controller.yaml file, which specifies that phy-mode defines the interface between the PHY and Ethernet port. The bindings states that "rgmii-rxid" must be used if the PHY provides an internal RX delay. Since an RX delay was already configured as required by the PHY bindings in an earlier step, this property applies and must be added to the port node.
&cpsw_port2 {
phy-handle = <&cpsw3g_phy1>;
+ phy-mode = "rgmii-rxid";
};This troubleshooting loop highlights the iterative workflow required to develop a fully functional board device tree. Once the fix is applied, rebuilding U-Boot and booting over UART confirms that the Ethernet port is active and available. This high speed interface can now be utilized to efficiently transfer the larger images and boot the Linux kernel.