DP83867IR: forced master

Hi Carla!

Thank you for submitting your query. There could be a number of reasons for this. To confirm, your board has two ethernet ports, one of which is working and the non-working one is using the DP83867. Do both PHYs share a common MDC/MDIO bus to the processor? If so, then they need to have unique PHY Addresses. Please confirm if the driver was loaded correctly, that can be done by using the command 'dmesg | grep mdio'.

Please refer to snla450 for more driver debug information.

Regards,

Alvaro 

 Hello, Alvaro,
I'm sorry, I explained myself badly.

I meant that for the first ethernet port, the hardware is on the toradex verdin am62 board.
Only the second ethernet port has my hardware.
I configured it in the device tree and each ethernet port has a different phy.

Here is the output of `dmesg | grep mdio`:

torizon@verdin-am62-15363911:~$ dmesg | grep mdio
[    1.202953] davinci_mdio 8000f00.mdio: Configuring MDIO in manual mode
[    1.254438] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000
[    1.445260] davinci_mdio 8000f00.mdio: Configuring MDIO in manual mode
[    1.504480] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000
[    1.525086] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver TI DP83867
[    1.525118] davinci_mdio 8000f00.mdio: phy[1]: device 8000f00.mdio:01, driver TI DP83867
[    8.909827] am65-cpsw-nuss 8000000.ethernet ethernet1: PHY [8000f00.mdio:01] driver [TI DP83867] (irq=370)
[    9.013740] am65-cpsw-nuss 8000000.ethernet ethernet0: PHY [8000f00.mdio:00] driver [TI DP83867] (irq=357)

Best Regards,

Carla

Hi Carla,

Excellent, both DP83867's are recognized and they both have a unique PHY Address: 0 & 1. 

How are the MDC/MDIO lines connected to the host controller? Would you be able to send the schematic?

Regards,

Alvaro

Hi Alvaro, 

I have already sent the schematic in 1st post. 

But here are the images of the schematic:

Best regards,

Carla 

Hi Carla,

Thankyou for resending the Schematics, I missed them in the original post. I'm not sure I understand your current board configuration. You have a carrier board with 2 ethernet ports. The first port is connected to the toradex am62 verdin board and the second port to your custom board. The schematics you sent are of your customer board correct? Where the RGMII, MDC, & MDIO signals are sent out through the 2309409-2 connector. Where do these signals go after? Could you confirm where the MAC and PHYs are on each board?

Regards,

Alvaro

Hi Alvaro,

I believe first is better to clarify the custom board schematic and the straps accordingly.

So, the 2309409-2 connectors are both inputs for the verdin IO's, where RGMII, MDC and MDIO signals go, as per the image:

So, I have defined the following configurations:

• PHY address for 0x1
• Auto negotiation ON
• RGMII-RXID mode
• rx-interval-delay = 2ns
• tx-interval-delay = 0ns
• advertise ability of 10/100/1000

The straps configuration for this, which are different from the image are:

• RX_D0
  • R5 10k
  • R54 2.49k
•  RX_D2
  • R91 open
  • R93 open
• RX_CTRL
  • R84 5.76k
  • R143 2.49k
• GPIO0:
  • R96 open
  • R97 open
• GPIO1
  • R98 open
  • R99 open
• ANGSEL/TX2
  • R102 10k
  • R105 2.49K
• MIRROR EN
  • R92 open
  • R94 open
• TX1/TX0
  • R109 open
  • R110 open

After this configuration, the verdin driver for DP83867 detects the IC and the output from ' ethtool ethernet1 ' is the following:

Settings for ethernet1:
	Supported ports: [ TP	 MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	                        1000baseX/Full
	Supported pause frame use: Symmetric
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	                        1000baseX/Full
	Advertised pause frame use: Symmetric
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: Unknown!
	Duplex: Unknown! (255)
	Auto-negotiation: on
	master-slave cfg: forced master
	master-slave status: resolution error
	Port: MII
	PHYAD: 1
	Transceiver: external
netlink error: Operation not permitted
        Current message level: 0x000020f7 (8439)
                               drv probe link ifdown ifup rx_err tx_err hw
	Link detected: no

Where the master-slave configuration is always forced-slave even after connecting to other machine (PC). It seems that it can't negotiate with the other machine.

Another thing is when trying to read the register of the DP83867 using mdio-tool, the built-in IC with reg 0x0 shows the registers:

root@verdin-am62-15363911:~/mdio-tool# mdio-tool -e ethernet0 -r -a 0x0 -l 0x0A
Probed phyaddr: 0
PHY: 0|REG: 0 ---> 0x1140
PHY: 0|REG: 1 ---> 0x796d
PHY: 0|REG: 2 ---> 0x2000
PHY: 0|REG: 3 ---> 0xa231
PHY: 0|REG: 4 ---> 0x05e1
PHY: 0|REG: 5 ---> 0x41e1
PHY: 0|REG: 6 ---> 0x0065
PHY: 0|REG: 7 ---> 0x2001
PHY: 0|REG: 8 ---> 0x0000
PHY: 0|REG: 9 ---> 0x0200

However the DP83867 on the custom board shows all register as 0xFFFF:

root@verdin-am62-15363911:~/mdio-tool# mdio-tool -e ethernet1 -r -a 0x0 -l 0x0A
Probed phyaddr: 1
PHY: 1|REG: 0 ---> 0xffff
PHY: 1|REG: 1 ---> 0xffff
PHY: 1|REG: 2 ---> 0xffff
PHY: 1|REG: 3 ---> 0xffff
PHY: 1|REG: 4 ---> 0xffff
PHY: 1|REG: 5 ---> 0xffff
PHY: 1|REG: 6 ---> 0xffff
PHY: 1|REG: 7 ---> 0xffff
PHY: 1|REG: 8 ---> 0xffff
PHY: 1|REG: 9 ---> 0xffff

Any other question, feel free to ask.

Thank you.

Regards.

Hi Carla,

Please allow me another day to review.

Regards,

Alvaro

Hi Carla,

Thank you for confirming the strapping, but these settings do not affect the register access issue you are having. Do both PHYs' MDC/MDIO pins go to the same processor? From the output of the dmesg command we can see that the PHY[1] is correctly identified on the MDIO bus as the DP83867, this requires register access. 

Carla Faria said:

Here is the output of `dmesg | grep mdio`:

Fullscreen

Could you try:

ifconfig eth1 down

ifconfig eth1 up

This will cause the driver to be re-loaded. After, please run dmesg | grep mdio again to see if it is recognized again.

Regards,

Alvaro