s32g2 serdes 0 mode 3 speed not supported

[gse31]

Hello,

Custom board with S32g2.

Serdes0 used in mode 3 (pfe2-sgmii + gmac-sgmii).

100M ext clock used.

hwconfig=serdes0:mode=xpcs0&xpcs1,clock=ext,fmhz=100;xpcs0_0:speed=1G;xpcs0_1:speed=1G;serdes1:mode=pcie,clock=ext,fmhz=100;pcie1:mode=rc

When configuring interface pfe2 or gmac, same error:

[ 25.972286] pfeng 46000000.pfe pfe2: Speed not supported
[ 234.370319] phy-s32gen1-serdes 40480000.serdes: Speed not supported

phy are detected on the mdio bus.

ping is not working on both interfaces.

Others errors:

[ 1.376469] phy-s32gen1-serdes 40480000.serdes: Unstable RX detected on XPCS1
[ 1.377747] phy-s32gen1-serdes 40480000.serdes: Unstable RX detected on XPCS0

Do you have an idea where the problem is ? DTS issue ?

Thanks for your help.

[gse31]

Hi Daniel,

Thanks for your reply.

BSP 36 is used.

pfeng_mode was set to "disable,rgmii,rgmii,none".

Changed to "enable,rgmii,rgmii,sgmii".

Same result.

Peer device is active: phy is detected on MDIO bus:

[ 863.207256] pfeng 46000000.pfe pfe2: PHY [PFEng Ethernet MDIO.2:01] driver [TI DP83869] (irq=POLL)
[ 863.207291] pfeng 46000000.pfe pfe2: configuring for phy/sgmii link mode
[ 863.207366] phy-s32gen1-serdes 40480000.serdes: speed=-1
[ 863.207375] phy-s32gen1-serdes 40480000.serdes: Speed not supported
[ 863.207442] pfeng 46000000.pfe pfe2: Speed not supported

[Daniel-Aguirre]

Hi,

Thanks for the information. Let us investigate what could be the cause of this behavior. If we require any more information we will let you know.

We apologize if we are delayed on our response.

Please, let us know.

[gse31]

Hi Daniel,

We have issues with auto-negotiation with our phy and it is linking up after a long time.

So the 1st message when setting the interface (pfe2 or eth0) is "speed not supported".

When the phy is linking up, this error disappear and the pfe/gemac indicate the negotiated speed.

Now we don't have ping working on both interfaces but this is another issue.

[Daniel-Aguirre]

Hi,

Thanks for your feedback. This can be related to the PHY itself then. Can you confirm that the PHY is available and ready to be used once the command is input? We suppose that it does, but we would like confirmation.

Also, the following information could be of use:

"I tried to test after changing phy-handle as fixed-link as below.

Than, it works.

In linux side, it also same way to change gmac0 in device tree.

"

Please, let us know.

[gse31]

Hi Daniel,

If "ifconfig" is executed after the phy link-up, we have the same error (speed not supported). In this case the linux phy driver re-configure the phy, the link is down, and when the link comes up, no more error, speed=10.

I tried fixed link, here is our device tree:

&gmac0 {
    status = "okay";
    phy-handle = <&pfe_mdio_2_phy0>;
    phy-mode = "sgmii";
};

&pfe {
    status = "okay";
    pinctrl-names = "default";
    pinctrl-0 = <&pfe0mdioeth2_pins>,
       <&pfe0rgmiieth2_pins>,
       <&pfe1mdioeth1_pins>,
       <&pfe1rgmiieth1_pins>,
       <&pfe2mdioeth0_pins>;
};

&pfe_mdio0 {
    pfe_mdio_0_phy0: ethernet-phy@0 {
       reg = <0>;
       phy-mode = "rgmii-id";
       ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
       ti,clk-output-sel = <DP83869_CLK_O_SEL_CHN_D_TCLK>;
    };
};

&pfe_mdio1 {
    pfe_mdio_1_phy0: ethernet-phy@0 {
       reg = <0>;
       phy-mode = "rgmii-id";
       ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
       ti,clk-output-sel = <DP83869_CLK_O_SEL_CHN_D_TCLK>;
    };
};

&pfe_mdio2 {
   pfe_mdio_2_phy0: fixed-link@0 {
       reg = <0>;
       speed = <1000>;
       full-duplex;
       ti,op-mode = <DP83869_SGMII_COPPER_ETHERNET>;
       phy-mode = "sgmii";
    };

    pfe_mdio_2_phy1: ethernet-phy@1 {
       reg = <1>;
       ti,op-mode = <DP83869_SGMII_COPPER_ETHERNET>;
       phy-mode = "sgmii";
    };
};

&pfe_netif0 {
    phy-mode = "rgmii-id";
    phy-handle = <&pfe_mdio_0_phy0>;
};

&pfe_netif1 {
    phy-mode = "rgmii-id";
    phy-handle = <&pfe_mdio_1_phy0>;
};

&pfe_netif2 {
    phy-mode = "sgmii";
    phy-handle = <&pfe_mdio_2_phy1>;
};

We have the same result, ping is not working:

- link is up at 10mbps (even if fixed-link in dts)

- ping from PC:
rx/tx activity PHY LED blink
tcpdump on s32 does not see packets / arp requests

- ping from s32:
rx/tx activity PHY LED off
tcpdump on PC does not see packets / arp requests

It seems to be an issue on sgmii / serdes configuration (serdes 0 mode 3).

We have a mass storage connected on serdes 1 in pci mode, and we have issues with it: PCI enumeration from uboot fails, PCI phy link never came up. The same mass storage has been connected to m.2 port of nxp rdb2 board and it works.

Could you confirm hwconfig env var is the only interface to be used for s32 serdes configuration?

Please note that the 2 sgmii-phy are connected to the same mdio bus. Pins are PF_00/01 configured as pfe2 mdio functions, no problem for gmac0 to have the phy connected to pfe mdio bus ?

[Daniel-Aguirre]

Hi,

Thanks for your feedback. We have received the following update:

"Firstly the config in uboot should be OK. secondly some additional changes in DTS is also needed.

1. arch/arm64/boot/dts/freescale/s32gxxxa-rdb.dtsi 

change &gmac0 and &pfe_netif2's content with the following lines. 

    phy-mode = "sgmii";

    fixed-link {

        speed = <1000>;

        full-duplex;

    };

2. arch/arm64/boot/dts/freescale/s32cc.dtsi

change gmac0's phys definition to the serdes_0 lane0

phys = <&serdes0 PHY_TYPE_XPCS 0 0>;

3. arch/arm64/boot/dts/freescale/s32g-pfe.dtsi

change phys for emac2 to serdes_0 lane1

<&serdes0 PHY_TYPE_XPCS 0 1>;"

Please, let us know.

[gse31 · Accepted solution]

Hi,
For the dtsi / pfe node:
3. arch/arm64/boot/dts/freescale/s32g-pfe.dtsi
change phys for emac2 to serdes_0 lane1
<&serdes0 PHY_TYPE_XPCS 0 1>;"

We modified this to have the correct xpcs routing :
<&serdes0 PHY_TYPE_XPCS 1 0>;"

And for the sgmii autoneg :
- Under uboot, we used xpcs an enable command
- Under linux, it worked by forcing sgmii autoneg in the s32 xpcs driver OR by using the "managed" property for the phys in the dtsi:
managed = "in-band-status";
Now both sgmii phys work on s32 serdes0 in mode 3.
Thanks for you help!

[gse31]

Hi Daniel,

Thanks for your reply.

Adding the fixed-link inside &gmac0 and &pfe2 and the trace from pfe or s32cc-dwmac indicate the 1Gbps link-up as soon as the ifconfig is done to put the interface on, whatever the phy status, linked-up or not.

In my case the phy link-up LED is off and the linux says link-up.

Removing the ethernet cable and linux does not see the link is down.

Removing these lines (fixed-link) and linux indicates link is up only when the phy is linking up.

phys = <&serdes0 PHY_TYPE_XPCS 0 0>; => was already in my DTS

<&serdes0 PHY_TYPE_XPCS 0 1>;" for pfe2 => changed this line but no effect.

[Daniel-Aguirre]

Hi,

It seems we need information of both your board and your device tree. Can you help us opening a case under the NXP online services for you to have a private channel to share this information with us?

The following is required:

"can we get their schematic and files in device tree folder arch/arm64/boot/dts/freescale/?"

Please, let us know.

[gse31]

Hi Daniel,

I did not open a case since we scoped the signals on serdes 0 / sgmii and for us nothing wrong here. So we have "communication" between mac and phy.

Our ethernet interface does not work but it seems to be related to the phy, not to the mac/s32.

I will let you know.

[gse31]

Hi Daniel,

We had an hardware issue with the phy (TI DP83869) on our custom board, connected at 10Mbits/s only. Now the phy is connected at 1000Mbits/s. On our board, 4 phy DP83869:

- 2 in RGMII mode connected to S32 pfe0 and pfe1: communication OK, bandwidth up to 940Mbits/s

- 2 in SGMII mode connected to serdes0 in mode 3 (pfe2/gmac0): DP83869 is now negocitated at 1Gbits/s so we hoped it could fixed our SGMII issue, but no communication (tcpdump on S32 and PC does not show any packet from both sides).

 We are trying to connect our custom S32 SOM board directly (serdes) to a TI eval board with DP83869 in SGMII mode. We need to use the serdes internal clock (internal PLL reference clock source) instead of the externel clock (on board oscillator).

How to do this?

I tried with uboot hwconfig env var:

hwconfig=serdes0:mode=xpcs0&xpcs1,clock=ref,fmhz=100;xpcs0_0:speed=1G;xpcs0_1:speed=1G;serdes1:mode=pcie,clock=ref,fmhz=100;pcie1:mode=rc

But it seems the external oscillator is always used since the PCIe on serdes1 has the link status to 8GT/S gen3, SSD PCI working in gen3 (whereas it should not work according to the NXP S32G design guide PCIe recommandation: an external clock is required to meet the gen3 jitter requirements. It should only worked in gen2 with the internal clock ?).

Another question: the phy DP83869 registers shows the SGMII autonegociation never complete. Is there something to do in the device tree to enable SGMII autoneg on the S32 or is it done by default (S32G2 and S32R SerDes Subsystem Reference Manual , Rev. 5, 7 Dec 2021 => §5.5.2)

Thanks for your help.

[gse31]

Hi Daniel,

We had an hardware issue on PCI (serdes clock signal path) and it explains why the PCI never came up. Now we have the PCI working, mass storage is detected. serdes 1 configuration is OK.

We always have issue on serdes 0 / sgmii. I will open a case next week.

Thanks for your help.

[gse31]

The issue we have is not 1Gbps for now.

There is no sgmii communication betweem mac and phy.

We have the same phy connected to rgmii and it works through pfe0/pfe1.

It seems serdes 0 is not configured properly.

And serdes 1 too since we don't have pci working.

[Daniel-Aguirre]

Hi,

Can you let us know which BSP are you working with? How are you configuring the "pfeng_mode" variable?

On regards of the "Speed not supported", the following is told:

"This log should be caused there is no active peer device.

Check if peer device is active."

As for the "Unstable RX" message, this is shown even under the NXP platforms with NXP pre-built images, which should not cause problems. 

Please, let us know.