• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 931 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM3352: Issue with RGMII2

Michael Amoruso
Intellectual 275 points
Part Number: AM3352


Hello,

We currently have an issue communicating over the RGMII2 interface. We are not using the RGMII1 interface as those pins are needed for other functionality. Is there some kind of configuration we need to have in this case. It seems that the processor does not respond well with RGMII2 when RGMII1 is not being used.

Thanks,

Mike

  • 0
    TI__Mastermind 27890 points
    Hi Michael,
    What have you done as far as PinMux and SW configurations?
  • 0 in reply to -DK-
    Prodigy 90 points

    We tried several things.  Here is our current DTS:

    &cpsw_default {
        pinctrl-single,pins = <
                /* Slave 2 */
                0x40 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)  /* gpmc_a0.rgmii2_tctl */
                0x44 (PIN_INPUT_PULLDOWN | MUX_MODE2)   /* gpmc_a1.rgmii2_rctl */
                0x48 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)  /* gpmc_a2.rgmii2_td3 */
                0x4c (PIN_OUTPUT_PULLDOWN | MUX_MODE2)  /* gpmc_a3.rgmii2_td2 */
                0x50 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)  /* gpmc_a4.rgmii2_td1 */
                0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)  /* gpmc_a5.rgmii2_td0 */
                0x58 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)  /* gpmc_a6.rgmii2_tclk */
                0x5c (PIN_INPUT_PULLDOWN | MUX_MODE2)   /* gpmc_a7.rgmii2_rclk */
                0x60 (PIN_INPUT_PULLDOWN | MUX_MODE2)   /* gpmc_a8.rgmii2_rd3 */
                0x64 (PIN_INPUT_PULLDOWN | MUX_MODE2)   /* gpmc_a9.rgmii2_rd2 */
                0x68 (PIN_INPUT_PULLDOWN | MUX_MODE2)   /* gpmc_a10.rgmii2_rd1 */
                0x6c (PIN_INPUT_PULLDOWN | MUX_MODE2)   /* gpmc_a11.rgmii2_rd0 */
        >;
};

&cpsw_sleep {
        pinctrl-single,pins = <
                /* Slave 2 reset value */
                0x40 (PIN_INPUT_PULLDOWN | MUX_MODE7)
                0x44 (PIN_INPUT_PULLDOWN | MUX_MODE7)
                0x48 (PIN_INPUT_PULLDOWN | MUX_MODE7)
                0x4c (PIN_INPUT_PULLDOWN | MUX_MODE7)
                0x50 (PIN_INPUT_PULLDOWN | MUX_MODE7)
                0x54 (PIN_INPUT_PULLDOWN | MUX_MODE7)
                0x58 (PIN_INPUT_PULLDOWN | MUX_MODE7)
                0x5c (PIN_INPUT_PULLDOWN | MUX_MODE7)
                0x60 (PIN_INPUT_PULLDOWN | MUX_MODE7)
                0x64 (PIN_INPUT_PULLDOWN | MUX_MODE7)
                0x68 (PIN_INPUT_PULLDOWN | MUX_MODE7)
                0x6c (PIN_INPUT_PULLDOWN | MUX_MODE7)
        >;
};

&cpsw_emac0 {
        status = "disabled";
};

&cpsw_emac1 {
        phy_id = <&davinci_mdio>, <1>;
        phy-mode = "rgmii-rxid";
};

    We are getting communications from the PHY, which is telling us that the Link is Up.  But the data between the MAC and the PHY are not being transferred. 

    Thanks,
    Vlad





  • 0 in reply to -DK-
    Prodigy 90 points
    I also tried keeping the pinmux for both Slaves, and setting the MAC to dual_emac = <1>; but the kernel was just crashing when I tried booting. Without dual_emac the kernel does come up, it configures eth0, but the data don't seem to go through.

    NB: we used to have the PHY connected to RGMII1, but moved to RGMII2 in the latest revision of the board.
  • 0 in reply to -DK-
    Intellectual 275 points
    Vlad will respond with the PinMux and SW configurations.