SPRADD1A August 2023 – September 2024 AM620-Q1 , AM623 , AM625 , AM625-Q1 , AM625SIP , AM62A3 , AM62A3-Q1 , AM62A7 , AM62A7-Q1 , AM62P , AM62P-Q1
Suppose this devicetree is used to generate U-Boot binaries to test the Ethernet configuration. After transferring u-boot.img over UART per the sections above, the U-Boot console output is displayed below when any key is used to stop 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 status of the Ethernet configuration at this point. An error message shows that Ethernet port 1 is recognizing the PHY as operating in an invalid mode. This likely points to a devicetree issue, as the message indicates the PHY is either not operating in the correct mode, or the Ethernet port is not recognizing the mode the PHY is operating in.
To fix this error, look to the PHY and Ethernet port nodes as the possible causes. In the EVM devicetree, the port node has a property "phy-mode" that is set to "rgmii-rxid". A search on the property assignment, "rgmii-rxid", finds the binding file ethernet-controller.yaml. This file specifies that "phy-mode" is set in the port node to specify the interface between the PHY and Ethernet port. The bindings specify that "rgmii_rxid" should be set as the "phy-mode" if the PHY provides a RX delay. Since an RX delay was set as required by the PHY bindings in an earlier step, the property applies and is added to the devicetree.
&cpsw_port1 {
phy-handle = <&cpsw3g_phy0>;
+ phy-mode = "rgmii-rxid";
};
This highlights the iterative process that eventually results in a functional board devicetree. Once this fix is applied, rebuilding and reloading U-Boot over UART should show a functional Ethernet port available to U-Boot. This port can now be used to transfer the larger images needed to load Linux.