DP83867IR: DP83867 modules not showing up when configured.

Hi Ray,

To try and narrow down the issue I have the following questions:

1. What is the bootstrap on RX_CTRL?

2. How have you strapped the PHY address?

3. How have you strapped the LED's? Are you only checking the LED's to check for link or are you checking the PHY_STS register?

4. Are still able to read and write registers?

5. What is the pull-up on the MDIO line?

Thank you,

Nikhil

I will try to get all those specifics on Monday. We are using two PHY ICs. One is strapped for reg 0, the other 1. And the RX/TX lines are not strapped for mode 1. I have not attempted to read any mdio registers. Can it be done from linux terminal, I've never done that?

I was able to force the kernel to boot using the DP83867 Driver by adding “CONFIG_DP83867_PHY=y” to /u-boot/configs/am335x_evm_defconfig.txt file and compiling on the laptop using the “gcc-linaro-6.5.0-2018.12-x86_64_arm-linux-gnueabihf” cross compiler. It shows as active in "lsmod" modules readout and in syslog it shows both phys assigned to dp83867 driver.

I still cannot ping or SSH the Dev board from my laptop by setting a static IP address (ie 192.168.10.1) and updating /etc/network/interfaces on the Dev board to make eth0 static with a matching IP address (ie 192.168.10.2).  I now noticed when I add my overlay as active, it will drop out the USB virtual connection now. I was thinking slaves = <2>; would fix it in the device tree for MAC. Nope.

But...There has to be some kind of negotiation going on as when it was loading the Generic PHY it would default to 1Gps Full, but now only goes to 100Mbps Full.

Using my laptop with "tcpdump" I never get an ARP or packets  with my dev board IP Address. I would think if I was  not connecting at all though, I would only get a 10Mbps connection.

Hi Ray,

You may read the registers through the MDIO/MDC pins with our USB-2-MDIO tool. This may be useful for debug, rather than adding read statements to your linux code. This forum focuses on the Physical Layer, so as we wait for the specifics on your hardware setup, you may want to post this question on processor forum in parallel.  

Thank you,

Nikhil

Nikhil,

1. What is the bootstrap on RX_CTRL?  Strapped with a 5.76k Ohm (to 3.3v) and 2.49k Ohm (to DGND). This should put it in Mode 3 (Auto Neg On).

2. How have you strapped the PHY address? Our PHY1 = 0 (No Strap). Our PHY2 = 1, RXD0 strapped with 2.49k Ohm (to DGND) and 10k Ohm (to 3.3v).

3. How have you strapped the LED's? Are you only checking the LED's to check for link or are you checking the PHY_STS register?

LED0 = No strap - just 560 Ohm resistor, LED1 = Strapped with 2.49k Ohm (to DGND) and 560 Ohm (to 3.3v), LED2 = No strap - just 560 Ohm resistor.

Just watching link status.

4. Are still able to read and write registers? I'm still looking into this using the USB-2-MDIO tool.

5. What is the pull-up on the MDIO line? Has a 2.2k Ohm resistor.

Additionally, I think I found that the latest Bone Debian (9.9) has an issue with bringing up the driver for the DP83867. I reverted back to an earlier version (9.1) and it seemed to auto detect the IC and bring up the driver. I'm going to load a fresh install of both with no u-boot edits and see if it associates the DP83867 driver automatically. 

Hi Ray,

Thanks for your update. Just to confirm again, are you are using a custom driver or our linux driver linked here: https://www.ti.com/tool/ETHERNET-SW.

Please give me an update in regards to using the earlier version of Bone Debian and using the USB-2-MDIO tool. 

Thank you,

Nikhil 

Nikhil,

Thanks for the help in this issue. We found the issue and now ethernet is working, but only at 10/100. I'm going to work with adjusting the Tx/Rx delay skews in the device tree to see if that can get us a 1G link.

As for your last question, yes we were using the correct driver. The correct driver is now substantiated by the device tree (verified in our syslog readout). We used the u-boot menu to read MDIO registers and they were all correct via mode 3 we configured.

So what fixed it? It ended up being a Bone Debian OS issue...or misunderstanding of configuring the network interfaces correctly. Embedded Debian development comes with the standard network manager to use ifconfig or simply edit the etc/network/interfaces config file.

They also added connmanctl (link here to more info), which is a network manager on top of the typical network manager. So simply going into the Linux terminal and typing in $ sudo ifconfig eth0 192.168.10.1 netmask 255.255.255.0 up is not enough. You have to also tell connmanctl to allow the service (ethernet device) to be approved to use the network.

What you have to do first is get the service name that connmanctl assigns to eth0 and/or eth1. Which can only be done if ifconfig is used to configure the eth0 first and you are actually connected to another device (like a switch). You get the ethernet service name in the terminal via $ connmanctl services.  But wait, that's not all. You have to now configure that network service the same as you configured eth0 with ifconfig via $ sudo connmanctl <ethernet service> --ipv4 manual 192.168.10.1 netmask 255.255.255.0 gateway <gateway addr>

And it gives the service a long name like ethernet_6064054f81d8_cable. 

The best thing to do is edit the etc/network/interfaces config file. It has a section to set up the ethernet similar to ifconfig and another to configure connmanctl services during bootup. I done this and it works. Crazy that embedded Debian is using, what is essentially, two network managers. I'm going to make a build of embedded debian and see if removing connmanctl (sudo apt remove) letting ifconfig work to set everything up. 

Hi Ray,

Thanks for the information! As a quick check, is the driver changing register 9 or writing to any other registers? Also as a sanity check, can you confirm that the link partner supports 1G communication?

Thank you,

Nikhil