This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6548: Where to find PRU firmware that works with MII?

Part Number: AM6548
Other Parts Discussed in Thread: DP83869

We want to have our ICSSG1 talking to a PHY. We build 'firmware/icss_dualmac' in git.ti.com/.../k3-image-gen (Commit 3b4a2007a54db72d8814ecbb2555392863c24935). It works fine for a RGMII connection to a PHY. Now we have an MII connection. Therefore we build the firmware with the makefile patched¹ to talk MII. RX seems to work (ethtool reports valid rx packages²), but TX does not. In firmware/icss_dualmac/src/rxl2_txl2.asm:61 I found the comment "MII : set up for MII mode (RX ok, TX not tested)". So I guess TX is not expected to work with this firmware? I also found that this firmware moved (git.ti.com/.../pdk, packages/ti/drv/emac/firmware/icss_dualmac), but the issue remains.

Is there any PRU MAC firmware out there that talks MII?

Thanks!

¹patch:

---
 firmware/icss_dualmac/src/makefile | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/firmware/icss_dualmac/src/makefile b/firmware/icss_dualmac/src/makefile
index ea78798..cb875d2 100644
--- a/firmware/icss_dualmac/src/makefile
+++ b/firmware/icss_dualmac/src/makefile
@@ -82,7 +82,7 @@ all:
     $(MAKE) BLDT="../bin" all_bins
   endif
 
-all_bins: $(BLDT)/rxl2_txl2_rgmii0_bin.h $(BLDT)/rxl2_txl2_rgmii1_bin.h \
+all_bins: $(BLDT)/rxl2_txl2_mii0_bin.h $(BLDT)/rxl2_txl2_mii1_bin.h \
         $(BLDT)/rtu_test0_bin.h $(BLDT)/rtu_test1_bin.h
 
 CL_FLAGS = --endian=little \
@@ -103,7 +103,7 @@ EF_PRU1 = -DMAC  -DSLICE1
 EF_RTU0 = -DMAC  -DSLICE0 -DDO_PSI_ABORT
 EF_RTU1 = -DMAC  -DSLICE1 -DDO_PSI_ABORT
 
-APP_DEFS = --define=RGMII \
+APP_DEFS = --define=MII \
        -z \
        --stack_size=0 \
        --heap_size=0 \
@@ -111,8 +111,8 @@ APP_DEFS = --define=RGMII \
        --warn_sections
 
 PRUS = rxl2_txl2
-PRU0 = $(PRUS)_rgmii0
-PRU1 = $(PRUS)_rgmii1
+PRU0 = $(PRUS)_mii0
+PRU1 = $(PRUS)_mii1
 RTU = rtu
 RTUS = rtu_v2
 RTU0 = rtu_test0
@@ -130,7 +130,7 @@ mkversion:
 $(BLDT)/$(PRU0)_bin.h: $(PRUS).asm pru.cmd
     mkdir -p $(BLDT)/$(PRU0)
     $(CLPRU) $(CL_FLAGS) $(FLAGS) \
-        -DRGMII $(EF_PRU0) -fr=$(BLDT)/$(PRU0) \
+        -DMII $(EF_PRU0) -fr=$(BLDT)/$(PRU0) \
         -fs=$(BLDT)/$(PRU0) --preproc_dependency="$(PRUS).d" $(PRUS).asm
     $(CLPRU) $(CL_FLAGS) $(APP_DEFS) \
         --entry_point=Start $(BLDT)/$(PRU0)/$(PRUS).opru pru.cmd \
@@ -143,7 +143,7 @@ $(BLDT)/$(PRU0)_bin.h: $(PRUS).asm pru.cmd
 $(BLDT)/$(PRU1)_bin.h: $(PRUS).asm pru.cmd
     mkdir -p $(BLDT)/$(PRU1)
     $(CLPRU) $(CL_FLAGS) $(FLAGS) \
-        -DRGMII $(EF_PRU1) -fr=$(BLDT)/$(PRU1) \
+        -DMII $(EF_PRU1) -fr=$(BLDT)/$(PRU1) \
         -fs=$(BLDT)/$(PRU1) --preproc_dependency="$(PRUS).d" $(PRUS).asm
     $(CLPRU) $(CL_FLAGS) $(APP_DEFS) \
         --entry_point=Start $(BLDT)/$(PRU1)/$(PRUS).opru pru.cmd \
@@ -157,7 +157,7 @@ $(BLDT)/$(RTU0)_bin.h: $(RTUS).asm pru.cmd
     mkdir -p $(BLDT)/$(RTU0)
     $(CLPRU) $(CL_FLAGS) $(FLAGS) \
         -ss \
-        -DRGMII $(EF_RTU0) -fr=$(BLDT)/$(RTU0) \
+        -DMII $(EF_RTU0) -fr=$(BLDT)/$(RTU0) \
         -fs=$(BLDT)/$(RTU0) --preproc_dependency="$(RTUS).d" $(RTUS).asm
     $(CLPRU) $(CL_FLAGS) $(APP_DEFS) \
         --entry_point=Start $(BLDT)/$(RTU0)/$(RTUS).opru pru.cmd \
@@ -171,7 +171,7 @@ $(BLDT)/$(RTU1)_bin.h: $(RTUS).asm pru.cmd
     mkdir -p $(BLDT)/$(RTU1)
     $(CLPRU) $(CL_FLAGS) $(FLAGS) \
         -ss \
-        -DRGMII $(EF_RTU1) -fr=$(BLDT)/$(RTU1) \
+        -DMII $(EF_RTU1) -fr=$(BLDT)/$(RTU1) \
         -fs=$(BLDT)/$(RTU1) --preproc_dependency="$(RTUS).d" $(RTUS).asm
     $(CLPRU) $(CL_FLAGS) $(APP_DEFS) \
         --entry_point=Start $(BLDT)/$(RTU1)/$(RTUS).opru pru.cmd \
--
2.25.1

² output after trying to ping the device (the rx_good_frames counter increases during pings):

# ethtool -S eth1
NIC statistics:
     rx_good_frames: 861
     rx_broadcast_frames: 10
     rx_multicast_frames: 55
     rx_crc_error_frames: 0
     rx_mii_error_frames: 0
     rx_odd_nibble_frames: 0
     rx_frame_max_size: 2000
     rx_max_size_error_frames: 0
     rx_frame_min_size: 64
     rx_min_size_error_frames: 1
     rx_overrun_frames: 3
     rx_class0_hits: 859
     rx_class1_hits: 859
     rx_class2_hits: 859
     rx_class3_hits: 859
     rx_class4_hits: 859
     rx_class5_hits: 0
     rx_class6_hits: 0
     rx_class7_hits: 0
     rx_class8_hits: 0
     rx_class9_hits: 0
     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: 64
     rx_bucket2_size: 128
     rx_bucket3_size: 256
     rx_bucket4_size: 512
     rx_64B_frames: 775
     rx_bucket1_frames: 776
     rx_bucket2_frames: 79
     rx_bucket3_frames: 7
     rx_bucket4_frames: 0
     rx_bucket5_frames: 0
     rx_total_bytes: 58217
     rx_tx_total_bytes: 58217
     tx_good_frames: 0
     tx_broadcast_frames: 0
     tx_multicast_frames: 0
     tx_odd_nibble_frames: 0
     tx_underflow_errors: 0
     tx_frame_max_size: 2000
     tx_max_size_error_frames: 0
     tx_frame_min_size: 64
     tx_min_size_error_frames: 0
     tx_bucket1_size: 64
     tx_bucket2_size: 128
     tx_bucket3_size: 256
     tx_bucket4_size: 512
     tx_64B_frames: 0
     tx_bucket1_frames: 0
     tx_bucket2_frames: 0
     tx_bucket3_frames: 0
     tx_bucket4_frames: 0
     tx_bucket5_frames: 0
     tx_total_bytes: 0

  • Jonatan,

    Not natively. Are you working with SR1.0 or SR2.0 silicon? If the former, we can give guidance on modifications to the dual-MAC firmware you are referencing to compile for MII. If on SR2.0 the firmware baseline is updated and MII is not yet enabled but should be in the coming weeks.

    Best regards,

    Dave

  • Hello Dave,

    thanks for the reply. I am working with SR1.0. So any guidance would be welcome.

    Best regards,

    Jonatan

  • What kind of guidance would that be? Some patch file? And is that something that might happen within the next one or two weeks maybe?

  • Jonatan,

    I'll post a summary this week.

    Best regards,

    Dave

  • Hi Dave,

    any chance you could post the summary this week?

    Best regards,

    Jonatan

  • Jonatan,

    For MII support with the ICSSG dual-MAC, the following changes are needed:
    1) SoC pinmux update to select GPIO pins rather than RGMII (use MODE 2)
    2) ICSSG pinmux to select MII_RT mode
    3) PRU:MAC port mapping per the hardware design for each Tx and Rx
    re-map in <install_dir>\pdk_am65xx_1_0_7\packages\ti\drv\emac\firmware\icss_dualmac\src\rxl2_txl2.asm
    >> enable_rx_l2 .macro <<


    4) Makefile update for MII vs. RGMII
    Change the 4x instances of “-DRGMII” to “-DMII” in <install_dir>\pdk_am65xx_1_0_7\packages\ti\drv\emac\firmware\icss_dualmac\src\makefile


    5) IPG update for MII timing
    There is a default in <install_dir>\pdk_am65xx_1_0_7\packages\ti\drv\emac\firmware\icss_dualmac\src\rxl2_txl2.asm
    >> set_tx_ipg .macro <<
    Currently defines IPG for 88ns. You can update here for the default, but more appropriate to go through the driver to update the IPG, which will over-write the value maintained by the firmware.

    Use emac_icssg_update_link_speed_100MB() ; source in <install_dir>\pdk_am65xx_1_0_7\packages\ti\drv\emac\src\v5\emac_drv_v5.c


    6) Disable 10M & half-duplex (for now, we’ve not tested and there are some issues for 10M IPG and half-duplex signaling with MII)
    For enforcing 100M FD operation, you can update your PHY initialization to restrict to this mode.

    Best regards,

    Dave

  • Hi Dave,

    1+2) I used the TI Pinmux Tool to change my Linux Device Tree according to MII_RT mode on the ICSSG1. Phytec (the SoM manufacturer) confirmed that those changes were correct. What do you mean with 1) though? Which GPIO pins are needed and what for? What is MODE 2?

    3) I am not sure I understand that hint correctly. I connected the pins according to what Phytec suggests for MII mode (which is a circular swapping of TDx and TX_CTL compared to RGMII). Is that enough or do I still need to change that macro? And if so, how do I need to change it?

    4) I have done that already (see my initial post).

    5) I can set the rate to 100MBit/s Full Duplex from within Linux. Is this enough then or do I still need to change the IPG? And if so, to what value? Should I just increase the value set to r11 (0x16) by the factor of 10 (to 0xDC)?

    6) I do this via ethtool in Linux.

    Best regards,

    Jonatan

  • Jonatan,

    1) At the SoC level, you can select the pinmux options. You want to be sure to select the PRU GPIO pins and not the PRU RGMII pins. I should have said MODE0 not MODE2. This is from Table4-75 of the datasheet.

    2) At the ICSSG level, MII_RT is a mode setting for the GPI and GPO

    3) You'll need to confirm the hardware change with PHYTEC, but yes effectively the Tx data/ctl "rotate" by 1 vs. RGMII. Inside the ICSSG there is a PRU-to-MAC port mapping that you'll need to change in the firmware and rebuild it.

    4-6 sound complete.

    Best regards,

    Dave

  • Hi Dave,

    thanks for the fast reply.

    1) Ok, seems like the device tree pinmuxing I exported from TI Pinmux Tool is exactly what you refer to:

        pru_icssg1_mii_pins_default: pru_icssg1_mii_pins_default {
            pinctrl-single,pins = <
                AM65X_IOPAD(0x0170, PIN_INPUT, 1) /* (AE19) PRG1_PRU1_GPO16.pr1_mii_mt0_clk */
                AM65X_IOPAD(0x016c, PIN_OUTPUT, 0) /* (AG19) PRG1_PRU1_GPO15.pr1_mii0_txen */
                AM65X_IOPAD(0x0168, PIN_OUTPUT, 0) /* (AH19) PRG1_PRU1_GPO14.pr1_mii0_txd3 */
                AM65X_IOPAD(0x0164, PIN_OUTPUT, 0) /* (AF19) PRG1_PRU1_GPO13.pr1_mii0_txd2 */
                AM65X_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AE20) PRG1_PRU1_GPO12.pr1_mii0_txd1 */
                AM65X_IOPAD(0x015c, PIN_OUTPUT, 0) /* (AC20) PRG1_PRU1_GPO11.pr1_mii0_txd0 */
                AM65X_IOPAD(0x00f0, PIN_INPUT, 1) /* (AG23) PRG1_PRU0_GPO4.pr1_mii0_rxdv */
                AM65X_IOPAD(0x00f8, PIN_INPUT, 1) /* (AF22) PRG1_PRU0_GPO6.pr1_mii_mr0_clk */
                AM65X_IOPAD(0x00ec, PIN_INPUT, 1) /* (AD21) PRG1_PRU0_GPO3.pr1_mii0_rxd3 */
                AM65X_IOPAD(0x00e8, PIN_INPUT, 1) /* (AF23) PRG1_PRU0_GPO2.pr1_mii0_rxd2 */
                AM65X_IOPAD(0x0108, PIN_INPUT, 1) /* (AH25) PRG1_PRU0_GPO10.pr1_mii0_crs */
                AM65X_IOPAD(0x00f4, PIN_INPUT, 1) /* (AF27) PRG1_PRU0_GPO5.pr1_mii0_rxer */
                AM65X_IOPAD(0x00e4, PIN_INPUT, 1) /* (AG24) PRG1_PRU0_GPO1.pr1_mii0_rxd1 */
                AM65X_IOPAD(0x00e0, PIN_INPUT, 1) /* (AE22) PRG1_PRU0_GPO0.pr1_mii0_rxd0 */
                AM65X_IOPAD(0x0104, PIN_INPUT, 1) /* (AF26) PRG1_PRU0_GPO9.pr1_mii0_col */
                AM65X_IOPAD(0x0100, PIN_INPUT, 1) /* (AF28) PRG1_PRU0_GPO8.pr1_mii0_rxlink */
                AM65X_IOPAD(0x0120, PIN_INPUT, 1) /* (AD20) PRG1_PRU0_GPO16.pr1_mii_mt1_clk */
                AM65X_IOPAD(0x011c, PIN_OUTPUT, 0) /* (AD19) PRG1_PRU0_GPO15.pr1_mii1_txen */
                AM65X_IOPAD(0x0118, PIN_OUTPUT, 0) /* (AG20) PRG1_PRU0_GPO14.pr1_mii1_txd3 */
                AM65X_IOPAD(0x0114, PIN_OUTPUT, 0) /* (AH21) PRG1_PRU0_GPO13.pr1_mii1_txd2 */
                AM65X_IOPAD(0x0110, PIN_OUTPUT, 0) /* (AH20) PRG1_PRU0_GPO12.pr1_mii1_txd1 */
                AM65X_IOPAD(0x010c, PIN_OUTPUT, 0) /* (AF21) PRG1_PRU0_GPO11.pr1_mii1_txd0 */
                AM65X_IOPAD(0x0140, PIN_INPUT, 1) /* (AE21) PRG1_PRU1_GPO4.pr1_mii1_rxdv */
                AM65X_IOPAD(0x0148, PIN_INPUT, 1) /* (AG22) PRG1_PRU1_GPO6.pr1_mii_mr1_clk */
                AM65X_IOPAD(0x013c, PIN_INPUT, 1) /* (AH22) PRG1_PRU1_GPO3.pr1_mii1_rxd3 */
                AM65X_IOPAD(0x0138, PIN_INPUT, 1) /* (AG21) PRG1_PRU1_GPO2.pr1_mii1_rxd2 */
                AM65X_IOPAD(0x0158, PIN_INPUT, 1) /* (AF24) PRG1_PRU1_GPO10.pr1_mii1_crs */
                AM65X_IOPAD(0x0144, PIN_INPUT, 1) /* (AC22) PRG1_PRU1_GPO5.pr1_mii1_rxer */
                AM65X_IOPAD(0x0134, PIN_INPUT, 1) /* (AH23) PRG1_PRU1_GPO1.pr1_mii1_rxd1 */
                AM65X_IOPAD(0x0130, PIN_INPUT, 1) /* (AH24) PRG1_PRU1_GPO0.pr1_mii1_rxd0 */
                AM65X_IOPAD(0x0154, PIN_INPUT, 1) /* (AF25) PRG1_PRU1_GPO9.pr1_mii1_col */
                AM65X_IOPAD(0x0150, PIN_INPUT, 1) /* (AE24) PRG1_PRU1_GPO8.pr1_mii1_rxlink */
            >;
        };

    Is that complete for ICSSG1?

    And maybe you could also check whether my device tree config on Linux side for the ICSSG1 is correct?

    	/* Dual Ethernet application node on PRU-ICSSG1 */
    	pruss1_eth {
    		compatible = "ti,am654-icssg-prueth";
    		pinctrl-names = "default";
    		pinctrl-0 = <&pru_icssg1_mii_pins_default>;
    		sram = <&msmc_ram>;
    		interrupt-parent = <&main_udmass_inta>;
    
    		prus = <&pru1_0>, <&rtu1_0>, <&pru1_1>, <&rtu1_1>;
    		firmware-name = "ti-pruss/am65x-pru0-prueth-fw.elf",
    				"ti-pruss/am65x-rtu0-prueth-fw.elf",
    				"ti-pruss/am65x-pru1-prueth-fw.elf",
    				"ti-pruss/am65x-rtu1-prueth-fw.elf";
    		mii-g-rt = <&icssg1_mii_g_rt>;
    		mii-rt = <&icssg1_mii_rt>;
    		dma-coherent;
    		dmas = <&main_udmap &icssg1 0 UDMA_DIR_TX>, /* egress slice 0 */
    		       <&main_udmap &icssg1 1 UDMA_DIR_TX>, /* egress slice 0 */
    		       <&main_udmap &icssg1 2 UDMA_DIR_TX>, /* egress slice 0 */
    		       <&main_udmap &icssg1 3 UDMA_DIR_TX>, /* egress slice 0 */
    		       <&main_udmap &icssg1 4 UDMA_DIR_TX>, /* egress slice 1 */
    		       <&main_udmap &icssg1 5 UDMA_DIR_TX>, /* egress slice 1 */
    		       <&main_udmap &icssg1 6 UDMA_DIR_TX>, /* egress slice 1 */
    		       <&main_udmap &icssg1 7 UDMA_DIR_TX>, /* egress slice 1 */
    
    		       <&main_udmap &icssg1 0 UDMA_DIR_RX>, /* ingress slice 0 */
    		       <&main_udmap &icssg1 1 UDMA_DIR_RX>, /* ingress slice 1 */
    		       <&main_udmap &icssg1 2 UDMA_DIR_RX>, /* mgmnt rsp slice 0 */
    		       <&main_udmap &icssg1 3 UDMA_DIR_RX>; /* 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";
    
    		pruss1_emac0: ethernet-mii0 {
    			phy-handle = <&pruss1_eth1_phy>;
    			phy-mode = "mii";
    			max-speed = <100>;
    			syscon-rgmii-delay = <&scm_conf 0x4110>;
    			iep = <&icssg1_iep0>;
    			/* Filled in by bootloader */
    			local-mac-address = [00 00 00 00 00 00];
    		};
    
    		pruss1_emac1: ethernet-mii1 {
    			phy-handle = <&pruss1_eth2_phy>;
    			phy-mode = "mii";
    			max-speed = <100>;
    			syscon-rgmii-delay = <&scm_conf 0x4114>;
    			iep = <&icssg1_iep1>;
    			/* Filled in by bootloader */
    			local-mac-address = [00 00 00 00 00 00];
    		};
    	};
    

    2) I assume you refer to Table 6-334. PRU_ICSSG1 I/O Signals in the TRM? I assume I need to configure the MII_RT mode for all pins somewhere in the PRU firmware, but where/how?

    3) Phytec even prepared the "rotational rerouting"  via change of some resistors and confirmed our change is correct. So that should be fine. Do I still need a change in the firmware, and if so where/how exactly?

  • Jonatan,

    Thanks. These configurations look to be correct. I believe we need to confirm the internal PRU:MAC port mapping. I'll provide pointers in follow up.

    Best regards,

    Dave

  • Hi Dave,

    thanks. Could you give me a timeline for that pointers?

    Best regards,

    Jonatan

  • Hi Dave,

    any chance you could give the last missing pointer any time soon?

    Best regards,

    Jonatan

  • Hi Dave,

    is there also a direct support line, e.g. via telephone? Because time is short for our development project.

    Best regards

    Jonatan

  • Hi Sunita,

    thanks for your reply. I am building the firmware using the Makefile packages/ti/drv/emac/firmware/icss_dualmac/src/makefile. Is that correct?

    The Makefile builds the source files from icss_dualmac/bin. To follow your advice and build the files from icss_dualmac/bin_pg2 instead, how do the 6 files in there map to the 4 processors of the IGCSS? Could you provide me with a Makefile that generates the firmware with MII support or an according patch file?

    Do I need to replace the -DRGMII flags by -DMII?

    Do I need to uncomment // #define SUPPORT_MII in config/emac_fw_config_dual_mac.h?

    I am not sure what to learn from the unit test you linked to. Could you please explain?

    Thanks & Regards

    Jonatan

  • Hi,

    Sorry for the delay but icss_dualmac/bin_pg2 sources are not public at the moment, and support is not available. Limited testing has been done for 100M support through RGMII but not via MII. It may work with app and driver level changes only but I am not sure as this scenario hasn't been tested.

    Regarding mapping of the 6 binaries, please take a look at the TRM in the section Programmable Real-Time Unit and Industrial Communication Subsystem - Gigabit (SR2.0), it describes the 3 units RTU, RX_PRU and TX_PRU and the concept of two slices. They map exactly like that.

    Please reach out through your TI representative and we can discuss any support issues.

    Regards

    Vineet

  • Hi,

    so am I right that `bin_pg2` is for SR 2.0 and `src` is for SR 1.0?

    How am I supposed to build the binaries out of the binary headers in `bin_pg2`?

    Is the firmware in `bin_pg2` talking MII or RGMII?

    Regards,

    Jonatan

  • Yes, bin_pg2 is SR 2.0.

    You can use the binary headers as it is, the array needs to be copied to the instruction RAM of respective PRU's and RTU's of ICSSG. See the EMAC example application.

    The firmware in bin_pg2 is RGMII

    Regards

    Vineet

  • Will it be possible to talk MII on the SR 2.0 or 2.1 any time soon?

    Could you still give me the pointers for how to make it work on the SR 1.0 that Dave promised?

  • Hi,

    SR 1.0 is not actively being supported so it will be difficult to do it there. I will check on SR 2.0 and get back to you.

    Regards

    Vineet

  • Hi Jonathan,

    Can you enable the macro MII_SUPPORT in this file, try rebuilding and try ?

    There is experimental support for MII in the dual mac firmware

    Regards

    Vineet

  • Hi Vineet,

    do you refer to SR 1.0 or SR 2.0? How to build a firmware with that file? Is that file meant for a driver on A53 side or for the ICSSG firmware? Do I need driver or device tree changes on Linux side (A53) other than the ones already discussed in this forum thread?

    Regards

    Jonatan

  • Hi Jonatan,

    Sorry for the delay over holidays.

    I am referring to SR 2.0 Firmware. It doesn't have to be rebuilt, this change is for the RTOS driver.

    For Linux, you can refer to this guide and use the 7.1 SDK.

    If I see the ethtool output shown in the link above, I can see that MII is supported.

    root@am65xx-evm:~# ethtool eth1
    Settings for eth1:
            Supported ports: [ TP MII ]
            Supported link modes:   100baseT/Full
                                    1000baseT/Full
            Supported pause frame use: No
            Supports auto-negotiation: Yes
            Supported FEC modes: Not reported
            Advertised link modes:  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/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
            Port: MII
            PHYAD: 0
            Transceiver: internal
            Auto-negotiation: on
            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

    Regards

    Vineet

  • I am using a Linux build based on the one provided by Phytec. We use their kernel, but adjust the Device Tree. As I don't know how to build elf files out of the headers you linked above, I am using the PRU firmware from git.ti.com/.../commit

    I see the same output as you showed above.

    When configuring phy-mode = "mii", ethtool reports no sent nor received data. But when configuring phy-mode = "rgmii-rxid" ethtool reports received and sent data, even though the pinning is MII not RGMII:

    # ethtool -i eth1
    driver: icssg-prueth
    version: 
    firmware-version: 
    expansion-rom-version: 
    bus-info: pruss1_eth
    supports-statistics: yes
    supports-test: no
    supports-eeprom-access: no
    supports-register-dump: no
    supports-priv-flags: no
    # ethtool -S eth1
    NIC statistics:
         rx_good_frames: 106
         rx_broadcast_frames: 60
         rx_multicast_frames: 106
         rx_crc_error_frames: 0
         rx_mii_error_frames: 0
         rx_odd_nibble_frames: 0
         rx_frame_max_size: 2000
         rx_max_size_error_frames: 0
         rx_frame_min_size: 64
         rx_min_size_error_frames: 0
         rx_overrun_frames: 0
         rx_class0_hits: 106
         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: 0
         rx_class9_hits: 0
         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: 64
         rx_bucket2_size: 128
         rx_bucket3_size: 256
         rx_bucket4_size: 512
         rx_64B_frames: 56
         rx_bucket1_frames: 56
         rx_bucket2_frames: 4
         rx_bucket3_frames: 33
         rx_bucket4_frames: 13
         rx_bucket5_frames: 0
         rx_total_bytes: 14993
         rx_tx_total_bytes: 133432
         tx_good_frames: 1052
         tx_broadcast_frames: 889
         tx_multicast_frames: 929
         tx_odd_nibble_frames: 0
         tx_underflow_errors: 0
         tx_frame_max_size: 2000
         tx_max_size_error_frames: 0
         tx_frame_min_size: 64
         tx_min_size_error_frames: 0
         tx_bucket1_size: 64
         tx_bucket2_size: 128
         tx_bucket3_size: 256
         tx_bucket4_size: 512
         tx_64B_frames: 0
         tx_bucket1_frames: 0
         tx_bucket2_frames: 1052
         tx_bucket3_frames: 0
         tx_bucket4_frames: 0
         tx_bucket5_frames: 0
         tx_total_bytes: 77411

    Even in that case no package sent by the SoC ever reaches the connected device (trying to ping in both directions, capturing via Wireshark etc.).

  • This is our current Device Tree Node for the ICSSG1:

    	pruss1_eth: pruss1_eth {
    		compatible = "ti,am654-icssg-prueth";
    		pinctrl-names = "default";
    		pinctrl-0 = <&pru_icssg1_mii_pins_default>;
    		sram = <&msmc_ram>;
    		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>;
    		dma-coherent;
    		dmas = <&main_udmap 0xc200>, /* egress slice 0 */
    		       <&main_udmap 0xc201>, /* egress slice 0 */
    		       <&main_udmap 0xc202>, /* egress slice 0 */
    		       <&main_udmap 0xc203>, /* egress slice 0 */
    		       <&main_udmap 0xc204>, /* egress slice 1 */
    		       <&main_udmap 0xc205>, /* egress slice 1 */
    		       <&main_udmap 0xc206>, /* egress slice 1 */
    		       <&main_udmap 0xc207>, /* egress slice 1 */
    
    		       <&main_udmap 0x4200>, /* ingress slice 0 */
    		       <&main_udmap 0x4201>, /* ingress slice 1 */
    		       <&main_udmap 0x4202>, /* mgmnt rsp slice 0 */
    		       <&main_udmap 0x4203>; /* 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";
    
    		pruss1_emac0: ethernet-mii0 {
    			phy-handle = <&pruss1_eth1_phy>;
    			phy-mode = "mii";
    			interrupts-extended = <&icssg1_intc 24>;
    			syscon-rgmii-delay = <&scm_conf 0x4110>;
    			iep = <&icssg1_iep0>;
    			/* Filled in by bootloader */
    			local-mac-address = [00 00 00 00 00 00];
    		};
    
    		pruss1_emac1: ethernet-mii1 {
    			phy-handle = <&pruss1_eth2_phy>;
    			phy-mode = "mii";
    			interrupts-extended = <&icssg1_intc 25>;
    			syscon-rgmii-delay = <&scm_conf 0x4114>;
    			/* Filled in by bootloader */
    			local-mac-address = [00 00 00 00 00 00];
    		};
    	};
  • The following error message pops up after a while or directly when we advertise 100BaseT/Full on SoM side:

    # ethtool -s eth1 advertise 0x008
    [   37.327617] icssg-prueth pruss1_eth eth1: Link is Down
    # [   41.688162] icssg-prueth pruss1_eth eth1: Link is Up - 100Mbps/Full - flow control off
    [   62.039232] ------------[ cut here ]------------
    [   62.043866] NETDEV WATCHDOG: eth1 (icssg-prueth): transmit queue 0 timed out
    [   62.050984] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:447 dev_watchdog+0x2ec/0x300
    [   62.059232] Modules linked in: icssg_prueth icss_iep pru_rproc crct10dif_ce irq_pruss_intc ti_k3_r5_remoteproc pruss phy_omap_usb2 at24 sch_fq_codel ipv6
    [   62.072969] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.4.74 #1
    [   62.078874] Hardware name: PHYTEC phyCORE-AM65x Carrier Board (DT)
    [   62.085996] pstate: 20000005 (nzCv daif -PAN -UAO)
    [   62.090778] pc : dev_watchdog+0x2ec/0x300
    [   62.094779] lr : dev_watchdog+0x2ec/0x300
    [   62.098777] sp : ffff80001006fdb0
    [   62.102081] x29: ffff80001006fdb0 x28: ffff000054236440 
    [   62.107382] x27: 0000000000000004 x26: 0000000000000140 
    [   62.112683] x25: 00000000ffffffff x24: 0000000000000003 
    [   62.117983] x23: ffff00005808641c x22: ffff000058086000 
    [   62.123284] x21: ffff000058086440 x20: ffff800010ff1000 
    [   62.128585] x19: 0000000000000000 x18: 0000000000000010 
    [   62.133885] x17: 0000000000000000 x16: 0000000000000000 
    [   62.139186] x15: ffff00005e09bb28 x14: ffffffffffffffff 
    [   62.144486] x13: ffff80009006fb07 x12: ffff80001006fb10 
    [   62.149787] x11: ffff80001100a000 x10: ffff8000110c6b30 
    [   62.155087] x9 : ffff8000110c7000 x8 : 6575657571207469 
    [   62.160388] x7 : ffff8000105b5680 x6 : 0000000000000171 
    [   62.165688] x5 : 0000000000000000 x4 : 0000000000000008 
    [   62.170989] x3 : ffff800010a30dc8 x2 : 0000000000000100 
    [   62.176289] x1 : 85befb0a4e9f8d00 x0 : 0000000000000000 
    [   62.181590] Call trace:
    [   62.184033]  dev_watchdog+0x2ec/0x300
    [   62.187690]  call_timer_fn.isra.0+0x20/0x80
    [   62.191864]  run_timer_softirq+0x1a0/0x410
    [   62.195954]  __do_softirq+0x128/0x264
    [   62.199609]  irq_exit+0xb8/0xe0
    [   62.202746]  __handle_domain_irq+0x64/0xc0
    [   62.206833]  gic_handle_irq+0x5c/0x148
    [   62.210573]  el1_irq+0xb8/0x180
    [   62.213709]  arch_cpu_idle+0x10/0x20
    [   62.217279]  do_idle+0xc0/0x140
    [   62.220414]  cpu_startup_entry+0x20/0x70
    [   62.224330]  secondary_start_kernel+0x148/0x180
    [   62.228850] ---[ end trace 0975b6d90dba2b41 ]---
    [   62.233476] icssg-prueth pruss1_eth eth1: xmit timeout

    The last message repeats endlessly.

    But: The other device recognizes the change in speed.

  • Is there anything else needed to make your firmware work in MII mode?

  • As it becomes difficult to follow the rather long thread, a summary of the situation we have:

    Setup

    • TI AM6548 SR 2.0 on Phytec Evaluation Board
    • TI DP83867IR-PAP (2x) connected to ICSSG1 (pins connected according to TI PINMUXTOOL; PHY pin strapping for MII, 100Mbps, auto-negotiation)
    • Linux based on Phytec ALPHA4-SR2.0, which is based on TI Linux SDK 7.1
    • Pin Muxing for Linux Device Tree exported from TI PINMUXTOOL for PRU_ICSSG1_MII_G_RT (can be found in this thread)
    • For ICSSG Device Tree nodes scroll up 3 posts
    • PRU firmware as provided in binary format by TI (git://git.ti.com/processor-firmware/ti-linux-firmware.git, c911bcec682)

    Observation

    • MDIO works fine, we can readout PHY registers (see below).
    • Link and Auto-negotiation to 100BaseTX/full duplex works fine (can be observed with dmesg/ip).
    • Activity on MII RX lanes can be observed with oscilloscope.
    • NO Activity on MII TX lanes can be observed with oscilloscope.
    • Linux reports 0 received and 0 sent packages (ethtool).
    • A few seconds after getting a link dmesg reports "transmit queue 0 timed out" (for full message scroll up), followed by periodic "icssg-prueth pruss1_eth eth1: xmit timeout" and finally a kernel panic after another short while.
    • The driver in use ti/icssg_prueth.c contains various comments like "/* FIXME for SR2.0 */".

    Additional information

    PHY Registers:

    0x00    0x1140  BMCR
    0x01    0x796D  BMSR
    0x09    0x1000  CTRL1000
    0x0a    0x0800  STAT1000
    0x0f    0x3000  ESTATUS     
    0x13    0x1C00  Pending Interrupts (PAGE_RECEIVED_INT, AUTONEG_COMP_INT, LINK_STATUS_CHNG_INT)

  • MII requires 100 Mbps speed, but the TI ICSSG Ethernet Linux driver seems to be simply incomplete and refuse to change the speed on SR2.0, looking at its source code:

    static void emac_change_port_speed_duplex(struct prueth_emac *emac,
    					  bool full_duplex, int speed)
    {
    	// ...
    
    	/* FIXME for SR2.0 */
    	if (!emac->is_sr1)
    		return;
    
    	// ...
    }
    

    When will the driver be ready for use with SR2.0?

  • Hi Jonatan,

    Thank you for your incredible patience in summarizing such a long thread. I have checked internally and MII mode seems to be supported in the driver if you are on 7.1 SDK. The comments in the code is something that we will be looking at internally.

    Based on this description,

    >>NO Activity on MII TX lanes can be observed with oscilloscope

    it's possible that you are running into the issue of MII and Tx signal pinmuxing described in Section 7.2 of this AM65 IDK User Guide 

    Can you please check it and let us know ? (I am not aware if this document was already mentioned to you in the context of this thread)

    Regards

    Vineet

  • Hi Vineet,

    are you refering to the alternative pin muxing where the tx pin rotational shift between MII and RGMII should not be necessary anymore? We don't use that but connected the phy according to the MII pin muxing.

    I just realized that between RGMII and MII muxing, the tx signals (data and clock) are switched between both channels (RGMII2 -> MII0, RGMII1 -> MII1) while for rx they are not (RGMII2 -> MII1, RGMII1 -> MII0). That means one cannot have 1 MII and 1 RGMII channel on the same ICSSG. That also means that for switching between RGMII and MII it is not sufficient to change the muxing, but a different physical routing is required. Could you please confirm that? Is that intended? Will this also be the case for the finale release of the AM65x?

    Kind regards

    Jonatan

  • Hi Jonatan,

    Regarding RGMII and MII conflict, can you point me to which section of TRM or schematic you are looking at ?

    I will check back regarding alternative pin muxing and report.

    Regards

    Vineet

  • Hi Vineet,

    I am not aware of any PRU MII PinMuxing described in the TRM. The Data Sheet also does not explicitly describe them (only RGMII) as far as I can see. So my source of information is the TI PINMUXTool. To illustrate the problem:

    # ICSSG1
    
    RGMII1  RD0(PRG1_RGMII1_RD0)        AE22
    RGMII1  TD0(PRG1_RGMII1_TD0)        AH20
    RGMII1  TX_CTL(PRG1_RGMII1_TX_CTL)  AF21
    
    RGMII2  RD0(PRG1_RGMII2_RD0)        AH24
    RGMII2  TD0(PRG1_RGMII2_TD0)        AE20
    RGMII2  TX_CTL(PRG1_RGMII2_TX_CTL)  AC20
    
    MII0    ii0_rxd0(pr1_mii0_rxd0)     AE22        (same as RGMII1  RD0)
    MII0    ii0_txd0(pr1_mii0_txd0)     AE20/AC20   (same as RGMII2  TD0/TX_CTL)
    
    MII1    ii1_rxd0(pr1_mii1_rxd0)     AH24        (same as RGMII2  RD0)
    MII1    ii1_txd0(pr1_mii1_txd0)     AH20/AF21   (same as RGMII1  TD0/TX_CTL)
    

    Here you can clearly see that RGMII1 option uses the same RX lanes as  MII0 while it uses the same TX lanes as MII1. Same for RGMII2 and MII1/MII0. That means RGMII1 can neither be interchanged with MII0 nor MII1. Same for RGMII2. There also cannot be one MII and one RGMII next to each other on the same ICSSG. Be aware that is independent of the alternative pin muxing (which is also reflected in the table above).

    Regards

    Jonatan

  • Hi Jonatan,

    I got some background on the topic now.

    This (pin incompatibility between MII and RGMII) was a known limitation in SR 1.0, to overcome this an alternate pin-mux mode (tx pin rotational shift) was added in SR 2.0. So if you want to use both MII and RGMII at the same time you need to use the alternate pin-muxing.

    Please note that even with the alternate pin-muxing, this use-case is not supported on the AM65 SR 2.0 IDK because the TX CLK is different for MII and RGMII. This is however a PHY limitation for DP83867. With a PHY like DP83869 you can support it.

    You can see this implemented in the AM64 EVM schematics and User Guide.

    Regards

    Vineet

  • Hi Jonatan,

    I got another query offline which I am responding to here.

    It's regarding information on where to configure which PRU gets/sends from/to which port. Whether it's configurable in SW or not.

    This muxing for Rx and Tx is configurable in SW in the register RXCFG0/1 and TXCFG0/1 respectively for Port 1 and Port 2. You will find the same being configured in EMAC/ENET-LLD drivers

    Regards

    Vineet

  • Hi Vineet,

    we found the RXCFG and TXCFG registers and configured them according to our needs. The pin muxing should be fine now, too. Thanks for that advise. Unfortunately this did not yet solve our issue. What exactly do mean by your comment about the drivers? Does the icssgprueth Linux driver in SDK 7.01 configure this register? And how can I control it then?

    We are using the DP83867PAP. According to its datasheet it should be capable of handling MII. What exactly do you mean by the TX clock limitation?

    Is the MII RX Link pin configured by the PinMUXTOOL mandatory? Does it need to be high or low to indicate a link? If optional, how to deactivate it? Would removing it from the device tree be sufficient?

    Regards,

    Jonatan

  • Hi Vineet,

    I just found out that the icssgprueth driver from TI Linux SDK 7.01 sets MII_G_RT_ICSS_G_CFG.MII0_MODE and MII1_MODE to RGMII when phy mode is set to "mii" in the device tree. That seems to confirm our suspicion that the driver simply does not support MII mode, yet. What leads you to your conviction that SDK 7.01 was able to support MII? Is there any example project?

    Kind Regards

    Jonatan

  • Since we are following up on email, I am locking this thread. We can re-open if required.

    Regards

    Vineet