We have made a carrier board that mostly matches the ref design on the dev kit.
But with a few differences.
One difference we’re not using the periphs enable signal. The regulators are directly powering the PHY KSZ chip.
The other main difference is we’re only using 100mb mode so only 2 of the twisted pair are connected to the RK45 jack.
The trouble is this PHY isnt working, and linux isnt connecting to it.
The design ref:
We actually have two problems, the Activity LEDS also are not working but that is likely a separate issue.
The KSZ negotiates a 100mb connection as seen on my switch but in Linux it refuses to connect, leaving me with the message Pending. But it also says “platform regulator-eth2phy: deferred probe pending”.
We currently have the assumption the driver is waiting for some signal from somewhere that the regulators that drive the PHY circuit are live and at voltage, but looking at the reference schematic I simply can not see any feedback for the voltage regs.
Clearly I’ve missed something but what?
Also interestingly in uboot, the PHY gets an IP address and I am able to ping other devices on my network.
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
The issue you’re experiencing with the Ethernet PHY not connecting in Linux, despite functioning in U-Boot, likely stems from the configuration in the Linux device tree or the power management setup.
The message “deferred probe pending” typically indicates that the driver is waiting for a resource, such as a regulator, to become available. Since you’ve mentioned that the PHY is directly powered and not using a peripheral enable signal, it’s possible that the device tree configuration needs to be adjusted to reflect this setup.
Here are some steps you can take to troubleshoot and resolve the issue:
Device Tree Configuration: Ensure that the device tree correctly defines the PHY and any associated power control signals. If the PHY is directly powered, you may need to remove or modify any references to a power enable GPIO in the device tree.
Power Supply Verification: Double-check that the power supply to the PHY is stable and meets the required voltage and current specifications. Any instability could cause the PHY to not initialize correctly.
Driver and Kernel Logs: Check the kernel logs (dmesg) for any additional error messages related to the Ethernet interface. This might provide more insight into what the driver is waiting for.
U-Boot vs. Linux Configuration: Since the PHY works in U-Boot, compare the U-Boot and Linux configurations to identify any differences. This might include PHY initialization sequences or specific settings that are not being applied in Linux.
Activity LEDs: While this might be a separate issue, ensure that the LED configuration in the device tree matches your hardware setup.
By focusing on these areas, you should be able to identify and resolve the issue preventing the PHY from connecting in Linux. If the problem persists, further investigation into the specific driver and hardware interactions may be necessary.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
I would double check the device tree as the default Ethernet phy regulators I believe are configured to use the peripheral enable signal.
In my project we defined a new “always on” regulator and set the phy regulator to that. Then the kernel driver shouldn’t get held up waiting for the regulator.
Im not the linux dev so ill try and get our guy to try this. But in the mean time. Do you know how its getting the feedback that the regulators are primed or not?
As I may end up having to re add in the power control for them.
Also, another point which is worth checking is which device tree is being loaded.
The Verdin Development Board device tree has support for a second ethernet port, but this is not the case for all Verdin carrier boards.
By default it should load the Verdin Development Board device tree, but double-checking would be recommended.
While we have managed to get pings out in Linux by going around the regulator… Do you know where this feed back for the regulator is on the dev kit?
on the devkit what is the vardin probing to see if the regulators are live for the external phy?
In this case, it is not really sensing that the power supply is enabled or disabled.
What was most likely happening is that the GPIO expander which is used to enable the power supply was not initialized.
If you don’t have the same PCAL6416AHF GPIO expander we have on our Verdin Development Board, this initialization was failing and the ethernet phy, which depended on it, had its probe deferred.
