Phy not working with OSD3358-512M-ICB

This topic has 2 replies, 2 voices, and was last updated 1 year, 10 months ago by Ian King.

Viewing 2 reply threads

Author
Posts

December 5, 2022 at 6:00 pm #12964

Participant

Greetings,

I’m currently working on a custom board utilizing the OSD3358-512M-ICB SIP. We developed a custom Linux image using Buildroot in conjunction with a BeagleBone Black Industrial board and a carrier board developed earlier. I’m currently bringing up and testing various critical components of our prototype.

We’ve replaced the LAN8710A phy with a Marvell 88e1512 phy, the Marvell drivers have been added to the kernel and we’ve modified the device tree with following overlay values:

    fragment@1 {
        // target-path="/";
        target=&lt;&amp;cpsw_emac0&gt;;
        __overlay__ {
                phy-handle = &lt;&amp;ethphy0&gt;;
                phy-mode = "rgmii-id";
        };

    };

    fragment@2 {
        target=&lt;&amp;davinci_mdio&gt;;
        __overlay__ {

            pinctrl-names = "default", "sleep";
            pinctrl-0 = &lt;&amp;davinci_mdio_default&gt;;
            pinctrl-1 = &lt;&amp;davinci_mdio_sleep&gt;;
            status = "okay";
            #address-cells = &lt;1&gt;;
            #size-cells = &lt;0&gt;;
            ethphy0: ethernet-phy@0 {
                compatible = "marvell,88e1510";
                device_type = "ethernet-phy";           
                reg = &lt;0&gt;;
            };
        };
    };

fragment@1 {

// target-path="/";

target=<&cpsw_emac0>;

__overlay__ {

phy-handle = <&ethphy0>;

phy-mode = "rgmii-id";

};

fragment@2 {

target=<&davinci_mdio>;

__overlay__ {

pinctrl-names = "default", "sleep";

pinctrl-0 = <&davinci_mdio_default>;

pinctrl-1 = <&davinci_mdio_sleep>;

status = "okay";

#address-cells = <1>;

#size-cells = <0>;

ethphy0: ethernet-phy@0 {

compatible = "marvell,88e1510";

device_type = "ethernet-phy";

reg = <0>;

};

With these current values the phy seems to be detected, it can be assigned a static IP; however, the board is not on the network and ping won’t work in either direction (also the activity light is off).

In the boot log the following message appears about 10 seconds before the phy claims to be attached:

[    3.036157] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@4a000000/segment@0/target-module@100000/ethernet@0/mdio@1000/ethernet-phy@0[0]'

1	[ 3.036157] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/ocp/interconnect@4a000000/segment@0/target-module@100000/ethernet@0/mdio@1000/ethernet-phy@0[0]'

This is the boot log confirming the phy is working:

[   13.417571] cpsw 4a100000.ethernet: initializing cpsw version 1.12 (0)

[   13.518366] Marvell 88E1510 4a101000.mdio:00: attached PHY driver [Marvell 88E1510] (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)

[   13.640474] cpsw 4a100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off

[   13.700981] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

[ 13.417571] cpsw 4a100000.ethernet: initializing cpsw version 1.12 (0)

[ 13.518366] Marvell 88E1510 4a101000.mdio:00: attached PHY driver [Marvell 88E1510] (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)

[ 13.640474] cpsw 4a100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off

[ 13.700981] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Some googling around yielded this forum post on the TI website. While interesting reading, adding a ‘reset-gpios’ property to the ‘&davinci_mdio’ node results in the overlay failing to compile, which isn’t very helpful.

Any insight into what’s going on would be most appreciated.

Best regards,

Ian King

December 6, 2022 at 4:57 pm #12966
Neeraj Dantu
Moderator
Ian,
Few inputs regarding the issue:
1. Please check whether you need TX/RX delays in your MAC-PHY interface. This is set by phy-mode property in the device tree
2. Please check the pinmux settings of the RGMII interface you are using and whether all the pinmux needed is defined in your device tree.
3. Defining reset-gpios should not give you an error in your device tree overlay compilation. You may have to check your formatting
4. You can use the Ethernet Loop Back test we provided in the Ethernet Application Note(https://octavosystems.com/app_notes/ethernet-am335x-system-in-package/#_Toc382081438) to see if you can exercise the MAC-PHY interface
5. Please review how are you bringing the PHY out of reset during initialization, specifically how the reset of the PHY is being released. You should hold the PHY in reset for a little while after all the power sequencing is done for the PHY to initialize properly. Holding the PHY in reset a little bit using a jumper after power sequencing should allow you to see if there is a PHY reset timing issue.
6. You can scope the MAC-PHY interface signals to see activity and check timings of the signals.
Please let us know how it goes.
Best,
Neeraj
January 9, 2023 at 10:13 am #13128
Ian King
Participant
In the end this issue was being caused by bad device-tree overlay syntax. We ended up going to the original device tree and making the changes there.

Author
Posts

Viewing 2 reply threads

You must be logged in to reply to this topic.