DP83867IR: DP83867IR: PHY unable to establish 1GE connection in U-boot to link partner but works every time from Linux, continued

Hi Mateusz,

Thanks for the register data. I will need a couple days to go through the data, and expect to have a response by Wednesday at latest.

Sincerely,

Gerome

Hi Mateusz,

I do agree with your assessment that PHY is getting auto-negotiated down to 10mbps in non-working mode however, it does seem like it is linking. Could you please confirm if you are using the same link partner for working and non-working cases? Can you also confirm if you are using any drivers on Linux and Uboot?

Sincerely,

Gerome

Please note: US offices will be closed on 11/25 and 11/26 due to Thanksgiving Holiday and will resume 11/29. Expect delayed responses until then.

Hi Gerome

yes, we are using the same link partner for both tests, the only thing that changes is the u-boot vs petalinux running on the Zynq. the Petalinux is using a standard Ethernet driver, the PS of the Zynq connects to the PL of the Zynq (the FPGA portion) and from there it connects to the PHY via GMII lines, in u-boot we are using the standard Ethernet driver that is included when one enables Ethernet from the builds. the MDIO communication is controlled by the PL (FPGA) portion and not u-boot or Petalinux. 

My assumption is that regardless of the state of GMII the PHY should be able to negotiate to the link partner so long as the 25 MHz reference clock is present. 

Hi Mateusz,

Thanks for the confirmation of same LP. I will bring this to the team once we are back from Holiday break and should expect an answer for you by 11/30.

Sincerely,

Gerome

Hi Mateusz,

It seems very odd that PHY is operating at 1G during Linux while 10mbps at UBoot. I do notice that the LP register on our PHY (0x5) is different in both instances. This would lead me to think that LP is being configured differently between operating system changes. I would check on the LP to see if there is any changes there when going from Linux to UBOOT.

Sincerely,

Gerome

Hi Gerome,

just to clarify when you mention the LP you mean the local processor? The local processor is disconnected from the PHY interface, through the programmable logic, where the MAC talks to the PHY outside of any control by the processor. MDIO lines are controlled only by the MAC logic.

that said are there are requirements for the PHY to be happy that should be done during link bring up/training with regards to the registers in the device? i,e, make sure you read/wite to register at offset 0xXX?

Hi Mateusz,

When I mean LP, I mean link partner; the other device that the PHY is connected to via MDI.

Sincerely,

Gerome

Hi Gerome

we will take a look at the link partner, but in both cases it is the same and nothing about the link partner has physically changed, is there anywhere a more detailed manner in which the DP83867 device should be brought up during link training? are there any dependencies on the MDIO interface or the GMII interface for the PHY to operate correctly?

Hi Mateusz,

There shouldn't be an dependencies on SMI (MDIO) or MII interface for the PHY to link correctly.

Sincerely,

Gerome

Hi Gerome,

how about any dependencies on the GMII side affecting the 1GE link side?

Hi Mateusz,

There is no dependencies of the MII side. The MDI behavior is completely independent of what is going on with the MII/MAC side of the PHY.

Some additional notes:

- Could you see what happens if you change your link partner to be another DP83867; whether it be another board you have and/or an EVM?

- Since OS is the changing variable between working and non-working cases, there might be some IO's that are driven differently on the SoC that might be electrically changing the conditions of the setup between Linux and UBoot.

Sincerely,

Gerome

Hi Gerome

we have run the experiment when two PHYs are connected together back to back and in both Linux and U-boot the links come up at 1 GE, with the following register values: 

Hi Mateusz,

So what has changed in this test setup? Before you had 867 board to link partner via RJ-45, but what is it now? You said back-to-back, may I please see a diagram of the non-working condition and working condition? What was the link partner previously?

Sincerely,

Gerome

Hi Gerome,

in our design we have multiple of the DP83867 chips on a single board. J26 is the RJ45 output from one of these PHYS connected via an external cable back to J27 which is a second PHY on the same board of the same part number. in the non-working case we have a standard laptop, we have also tried a layer 2 gigabit Ethernet switch as well as a standard 1 GE switch. all 3 non-working devices behave in the same fashion. 

Hi Mateusz,

So for clarification:

- 867-867 works in both Linux and UBOOT

- 867-Laptop via 2 setups of 1G switches and 1 setup of GE switch work in Linux, but not in UBoot

Is this accurate?

Sincerely,

Gerome

DP83867 connected directly to DP83867 works in both u-boot and linux

DP83867 connected directly to a GE port on a laptop work in Linux but not in u-boot

DP83867 connected directly to a GE port on a layer 2 GE switch works in Linux but not in u-boot

DP83867 connected directly to a GE port on a standard GE switch works in Linux but not in u-boot

Hi Mateusz,

I will bring this up to the team tomorrow and have feedback then.

Sincerely,

Gerome

Hi Mateusz,

The settings all look correct from a PHY level. The LP in working and non-working cases is advertising 1G capabilities, which the PHY is also advertising, so the auto-negotiation process should be resolved at 1G like in working case, not 10mbps in non-working case.

And just to confirm, you aren't changing link partners to a same design, but different device of LP? And do you have multiple boards in testing? Is this behavior evident on all boards, or just a few/single?

In the 4 cases you described above, could you please read registers 0x6E, 0x6F, and 0x31 please?

Also, could you please send over schematic of the board to me for review?

Sincerely,

Gerome

Hi Gerome

in all test cases reported above the hardware in question did not change at all, only the LP.

we have also replicated this same behavior on a number of boards now, leading me to be fairly confident if we were to test all 10 boards we have all would behave in this same fashion. we have also tried to run this test 10s of times on a single hardware set up to see if we can get "lucky" once, unfortunately with no success in u-boot mode. 

the schematic have been shared with Adam Daluga, let me know if you have trouble getting them from him.

Hi Mateusz,

I will check with Adam on schematic.

Sincerely,

Gerome

Hi Mateusz,

In a non-working condition, when linking up the PHY to the LP and getting the speed at 10Mbps. Are you able to reset the PHY using reset pin? If so, does the speed change upon new link up?

Sincerely,
Gerome

Hi Gerome,

when i toggle the external reset pin of the Eth PHY, the link goes away and comes back at the same result for the non-working case. 

regards

mateusz

Hi Mateusz,

If in the non-working case, to disable auto-negotiation advertisement of 10 and 100mbps, so that only 1G speed is advertised, would this help?

Sincerely,

Gerome

Hi Gerome,

i will need to re-work one of the boards to try this experiment, but from previous register reads, it would seem that the link attempts at 1 gig speed training and fails, is there some way we can get a better idea of why the link may be failing at 1 gig speed training? 

Hi Mateusz,

The PHY is advertising 1G capabilities in both working and non-working instances (0x9[9:8] = '11') while the LP is advertising 1G full duplex in both instances as well. This should be all that is required to link at 1G, not at 10mbps like in non-working case. From a PHY standpoint, it is doing everything required for 1G link. Depending on how the latest experiment goes, there might be something on a higher level than the PHY that is preventing proper connection when in UBOOT.

Sincerely,

Gerome

Hi Gerome, 

i have reworked a board so that the Eth PHY only advertises 1 gig link speed support, this does not result with a link in u-boot, but provides new register values that would suggest some sort of link training issue:

this is with the same hardware as before, where we are using an off the shelf gigabit capable Ethernet switch or a laptop with a gigabit ethernet port, where example working are values from linux, example non-working are values from u-boot, and the following two columns are after the hardware modification (AUTO NEG SEL change from "00" to "10")  

Taking debug conversation offline