• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 1016 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83867IR: eth0 Link Status goes down after ifdown eth1

SeanHC Lin
Intellectual 400 points
Part Number: DP83867IR

Hi TI Team,

We use DP83867IRPAPT,

After setting the eth1 link down, the eth0 Link Status went down unexpectedly.

There is my test scenario:

$ ifconfig eth0 up;  ifconfig eth1 up

TI DP83867 8000f00.mdio:00: attached PHY driver [TI DP83867] (mii_bus:phy_addr=8000f00.mdio:00, irq=POLL)
am65-cpsw-nuss 8000000.ethernet eth0: Link is Down
TI DP83867 8000f00.mdio:01: attached PHY driver [TI DP83867] (mii_bus:phy_addr=8000f00.mdio:01, irq=POLL)
am65-cpsw-nuss 8000000.ethernet eth1: Link is Down
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off

$ ifconfig | grep eth.:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
eth1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500

$ ./mdio-tool r eth0 1 # BMSR register 
0x796d

After eth0 works. I turned off eth1. eth0 also lost the link unexpectedly.

$ ifconfig eth1 down
am65-cpsw-nuss 8000000.ethernet eth0: Link is Down

$ ifconfig eth0
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500

$ ./mdio-tool r eth0 17 # STS2 register
0x1140

$ ./mdio-tool r eth0 0 # BMCR register
0x1140

$ ./mdio-tool r eth0 1 # BMSR register
0x1140

OS polls the link status of all LANs, in genphy_update_link( ) at drivers/net/phy/phy_device.c.

Getting the Phy Link Status via davinci_mdiobb_read( ) at drivers/net/ethernet/ti/davinci_mdio.c

 I am sure the driver using the correct Phy ID to write the eth1 MDIO register.

davinci_mdiobb_write(struct mii_bus *bus, int phy, int reg, u16 val)

I don't know why it affects the other PHY (eth0).

Only writing to the eth1 (PHY1) MDIO register would cause the eth0 (PHY0) link to go down.

If I swap eth0 and eth1 roles and do the test, there is no problem.

Writing to the PHY0 MDIO register affects only himself.

Could someone provide some clues on this issue?

Thanks,

Sean

 

  • 0
    TI__Intellectual 2260 points

    Sean,

    I suggest going through the following:

    • Check connection on eth1 (interface?)
    • Verify if register reads are correct
    • Check what processor is running both PHYs
      • Are both 867?
    • Provide more details on setup (block diagram, schematic, etc.)
    • Double-check PHY addresses by reading bits 0 to 3 of register 6E
    • Confirm correct strapping of PHY
      • Confirm with datasheet

    Please let me know how this goes and we can investigate further!

    Sincerely,

    Jason Lee

  • 0 in reply to James Lee
    Prodigy 150 points

    Hi Jason, Sean

    Reply as below

    • Check connection on eth1 (interface?) => eth1 & 2 interfaces are RGMII.
    • Check what processor is running both PHYs => Both PHY are DP83867IRPAPT.
    • Provide more details on setup (block diagram, schematic, etc.) => The block diagram is such as the below picture.
    • Confirm correct strapping of PHY => Yes, we have checked the strapping, Please refer below drawing.


      BR,
      Taylor
  • 0 in reply to James Lee
    Intellectual 400 points

    Hi Jason, Taylor,

    root@# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::290:e8ff:fe11:2244  prefixlen 64  scopeid 0x20<link>
        ether 00:90:e8:11:22:44  txqueuelen 1000  (Ethernet)
        RX packets 173  bytes 47890 (46.7 KiB)
        RX errors 0  dropped 58  overruns 0  frame 0
        TX packets 233  bytes 16278 (15.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


root@# ./mdio-tool r eth0 0
0x1140
root@# ./mdio-tool r eth0 1
0x796d
root@# ./mdio-tool r eth0 2
0x2000
root@# ./mdio-tool r eth0 3
0xa231

root@# ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::290:e8ff:fe11:2245  prefixlen 64  scopeid 0x20<link>
        ether 00:90:e8:11:22:45  txqueuelen 1000  (Ethernet)
        RX packets 578  bytes 116552 (113.8 KiB)
        RX errors 0  dropped 232  overruns 0  frame 0
        TX packets 27  bytes 1566 (1.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
root@# ./mdio-tool r eth1 0
0x1140
root@# ./mdio-tool r eth1 1
0x796d
root@# ./mdio-tool r eth1 2
0x2000
root@# ./mdio-tool r eth1 3
0xa231

    • Double-check PHY addresses by reading bits 0 to 3 of register 6E =>

    When the error occurs the register bits 0 to 3 of 6E Reg are: 

    bit : 4 3 2 1 0

    Val: 0 1 0 1 0 = 10

    root@# ./mdio-tool r eth0 0x6e
    0xffea

    Some register values are:

    Reg Value at  eth0 running Value when the error occurs 
    0x0 MBCR 0x1140 0x1140
    0x1 BMSR 0x796d 0x1140
    0x2 PHYIDR1 0x2000 0x1140
    0x3 PHYIDR2 0xa231 0x1140
    0x4 ANAR 0x01e1 0x1140
    0x5 ANLPAR 0xc5e1 0x1140
    0x6 ANER 0x006f 0x1140
    0x7 ANNPTR 0x2001 0x1140
    0x8 ANNPTR 0x4806 0x1140
    0x9 CFG1 0x0300 0x1140
    0xa STS1 0x3800 0x1140
    0xd REGCR 0x401f 0x401f
    0xe ADDAR 0x0007 0x1140
    0xf 1KSCR 0x3000 0x1140
    0x10 PHYCR 0x5048 0x1140
    0x11 PHYSTS 0xac3e 0x1140
    0x12 MICR 0x0000 0x1140
    0x13 ISR 0x1c42 0x1140
    0x14 CFG2 0x2bc7 0x1140
    0x15 RECR 0x0000 0x1140
    0x16 BISCR 0x0000 0x1140
    0x17 STS2 0x0040 0x1140
    0x18 LEDCR1 0xd156 0x1140
    0x19 LEDCR2 0x4444 0x1140
    0x1a LEDCR3 0x0002 0x1140
    0x1e CFG3 0x0202 0x1140
    0x1f CTRL 0x0000 0x1140
    0x2c FLD_CFG 0xffea 0xffea
    0x2d FLD_CFG 0xffea 0xffea
    0x31 CFG4 0xffea 0xffea
    0x32 RGMIICTL 0xffea 0xffea
    0x33 RGMIICTL2 0xffea 0xffea
    0x39 BICSR1 0xffea 0xffea
    0x43 100CR 0xffea 0xffea
    0x6e STRAP_STS1 0xffea 0xffea
    0x6f STRAP_STS2 0xffea 0xffea
    0x86 RGMIIDCTL 0xffea 0xffea
    0xfe LOOPCR 0xffea 0xffea
    0x134 RXFCFG 0xffea 0xffea
    0x135 RXFSTS 0xffea 0xffea
    0x136 RXFPMD1 0xffea 0xffea
    0x1a7 ALCD_CTRL 0xffea 0xffea
  • 0 in reply to SeanHC Lin
    TI__Intellectual 2260 points

    Sean and Taylor,

    I am going to meet with the Apps team tomorrow morning to confirm and verify these results. Thank you for your patience!

    Sincerely,

    Jason Lee

  • 0 in reply to James Lee
    TI__Intellectual 2260 points

    Sean and Taylor,

    I met with our Apps team and noted that:

    • There are different values from schematic and register reads provided for PHY Addresses of eth0 and eth1
    • For MDIO00 and MDIO01, do these correspond to PHY Address 00 and 01?
    • They are trying to directly access 6E register. This will not work (Please see Section 8.4.2.1 in the datasheet for proper read procedure for extended registers. (This is why the same values are populating after 0x1E)
    • There is an issue with register reads after 0x1140

    Sincerely,

    Jason Lee

  • 0 in reply to James Lee
    Prodigy 150 points

    Hi Jason

    PHY Address is 00 & 01. 

    BR,
    Taylor

  • 0 in reply to Taylor Lin
    TI__Intellectual 2260 points

    Taylor,

    I believe that they are still trying to directly access the registers. Please see Section 8.4.2.1 in the datasheet for proper read procedure for extended registers. (This is why the same values are populating after 0x1E.) Thank you!

    Sincerely,

    Jason Lee

  • 0 in reply to James Lee
    Intellectual 400 points

    Hi Jason,

    The register 0x1e shows the PHY ID is correct.

    # Read register 0x6e of Phy0

    root@# ./mdio-tool w eth0 d 1f
root@# ./mdio-tool w eth0 e 6e
root@# ./mdio-tool w eth0 d 401f
root@# ./mdio-tool r eth0 e
0xe000


    # Read register 0x6e of Phy1

    root@# ./mdio-tool w eth1 d 1f
root@# ./mdio-tool w eth1 e 6e
root@# ./mdio-tool w eth1 d 401f
root@# ./mdio-tool r eth1 e
0xe001

    Thanks,

    Sean

  • 0 in reply to SeanHC Lin
    TI__Intellectual 2260 points

    Sean,

    To confirm, are you able to read all the other registers properly now?

    SeanHC Lin said:
    Only writing to the eth1 (PHY1) MDIO register would cause the eth0 (PHY0) link to go down.

    I assume that you were doing this in Linux terminal through a software approach. Have you tried this test manually by unplugging the cable to eth1? We are trying to determine if this is a hardware or software issue.

    Sincerely,

    Jason Lee