cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
782 Views
Registered: ‎09-17-2018

ZynqMP PS GEM + TI DP83822H PHY not working on petalinux

Hi,

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:

root@gollum:~# ifconfig eth0 down
[  526.048044] macb ff0c0000.ethernet: gem-ptp-timer ptp clock unregistered.
root@gollum:~# ifconfig eth0 up
[  529.288324] pps pps0: new PPS source ptp0
[  529.292422] macb ff0c0000.ethernet: gem-ptp-timer ptp clock registered.
[  529.299259] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
 
My device tree for ethernet is as follows:

&gem1 {
   status = "okay";
   phy-mode = "rgmii-id";

   mdio {
      #address-cells = <1>;
      #size-cells = <0>;
      ethernet-phy@9 {
         device_type = "ethernet-phy";
         max-speed = <100>;
         reg = <0x9>;
      };
   };
};

I know there are some patches which should be applied to the device tree for TI dp83867 device, but I don't think they are useful for our device.
I attached the full boot log to this post. Does anyone has any thoughts on this? Thanks in advance!
 
0 Kudos
10 Replies
Highlighted
Moderator
Moderator
717 Views
Registered: ‎12-04-2016

Hi @xinyiz 

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

 

Best Regards

Shabbir

0 Kudos
Highlighted
Contributor
Contributor
671 Views
Registered: ‎09-17-2018

Hi Shabbir,

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.

Thanks!

 

0 Kudos
Highlighted
Adventurer
Adventurer
625 Views
Registered: ‎03-21-2016

You can try to shift the clock signal relative to the data, maybe the board has a problem. Look at 8.6.43 RGMII Delay Control Register (RGMIIDCTL) in DP83822H datasheet.
0 Kudos
Highlighted
Contributor
Contributor
588 Views
Registered: ‎09-17-2018

Hi @fincs 

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:

register_rcsr.png

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: 

  • By default auto negotiation is enabled both on the phy chip and on my host, with which I could only get IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready after petalinux boots.
  • When I tried disabling auto negotiation on Host, I saw petalinux printing continuosly:

target_adv.png

  • When disabling auto negotiation on zynq and enabling it on host, I got:

host_adv.png'

          but at much lower frequency.

  • When disabling auto negotiation on both sides, I can only get eth0 link up and then down once when forcing the speed on both sides to be 10Mbps. When speed is 100Mbps, nothing happens.

@shabbirk @fincs @Others, do you have any idea on this?

0 Kudos
Highlighted
Adventurer
Adventurer
566 Views
Registered: ‎03-21-2016

Sorry, I saw the RGMIIDCTL in the document on another chip.
Total, if you turn off the auto-negotiation on two sides, that is, a link at a speed of 10 Mbit / s? Data is transferred in this case?
0 Kudos
Highlighted
Contributor
Contributor
520 Views
Registered: ‎09-17-2018

@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.

0 Kudos
Highlighted
Adventurer
Adventurer
501 Views
Registered: ‎03-21-2016

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?

Spoiler
0 Kudos
Highlighted
Moderator
Moderator
411 Views
Registered: ‎03-10-2020

@xinyiz,

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.

0 Kudos
Highlighted
Contributor
Contributor
393 Views
Registered: ‎09-17-2018

Hi @nishak @fincs :

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?

Thanks!

0 Kudos
Highlighted
Moderator
Moderator
345 Views
Registered: ‎03-10-2020

@xinyiz,

You could try "mii dump" at U-Boot console to debug the issue. 

"mii dump <phy-id> 1" should give you the status register details.