DP83867IS: RX Err on 1 GiBit (AM6548)

Hi Michael,

As you have mentioned slight strapping differences, you may check registers 0x6E and 0x6F of both the working and non-working setups to ensure both are strapped as expected. I would expect these values to be the same, as the only change you have mentioned was PHY address. 

Additionally, can you provide a register dump for both the working and non-working PHY's for registers 0x0 - 0x1F, and 0x32.

Thank you,

Nikhil

Nikhil,

the registers 0x6E and 0x6F were indeed equal.

Please find attached the requested register dumps.

I took one non-working PHY as an example against the one working.

I already marked the differences in the dump for better readability.

Interestingly the non-working phy on eth5 reports that it did not receive even the Link Code Word (register 0x06).

Because of the difference in register 0x11 suggesting different MDI/X settings, I already tried to force Manual MDI and MDI-X via register 0x10 bits 6:5 on eth5, but it not change the result.

Best regards,

Michael

Register dump of NON-working phy on eth5 (icssg-prueth pruss2_eth eth5: Link is Up - 1Gbps/Full - flow control off)
========================================
                  Difference
				  ==========
				  | |    Register dump of WORKING phy on eth0 (am65-cpsw-nuss 46000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off)
                  | |    ====================================
0x00: 0x001140    | |    0x00: 0x001140
0x01: 0x00796d    | |    0x01: 0x00796d
0x02: 0x002000    | |    0x02: 0x002000
0x03: 0x00a231    | |    0x03: 0x00a231
0x04: 0x000101    |*|    0x04: 0x0001e1
0x05: 0x00c5e1    | |    0x05: 0x00c5e1
0x06: 0x00006d    |*|    0x06: 0x00006f
0x07: 0x002001    | |    0x07: 0x002001
0x08: 0x004000    | |    0x08: 0x004000
0x09: 0x001a00    |*|    0x09: 0x000300
0x0a: 0x007800    |*|    0x0a: 0x003800
0x0b: 00000000    | |    0x0b: 00000000
0x0c: 00000000    | |    0x0c: 00000000
0x0d: 0x00401f    | |    0x0d: 0x00401f
0x0e: 00000000    | |    0x0e: 00000000
0x0f: 0x003000    | |    0x0f: 0x003000
0x10: 0x005048    | |    0x10: 0x005048
0x11: 0x00ac02    |*|    0x11: 0x00af02
0x12: 00000000    | |    0x12: 00000000
0x13: 0x001dc6    |*|    0x13: 0x000000
0x14: 0x0029c7    | |    0x14: 0x0029c7
0x15: 00000000    | |    0x15: 00000000
0x16: 00000000    | |    0x16: 00000000
0x17: 0x000040    | |    0x17: 0x000040
0x18: 0x006150    | |    0x18: 0x006150
0x19: 0x004444    | |    0x19: 0x004444
0x1a: 0x000002    | |    0x1a: 0x000002
0x1b: 00000000    | |    0x1b: 00000000
0x1c: 00000000    | |    0x1c: 00000000
0x1d: 00000000    | |    0x1d: 00000000
0x1e: 0x000202    | |    0x1e: 0x000202
0x1f: 00000000    | |    0x1f: 00000000
                  | |
0x32: 0x0000d1    | |    0x32: 0x0000d1

Hi Michael,

A couple follow up questions:

1. What is the desired MAC interface?

2. What is the cable length used in both the working and non-working case?

3. On the connected pins between the PHY and processor, particularly the strap pins, are there differences in the internal pull values of the MCU CPSW versus the  PRUSS module?

4. In the non-working case, Register 0x9 = 0x1A00, which is not the default value. Have any write statements been done to set this value? Does returning this register to value 0x0300 return the PHY to an operational state?

Thank you,

Nikhil

hi Nikhil,

1) All PHYs are connected as RGMII.

2) I use the same cable - 1m length - when testing the working/non-working PHYs.

3) The pull settings are the same across all ethernet pins.

4) Yes, I needed to write that register to 0x1A00 on every PRU PHY in order to establish a link at all (CFG1, bit12,11 - see first post).

It should be mentioned, that we are using a AM6548 SR2.0 and these firmware files from 07.02.00.001:

https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/commit/ti-pruss?h=ti-linux-firmware&id=31e626d84a3f8a5dc7175b79440972ce90a23de0

I wanted to compare against the TI starterkit TMDX654GPEVM with the same DP83867 PHY and an AM6548 SR1.0 and using these firmware files:

https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/commit/ti-pruss?h=ti-linux-firmware&id=534ba03becfa9b39ccbd42b97e091abd94a207e7

PRG2 ethernet works on that board.

Best regards,
Michael

Hi Michael,

Some follow ups to the specific line items:

2. Is the issue also seen at other cable lengths, such as 10m or 20m?

4. Thanks for the clarification, I understand this operation now. 

Thank you,

Nikhil

Hi Nikhil

I only have a 10m cable available. Auto-negotiation does take a bit longer with it but in the end it's the same: Got Link up, but packets dropped.

Best regards

Michael

Hi Michael,

Can we try both a near-end and far-end loopback test to help determine the source of the error? Please review section 8.4.4 in the datasheet for information on loopback modes. Let's try both an analog loopback and reverse loopback. Please let me know if errors are observed with either loopback experiment. Please let me know if you require additional information for setting up loopback modes.

Thank you,

Nikhil

Hi NIkhil

I guess I need a little help in setting up and testing the two loopback modes.

Reverse Loopback test: 

1. Set register 0x16 (BISCR) to 0x0020 (set bit 5)

Now I my PC I use wireshark to monitor packets on the Ethernet interface and send a ping to the device's IP address. But wireshark does only show the ARPs to ask who has that IP address.

Is that how you test this loopback mode?

Analog Loopback test: 

1. Disable auto-negotiation: Set register 0x00 (BMCR) to 0x0140 (clear bit 12).

2. Disable Auto MDI/X, force manual MDI: Set register 0x10 (PHYCR) to 0x5008 (bits 6:5 to 0x00)

3. Set register 0x00FE (LOOPCR) to 0xE720.

4. Issue a sw restart: Set register 0x1F (CTRL), bit 14.

How do I test this loopback mode?

Then I assign an IP address to the ethernet interface and try to ping my host PC.

I have tcpdump on the target but I don't how to use it

Thanks,

Michael

Hi Michael,

Some additional notes for each test:

1. Reverse loopback: Writing 0x0016 = 0x0020 is the correct register setting. This should be all that is needed for this test. Do you have access to the MII pins of the PHY? If so, can you confirm you can observe MII data on these pins before setting the loopback mode? Have the link partner send the PHY data during normal operation and observe the RX_Data pins. 

2. Analog loopback: You have the correct steps 1-3. Step 4 should be set analog loopback (register 0x16 = 0x0008). Then step 5 would be issue a soft reset (0x1F = 0x4000). For this test the PHY must be connected to a MAC, and the MAC should be set to generate packets, the PHY will loop the packets back to the MAC and the MAC should count the packets and display that there are no errors. The MDI pairs (cable side) should be terminated with a 100 ohm differential impedance. If the termination is not available, digital loopback can be used instead (set register 0x16 = 0x0004). However, analog loopback engages all analog blocks of the PHY and will be useful in fully confirming the functionality of the MDI side of the PHY.  

Please let me know if this has helped clarify the setup for near-end loopback.

Thank you,

Nikhil

Hi Nikhil,

I will connect a scope to the RGMII pins and try to observe RX Data as you described.
Will get back to you next week!

Regards,

Michael

Hi Michael,

Thanks for the update! I will await your response.

Thank you,

Nikhil

Hi Nikhil,

I monitored RX_D0 on the PHY during pings from my PC. It has a 1.8V idle level. The pings are sent every second.

In normal mode, I could see data on the scope each second (without verifying the data itself). Still, ping reports "Host unreachable" and on the device "RX packets" and "RX packets dropped" increments.

1. Reverse loopback:

• No RX data is seen after setting register 0x16 to 0x0020. RX counters on the target do not increase. RX counters on the PC increase, no error or dropped packets.

2. Digital loopback: Ping on the target.

• Data on RX_D0 is observed each second. TX packets counter increases as well as counters "RX packet" and "RX packets dropped".

2. Analog loopback: I'm still building a RJ45 connector with termination. Will report the results when available.

Since data is observable so far on the MII side, but gets rejected by Linux, should we add either the hardware (CPU/IP) itself or Linux configuration as suspects?

Best regards,
Michael