BeagleBone Black Ethernet PHY issues

BeagleBone Black Ethernet PHY issues

[Geert Uytterhoeven]

Hi all,

During the last few months, booting kernels on BeagleBone Black
sometimes fails with:

    +SMSC LAN8710/LAN8720 4a101000.mdio:00: probe with driver SMSC
LAN8710/LAN8720 failed with error -5
     davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00,
driver SMSC LAN8710/LAN8720
     soc_device_match(cpsw_soc_devices): no match
     cpsw-switch 4a100000.switch: initialized cpsw ale version 1.4
     ...
     am335x-phy-driver 47401300.usb-phy: dummy supplies not allowed
for exclusive requests (id=vbus)
    +cpsw-125mhz-clkctrl:0014:0: failed to disable
     am335x-phy-driver 47401b00.usb-phy: using DT
'/ocp/target-module@47400000/usb-phy@1b00' for 'reset' GPIO lookup
     ...
     cpsw-switch 4a100000.switch: starting ndev. mode: dual_mac
    -SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver
(mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
    -cpsw-switch 4a100000.switch eth0: Link is Up - 100Mbps/Full -
flow control off
    -Sending DHCP requests ., OK
    -IP-Config: Complete:
    -[...]
    +cpsw-switch 4a100000.switch: phy
"/ocp/interconnect@4a000000/segment@0/target-module@100000/switch@0/mdio@1000/ethernet-phy@0"
not found on slave 0
    +[HANG]

Adding debug prints to smsc_phy_probe() makes the issue go away, so it
must be timing related.

Adding specific debug prints in the failure case gives:

    SMSC LAN8710/LAN8720 4a101000.mdio:00: genphy_read_abilities:2859:
phy_read(MII_BMSR) failed -EIO
    SMSC LAN8710/LAN8720 4a101000.mdio:00: phy_probe:3613:
genphy_read_abilities() failed -EIO
    SMSC LAN8710/LAN8720 4a101000.mdio:00: probe with driver SMSC
LAN8710/LAN8720 failed with error -5

and later:

    Generic PHY 4a101000.mdio:00: genphy_read_abilities:2859:
phy_read(MII_BMSR) failed -EIO
    Generic PHY 4a101000.mdio:00: phy_probe:3609:
genphy_read_abilities failed -EIO
    cpsw-switch 4a100000.switch: phy
"/ocp/interconnect@4a000000/segment@0/target-module@100000/switch@0/mdio@1000/ethernet-phy@0"
not found on slave 0

Adding debug prints to __mdiobus_read() and davinci_mdio_read() gives:

    mdio_bus 4a101000.mdio: davinci_mdio_read:444:
readl(&data->regs->user[0].access) = 0x3a0ffff
    mdio_bus 4a101000.mdio: __mdiobus_read:900: davinci_mdio_read failed -EIO

but this is a different (and unimportant?) early failure from
smsc_phy_config_intr(), and that debug print actually makes the issue go
away, too.

Ignoring the early failure reveals that phy_read(MII_BMSR) failed due
to:

    mdio_bus 4a101000.mdio: davinci_mdio_read:446:
readl(&data->regs->user[0].access) = 0x20ffff

Anyone with a clue?
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: BeagleBone Black Ethernet PHY issues

[Roger Quadros]

Hi Geert,

On 29/10/2024 19:18, Geert Uytterhoeven wrote:
> Hi all,
> 
> During the last few months, booting kernels on BeagleBone Black
> sometimes fails with:
> 
>     +SMSC LAN8710/LAN8720 4a101000.mdio:00: probe with driver SMSC
> LAN8710/LAN8720 failed with error -5
>      davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00,
> driver SMSC LAN8710/LAN8720
>      soc_device_match(cpsw_soc_devices): no match
>      cpsw-switch 4a100000.switch: initialized cpsw ale version 1.4
>      ...
>      am335x-phy-driver 47401300.usb-phy: dummy supplies not allowed
> for exclusive requests (id=vbus)
>     +cpsw-125mhz-clkctrl:0014:0: failed to disable
>      am335x-phy-driver 47401b00.usb-phy: using DT
> '/ocp/target-module@47400000/usb-phy@1b00' for 'reset' GPIO lookup
>      ...
>      cpsw-switch 4a100000.switch: starting ndev. mode: dual_mac
>     -SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver
> (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
>     -cpsw-switch 4a100000.switch eth0: Link is Up - 100Mbps/Full -
> flow control off
>     -Sending DHCP requests ., OK
>     -IP-Config: Complete:
>     -[...]
>     +cpsw-switch 4a100000.switch: phy
> "/ocp/interconnect@4a000000/segment@0/target-module@100000/switch@0/mdio@1000/ethernet-phy@0"
> not found on slave 0
>     +[HANG]
> 
> Adding debug prints to smsc_phy_probe() makes the issue go away, so it
> must be timing related.
> 
> Adding specific debug prints in the failure case gives:
> 
>     SMSC LAN8710/LAN8720 4a101000.mdio:00: genphy_read_abilities:2859:
> phy_read(MII_BMSR) failed -EIO
>     SMSC LAN8710/LAN8720 4a101000.mdio:00: phy_probe:3613:
> genphy_read_abilities() failed -EIO
>     SMSC LAN8710/LAN8720 4a101000.mdio:00: probe with driver SMSC
> LAN8710/LAN8720 failed with error -5
> 
> and later:
> 
>     Generic PHY 4a101000.mdio:00: genphy_read_abilities:2859:
> phy_read(MII_BMSR) failed -EIO
>     Generic PHY 4a101000.mdio:00: phy_probe:3609:
> genphy_read_abilities failed -EIO
>     cpsw-switch 4a100000.switch: phy
> "/ocp/interconnect@4a000000/segment@0/target-module@100000/switch@0/mdio@1000/ethernet-phy@0"
> not found on slave 0
> 
> Adding debug prints to __mdiobus_read() and davinci_mdio_read() gives:
> 
>     mdio_bus 4a101000.mdio: davinci_mdio_read:444:
> readl(&data->regs->user[0].access) = 0x3a0ffff
>     mdio_bus 4a101000.mdio: __mdiobus_read:900: davinci_mdio_read failed -EIO
> 
> but this is a different (and unimportant?) early failure from
> smsc_phy_config_intr(), and that debug print actually makes the issue go
> away, too.
> 
> Ignoring the early failure reveals that phy_read(MII_BMSR) failed due
> to:
> 
>     mdio_bus 4a101000.mdio: davinci_mdio_read:446:
> readl(&data->regs->user[0].access) = 0x20ffff
> 
> Anyone with a clue?

Just wondering if the Reset is happening correctly and it has settled
before PHY access.

From arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi

&davinci_mdio_sw {
        pinctrl-names = "default", "sleep";
        pinctrl-0 = <&davinci_mdio_default>;
        pinctrl-1 = <&davinci_mdio_sleep>;

        ethphy0: ethernet-phy@0 {
                reg = <0>;
                /* Support GPIO reset on revision C3 boards */
                reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
                reset-assert-us = <300>;
                reset-deassert-us = <13000>;
        };
};

Do we need to increase reset-deassert-us for some reason?

I couldn't find MII ready time after reset de-assert information form the
PHY datasheet. except the following line [1].
"For the first 16us after coming out of reset, the MII/RMII interface will run at 2.5 MHz. After this time, it will
switch to 25 MHz if auto-negotiation is enabled"

[1] 3.8.5 RESETS
https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/LAN8710A-LAN8710Ai-Data-Sheet-DS00002164.pdf
 
> Thanks!
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

-- 
cheers,
-roger

Re: BeagleBone Black Ethernet PHY issues

[Robert Nelson]

On Tue, Oct 29, 2024 at 12:18 PM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi all,
>
> During the last few months, booting kernels on BeagleBone Black
> sometimes fails with:
>
>     +SMSC LAN8710/LAN8720 4a101000.mdio:00: probe with driver SMSC
> LAN8710/LAN8720 failed with error -5
>      davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00,
> driver SMSC LAN8710/LAN8720
>      soc_device_match(cpsw_soc_devices): no match
>      cpsw-switch 4a100000.switch: initialized cpsw ale version 1.4
>      ...
>      am335x-phy-driver 47401300.usb-phy: dummy supplies not allowed
> for exclusive requests (id=vbus)
>     +cpsw-125mhz-clkctrl:0014:0: failed to disable
>      am335x-phy-driver 47401b00.usb-phy: using DT
> '/ocp/target-module@47400000/usb-phy@1b00' for 'reset' GPIO lookup
>      ...
>      cpsw-switch 4a100000.switch: starting ndev. mode: dual_mac
>     -SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver
> (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
>     -cpsw-switch 4a100000.switch eth0: Link is Up - 100Mbps/Full -
> flow control off
>     -Sending DHCP requests ., OK
>     -IP-Config: Complete:
>     -[...]
>     +cpsw-switch 4a100000.switch: phy
> "/ocp/interconnect@4a000000/segment@0/target-module@100000/switch@0/mdio@1000/ethernet-phy@0"
> not found on slave 0
>     +[HANG]
>
> Adding debug prints to smsc_phy_probe() makes the issue go away, so it
> must be timing related.
>
> Adding specific debug prints in the failure case gives:
>
>     SMSC LAN8710/LAN8720 4a101000.mdio:00: genphy_read_abilities:2859:
> phy_read(MII_BMSR) failed -EIO
>     SMSC LAN8710/LAN8720 4a101000.mdio:00: phy_probe:3613:
> genphy_read_abilities() failed -EIO
>     SMSC LAN8710/LAN8720 4a101000.mdio:00: probe with driver SMSC
> LAN8710/LAN8720 failed with error -5
>
> and later:
>
>     Generic PHY 4a101000.mdio:00: genphy_read_abilities:2859:
> phy_read(MII_BMSR) failed -EIO
>     Generic PHY 4a101000.mdio:00: phy_probe:3609:
> genphy_read_abilities failed -EIO
>     cpsw-switch 4a100000.switch: phy
> "/ocp/interconnect@4a000000/segment@0/target-module@100000/switch@0/mdio@1000/ethernet-phy@0"
> not found on slave 0

Hey Geert,

What revision of the board do you have, Bx, Cx, etc.

Only C3 has the new PCB with the phy 'reset' gpio line.

https://openbeagle.org/beagleboard/beaglebone-black/-/blob/master/BBB_SCH.pdf?ref_type=heads

For pre-C3 boards, removing "C24" has fixed a large percentage of my
boards in my ci test farm, while it's not a perfect fix as some still
fail..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

Re: BeagleBone Black Ethernet PHY issues

[Geert Uytterhoeven]

Hi Roger,

On Wed, Oct 30, 2024 at 1:58 PM Roger Quadros <rogerq@kernel.org> wrote:
> On 29/10/2024 19:18, Geert Uytterhoeven wrote:
> > During the last few months, booting kernels on BeagleBone Black
> > sometimes fails with:
> >
> >     +SMSC LAN8710/LAN8720 4a101000.mdio:00: probe with driver SMSC
> > LAN8710/LAN8720 failed with error -5

[...]

> Just wondering if the Reset is happening correctly and it has settled
> before PHY access.
>
> From arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi
>
> &davinci_mdio_sw {
>         pinctrl-names = "default", "sleep";
>         pinctrl-0 = <&davinci_mdio_default>;
>         pinctrl-1 = <&davinci_mdio_sleep>;
>
>         ethphy0: ethernet-phy@0 {
>                 reg = <0>;
>                 /* Support GPIO reset on revision C3 boards */
>                 reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
>                 reset-assert-us = <300>;
>                 reset-deassert-us = <13000>;
>         };
> };
>
> Do we need to increase reset-deassert-us for some reason?

Thanks for the hint!

This is indeed on Rev. C3 (my other boards are Rev. A5C or C, but
I don't test boot recent kernels on them, as they are in active use).

Multiplying reset-deassert-us by 10 gives me a booting board.
More experiments reveal that I need a delay of 14 ms to boot
successfully, and 15 ms to avoid the early __mdiobus_read()
failure, too.

> I couldn't find MII ready time after reset de-assert information form the
> PHY datasheet. except the following line [1].
> "For the first 16us after coming out of reset, the MII/RMII interface will run at 2.5 MHz. After this time, it will
> switch to 25 MHz if auto-negotiation is enabled"
>
> [1] 3.8.5 RESETS
> https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/LAN8710A-LAN8710Ai-Data-Sheet-DS00002164.pdf

3.8.5.1 Hardware Reset
"A Hardware reset is asserted by driving the nRST input pin low. When
 driven, nRST should be held low for the minimum time detailed in
 Section 5.6.3, "Power-On nRST & Configuration Strap Timing," on page
 60 to ensure a proper transceiver reset."

5.6.3 POWER-ON NRST & CONFIGURATION STRAP TIMING
"For proper operation, nRST must be asserted for no less than trstia."

TABLE 5-8: POWER-ON NRST & CONFIGURATION STRAP TIMING VALUES
"trstia nRST input assertion time min. 100 µS"

On Rev. C3, ETH_RESETn is controlled by an open-drain AND gate.
It is pulled high by a 10K resistor, and has a 4.7µF capacitor to
ground.  That gives an RC constant of 47ms.  As you need 0.7RC to charge
the capacitor above the threshold voltage of a CMOS input (VDD/2),
reset-deassert-us should be at least 33ms. Considering the typical
tolerance of 20% on capacitors, 40ms would be safer. Or perhaps
even 50ms?

If you agree, I can send a patch.
Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: BeagleBone Black Ethernet PHY issues

[Geert Uytterhoeven]

Hi Robert,

On Wed, Oct 30, 2024 at 4:00 PM Robert Nelson <robertcnelson@gmail.com> wrote:
> On Tue, Oct 29, 2024 at 12:18 PM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > During the last few months, booting kernels on BeagleBone Black
> > sometimes fails with:

> What revision of the board do you have, Bx, Cx, etc.

This particular one is a C3.

> Only C3 has the new PCB with the phy 'reset' gpio line.

Indeed.

> https://openbeagle.org/beagleboard/beaglebone-black/-/blob/master/BBB_SCH.pdf?ref_type=heads
>
> For pre-C3 boards, removing "C24" has fixed a large percentage of my
> boards in my ci test farm, while it's not a perfect fix as some still
> fail..

Yeah, C24 affects reset delay, too. But Rev. C3 does not have it
mounted.  My Rev. C (no known issues) should have it, and Rev. A5C
(the one that sometimes needs a manual reset after power-up) has only
1µF instead of 2.2µF.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: BeagleBone Black Ethernet PHY issues

[Roger Quadros]

On 30/10/2024 17:08, Geert Uytterhoeven wrote:
> Hi Roger,
> 
> On Wed, Oct 30, 2024 at 1:58 PM Roger Quadros <rogerq@kernel.org> wrote:
>> On 29/10/2024 19:18, Geert Uytterhoeven wrote:
>>> During the last few months, booting kernels on BeagleBone Black
>>> sometimes fails with:
>>>
>>>     +SMSC LAN8710/LAN8720 4a101000.mdio:00: probe with driver SMSC
>>> LAN8710/LAN8720 failed with error -5
> 
> [...]
> 
>> Just wondering if the Reset is happening correctly and it has settled
>> before PHY access.
>>
>> From arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi
>>
>> &davinci_mdio_sw {
>>         pinctrl-names = "default", "sleep";
>>         pinctrl-0 = <&davinci_mdio_default>;
>>         pinctrl-1 = <&davinci_mdio_sleep>;
>>
>>         ethphy0: ethernet-phy@0 {
>>                 reg = <0>;
>>                 /* Support GPIO reset on revision C3 boards */
>>                 reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
>>                 reset-assert-us = <300>;
>>                 reset-deassert-us = <13000>;
>>         };
>> };
>>
>> Do we need to increase reset-deassert-us for some reason?
> 
> Thanks for the hint!
> 
> This is indeed on Rev. C3 (my other boards are Rev. A5C or C, but
> I don't test boot recent kernels on them, as they are in active use).
> 
> Multiplying reset-deassert-us by 10 gives me a booting board.
> More experiments reveal that I need a delay of 14 ms to boot
> successfully, and 15 ms to avoid the early __mdiobus_read()
> failure, too.
> 
>> I couldn't find MII ready time after reset de-assert information form the
>> PHY datasheet. except the following line [1].
>> "For the first 16us after coming out of reset, the MII/RMII interface will run at 2.5 MHz. After this time, it will
>> switch to 25 MHz if auto-negotiation is enabled"
>>
>> [1] 3.8.5 RESETS
>> https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/LAN8710A-LAN8710Ai-Data-Sheet-DS00002164.pdf
> 
> 3.8.5.1 Hardware Reset
> "A Hardware reset is asserted by driving the nRST input pin low. When
>  driven, nRST should be held low for the minimum time detailed in
>  Section 5.6.3, "Power-On nRST & Configuration Strap Timing," on page
>  60 to ensure a proper transceiver reset."
> 
> 5.6.3 POWER-ON NRST & CONFIGURATION STRAP TIMING
> "For proper operation, nRST must be asserted for no less than trstia."
> 
> TABLE 5-8: POWER-ON NRST & CONFIGURATION STRAP TIMING VALUES
> "trstia nRST input assertion time min. 100 µS"
> 
> On Rev. C3, ETH_RESETn is controlled by an open-drain AND gate.
> It is pulled high by a 10K resistor, and has a 4.7µF capacitor to
> ground.  That gives an RC constant of 47ms.  As you need 0.7RC to charge
> the capacitor above the threshold voltage of a CMOS input (VDD/2),
> reset-deassert-us should be at least 33ms. Considering the typical
> tolerance of 20% on capacitors, 40ms would be safer. Or perhaps
> even 50ms?

Super! Yes, I agree 50ms would be a good setting.

> 
> If you agree, I can send a patch.
> Thanks!

Much appreciated, thanks!

-- 
cheers,
-roger

Re: BeagleBone Black Ethernet PHY issues

[Geert Uytterhoeven]

On Thu, Oct 31, 2024 at 10:06 AM Roger Quadros <rogerq@kernel.org> wrote:
> On 30/10/2024 17:08, Geert Uytterhoeven wrote:
> > On Wed, Oct 30, 2024 at 1:58 PM Roger Quadros <rogerq@kernel.org> wrote:
> >> On 29/10/2024 19:18, Geert Uytterhoeven wrote:
> >>> During the last few months, booting kernels on BeagleBone Black
> >>> sometimes fails with:
> >>>
> >>>     +SMSC LAN8710/LAN8720 4a101000.mdio:00: probe with driver SMSC
> >>> LAN8710/LAN8720 failed with error -5
> >
> > [...]
> >
> >> Just wondering if the Reset is happening correctly and it has settled
> >> before PHY access.
> >>
> >> From arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi
> >>
> >> &davinci_mdio_sw {
> >>         pinctrl-names = "default", "sleep";
> >>         pinctrl-0 = <&davinci_mdio_default>;
> >>         pinctrl-1 = <&davinci_mdio_sleep>;
> >>
> >>         ethphy0: ethernet-phy@0 {
> >>                 reg = <0>;
> >>                 /* Support GPIO reset on revision C3 boards */
> >>                 reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
> >>                 reset-assert-us = <300>;
> >>                 reset-deassert-us = <13000>;
> >>         };
> >> };
> >>
> >> Do we need to increase reset-deassert-us for some reason?
> >
> > Thanks for the hint!
> >
> > This is indeed on Rev. C3 (my other boards are Rev. A5C or C, but
> > I don't test boot recent kernels on them, as they are in active use).
> >
> > Multiplying reset-deassert-us by 10 gives me a booting board.
> > More experiments reveal that I need a delay of 14 ms to boot
> > successfully, and 15 ms to avoid the early __mdiobus_read()
> > failure, too.
> >
> >> I couldn't find MII ready time after reset de-assert information form the
> >> PHY datasheet. except the following line [1].
> >> "For the first 16us after coming out of reset, the MII/RMII interface will run at 2.5 MHz. After this time, it will
> >> switch to 25 MHz if auto-negotiation is enabled"
> >>
> >> [1] 3.8.5 RESETS
> >> https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/LAN8710A-LAN8710Ai-Data-Sheet-DS00002164.pdf
> >
> > 3.8.5.1 Hardware Reset
> > "A Hardware reset is asserted by driving the nRST input pin low. When
> >  driven, nRST should be held low for the minimum time detailed in
> >  Section 5.6.3, "Power-On nRST & Configuration Strap Timing," on page
> >  60 to ensure a proper transceiver reset."
> >
> > 5.6.3 POWER-ON NRST & CONFIGURATION STRAP TIMING
> > "For proper operation, nRST must be asserted for no less than trstia."
> >
> > TABLE 5-8: POWER-ON NRST & CONFIGURATION STRAP TIMING VALUES
> > "trstia nRST input assertion time min. 100 µS"
> >
> > On Rev. C3, ETH_RESETn is controlled by an open-drain AND gate.
> > It is pulled high by a 10K resistor, and has a 4.7µF capacitor to
> > ground.  That gives an RC constant of 47ms.  As you need 0.7RC to charge
> > the capacitor above the threshold voltage of a CMOS input (VDD/2),
> > reset-deassert-us should be at least 33ms. Considering the typical
> > tolerance of 20% on capacitors, 40ms would be safer. Or perhaps
> > even 50ms?
>
> Super! Yes, I agree 50ms would be a good setting.

> > If you agree, I can send a patch.
> > Thanks!
>
> Much appreciated, thanks!

https://lore.kernel.org/9002a58daa1b2983f39815b748ee9d2f8dcc4829.1730366936.git.geert+renesas@glider.be

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds