DP83867E: RGMII connection issues - ARP Retry count exceeded, Tx buffer not ready

Hi Maciej,

From the info you provided, DP83867 is configured into RGMII mode with 2ns clock skew on both TX and RX direction. Depending on whether the NXP LS1046A has internal delay, it could be double delay on the RGMII interface between PHY and MAC.

You can play around with the PHY delay by using RGMII Delay Control Register (RGMIIDCTL), Address 0x0086 to see if it helps.

However, it's kind of puzzled me that the timing is very loose for 100M, so even with additional delay, it should work. Can you also probe the RGMII RX pins from the PHY to make sure it sends expected RGMII signals (RX_CLK, RX_DV, RX_D[3:0].

Regards,

Hung Nguyen

It looks like the NXP LS1046A do not ghave internal delay on the RGMII. On the Reference Board (LS1046ARDB) they are using Realtek chip for the RGMII with the 2ns TX internal delay enabled in the PHY (I have found nothing on the RX delay - at least it is not enabled by the driver).

We have already played with the RGMIIDCTL. Now we are playing a little bit more, but with the scope attached to the RX_CLK and RX_D[3] lines
to measure the delays as shown in the http://www.ti.com/lit/an/snla243/snla243.pdf


In the current state we are getting the CLK signal and data on the RX_[3] lines when using the internal packets generator (in the TI PHY) with loopback.
When sending packets from external device via Ethernet cable, we are getting the CLK signal, but not getting any data on the RX_[3] line.

Hello.

Some more test results:

Receive:
1. When we ping our board, the signal appears only on the RX_CLK. Nothing on RX_D3 (we were be able to connect probe only with this pin at the moment). Delay changes don't help.
2. Signal appears on tje RX_D3, when we use PRBS generator and internal digital loopback within the PHY.
3. Delay:
  * When delay on DP83867 is disabled, RX_CLK signal is ahead of the RX_D3 by 2ns (skew is added to RX_D3).



  * When delay on DP83867 is enabled and set to 2ns, there are any clock skew between RX_D3 and RC_CLK.


 
* When delay on DP83867 is enabled and set to 4ns, RX_D3 signal is ahead of the RX_CLK by 2ns (skew is added to RX_CLK).


Transmit:
1. No signal on TX_D3 when we try to ping from our custom board.


But I believe that our main issue is the fact that there is nothing on the data line when receiving packets from external device.
There is data flowing on the D3 line when using the internal packets generator. When sending packets from external device,
the clock appears on the RX_CLK line, but the RX_D3 line is always low.

The data path from RJ-45 to MII and back to the RJ-45 was already verified using the far-end loopback as described in the http://www.ti.com/lit/an/snla246a/snla246a.pdf

Hi Maciej,

RX_CLK should always output 25MHz clock signal when the device links up in 100M speed.

When internal packet generator is used, the data is PRBS. So it is expected to have all 3 data lines toggling.

When sending data from external device, depending on the content of the incoming packets, RX_D3 could be low. For example, you send 5555 data, bit 3 and bit 1 are always 0. However, you should still see RX_D3 toggling at least for 4 bytes CRC field.

Can you confirm RX_D[2:0] and RX_CTRL are correct RGMII signals?

Is the behavior the same for 10M and 1G speed?

Regards,

Hung Nguyen

Does it mean that the RX_CLK should always be operating when the link is established?
The link status bit is set. But the RX_CLK is only operating when we are transmitting some data from an external device.
When there is not data being transmitted, the RX_CLK is always low.

We had some difficulties probing the RX_D[2:0] pins. We will try to arrange that.

I believe the 1Gb mode is not available since there are only 2 enet pairs routed to the connector.
The remaining 2 are exposed on the test points.

Hi,

What is your strap on RX_CTRL pin?

Can you read register 0x31?

Regards,

Hung Nguyen

Hi,

There are no straps on the RX_CTRL. All the straps used are visible on the attached schematics.
I will provide the register reading tomorrow morning.
Thank you for your feedback.

Hi, 

There is a note, particularly for RX_CTRL, in the datasheet section 8.5.1 you need to follow:

 "Strap modes 1 and 2 are not applicable for RX_CTRL. The RX_CTRL strap must be configured for strap mode 3 or strap mode 4. If the RX_CTRL pin cannot be strapped to mode 3 or mode 4, bit[7] of Configuration Register 4 (address 0x0031) must be cleared to 0."

Regards,

Hung Nguyen

Hi,

Thank you for this tip.

The 0x31 value was 0x10B0. So there are no straps on the RX_CTRL and the reserved bit (7th) was not unset.
I have enabled the quirk in the ti,c U-Boot driver to unset this bit and now the 0x31 register content is 0x1030.
This change caused the RX_CLK to be always on (stable 25MHZ). Previously it was only operating when there was
incoming data stream.

I also found some issues with the TI driver. When accessing the extended register set from
within the driver code, it always got 0xFFFF. I was able to fix this by changing:

"phydev->addr, val" to "MDIO_DEVAD_NONE" in function calls.

Maybe this upstream commit also fixes that: github.com/.../4c29dc1863e4f739ec2f496352935fd37c123553

This issue caused that the extended registers read inisde the driver code were always 0xFFFF. The writing was not working
properly either. So all the configuration done within the driver in the extended registers configuration space was ignored
and the default values were used.

Driver code: https://source.codeaurora.org/external/qoriq/qoriq-components/u-boot/tree/drivers/net/phy/ti.c?h=integration#n134


I was able to capture some traffic on the TX _Dx lines when pinging from the U-Boot shell (tcpdump on the other side still does not show any packets received).
I was able to capture some data on one of the RX_D lines today, as shown below: