DRA829V: Enable cpsw0 main domain ethernet switch in u-boot

Sudheer,

To answer some of your questions, here are the SoC registers you asked for:

=> md 0x0C000030 1
0c000030: 00000003 ....
=> md 0x0C000038 1
0c000038: 00000003 ....
=> md 0x0C00003c 1
0c00003c: 00000003 ....
=> md 0x00104044 1
00104044: 00000012 ....
=> md 0x0010404c 1
0010404c: 00000012 ....
=> md 0x00104050 1
00104050: 00000012 ....

Isn't it a bit strange that the don't report full duplex?

Yes, we have 25MHz crystals on all three PHYs.

Best regards,

/Bo

Some more information.

For PHY@4 (one of the DP83822):

Register 0x467 is 0xC14F
Register 0x468 is 0x0000

I guess this means:

RX_D1 - mode 4
RX_D0 - mode 1
COL - mode 1
RX_ER - mode 2
CRS - mode 2
RX_DV - mode 1
LED_0 - mode 4
RX_D2 - mode 1
RX_D3 - mode 1

which in turn means:

FX_EN = 0
PHY_AD0 = 0
AN_1 = 1
PHY_AD1 = 0
EEE_EN = 0
PHY_AD2 = 1
FLD_EN = 0
PHY_AD3 = 0
AN_EN = 1
PHY_AD4 = 0
AN_0 = 1
LED_SPEED = 1
LED_CFG = 0
RGMII_EN = 1
AMDIX_EN = 0
XI_50 = 0
RMII_EN = 0

Every strap seems to be what they're meant to be. Link up/down is still shaky and traffic is never observed.

Best regards,

/Bo

Any more ideas that I can test out?

Regards,

/Bo

Bo Mellberg said:

Any more ideas that I can test out?

Please check if the MAC Port statistics show the packets being transmitted from the MAC to the PHY.

Regards,
Siddharth.

Siddharth, thanks for helping out, it is really appreciated.

The status of the three MACs:

=> md 0x0c000030 1
0c000030: 00000003 ....
=> md 0x0c000038 1
0c000038: 00000003 ....
=> md 0x0c00003c 1
0c00003c: 00000003 ....

All three reports link up and 100Mbit. If this is the connection between MAC and PHY it seems ok, even though it should be 1000Mbit for the DP83867.

If I try to read the MAC stat registers after a failed ping operation, my U-boot crashes. I can only do it with the cable inserted in the working 1GBit port:

=> mdio list
ethernet@c000000port@1:
0 - TI DP83867 <--> ethernet@c000000port@3
4 - TI DP83822 <--> ethernet@c000000port@4
5 - TI DP83822 <--> ethernet@c000000port@1
=> net list
eth2 : ethernet@c000000port@1 de:ad:be:af:0b:05
eth0 : ethernet@c000000ethernet@c000000port@3 de:ad:be:af:0b:00 active
eth1 : ethernet@c000000port@4 de:ad:be:af:0b:04
=> setenv ipaddr 10.142.3.9; setenv netmask 255.255.252.0; setenv serverip 10.142.0.139; setenv gatewayip 10.142.0.1
=> md 0x0c03a034 1
0c03a034: 00000000 ....
=> md 0x0c03a434 1
0c03a434: 00000000 ....
=> md 0x0c03a634 1
0c03a634: 00000000 ....
=> ping 10.142.0.1
k3-navss-ringacc ringacc@3c000000: Ring Accelerator probed rings:1024, gp-rings[440,150] sci-dev-id:211
k3-navss-ringacc ringacc@3c000000: dma-ring-reset-quirk: disabled
am65_cpsw_nuss_port ethernet@c000000port@3: K3 CPSW: rflow_id_base: 16
link up on port 3, speed 1000, full duplex
Using ethernet@c000000port@3 device
host 10.142.0.1 is alive
=> md 0x0c03a034 1
0c03a034: 00000002 ....
=> md 0x0c03a434 1
0c03a434: 00000000 ....
=> md 0x0c03a634 1
0c03a634: 00000002 ....

As you can see, for RGMII1 the count increases to 2 after a ping. Also for RGMII4, but not for RGMII3 which is strange because that is the working port.

Best regards,

/Bo

Bo,

The formula for the offset is (PORT_ID)*200h with PORT_ID being 0 for Host Port, 1 for MAC Port 1, 2 for MAC Port 2 and so on.
For RGMII1 (MAC Port 1), the register address will be:
0x0c03a234
The register you checked: 0x0c03a034 is for the Host Port indicating that CPSW has received the packet from Software.

Reinterpreting the register values above, we see:
0x0c03a434 is 0, indicating that RGMII2 sent no packets (Since MAC Port 2 is not enabled, this is expected).
0x0c03a634 is 2, indicating that RGMII3 sent 2 packets (Since MAC Port 3 is being used).

Regards,
Siddharth.

Siddharth,

Thank you, that was a very valuable explanation!

Could we then conclude that the MAC-to-PHY seems correct for all three interfaces?

Where to next? I still don't have link on my DP83822 PHYs, unless I force them to 10Mbit.

In a related thread, they talk about MDIX auto needed to be turned on. Is that true?

e2e.ti.com/.../dp83822i-missing-link-after-switching-from-auto-negotiation-to-forced-mode

Best regards,

/Bo

Bo Mellberg said:

I now have working link and autonegotiation on all my three ports, but I can't ping or tftp on the 100Mbit ports.

Bo,

Please confirm whether the above statement you mentioned earlier is still valid. Is link being detected or not?
It contradicts your latest statement:

Bo Mellberg said:

I still don't have link on my DP83822 PHYs, unless I force them to 10Mbit.

Regards,
Siddharth.

Siddharth,

As you can imagine, the system doesn't seem stable at all. I know I had link before, but I might have mistaken it for 10Mbit fixed link.

At the moment, link is not detected on DP83822, neither in U-boot nor in Linux.

Regards,

/Bo

Update on my issue with dp83822.

Another team member tried his ports and both of them had link. There is no traffic however, either from U-boot or Linux.

I tried another board on my setup and on the port on phy5 i get link up. No traffic here either.

Considering that we got stable traffic on the GBit port when we trimmed the delay parameters, can we do the same for the DP83822 phy? As you know, I have tried "rgmii-id" and various delays for both rx and tx, but nothing has worked so far.

Best regards,

/Bo

FINALLY!

Just by chance, I tried to set the delays to different values. It turns out that turning on internal delay on RX but not on TX works. I can now ping in both uboot and Linux. It remains to be seen if the network traffic is acceptable.

Thank you for all your help!

/Bo