DP83867IR: Disabling TX_CLK

Hi Adam,

Let me consult with my team on whether this is possible. I can get back to you tomorrow.

Regards,

Adrian Kam

Hi Adam,

What MAC interface are you using? If it is MII, then TX_CLK is required and cannot be disabled.

In addition, what kind of issue are you seeing where TX_CLK could be the cause?

Regards,

Adrian Kam

Hi Adrian, thanks for the response! We are using RGMII. We are suspecting that 25MHz TX_CLK is interfering with GPS performance.

Hi Adam,

I will have to consult my team again, as there may be a way to disable it. It might require some experiments, so I can get back to you by Tuesday at the latest on whether it is possible.

Regards,

Adrian Kam

Hi Adam,

Can you read register 0x0032 and check to see if bit[11] is 0 or 1?

Regards,

Adrian Kam

Hi Adrian, thanks for the response. By 0x0032, do you mean RGMII Control Register (RGMIICTL)? If so, I don't know how to talk the the PHY over MDIO from Linux (I can do it from U-Boot with MII cmd). Do you have a Linux tool that works with DP83867? I vaguely remember trying out the mii-tool (from net-tools) and it wasn't compatible with my PHY.

Hi Adam,

The Linux driver for DP83867 can be found at the link below. The driver should contain a function that will allow you to read registers. Using U-Boot should be fine as well. If you are having issues reading the register, try using the extended register read procedure detailed in section 8.4.2.1 of the datasheet.

https://www.ti.com/tool/ETHERNET-SW

Regards,

Adrian Kam

Thanks Adrian, let me take a look.

Also, I think I have the answer you are looking for:

root@sg3:~# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: d
        Wake-on: d
        Current message level: 0x00000000 (0)

        Link detected: yes
        
root@sg3:~# ethtool --register-dump eth0
Offset          Values
------          ------
0x0000:         00 00 00 00 00 00 01 20 03 00 03 03 1c 00 00 00
0x0010:         ff ff 01 30 ff ff ff ff 01 00 00 00 a9 d8 01 30
0x0020:         c5 07 4b 8b 00 00 00 00 00 00 00 20 07 00 00 07
0x0030:         01 00 00 00 a9 d8 01 30 c4 07 4b 8b 00 00 00 00
0x0040:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0050:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0x32 is read as 0x0. Am I looking at the right stuff?

Hi Adam,

From my experience, when it comes to a register dump of that format, there are usually 32 values per row. Each PHY register is 16 bits, so the first two values will be the value for register 0x0000, second two values for register 0x0001, etc. Can you double check if that command works properly or can be used?

If reading works properly, reading register 0x0002 and 0x0003 should yield the default values stated in the datasheet.

Regards,

Adrian Kam