AM6422: icssg_prueth port initializing but not able to connect.

Looking at the log, here is something I didn't notice before:

[   12.075289] remoteproc remoteproc8: unsupported resource 5

Hi,

I believe our icssg apps engineer is out of the office through next week.

I see this line in the boot log

icssg-prueth icssg1-eth eth2: Link is Up - 1Gbps/Full - flow control off

Since you are getting an interface I am not sure what the unsupported resource means. But since interface and a link partner could you please provide the ping steps you are using? What is the ip address of the computer you are trying to ping?

Best Regards,

Schuyler

We're trying to ping 169.254.10.100.

When we bring the eth2 interface down and either eth0 or eth1 up with 169.254.10.1, ping works.

The kernel is complaining about an unsupported resource type in the firmware blob.

The message is coming from drivers/remoteproc/remoteproc_core.c:

                if (hdr->type >= RSC_LAST) {
                        dev_warn(dev, "unsupported resource %d\n", hdr->type);
                        continue;
                }

I'm going to try an earlier version of the firmware to see if the message goes away.

I've been seeing that warning message for some time (maybe 1-2 years?), with custom hardware and with EVMs, while the ports functioned just fine. I just checked with an AM64x EVM and processor SDK 09.02, and it is showing the same warning.

I don't think that's your problem.

Please note that I'm not TI. They might have other advice for you.

Regards,

Dominic

Thank you for the information.  Were you able to get the ports working using SDK 08.06?  With all the problems I'm seeing with 09.02, I'm not ready to upgrade the kernel.

The ICSSG ports have been working fine for a long time, way before 08.06. That version should be good enough.

I usually try to verify if sending, receiving or both don't work, e.g. directly connected to a pc with Wireshark. You can also try reading the statistics registers to see if the ICSSG MAC sees the frames.

Regards,  Dominic 

We tried probing the clock pins on the device and are getting nothing.  Thanks again.

We are using the DP83867IRRGZ Phy chip.  Is it compatible with the firmware?

Hi Dan,

What exactly did you see when probing the clock and data lines? If data and clock are not offset enough then data received/sent would not be read properly. 

Just to clarify are eth0 and eth1 on your board CPSW? And eth2 is the only one that is PRU_ICSSG ethernet?

Have you tried checking the MAC statistics with "ethtool -S eth2" for any errors or dropped packets after the ping failed?

-Daolin

Part Number: AM6422

Hi, 

We have custom board design based on AM64x EVM. We are using total three ethernet. Two ethernet on cpsw and one on the icssg1. 

dts entry of the cpsw interface is mentioned below which are working fine (eth0 and eth1).

        cpsw_mdio0_pins: cpsw-mdio0-pins {
                pinctrl-single,pins = <
                        AM64X_IOPAD(0x01fc, PIN_OUTPUT, 4) /* (R2) PRG0_PRU1_GPO19.MDIO0_MDC */
                        AM64X_IOPAD(0x01f8, PIN_INPUT, 4) /* (P5) PRG0_PRU1_GPO18.MDIO0_MDIO */
                >;
        };

        cpsw_rgmii1_pins: cpsw-rgmii1-pins {
                pinctrl-single,pins = <
                        AM64X_IOPAD(0x011c, PIN_INPUT, 4) /* (AA13) PRG1_PRU1_GPO5.RGMII1_RD0 */
                        AM64X_IOPAD(0x0128, PIN_INPUT, 4) /* (U12) PRG1_PRU1_GPO8.RGMII1_RD1 */
                        AM64X_IOPAD(0x0150, PIN_INPUT, 4) /* (Y13) PRG1_PRU1_GPO18.RGMII1_RD2 */
                        AM64X_IOPAD(0x0154, PIN_INPUT, 4) /* (V12) PRG1_PRU1_GPO19.RGMII1_RD3 */
                        AM64X_IOPAD(0x00d8, PIN_INPUT, 4) /* (W13) PRG1_PRU0_GPO8.RGMII1_RXC */
                        AM64X_IOPAD(0x00cc, PIN_INPUT, 4) /* (V13) PRG1_PRU0_GPO5.RGMII1_RX_CTL */
                        AM64X_IOPAD(0x0124, PIN_OUTPUT, 4) /* (V15) PRG1_PRU1_GPO7.RGMII1_TD0 */
                        AM64X_IOPAD(0x012c, PIN_OUTPUT, 4) /* (V14) PRG1_PRU1_GPO9.RGMII1_TD1 */
                        AM64X_IOPAD(0x0130, PIN_OUTPUT, 4) /* (W14) PRG1_PRU1_GPO10.RGMII1_TD2 */
                        AM64X_IOPAD(0x014c, PIN_OUTPUT, 4) /* (AA14) PRG1_PRU1_GPO17.RGMII1_TD3 */
                        AM64X_IOPAD(0x00e0, PIN_OUTPUT, 4) /* (U14) PRG1_PRU0_GPO10.RGMII1_TXC */
                        AM64X_IOPAD(0x00dc, PIN_OUTPUT, 4) /* (U15) PRG1_PRU0_GPO9.RGMII1_TX_CTL */
                >;
        };

       cpsw_rgmii2_pins: cpsw-rgmii2-pins {
                pinctrl-single,pins = <
                        AM64X_IOPAD(0x0108, PIN_INPUT, 4) /* (W11) PRG1_PRU1_GPO0.RGMII2_RD0 */
                        AM64X_IOPAD(0x010c, PIN_INPUT, 4) /* (V11) PRG1_PRU1_GPO1.RGMII2_RD1 */
                        AM64X_IOPAD(0x0110, PIN_INPUT, 4) /* (AA12) PRG1_PRU1_GPO2.RGMII2_RD2 */
                        AM64X_IOPAD(0x0114, PIN_INPUT, 4) /* (Y12) PRG1_PRU1_GPO3.RGMII2_RD3 */
                        AM64X_IOPAD(0x0120, PIN_INPUT, 4) /* (U11) PRG1_PRU1_GPO6.RGMII2_RXC */
                        AM64X_IOPAD(0x0118, PIN_INPUT, 4) /* (W12) PRG1_PRU1_GPO4.RGMII2_RX_CTL */
                        AM64X_IOPAD(0x0134, PIN_OUTPUT, 4) /* (AA10) PRG1_PRU1_GPO11.RGMII2_TD0 */
                        AM64X_IOPAD(0x0138, PIN_OUTPUT, 4) /* (V10) PRG1_PRU1_GPO12.RGMII2_TD1 */
                        AM64X_IOPAD(0x013c, PIN_OUTPUT, 4) /* (U10) PRG1_PRU1_GPO13.RGMII2_TD2 */
                        AM64X_IOPAD(0x0140, PIN_OUTPUT, 4) /* (AA11) PRG1_PRU1_GPO14.RGMII2_TD3 */
                        AM64X_IOPAD(0x0148, PIN_OUTPUT, 4) /* (Y10) PRG1_PRU1_GPO16.RGMII2_TXC */
                        AM64X_IOPAD(0x0144, PIN_OUTPUT, 4) /* (Y11) PRG1_PRU1_GPO15.RGMII2_TX_CTL */
                >;
        };

&cpsw3g {
        pinctrl-names = "default";
        pinctrl-0 = <&cpsw_mdio0_pins
                     &cpsw_rgmii1_pins
                     &cpsw_rgmii2_pins>;

        cpts@3d000 {
                ti,pps = <7 1>;
        };
};

&cpsw_port1 {
        phy-mode = "rgmii-rxid";
        phy-handle = <&cpsw3g_phy0>;
};

&cpsw_port2 {
        phy-mode = "rgmii-rxid";
        phy-handle = <&cpsw3g_phy1>;
};

&cpsw3g_mdio {
        cpsw3g_phy0: ethernet-phy@0 {
                reg = <0>;
                ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
                ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
        };

        cpsw3g_phy1: ethernet-phy@1 {
                reg = <1>;
                ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
                ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
        };
};

Below is the dts entry of the icssg1 ethernet. Ethernet interface comes up on this interface but we are only able to transmit and not able to receive anything on this ethernet. Even receive interrupt of this ethernet stays 0 whereas transmit interrupt gets incremented on doing the ping to other system. 

        prg1_mdio0_pins: prg1-mdio0-pins {
                pinctrl-single,pins = <
                        AM64X_IOPAD(0x015c, PIN_OUTPUT, 0) /* (Y6) PRG1_MDIO0_MDC */
                        AM64X_IOPAD(0x0158, PIN_INPUT, 0) /* (AA6) PRG1_MDIO0_MDIO */
                >;
        };
        
        
        prg1_iep0_pins: prg1-iep0-pins {
                pinctrl-single,pins = <
                        AM64X_IOPAD(0x0104, PIN_OUTPUT, 2) /* (W7) PRG0_PRU0_GPO17.PRG0_IEP0_EDC_SYNC_OUT1 */
                >;
        };

        prg1_rgmii1_pins: prg1-rgmii1-pins {
                pinctrl-single,pins = <
                        AM64X_IOPAD(0x00b8, PIN_INPUT, 2) /* (Y7) PRG1_PRU0_GPO0.PRG1_RGMII1_RD0 */
                        AM64X_IOPAD(0x00bc, PIN_INPUT, 2) /* (U8) PRG1_PRU0_GPO1.PRG1_RGMII1_RD1 */
                        AM64X_IOPAD(0x00c0, PIN_INPUT, 2) /* (W8) PRG1_PRU0_GPO2.PRG1_RGMII1_RD2 */
                        AM64X_IOPAD(0x00c4, PIN_INPUT, 2) /* (V8) PRG1_PRU0_GPO3.PRG1_RGMII1_RD3 */
                        AM64X_IOPAD(0x00d0, PIN_INPUT, 2) /* (AA7) PRG1_PRU0_GPO6.PRG1_RGMII1_RXC */
                        AM64X_IOPAD(0x00c8, PIN_INPUT, 2) /* (Y8) PRG1_PRU0_GPO4.PRG1_RGMII1_RX_CTL */
                        AM64X_IOPAD(0x00e4, PIN_OUTPUT, 2) /* (AA8) PRG1_PRU0_GPO11.PRG1_RGMII1_TD0 */
                        AM64X_IOPAD(0x00e8, PIN_OUTPUT, 2) /* (U9) PRG1_PRU0_GPO12.PRG1_RGMII1_TD1 */
                        AM64X_IOPAD(0x00ec, PIN_OUTPUT, 2) /* (W9) PRG1_PRU0_GPO13.PRG1_RGMII1_TD2 */
                        AM64X_IOPAD(0x00f0, PIN_OUTPUT, 2) /* (AA9) PRG1_PRU0_GPO14.PRG1_RGMII1_TD3 */
                        AM64X_IOPAD(0x00f8, PIN_OUTPUT, 2) /* (V9) PRG1_PRU0_GPO16.PRG1_RGMII1_TXC */
                        AM64X_IOPAD(0x00f4, PIN_OUTPUT, 2) /* (Y9) PRG1_PRU0_GPO15.PRG1_RGMII1_TX_CTL */
                >;
        };
*******************************************************************************************************************
        icssg1_eth: icssg1-eth {
                compatible = "ti,am642-icssg-prueth";
                pinctrl-names = "default";
                pinctrl-0 = <&prg1_rgmii1_pins>;

                sram = <&oc_sram>;
                ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
                firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
                                "ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
                                "ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
                                "ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
                                "ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
                                "ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";

                ti,pruss-gp-mux-sel = <2>,      /* MII mode */
                                      <2>,
                                      <2>,
                                      <2>,      /* MII mode */
                                      <2>,
                                      <2>;

                mii-g-rt = <&icssg1_mii_g_rt>;
                mii-rt = <&icssg1_mii_rt>;
                iep = <&icssg1_iep0>,  <&icssg1_iep1>;

                interrupt-parent = <&icssg1_intc>;
                interrupts = <24 0 2>, <25 1 3>;
                interrupt-names = "tx_ts0", "tx_ts1";

                dma-coherent;
                dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
                       <&main_pktdma 0xc201 15>, /* egress slice 0 */
                       <&main_pktdma 0xc202 15>, /* egress slice 0 */
                       <&main_pktdma 0xc203 15>, /* egress slice 0 */
                       <&main_pktdma 0xc204 15>, /* egress slice 1 */
                       <&main_pktdma 0xc205 15>, /* egress slice 1 */
                       <&main_pktdma 0xc206 15>, /* egress slice 1 */
                       <&main_pktdma 0xc207 15>, /* egress slice 1 */
                       <&main_pktdma 0x4200 15>, /* ingress slice 0 */
                       <&main_pktdma 0x4201 15>, /* ingress slice 1 */
                       <&main_pktdma 0x4202 0>, /* mgmnt rsp slice 0 */
                       <&main_pktdma 0x4203 0>; /* mgmnt rsp slice 1 */
                dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
                            "tx1-0", "tx1-1", "tx1-2", "tx1-3",
                            "rx0", "rx1",
                            "rxmgm0", "rxmgm1";

                icssg1_emac0: ethernet-mii0 {
                        phy-handle = <&icssg1_phy1>;
                        phy-mode = "rgmii-rxid";
                        syscon-rgmii-delay = <&main_conf 0x4110>;
                        /* Filled in by bootloader */
                        local-mac-address = [00 00 00 00 00 00];
                        status = "okay";
                };

                icssg1_emac1: ethernet-mii1 {
                        syscon-rgmii-delay = <&main_conf 0x4114>;
                        /* Filled in by bootloader */
                        local-mac-address = [00 00 00 00 00 00];
                        status = "disabled";
                };
        };

&icssg0_mdio {
        status = "disabled";
};

&icssg1_mdio {
        status = "okay";
        pinctrl-names = "default";
        pinctrl-0 = <&prg1_mdio0_pins>;

        icssg1_phy1: ethernet-phy@2 {
                reg = <0x2>;
                //interrupt-parent = <&exp1>;
                //interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
                ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
                ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;

                /*tx-internal-delay-ps = <250>;
                rx-internal-delay-ps = <2000>;
                ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;*/
        };
};

&icssg1_iep0 {
        pinctrl-names = "default";
        pinctrl-0 = <&prg1_iep0_pins>;
};

We are stuck on icssg1 ethernet bring-up. Do see, anything wrong with dts entry of icssg1?

Regards,

Jay

Hi, 

I realized that one of the project member has posted the same issue before. I am attaching the link below. It's the same issue i have posted above. 

AM6422: icssg_prueth port initializing but not able to connect. - Processors forum - Processors - TI E2E support forums

Here is the output of the "ethtool -S eth2"

NIC statistics:
     rx_good_frames: 0
     rx_broadcast_frames: 0
     rx_multicast_frames: 0
     rx_crc_error_frames: 1
     rx_mii_error_frames: 0
     rx_odd_nibble_frames: 0
     rx_frame_max_size: 56000
     rx_max_size_error_frames: 0
     rx_frame_min_size: 1792
     rx_min_size_error_frames: 1
     rx_overrun_frames: 1
     rx_class0_hits: 1
     rx_class1_hits: 0
     rx_class2_hits: 0
     rx_class3_hits: 0
     rx_class4_hits: 0
     rx_class5_hits: 0
     rx_class6_hits: 0
     rx_class7_hits: 0
     rx_class8_hits: 1
     rx_class9_hits: 1
     rx_class10_hits: 0
     rx_class11_hits: 0
     rx_class12_hits: 0
     rx_class13_hits: 0
     rx_class14_hits: 0
     rx_class15_hits: 0
     rx_smd_frags: 0
     rx_bucket1_size: 1792
     rx_bucket2_size: 3584
     rx_bucket3_size: 7168
     rx_bucket4_size: 14336
     rx_64B_frames: 0
     rx_bucket1_frames: 1
     rx_bucket2_frames: 0
     rx_bucket3_frames: 0
     rx_bucket4_frames: 0
     rx_bucket5_frames: 0
     rx_total_bytes: 0
     rx_tx_total_bytes: 15651
     tx_good_frames: 141
     tx_broadcast_frames: 141
     tx_multicast_frames: 141
     tx_odd_nibble_frames: 0
     tx_underflow_errors: 0
     tx_frame_max_size: 56000
     tx_max_size_error_frames: 0
     tx_frame_min_size: 1792
     tx_min_size_error_frames: 0
     tx_bucket1_size: 1792
     tx_bucket2_size: 3584
     tx_bucket3_size: 7168
     tx_bucket4_size: 14336
     tx_64B_frames: 0
     tx_bucket1_frames: 0
     tx_bucket2_frames: 141
     tx_bucket3_frames: 0
     tx_bucket4_frames: 0
     tx_bucket5_frames: 0
     tx_total_bytes: 10152

Regards,

Jay

Hi, 

Any update on this thread. 

Regards,

Jay

We are observing data going out on the lines, but we get no replies from the other host.

The other 2 interfaces on the board are using CPSW.

We have configured an address on the ports one at a time and are able to ping the same host with both CPSW ports.

Hello,

Are the data and clock lines observed for RX signals aligned properly? (with enough setup time for the data to be detected?). It would be helpful to show us a capture of what is observed.

I see the following from your NIC statistics log which indicates at least these frames are received but because have a CRC error, overrun error, min size error and there are no good frames without any errors. The most common issue with no packets being received but still being able to transfer is due to some sort of frame alignment issue which can be fixed by adjusting the clock shift line so that there is enough setup time for the data to be detected. I believe this can be tested with "phytool" command to write to the correct PHY register to introduce a delay and once proven out, modify the PHY driver to do this delay through the driver. If this is what we need to do and if you'd like, I can get in contact with the PHY team for DP83867 for them to help.

rx_crc_error_frames: 1
rx_min_size_error_frames: 1
rx_overrun_frames: 1

Looking at the AM64x EVM as reference, the DP83867 is used for CPSW and DP83869 is used for CPSW/ICSSG pinmuxed and ICSSG. I don't think DP83867 was used for ICSSG before. However, based on the EVM user's guide, DP83867 was chosen mainly for it's ability to configure its TX and RX delays. On the AM64x, TX delays are configured from SoC side and RX delays configured from PHY side. 

-Daolin

I would very much like to work with the PHY team on this issue.

Hi Dan,

I'm an Applications Engineer in the Ethernet Team. I briefly read through this query and see we want to adjust the RGMII TX/RX delays? The easiest way to check this would be to read the Registers of the PHY.

Register 0x32[1:0] will confirm whether the PHY is in RGMII shift or align mode. If shift mode is enabled, the amount of delay can be controlled in Register 0x86. Please refer to the DP83867 Data sheet for the register descriptions. Please note that both Reg 0x32 & 0x86 are extended registers and cannot be read directly, please refer to the following FAQ for more information.

The code block below is an example of how to use phytool to read Reg 0x32

phytool write ethx/phyaddr/0xD 0x001f

phytool write ethx/phyaddr/0xE 0x0032

phytool write ethx/phyaddr/0xD 0x401F

phytool read ethx/phyaddr/0xE

Regards,

Alvaro

Thanks for the information, Alvaro.  I do not have physical access to the board at this time, but I will have my remote team execute the commands.  I have a board in transit that I will be able to test myself.  I'll keep you informed.

Hi Alvaro,

We've configured Rx shift mode in 0x0032 register and delay is set to 2ns in 0x0086 register though Linux DTS. 

When we enable eth2 , We see below values in 0x0032 & 0x0086 registers:

///////////////////////
Read 0x86
phytool write eth2/0x02/0xD 0x001f
phytool write eth2/0x02/0xE 0x0086
phytool write eth2/0x02/0xD 0x401F
phytool read eth2/0x02/0xE
0x0007

///////////////////
Read 0x0032
phytool write eth2/0x02/0xD 0x001f
phytool write eth2/0x02/0xE 0x0032
phytool write eth2/0x02/0xD 0x401F
phytool read eth2/0x02/0xE
0x00d1

Regards,

Sanjay

Dear TI team, 

I have taken the waveform of PRG1_RGMII_RX_CLK_& Data to understand the DELAY. 

6507.PRG1_RGMII_RX_CLK_&_D_DELAY.zip

please take a look and let us know if you have any concerns. 

-

Vaibhav 

Hello,

Can you clarify which signal is PRG1_RGMII_RX_CLK and which signal is DATA? 

According to our hardware team, "RGMII is dual-data so it latches data on both rising and falling edge of clock"

If the yellow traced signal is the clock signal and the blue trace is the data signal, then the signal is definitely off as the clock should be delayed by 2ns and not the data delayed by 2ns.

-Daolin

Hi Einfochips,

Are you now able to transmit packets without any errors? The figure pasted below illustrates the transmitter emitting data and clock in aligned mode (no delay), the receiver (our PHY in this example) adds a delay to the Clock, so the rising edge of the clock falls squarely within the '1' or '0' region of the data signal. 

Regards,

Alvaro

Dear Daolin Qiu, 

Daolin Qiu said:

Can you clarify which signal is PRG1_RGMII_RX_CLK and which signal is DATA?

Yellow signal is PRG1_RGMII_RX_CLK & Blue signal is PRG1_RGMII_RX_DATA. 

-

Vaibhav

Dear Daolin,

Daolin Qiu said:

If the yellow traced signal is the clock signal and the blue trace is the data signal, then the signal is definitely off as the clock should be delayed by 2ns and not the data delayed by 2ns.

In the previous waveform /cfs-file/__key/communityserver-discussions-components-files/791/6507.PRG1_5F00_RGMII_5F00_RX_5F00_CLK_5F0026005F00_D_5F00_DELAY.zip, According to my observation clock is delayed by 2ns after the data transition. 

We have re-verified the delay between clock and data by setting 1nS delay in place of 2ns. You can take a look on attached waveform

PRG1_RGMII_RX_CLK_&_Data_1nS_DELAY.zip, Blue signal is PRG1_RGMII_RX_CLK & Yellow is PRG1_RGMII_RX_DATA.

-

Vaibhav

Dear Alvaro & Daolin Qiu 

Alvaro (Al-vuh-roe) Reyes said:

Are you now able to transmit packets without any errors?

Below is the MAC statistics with "ethtool -S eth2" for any errors or dropped packets after the ping failed. Can you please review it and let us know transmission of packets is working without any errors or not? 

# ethtool -S eth2
NIC statistics:
     rx_good_frames: 0
     rx_broadcast_frames: 0
     rx_multicast_frames: 0
     rx_crc_error_frames: 0
     rx_mii_error_frames: 0
     rx_odd_nibble_frames: 0
     rx_frame_max_size: 8000
     rx_max_size_error_frames: 0
     rx_frame_min_size: 256
     rx_min_size_error_frames: 1
     rx_overrun_frames: 1
     rx_class0_hits: 1
     rx_class1_hits: 0
     rx_class2_hits: 0
     rx_class3_hits: 0
     rx_class4_hits: 0
     rx_class5_hits: 0
     rx_class6_hits: 0
     rx_class7_hits: 0
     rx_class8_hits: 1
     rx_class9_hits: 1
     rx_class10_hits: 0
     rx_class11_hits: 0
     rx_class12_hits: 0
     rx_class13_hits: 0
     rx_class14_hits: 0
     rx_class15_hits: 0
     rx_smd_frags: 0
     rx_bucket1_size: 256
     rx_bucket2_size: 512
     rx_bucket3_size: 1024
     rx_bucket4_size: 2048
     rx_64B_frames: 0
     rx_bucket1_frames: 1
     rx_bucket2_frames: 0
     rx_bucket3_frames: 0
     rx_bucket4_frames: 0
     rx_bucket5_frames: 0
     rx_total_bytes: 0
     rx_tx_total_bytes: 3663
     tx_good_frames: 33
     tx_broadcast_frames: 33
     tx_multicast_frames: 33
     tx_odd_nibble_frames: 0
     tx_underflow_errors: 0
     tx_frame_max_size: 8000
     tx_max_size_error_frames: 0
     tx_frame_min_size: 256
     tx_min_size_error_frames: 0
     tx_bucket1_size: 256
     tx_bucket2_size: 512
     tx_bucket3_size: 1024
     tx_bucket4_size: 2048
     tx_64B_frames: 0
     tx_bucket1_frames: 0
     tx_bucket2_frames: 33
     tx_bucket3_frames: 0
     tx_bucket4_frames: 0
     tx_bucket5_frames: 0
     tx_total_bytes: 2376

By looking on the below outcome of "ethtool -S eth2", Do you think packets are transmitted without any errors?

     tx_good_frames: 33
     tx_broadcast_frames: 33
     tx_multicast_frames: 33

Can anyone help on the https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1343344/am6422-icssg_prueth-port-initializing-but-not-able-to-connect

-

Vaibhav 

Dear TI Team,

We came across available PRU_ICSSG Ethernet documentation at https://software-dl.ti.com/processor-sdk-linux/esd/docs/08_00_00_21/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/PRU_ICSSG_Ethernet.html  and run the ethtool command as suggested in the document & provided output/response below for your review. Can you please take a look and let us know if have any concerns on the same? 

1) Enable (Up) the PRU_ICSSG Ethernet port

# echo 1 > /proc/sys/net/ipv6/conf/eth2/disable_ipv6
# ip addr add 192.168.1.35/24 dev eth2
# ip link set dev eth2 up
[  129.572603] remoteproc remoteproc8: powering up 300b4000.pru
[  129.580413] remoteproc remoteproc8: Booting fw image ti-pruss/am65x-sr2-pru0-prueth-fw.elf, size 38148
[  129.589775] remoteproc remoteproc8: unsupported resource 5
[  129.595336] remoteproc remoteproc8: remote processor 300b4000.pru is now up
[  129.602326] remoteproc remoteproc9: powering up 30084000.rtu
[  129.609313] remoteproc remoteproc9: Booting fw image ti-pruss/am65x-sr2-rtu0-prueth-fw.elf, size 30852
[  129.618673] remoteproc remoteproc9: remote processor 30084000.rtu is now up
[  129.625672] remoteproc remoteproc10: powering up 3008a000.txpru
[  129.632995] remoteproc remoteproc10: Booting fw image ti-pruss/am65x-sr2-txpru0-prueth-fw.elf, size 37208
[  129.642654] remoteproc remoteproc10: remote processor 3008a000.txpru is now up
[  129.651899] pps pps1: new PPS source ptp2
[  129.657518] net eth2: started

# [  133.755426] icssg-prueth icssg1-eth eth2: Link is Up - 1Gbps/Full - flow control off

2) Display Standard Information about device/link  for PRU_ICSSG Ethernet port

# ethtool eth2
Settings for eth2:
        Supported ports: [ TP    MII ]
        Supported link modes:   10baseT/Full
                                100baseT/Full
                                1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Full
                                100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Half 1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        master-slave cfg: preferred slave
        master-slave status: slave
        Port: Twisted Pair
        PHYAD: 2
        Transceiver: external
        MDI-X: Unknown
        Current message level: 0x00007fff (32767)
                               drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
        Link detected: yes

3) Display time stamping capabilities

# ethtool -T eth2
Time stamping parameters for eth2:
Capabilities:
        hardware-transmit
        software-transmit
        hardware-receive
        software-receive
        software-system-clock
        hardware-raw-clock
PTP Hardware Clock: 2
Hardware Transmit Timestamp Modes:
        off
        on
Hardware Receive Filter Modes:
        none
        all

4) Show permanent hardware address

# ethtool -P eth2
Permanent address: not set

-

Vaibhav

Hello,

The signals in the below scope capture (1ns delay) with blue as clock and yellow as data appear to be correct in terms of clock delayed rather than data delayed. You just need to make sure it is 2ns delay of the clock. 

I was under the impression that RX was not working properly but TX was working properly based on the previous statement below

"Ethernet interface comes up on this interface but we are only able to transmit and not able to receive anything on this ethernet". 

One way to check if the packets transferred successfully with no errors is to check the ethtool RX statistics on the link partner where you are sending the packets. In fact, I would recommend doing this to check if transmitting packets worked without errors.

From the ethtool statistics I no longer see "rx_crc_error_frames" but I still see the following errors. I'll have to check with an expert on the team about these errors and will get back to you later today or tomorrow.

rx_min_size_error_frames: 1
rx_overrun_frames: 1

-Daolin

Dear TI Team,

We came across available PRU_ICSSG Ethernet documentation at https://software-dl.ti.com/processor-sdk-linux/esd/docs/08_00_00_21/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/PRU_ICSSG_Ethernet.html  and run the ethtool command as suggested in the document & provided output/response below for your review. Can you please take a look and let us know if have any concerns on the same? 

1) Enable (Up) the PRU_ICSSG Ethernet port

# echo 1 > /proc/sys/net/ipv6/conf/eth2/disable_ipv6
# ip addr add 192.168.1.35/24 dev eth2
# ip link set dev eth2 up
[  129.572603] remoteproc remoteproc8: powering up 300b4000.pru
[  129.580413] remoteproc remoteproc8: Booting fw image ti-pruss/am65x-sr2-pru0-prueth-fw.elf, size 38148
[  129.589775] remoteproc remoteproc8: unsupported resource 5
[  129.595336] remoteproc remoteproc8: remote processor 300b4000.pru is now up
[  129.602326] remoteproc remoteproc9: powering up 30084000.rtu
[  129.609313] remoteproc remoteproc9: Booting fw image ti-pruss/am65x-sr2-rtu0-prueth-fw.elf, size 30852
[  129.618673] remoteproc remoteproc9: remote processor 30084000.rtu is now up
[  129.625672] remoteproc remoteproc10: powering up 3008a000.txpru
[  129.632995] remoteproc remoteproc10: Booting fw image ti-pruss/am65x-sr2-txpru0-prueth-fw.elf, size 37208
[  129.642654] remoteproc remoteproc10: remote processor 3008a000.txpru is now up
[  129.651899] pps pps1: new PPS source ptp2
[  129.657518] net eth2: started

# [  133.755426] icssg-prueth icssg1-eth eth2: Link is Up - 1Gbps/Full - flow control off

2) Display Standard Information about device/link  for PRU_ICSSG Ethernet port

# ethtool eth2
Settings for eth2:
        Supported ports: [ TP    MII ]
        Supported link modes:   10baseT/Full
                                100baseT/Full
                                1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Full
                                100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Half 1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        master-slave cfg: preferred slave
        master-slave status: slave
        Port: Twisted Pair
        PHYAD: 2
        Transceiver: external
        MDI-X: Unknown
        Current message level: 0x00007fff (32767)
                               drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
        Link detected: yes

3) Display time stamping capabilities

# ethtool -T eth2
Time stamping parameters for eth2:
Capabilities:
        hardware-transmit
        software-transmit
        hardware-receive
        software-receive
        software-system-clock
        hardware-raw-clock
PTP Hardware Clock: 2
Hardware Transmit Timestamp Modes:
        off
        on
Hardware Receive Filter Modes:
        none
        all

4) Show permanent hardware address

# ethtool -P eth2
Permanent address: not set

-

Vaibhav

Hello Vaibhav,

Actually, let me ask some clarifying questions first to understand the current issue better.

1. The link partner device you have connected to your custom board (DUT), is that link partner known to transmit and receive packets without errors? Please verify by testing the link partner device with a known good device first.

2. Does ping test from link partner to DUT work? This tests if receive packets on DUT is working.

3. Does ping test from DUT to link partner work? This tests if transmit packets on DUT is working.

4. Ethtool -S eth2 statistics you shared recently, is that from ping from link partner to DUT not working? If so, this would be results from receive packets on DUT not working in which case we need to understand the rx statistics better.

5. If the transmit packets on DUT is not working, could you share the ethtool statistics from both the DUT and link partner? Additionally, could you share the TX data and clk signals in a scope capture? We would be checking for similar data-clock timing as Alvaro indicated.

-Daolin

Dear Daolin, 

Daolin Qiu said:

1. The link partner device you have connected to your custom board (DUT), is that link partner known to transmit and receive packets without errors? Please verify by testing the link partner device with a known good device first.

2. Does ping test from link partner to DUT work? This tests if receive packets on DUT is working.

3. Does ping test from DUT to link partner work? This tests if transmit packets on DUT is working.

4. Ethtool -S eth2 statistics you shared recently, is that from ping from link partner to DUT not working? If so, this would be results from receive packets on DUT not working in which case we need to understand the rx statistics better.

5. If the transmit packets on DUT is not working, could you share the ethtool statistics from both the DUT and link partner? Additionally, could you share the TX data and clk signals in a scope capture? We would be checking for similar data-clock timing as Alvaro indicated.

Your many questions from above can be resolved by following input. If still not resolved then please let us know specific questions again. 

We have tested Tx path by connecting board ICSSG1 eth2 (192.168.1.200) to external HOST PC(192.168.1.10)

 Board ((192.168.1.200)  -> PC(192.168.1.10)

 1) Please see below console capture of am64x board. Sending ping to HOST PC - 192.168.1.10

 2) See below picture which shows wireshark capture on HOST PC. It shows ARP packets coming from am64x board with IP Address =192.168.1.200 and MAC = 0A:0D:C6:7A:2A:86

 3) Below screen capture shows ARP reply.

Attached wireshark pcapng file for detailed review: am64x pru Tx packet wireshark capture on host.zip

Please review above and let us know if you have any concerns on the transmit path of ICSSG1 eth2 working functionality.

-

Vaibhav 

Hello Vaibhav,

Based on your wireshark capture, it looks like after running ping from your custom AM64x board to the host PC, the ARP request (transmitted packet) was successful as the host PC is responding to the ARP request (ARP reply) and replying back to the AM64x custom board. However, on the previously shared ethtool -S eth2 on the custom board, zero rx_good_frames were observed. This indicates that the ARP reply is not received on the custom board end which explains why the ping fails. 

What is strange is zero rx_crc_errors are observed which would have been indicative of erroneous frames detected and then dropped because of the errors. Additionally, zero rx_broadcast_frames are observed which usually would show up when ethernet interface link is up and before any IP addresses are set as the connected devices would be broadcasting for a DHCP server. It seems as if full frames are not being received such that CRC errors cannot even be calculated.

The single rx_min_size_error_frames: 1, rx_overrun_frames: 1, are strange as well because typically you would see more than just 1 single frame and see at least several rx_broadcast_frames or rx_good_frames before rx_overrun_frames show up. Do these rx_min_size_error_frames and rx_overrun_frames increment at all or stay at 1 after ping transmission?

Could you try switching your ethernet cable with another one? I know this sounds like strange request but if the ethernet cable was damaged (one of the 4 twisted pairs was faulty) then it could be likely that the entire ARP reply frame was lost before it gets to the custom board PHY or MAC. 

To determine if the frame loss/error is present at the PHY, I'll ask Alvaro from the Ethernet PHY team to suggest how to read the PHY registers to detect any data valid/errors detected.

Later, if we determine that no data/frame errors are detected at the PHY then the frame loss/error must be at the MAC. If this is the case, I would recommend probing the RX data and clock signals closer to the SOC and compare the results with the signals probed closer to the PHY to see if any signal distortion is happening. If it comes to this issue, I will have to consult with our hardware team for more advice on how to proceed troubleshooting.

I appreciate your patience as we try to narrow down the issue.

-Daolin

Dear Daolin, 

Thanks for further guidance, 

Below is a response to your question.

1) 

Daolin Qiu said:

Do these rx_min_size_error_frames and rx_overrun_frames increment at all or stay at 1 after ping transmission?

Below is the latest outcome of "ethtool -S eth2", In the same rx_crc_errors is 1 which was not in earlier shared log.

# ethtool -S eth2
NIC statistics:
     rx_good_frames: 0
     rx_broadcast_frames: 0
     rx_multicast_frames: 0
     rx_crc_error_frames: 1
     rx_mii_error_frames: 0
     rx_odd_nibble_frames: 0
     rx_frame_max_size: 372000
     rx_max_size_error_frames: 0
     rx_frame_min_size: 11904
     rx_min_size_error_frames: 1
     rx_overrun_frames: 1
     rx_class0_hits: 1
     rx_class1_hits: 0
     rx_class2_hits: 0
     rx_class3_hits: 0
     rx_class4_hits: 0
     rx_class5_hits: 0
     rx_class6_hits: 0
     rx_class7_hits: 0
     rx_class8_hits: 1
     rx_class9_hits: 1
     rx_class10_hits: 0
     rx_class11_hits: 0
     rx_class12_hits: 0
     rx_class13_hits: 0
     rx_class14_hits: 0
     rx_class15_hits: 0
     rx_smd_frags: 0
     rx_bucket1_size: 11904
     rx_bucket2_size: 23808
     rx_bucket3_size: 47616
     rx_bucket4_size: 95232
     rx_64B_frames: 0
     rx_bucket1_frames: 1
     rx_bucket2_frames: 0
     rx_bucket3_frames: 0
     rx_bucket4_frames: 0
     rx_bucket5_frames: 0
     rx_total_bytes: 0
     rx_tx_total_bytes: 10323
     tx_good_frames: 93
     tx_broadcast_frames: 93
     tx_multicast_frames: 93
     tx_odd_nibble_frames: 0
     tx_underflow_errors: 0
     tx_frame_max_size: 372000
     tx_max_size_error_frames: 0
     tx_frame_min_size: 11904
     tx_min_size_error_frames: 0
     tx_bucket1_size: 11904
     tx_bucket2_size: 23808
     tx_bucket3_size: 47616
     tx_bucket4_size: 95232
     tx_64B_frames: 0
     tx_bucket1_frames: 0
     tx_bucket2_frames: 93
     tx_bucket3_frames: 0
     tx_bucket4_frames: 0
     tx_bucket5_frames: 0
     tx_total_bytes: 6696

2) 

Daolin Qiu said:

Could you try switching your ethernet cable with another one? I know this sounds like strange request but if the ethernet cable was damaged (one of the 4 twisted pairs was faulty) then it could be likely that the entire ARP reply frame was lost before it gets to the custom board PHY or MAC. 

we have make sure ethernet cable is working. With the same ethernet cable we are able to ping Host PC (192.168.1.10) from CPSW ethernet port (eth0), however not with PRU_ICSSG ethernet (eth2) . 

3)

Daolin Qiu said:

If this is the case, I would recommend probing the RX data and clock signals closer to the SOC and compare the results with the signals probed closer to the PHY to see if any signal distortion is happening

Package of SOC(Processor) is BGA, So probing on the PIN/BALL of SOC(Processor) is not possible, However we have probed the RX data, clock, RXDV_ER (RX_CTL) on the series resistor which is placed close to the EPHY. Here is folder of all waveforms "PRU-ICSSG_ETH2_RX_Path_waveform.zip". please note that in device tree we have set following (rgmii-rxid) mode of EPHY & SOC 

icssg1_emac0: ethernet-mii0 {
                        phy-handle = <&icssg1_phy1>;
                        phy-mode = "rgmii-rxid";

4) Schematic of PRU_ICSSG ethernet (eth2) is attached here "7026.PRU-ETH3.pdf"for your review and future reference. 

5) Dear Alvaro (Al-vuh-roe) Reyes

Daolin Qiu said:

To determine if the frame loss/error is present at the PHY, I'll ask Alvaro from the Ethernet PHY team to suggest how to read the PHY registers to detect any data valid/errors detected.

Do you have any feedback on the above point? 

Let us know if any information required from our side. 

-

Vaibhav

Dear all,

Just for everyone information, We have taken the reference of SK-AM64 EVM design for 2 x CPSW ethernet port, and we followed SysConfig (ti.com) tool for (PRU ICSS) 3rd ethernet port. SK-AM64 EMV design have DP83867 EPHY for CPSW ethernet port and DP83869 EPHY for PRU ICSS ethernet port.  However, in order to keep a singal EPHY part in BOM, In our custom board design have DP83867 EPHY for both CPSW ethernet port & PRU ICSS ethernet port.

In our custom board CPSW ethernet port  is working, however,PRU ICSS ethernet port only RGMII transmitter path working and RGMII receiver path is not working. 

-

Vaibhav

Hello Vaibhav,

Thanks for sharing additional information including the waveform scope captures. We checked the waveforms and noticed for the RD0-RD3 with RX_CLK graphs, the time offset is <2nS. We would need to review the layout to check if for example RX trace length matching is satisfied. Can the layout files be provided for our hardware team to review?

I checked the previously shared device tree snippet for icssg ethernet and nothing immediately looks incorrect. The only thing I noticed is that in the TI EVM dts "rgmii-id" is used for phy-mode rather than "rgmii-rxid". The DP83867_RGMIIDCTL_2_00_NS is set to 2ns delay for the PHY which make sense. We need to ask the Ethernet PHY team about whether setting this DP83867_RGMIIDCTL_2_00_NS means measuring 2nS delay on RX path.

Can you try testing the icssg ethernet interface at 10Mbps? The idea is to configure to a lower speed to drop the RX clock rate down to a lower speed, to help make the MAC more tolerant of any timing issues. The goal is to check if rx_good_frames are detected or at the very least if we can see more than just a single rx_crc_error. You can do this by using "ethtool -s eth2 speed 10" and make sure to do the equivalent for your host PC/link partner.

DP83867 PHY should technically work fine for icssg ethernet and is likely not causing the current issue.

Additionally, is this issue of "PRU ICSS ethernet port only RGMII transmitter path working and RGMII receiver path is not working" observable on multiple boards or just one?

-Daolin

The issue is observable with more than one board. I will change the dts setting to rgmii-rxid.  It was originally set to that, but we were changing settings while trying to get it to work.

Just to clarify, on the TI EVM dts we used rgmii-id but it looks like from the dts snippet, rgmii-rxid was already used...

Hi Einfochips,

This can be checked by reading Reg 0x15. This register is cleared when written to.

Regards,

Alvaro

Dear Daolin, 

Daolin Qiu said:

the time offset is <2nS

2nS is ideal delay for batter setup & hold time of RGMII signal. However, minimum 1nS setup & hold time of RGMII signal is acceptable by AM64xx & PHY.

Daolin Qiu said:

Can the layout files be provided for our hardware team to review?

I have attached PRU_ICSSG_Ethernet_Length Match report.zip  & Layout.zip image of the same for your reference. 

please let us know, if you have any concern on the same.

-

Vaibhav

Hello Vaibhav and Dan,

Thanks for sharing the additional information. We will have our hardware team review this.

Daolin Qiu said:

Can you try testing the icssg ethernet interface at 10Mbps? The idea is to configure to a lower speed to drop the RX clock rate down to a lower speed, to help make the MAC more tolerant of any timing issues. The goal is to check if rx_good_frames are detected or at the very least if we can see more than just a single rx_crc_error. You can do this by using "ethtool -s eth2 speed 10" and make sure to do the equivalent for your host PC/link partner.

Can you try this as well and let us know about your findings? While this doesn't not directly solve the issue, it would give us more clues about why it seems like the ARP reply message is not being detected at all on the RX path of the icssg ethernet interface (no rx_good_frames, and only single digit crc_error_frames etc).

-Daolin

We did not get some of this requested information, so we are not sure how productive the requested call for tomorrow will be. 

Some more suggestions based on some of our internal discussions , that may help you with root causing /isolating the issues you are seeing 

DP83867 clocking requirements are different from DP83869 , but assumption is that you have CPSW working then it should be ok.
If you need a working hardware /software example of this, you can evaluate buying the PHYTEC board

https://www.phytec.com/product/phycore-am64x/

https://docs.phytec.com/projects/yocto-phycore-am64x/en/bsp-yocto-ampliphy-am64x-pd23.2.1/interfaceguides/ethernet.html

The below testing is a bit unclear?

tx_frame_max_size: 372000
tx_frame_min_size: 11904

tx_frame_max_size: 8000
tx_frame_min_size: 256

rx_frame_max_size: 56000
rx_frame_min_size: 1792

Are you doing this different intentionally ?
Firmware supports max 2000B frame size, due to buffer allocation (buffer pool HW widget in ICSSG also has hardcoding). So if changes are intentional, its not as straightforward as you may think.

RX min and max size needs to be configured in couple of registers in HW. So if this is not taken care also can be an issue.
As such max MTU configured by Linux driver is 1522 . So if you are configuring higher - its out of spec usage

PHY team suggestion to read PHY RXERR register (0x15) is also a good hint.- do you have this info to share yet?

Hi Daolin,

We tested with 10 MBPS , still there is no change in rx_good_frames. It stays rx_good_frames=0, crc_error_frames=1 

we showed this to one of TI representatives during the call.

Regards,

Sanjay

HI Daolin,

Not sure how to configure rx_frame_max_size . It pops up automatically and keeps on changing. every time we run ethtool -S eth2 , it shows different values. 

I will try to change  using sysfs today.

PHY RXERR register (0x15) shows 0x00.

regards,

Sanjay

Hi All, 

In the Am64x EVM the buffer output IO is 1.8V and on the customer schematics also the IO is 1.8V.

Mukul Bhatnagar said:

DP83867 clocking requirements are different from DP83869 , but assumption is that you have CPSW working then it should be ok.

For 3.3V IO, for the DP83869 it is Ok to provide a 1.8V supply. Please refer below FAQ

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1334656/faq-dp83869-clock-input-xi-range-am644x-am64x-use-case

For the DP83867, the clock input is recommended to be 1.8V irrespective of the IO supply.

You should be Ok with the clock configuration.

Regards,

Sreenivasa

few things we captured from our discussions 

1) Please procure the TMDS64EVM for any ICSSG based debug and evaluation as the SK does not have the same debuggability and MCU+ SDK support incase some RTOS/baremetal examples like loop back are needed. We would also like (at a lower priority) to have you try the EVM to rule out any setup /networking issues (switches etc)

2) We strongly recommend that you move to SDK9.2 baseline as there are some known issues on SYSFW and ICSSG firmware that were fixed /addressed in the latest SDK. I will find the release notes to point to the ICSSG specific improvements. I understand that kernel change will not be easy for you , but at the minimum we need you to eliminate any SDK/software "improvements" mis match 

3) Loopback testing - to confirm MAC to PHY interface integrity. No support in Linux, so potentially look at PHY register bit banging or evaluate MCU+ SDK examples. Will discuss more internally if there is an easy/quick way for you to try.

4) Series resistor mods/test recommended by Sreenivasa

5) Potentially evaluate the AM64 PHYTEC board hardware/software for a known good working combination of the PHY you are using with ICSSG. 

Thanks Mukul.

We’re able to get Linux kernel from SDK(09.02..)  and build with old SDK( 08.05..) .

ICSSG1 Ethernet working with this kernel. 

Regards,

Sanjay

Sanjay

Sorry I want to make sure I understand your last message. Did your issues you were facing went away all together with the latest SDK release ?

Hello Sanjay,

Mukul Bhatnagar said:

Did your issues you were facing went away all together with the latest SDK release ?

To add onto Mukul's question, was the original build based on SDK 8.06 different from the out of box version provided on https://www.ti.com/tool/download/PROCESSOR-SDK-LINUX-RT-AM64X/08.06.00.42 wic image?

=======================================================================================

I've tested on AM64x EVM (TMDS64EVM) with out of box SDK 8.06 (kernel 5.10.168-rt83-gc1a1291911) on eth2 (icssg-prueth ethernet) and see the following when just plugging in the cable to my host PC.

root@am64xx-evm:~# ethtool -S eth2
NIC statistics:
     rx_good_frames: 7
     rx_broadcast_frames: 3
     rx_multicast_frames: 3
     rx_crc_error_frames: 0
     rx_mii_error_frames: 0
     rx_odd_nibble_frames: 0
     rx_frame_max_size: 12000
     rx_max_size_error_frames: 0
     rx_frame_min_size: 384
     rx_min_size_error_frames: 0
     rx_overrun_frames: 0

root@am64xx-evm:~# ethtool -i eth2
driver: icssg-prueth
version: 5.10.168-rt83-gc1a1291911

I don't see any rx_crc_error_frames, rx_min_size_error_frames, rx_overrun_frames from my result. This implies there shouldn't be an issue based on the out of box SDK version.

-Daolin

The kernel we are using is from SDK 8.06 with a DTS customized for our configuration.  We based our build on instructions from the SDK.  We are using buildroot instead of yocto.  We've been running it on the SK-AM64B board with no issues.  When we started this project, the 9.x SDK was not yet available.  With some of the issues I've been seeing with the new SDK, I've been delaying an upgrade to it..

Dan

FYI my colleague just updated the FAQ on buildroot with support for 9.x incase this helps

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1226815/faq-buildroot-support-for-sitara-am62x-am62ax-am62px-am64x-devices