S32g274 BSP35.0 PFEMAC2 connects directly to the MAC of another SOC

[sdx111]

I am using the BSP35.0 software of S32G274, and now my own board has made the RGMII of PFEMAC2 directly connected to the MAC of another SOC, so how can I modify the PFEMAC2 driver in BSP35.0 to achieve communication with the MAC of another SOC?  For example, how to directly modify the Settings of speed and full duplex? 

[alejandro_e]

Hello @sdx111,

We do not have complete support for the functionality you are mentioning, however, I will try my best to help you. To have better understanding of your setup, can you share the following details:

• schematics of your board, at least the part that related to the RGMII interconnection between the two SoCs
• Changes in the device tree to use RGMII as the selected interface.

If you are not comfortable sharing the details of your project you can always open a support ticket to have a private communication channel in https://www.nxp.com/ :

Best regards,

Alejandro

[sdx111]

Which part of which file should be modified in a specific device tree?  Includes rate and RGMII and full duplex. 

[alejandro_e]

Hello @sdx111, 

Comparing with the schematics of the S32G-VNP-RDB2 I see that you are using the PFE_MAC2 pins in the opposite way, this is the RX pins as TX pins and vice versa, althought this configuration may work, I cannot assure it. [sheet 14, SPF-47440_E.pdf, S32G-VNP-RDB2-DESIGN-FILES]

About the device tree, this is an example of how to configure PFE_MAC1 as RGMII, you can use this as base to configure PFE_MAC2 (works with BSP38 and older):

In u-boot:

setenv hwconfig "pcie0:mode=pcie,clock=ext;pcie1:mode=sgmii,clock=ext,fmhz=125,xpcs_mode=2G5"
setenv pfeng_mode 'enable,sgmii,rgmii,rgmii'
setenv s32cc_gmac_mode disable
saveenv

in Linux arch/arm64/boot/dts/freescale/s32g274a-rdb2.dtsi:

//// Comment out original nodes &gmac0_mdio and &pfe_netif1 ////
// &gmac0_mdio {
//     /* AQR107 */
//     gmac_mdio_a_phy3: ethernet-phy@3 {
//         compatible = "ethernet-phy-ieee802.3-c45";
//         #address-cells = <1>;
//         #size-cells = <0>;
//         /*
//          * Warning: from board rev D it is subject
//          * for eth fixup: addr changed to 0x8
//          */
//         reg = <3>;
//     };
// };

// &pfe_netif1 {
//     phy-mode = "sgmii";
//     phy-handle = <&gmac_mdio_a_phy3>;
// };


//// Add these new nodes ////
&gmac0 {
    status = "disabled";
};

&gmac0_mdio {
    status = "disabled";
};

&pfe_mdio1 {
    status = "okay";
    /* KSZ9031 GMAC */
    pfe_mdio_a_phy1: ethernet-phy@1 {
        reg = <1>;
    };
};

&pfe {
    status = "okay";
    pinctrl-names = "default";
    pinctrl-0 = <&pfe2mdiob_pins>,
            <&pfe2rgmiib_pins>, <&pfe1mdioa_pins>, <&pfe1rgmiia_pins>;
};

&pfe_netif1 {
    status = "okay";
    phy-handle = <&pfe_mdio_a_phy1>;
    phy-mode = "rgmii-id";
};

&pinctrl {
    pfe1mdioa_pins: pfe1mdioa {
        pfe1mdioa_grp0 {
            pinmux = <S32CC_PINMUX(60, FUNC2)>;
            output-enable;
            slew-rate = <S32CC_SLEW_208MHZ>;
        };

        pfe1mdioa_grp1 {
            pinmux = <S32CC_PINMUX(61, FUNC2)>;
            output-enable;
            input-enable;
            slew-rate = <S32CC_SLEW_208MHZ>;
        };

        pfe1mdioa_grp2 {
            pinmux = <S32CC_PINMUX(857, FUNC2)>;
        };

    };

    pfe1rgmiia_pins: pfe1rgmiia {
        pfe1rgmiia_grp0 {
            pinmux = <S32CC_PINMUX(66, FUNC2)>;
            output-enable;
            slew-rate = <S32CC_SLEW_208MHZ>;
            bias-pull-up;
        };

        pfe1rgmiia_grp1 {
            pinmux = <S32CC_PINMUX(866, FUNC2)>,
                 <S32CC_PINMUX(859, FUNC2)>,
                 <S32CC_PINMUX(865, FUNC2)>,
                 <S32CC_PINMUX(861, FUNC2)>,
                 <S32CC_PINMUX(862, FUNC2)>,
                 <S32CC_PINMUX(863, FUNC2)>,
                 <S32CC_PINMUX(864, FUNC2)>;
        };

        pfe1rgmiia_grp2 {
            pinmux = <S32CC_PINMUX(67, FUNC2)>,
                 <S32CC_PINMUX(68, FUNC2)>,
                 <S32CC_PINMUX(69, FUNC2)>,
                 <S32CC_PINMUX(70, FUNC2)>,
                 <S32CC_PINMUX(71, FUNC3)>;
            output-enable;
            slew-rate = <S32CC_SLEW_208MHZ>;
        };

        pfe1rgmiia_grp3 {
            pinmux = <S32CC_PINMUX(72, FUNC0)>,
                 <S32CC_PINMUX(73, FUNC0)>,
                 <S32CC_PINMUX(74, FUNC0)>,
                 <S32CC_PINMUX(75, FUNC0)>,
                 <S32CC_PINMUX(76, FUNC0)>,
                 <S32CC_PINMUX(77, FUNC0)>;
            input-enable;
            slew-rate = <S32CC_SLEW_208MHZ>;
        };

    };
};

You can recompile the device tree with:

make -j ARCH=arm64 CROSS_COMPILE=<path-to-your-cross-compiler> dtbs

Let me know the result of the changes.

Best regards, 

Alejandro

[sdx111]

Now I have no PHY connection, so can the PHY connection in the figure be removed?  So I want to know how the gigabit / 100 gigabit / 10 gigabit rate or full duplex mode can be changed directly? 

[alejandro_e]

Hello @sdx111,

To the best of my understanding RGMII should be full duplex by default, given that the S32G2 has RX and TX pins: 

About the PHY nodes, although the name and comments can be a little confusing you need them to achieve RGMII communication.

About the data rate, to the best of my understanding the data rate should set once a network is detected, I can raise this questions with the internal team but their answer could take some time since an important part of the team is taking holidays. I would recommend traying the changes I shared and sharing your result with me. 

It is important to note that I can help you with RGMII configuration but I would not be able to help much with the communication between the two SOCs, I have not seeing this use case in the past and it does not seem to be the intended use of the protocol, with that said, may I ask why did you decided to implement your design in this way? What problem exactly were you traying to solve by communicating two SOCs via RGMII? There are other protocols that have a better fit for this kind of implementations, QSPI for example.

Thanks for the information and let me know if you want me to raise the topic with the internal team.