05-08-2020 08:47 AM
I have a customzied zynq Ultrascale+ board with TI DP83822H PHY chip. We are using PS GEM as ethernet controller and operates in rgmii mode, 100Mbps. I have enabled the dp83822_phy driver in petalinux kernel and from the linux boot log I can see the driver is successfully attached with correct phy address, but the link is never up. I could only get: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready.
I tried to reset the eth0 device, and got:
status = "okay";
phy-mode = "rgmii-id";
#address-cells = <1>;
#size-cells = <0>;
device_type = "ethernet-phy";
max-speed = <100>;
reg = <0x9>;
05-10-2020 12:39 AM
As we haven't tested this PHY ever, we are not sure of the device tree entries required to make this PHY operation.
However, you can give it a try after removing device_type = "ethernet-phy"; & max-speed = <100>;
Also, make sure that the PHY ID is correct
05-11-2020 09:35 AM
Thanks for your reply. I tried your suggestion but the result was still the same.
Do you know where I can find information on what device tree entries are needed for this phy? I looked at the driver source code for this phy: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/phy/dp83822.c. It doesn't seem that it is probing the device tree at all.
Regarding the phy id, are you talking about the phy address? We are using phy address 9 on our device. Does the <reg> property in the device tree means the same thing as the phy address? I have looked at several examples where they always set the <reg> property the same value as the phy address, but I'm not sure if this is really needed.
05-13-2020 01:52 AM
05-14-2020 08:28 AM - edited 05-14-2020 08:37 AM
Thank you for your suggestion. I don't see any RGMIIDCTL register in DP83822H datasheet, but there is a RCSR register which can be written to enable RX/TX clock delay by 3.5ns:
I tried enabling RX only, TX only and both but nothing changed. I also have tried adding phy-mode = "rgmii-id" in the device tree but the result is still the same.
These days I have new findings:
but at much lower frequency.
05-14-2020 12:32 PM
05-15-2020 05:31 AM
@fincs No, when I turn off auto negotiation on both sides, I can only see the leds blinking on ethernet port when the speed is set to 10Mbps, but there is no data at all. From petalinux terminal I see eth0: link up and then down once, and it's not possible to ping from either side.
05-15-2020 11:07 AM
Try using Loopback https://www.ti.com/lit/ds/symlink/dp83822h.pdf?&ts=1589564948687(page 42). Will a link be installed and data transferred?
Is the Bootstrap Configurations set correctly?
05-19-2020 08:06 AM
Does the ethernet PHY work in U-Boot? If yes, then it is an issue with linux configuration. Else, the issue is at hardware level.
Regarding to your question about PHY driver, the PHY does not need any specific property, so there are no of_* function calls. generic properties needed are handled in MAC driver.
05-19-2020 10:00 AM
I have solved the previous problem of autonegotiation not working. It was hardware related. On the DP83822 datasheet, it mentioned: Center tap of the transformer must be connected to analog supply rail (3.3V), which was not done in our board. After applying the patch, we are able to get the link established, and we are able to ping from both sides.
But now we have another problem: The phy device cannot always be detected in uboot. When I boot the board from flash, sometimes phy can be detected in uboot and sometimes not, which is a very random behavior. I know this sounds like a hardware related problem, but we have checked all the configuration pins and clock pin on the phy chip, and they all look good. We are also sure that the reset pin is released before linux tries to talk to phy using mdio.
I'm attaching the boot logs of different behaviors to the reply. Do you have any idea on what I should check?