• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 502 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.

AM6548: Multi phy with shared MDIO config

Eric Hsieh4
Expert 1310 points

Part Number: AM6548

Hi Ti,

 

We are working on our EVM with SDK 07.01.00.18.

We have 3 ethernet phy (83822 and 83867) with 2 MDIO interface, that means there are 2 ethernet phy shared with 1 MIDO. 

Below is our dts setting.

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


reset = <&main_gpio0 66 GPIO_ACTIVE_LOW>; /*83867*/
reset-delay-us = <2>;

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

/*83822*/
pruss1_eth1_phy: ethernet-phy@7 {
reg = <7>;
};
};

&icssg2_mdio {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&ethernet1_mdio_pins_default>;

reset = <&main_gpio0 16 GPIO_ACTIVE_LOW>;
reset-delay-us = <2>;

/*83867*/
pruss2_eth0_phy: ethernet-phy@2 {
reg = <2>;
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
};
};

gpio0_pins_default: gpio0_pins_default {
pinctrl-single,pins = <
AM65X_IOPAD(0x0040, PIN_OUTPUT, 7) /* (R28) GPMC0_CLK.GPIO0_16 */ /*ETH1-PHY-RESET*/
AM65X_IOPAD(0x0058, PIN_INPUT, 7) /* (R26) GPMC0_WAIT0.GPIO0_22 */
AM65X_IOPAD(0x0060, PIN_OUTPUT, 7) /* (T25) GPMC0_WPn.GPIO0_24 */
AM65X_IOPAD(0x0064, PIN_OUTPUT, 7) /* (T24) GPMC0_DIR.GPIO0_25 */
AM65X_IOPAD(0x0068, PIN_INPUT, 7) /* (R24) GPMC0_CSn0.GPIO0_26 */
AM65X_IOPAD(0x006c, PIN_OUTPUT, 7) /* (T23) GPMC0_CSn1.GPIO0_27 */ /* RUN-LED */
AM65X_IOPAD(0x0070, PIN_INPUT, 7) /* (R25) GPMC0_CSn2.GPIO0_28 */
AM65X_IOPAD(0x0074, PIN_INPUT, 7) /* (T27) GPMC0_CSn3.GPIO0_29 */
AM65X_IOPAD(0x00ac, PIN_INPUT, 7) /* (AH15) PRG2_PRU1_GPO0.GPIO0_43 */
AM65X_IOPAD(0x00b0, PIN_INPUT, 7) /* (AC16) PRG2_PRU1_GPO1.GPIO0_44 */
AM65X_IOPAD(0x00b4, PIN_INPUT, 7) /* (AD17) PRG2_PRU1_GPO2.GPIO0_45 */
AM65X_IOPAD(0x00b8, PIN_INPUT, 7) /* (AH14) PRG2_PRU1_GPO3.GPIO0_46 */
AM65X_IOPAD(0x0108, PIN_OUTPUT, 7) /* (AH25) PRG1_PRU0_GPO10.GPIO0_66 */ /*ETH0-PHY-RESET*/
AM65X_IOPAD(0x0124, PIN_OUTPUT, 7) /* (AH26) PRG1_PRU0_GPO17.GPIO0_73 */ /*ECAT2-PHY-RST*/
>;
};

Our questions are:

1.For 83822, if we need to add phy resey pin in dts file as "reset = <&main_gpio0 73 GPIO_ACTIVE_LOW>;" ?  Or how does 83822 reset pin work?

2.For 83867, we offer the reset pin by VDDSHV4, it should be 3.3V, but we only see 1.6V~1.7V. If the config has any problem or how can we do further debugging?

Thanks.

Eric

  • 0
    TI__Mastermind 37435 points

    Hi Eric,

    Sorry for the delay. Were you able to resolve your issue ? 

    Eric Hsieh4 said:
    1.For 83822, if we need to add phy resey pin in dts file as "reset = <&main_gpio0 73 GPIO_ACTIVE_LOW>;" ?  Or how does 83822 reset pin work?

    Yes, this should work. The datasheet mentions that the reset pin is active low

    Eric Hsieh4 said:
    2.For 83867, we offer the reset pin by VDDSHV4, it should be 3.3V, but we only see 1.6V~1.7V. If the config has any problem or how can we do further debugging?

    Have you checked the AM65 IDK schematics, dts and User guide ? It uses a DP83867 PHY. I see that reset pin is connected to 1.8V

    Regards

    Vineet

  • 0 in reply to Vineet Roy
    Expert 1310 points

     Hi

    For question 1, not fixed yet.

    According to your response, I modified the settings below. There are two "reset" pin existed.

    I wonder if it works for both 83867 and 83822 driver.

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

    reset = <&main_gpio0 66 GPIO_ACTIVE_LOW>; /*83867*/
    reset = <&main_gpio0 73 GPIO_ACTIVE_LOW>; /*83822*/
    reset-delay-us = <2>;

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

    /*83822*/
    pruss1_eth1_phy: ethernet-phy@7 {
    reg = <7>;
    };
    };

    Eric

  • 0 in reply to Eric Hsieh4
    TI__Mastermind 37435 points

    Hi Eric,

    Eric Hsieh4 said:

    For question 1, not fixed yet.

    According to your response, I modified the settings below. There are two "reset" pin existed.

    I wonder if it works for both 83867 and 83822 driver.

    Can you verify your pinmux configuration manually and double-check the connections ? If possible probe the reset pin on the board to make sure it goes active low.

    Regards

    Vineet

  • 0 in reply to Vineet Roy
    Expert 1310 points

    Hi

    With my dts setting, sometimes there will exception happened.

    Do you have any idea about this?

    root@AX-564EB0MB1T:~# [ 256.997709] 000: ------------[ cut here ]------------
    [ 256.997723] 000: WARNING: CPU: 0 PID: 83 at drivers/net/phy/phy.c:716 phy_error+0x10/0x58
    [ 256.997750] 000: Modules linked in: xhci_plat_hcd xhci_hcd rpmsg_client_sample rpmsg_char usbcore virtio_rpmsg_bus dwc3 udc_core usb_common ti_am335x_adc kfifo_buf icssg_prueth icss_iep crct10dif_ce pru_rproc irq_pruss_intc ti_k3_r5_remoteproc m_can_platform m_can can_dev pruss ti_am335x_tscadc dwc3_keystone phy_omap_usb2 at24 sch_fq_codel ipv6
    [ 256.997811] 000: CPU: 0 PID: 83 Comm: kworker/u8:1 Not tainted 5.4.74-rt42-yocto-preempt-rt #1
    [ 256.997816] 000: Hardware name: Texas Instruments AM654 Base Board (DT)
    [ 256.997828] 000: Workqueue: events_power_efficient phy_state_machine
    [ 256.997831] 000: pstate: 60000005 (nZCv daif -PAN -UAO)
    [ 256.997835] 000: pc : phy_error+0x10/0x58
    [ 256.997840] 000: lr : phy_state_machine+0x88/0x168
    [ 256.997844] 000: sp : ffff8000111fbd60
    [ 256.997847] 000: x29: ffff8000111fbd60 x28: ffff800010d29000
    [ 256.997852] 000: x27: ffff00003cc0c070 x26: ffff00003cc0c020
    [ 256.997857] 000: x25: 0000000000000000 x24: ffff000038301c38
    [ 256.997861] 000: x23: 00000000fffffffb x22: ffff000038301800
    [ 256.997866] 000: x21: 0000000000000005 x20: ffff000038301c88
    [ 256.997871] 000: x19: ffff000038301800 x18: 0000000000000007
    [ 256.997875] 000: x17: 000000000000000e x16: 0000000000000001
    [ 256.997880] 000: x15: 0000000000000019 x14: 0000000000000033
    [ 256.997884] 000: x13: 0000000000000000 x12: 0000000000000001
    [ 256.997889] 000: x11: 0000000000000000 x10: 0000000000000a80
    [ 256.997893] 000: x9 : ffff8000111fbae0 x8 : ffff00003c0c54a0
    [ 256.997898] 000: x7 : ffff00003e594d80 x6 : 0000000c2d538c79
    [ 256.997902] 000: x5 : ffff000038301ca0 x4 : 0000000000000000
    [ 256.997907] 000: x3 : ffff000038301c88 x2 : 0000000000000000
    [ 256.997911] 000: x1 : 19b74b18efb1c300 x0 : ffff000038301800
    [ 256.997915] 000: Call trace:
    [ 256.997918] 000: phy_error+0x10/0x58
    [ 256.997923] 000: phy_state_machine+0x88/0x168
    [ 256.997927] 000: process_one_work+0x1a4/0x328
    [ 256.997935] 000: worker_thread+0x48/0x418
    [ 256.997939] 000: kthread+0x10c/0x140
    [ 256.997944] 000: ret_from_fork+0x10/0x1c
    [ 256.997950] 000: ---[ end trace 0000000000000002 ]---

    And 2nd question, 

    "probe the reset pin on the board to make sure it goes active low",

    Do you mean we just need to pull up the gpio when board bring up?

    Thanks.

    Eric