RGMII tx error

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

RGMII tx error

954 Views
jb2
Contributor III

Hello,

I've a problem with my custom board with a LS1020A CPU.

I've a RGMII PHY (Marvell 88e1510-a0) connected to eTSEC3 like the LS1021A board.

The PHY is detected by U-Boot through MDIO on the good eTSEC port:

Spoiler
=> mdio list
ethernet@2d10000:
ethernet@2d50000:
ethernet@2d90000:
1 - Marvell 88E151x <--> ethernet@2d90000

The link with my switch is up and the PHY model is correct (PHY 0x01):

Spoiler
=> mii info
PHY 0x01: OUI = 0x5043, Model = 0x1D, Rev = 0x01, 1000baseT, FDX
PHY 0x1F: OUI = 0x0000, Model = 0x00, Rev = 0x00, 1000baseX, HDX

=> mii dump 1 0
0. (1000) -- PHY control register --
(8000:0000) 0.15 = 0 reset
(4000:0000) 0.14 = 0 loopback
(2040:0000) 0. 6,13 = b00 speed selection = 10 Mbps
(1000:1000) 0.12 = 1 A/N enable
(0800:0000) 0.11 = 0 power-down
(0400:0000) 0.10 = 0 isolate
(0200:0000) 0. 9 = 0 restart A/N
(0100:0000) 0. 8 = 0 duplex = half
(0080:0000) 0. 7 = 0 collision test enable
(003f:0000) 0. 5- 0 = 0 (reserved)


=> mii dump 1 1
1. (796d) -- PHY status register --
(8000:0000) 1.15 = 0 100BASE-T4 able
(4000:4000) 1.14 = 1 100BASE-X full duplex able
(2000:2000) 1.13 = 1 100BASE-X half duplex able
(1000:1000) 1.12 = 1 10 Mbps full duplex able
(0800:0800) 1.11 = 1 10 Mbps half duplex able
(0400:0000) 1.10 = 0 100BASE-T2 full duplex able
(0200:0000) 1. 9 = 0 100BASE-T2 half duplex able
(0100:0100) 1. 8 = 1 extended status
(0080:0000) 1. 7 = 0 (reserved)
(0040:0040) 1. 6 = 1 MF preamble suppression
(0020:0020) 1. 5 = 1 A/N complete
(0010:0000) 1. 4 = 0 remote fault
(0008:0008) 1. 3 = 1 A/N able
(0004:0004) 1. 2 = 1 link status
(0002:0000) 1. 1 = 0 jabber detect
(0001:0001) 1. 0 = 1 extended capabilities


=> mii dump 1 2
2. (0141) -- PHY ID 1 register --
(ffff:0141) 2.15- 0 = 321 OUI portion


=> mii dump 1 3
3. (0dd1) -- PHY ID 2 register --
(fc00:0c00) 3.15-10 = 3 OUI portion
(03f0:01d0) 3. 9- 4 = 29 manufacturer part number
(000f:0001) 3. 3- 0 = 1 manufacturer rev. number


=> mii dump 1 4
4. (01e1) -- Autonegotiation advertisement register --
(8000:0000) 4.15 = 0 next page able
(4000:0000) 4.14 = 0 (reserved)
(2000:0000) 4.13 = 0 remote fault
(1000:0000) 4.12 = 0 (reserved)
(0800:0000) 4.11 = 0 asymmetric pause
(0400:0000) 4.10 = 0 pause enable
(0200:0000) 4. 9 = 0 100BASE-T4 able
(0100:0100) 4. 8 = 1 100BASE-TX full duplex able
(0080:0080) 4. 7 = 1 100BASE-TX able
(0040:0040) 4. 6 = 1 10BASE-T full duplex able
(0020:0020) 4. 5 = 1 10BASE-T able
(001f:0001) 4. 4- 0 = 1 selector = IEEE 802.3 CSMA/CD


=> mii dump 1 5
5. (c5e1) -- Autonegotiation partner abilities register --
(8000:8000) 5.15 = 1 next page able
(4000:4000) 5.14 = 1 acknowledge
(2000:0000) 5.13 = 0 remote fault
(1000:0000) 5.12 = 0 (reserved)
(0800:0000) 5.11 = 0 asymmetric pause able
(0400:0400) 5.10 = 1 pause able
(0200:0000) 5. 9 = 0 100BASE-T4 able
(0100:0100) 5. 8 = 1 100BASE-X full duplex able
(0080:0080) 5. 7 = 1 100BASE-TX able
(0040:0040) 5. 6 = 1 10BASE-T full duplex able
(0020:0020) 5. 5 = 1 10BASE-T able
(001f:0001) 5. 4- 0 = 1 partner selector = IEEE 802.3 CSMA/CD

At boot, driver is probed and recognized as prime:

Spoiler
mdio_register: non unique device name 'ethernet@2d50000'
, eth-1: ethernet@2d50000, eth0: ethernet@2d90000 [PRIME]

When I try to make a dchp command I have a timeout error. Same thing for the ping command if I set an IP:

Spoiler

=> dhcp
tsec_probe: Name: ethernet@2d10000
mdio_register: non unique device name 'ethernet@2d10000'
tsec_probe: Name: ethernet@2d50000
mdio_register: non unique device name 'ethernet@2d50000'
tsec_init: Name: ethernet@2d90000
ethernet@2d90000: tsec: halt
ethernet@2d90000: TSEC Ethernet [02d90000]
Speed: 1000, full duplex
Link: up
BOOTP broadcast 1
tsec_send: Len: 342
ethernet@2d90000: tsec: tx buffers not full
ethernet@2d90000: tsec: tx_idx: 0
ethernet@2d90000: tsec: status: 0x0
ethernet@2d90000: tsec: length: 342
ethernet@2d90000: tsec: buffer: 0x9ffed540
ethernet@2d90000: tsec: &priv->txbd[priv->tx_idx]: 0x9ef2db40
ethernet@2d90000: tsec: status: 0x0
ethernet@2d90000: tsec: tx error. Status: 0x9c00
BOOTP broadcast 2
tsec_send: Len: 342
ethernet@2d90000: tsec: tx buffers full
BOOTP broadcast 3
tsec_send: Len: 342
ethernet@2d90000: tsec: tx buffers full
BOOTP broadcast 4
tsec_send: Len: 342
ethernet@2d90000: tsec: tx buffers full
BOOTP broadcast 5
tsec_send: Len: 342
ethernet@2d90000: tsec: tx buffers full
ethernet@2d90000: tsec: halt

Abort
=> <INTERRUPT>

I added some log to have more information. Main error is "ethernet@2d90000: tsec: tx error. Status: 0x9c00". The txbd status is always TXBD_READY.

The device tree is:

...
 
&enet0 {
         phy-handle = <&rgmii_phy2>;
         phy-connection-type = "rgmii-id";
         status = "okay";
 };
 
 &enet1 {
         tbi-handle = <&tbi1>;
         phy-handle = <&sgmii_phy0>;
         phy-connection-type = "sgmii";
         status = "okay";

 };
 
 &enet2 {
         phy-handle = <&rgmii_phy1>;
         phy-connection-type = "rgmii-id";
         status = "okay";
 };

...

&mdio0 {
         sgmii_phy0: ethernet-phy@0 { /* DSP/Serdes MDIO Address is unallocated (Not Implemented) */
                 reg = <0x0>;
         };
 
         rgmii_phy1: ethernet-phy@1 { /* PHY MDIO Address is 1 */
                 compatible = "marvell,88E1510";
                 device_type = "ethernet-phy";
                 interrupt-parent = <&gic>;
                 interrupts = <GIC_SPI 167 IRQ_TYPE_EDGE_RISING>; // lore.kernel.org/lkml/20191109105642.30700-1-olteanv@gmail.com
                 reg = <0x1>;
         };
 
         rgmii_phy2: ethernet-phy@2 { /* SWITCH MDIO Address is 2 (Not Used in U-Boot) */
                 reg = <0x2>;
         };
 
         /* SGMII PCS for enet0 - Not Used in U-Boot */
         tbi0: tbi-phy@1f {
                 reg = <0x1f>;
                 device_type = "tbi-phy";
         };
 };
 
 &mdio1 {
         /* SGMII PCS for enet1 - Not Used in U-Boot */
         tbi1: tbi-phy@1f {
                 reg = <0x1f>;
                 device_type = "tbi-phy";
         };
 };

...

 

Thank you for your help

Labels (1)
0 Kudos
Reply
1 Reply

941 Views
jb2
Contributor III

We found the problem, RCW was not good.

0 Kudos
Reply