U-Boot and ethernet regression on mx6cuboxi

U-Boot and ethernet regression on mx6cuboxi

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

Hey,

So my mx6cuboxi was out of my lab for a bit, and that's how this
regression got in mainline.  With:
4223fb0ee18d11462c55ac94198fdc2055f2c27c is the first bad commit
commit 4223fb0ee18d11462c55ac94198fdc2055f2c27c
Author: Tim Harvey <tharvey@gateworks.com>
Date:   Tue Mar 1 12:15:01 2022 -0800

    net: fec: prevent undesired de-assertion of phy-reset on request

I now see:
=> dhcp
ethernet@2188000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
Could not initialize PHY ethernet@2188000
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16

Any ideas?  Thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: U-Boot and ethernet regression on mx6cuboxi

[Tim Harvey]

On Thu, Apr 28, 2022 at 1:41 PM Tom Rini <trini@konsulko.com> wrote:
>
> Hey,
>
> So my mx6cuboxi was out of my lab for a bit, and that's how this
> regression got in mainline.  With:
> 4223fb0ee18d11462c55ac94198fdc2055f2c27c is the first bad commit
> commit 4223fb0ee18d11462c55ac94198fdc2055f2c27c
> Author: Tim Harvey <tharvey@gateworks.com>
> Date:   Tue Mar 1 12:15:01 2022 -0800
>
>     net: fec: prevent undesired de-assertion of phy-reset on request
>
> I now see:
> => dhcp
> ethernet@2188000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
> Could not initialize PHY ethernet@2188000
> BOOTP broadcast 1
> BOOTP broadcast 2
> BOOTP broadcast 3
> BOOTP broadcast 4
> BOOTP broadcast 5
> BOOTP broadcast 6
> BOOTP broadcast 7
> BOOTP broadcast 8
> BOOTP broadcast 9
> BOOTP broadcast 10
> BOOTP broadcast 11
> BOOTP broadcast 12
> BOOTP broadcast 13
> BOOTP broadcast 14
> BOOTP broadcast 15
> BOOTP broadcast 16
>
> Any ideas?  Thanks!
>

Tom,

What PHY is used on that board and can you verify the PHY reset is
properly defined in the dt polarity and all?

What I found is that before commit 4223fb0ee18d11 ("net: fec: prevent
undesired de-assertion of phy-reset on request") my board's
(imx8mm-venice-gw73xx) PHY_RST would driver high during the
gpio-request before it was driven low then high again. The PHY used on
my board (at least new revisions) is the MaxLinear GPY111 and we it
was extremely sensitive to multiple reset events and this behavior
would make it unreliable.

Best Regards,

Tim

Re: U-Boot and ethernet regression on mx6cuboxi

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2212 bytes --]

On Thu, Apr 28, 2022 at 02:25:03PM -0700, Tim Harvey wrote:
> On Thu, Apr 28, 2022 at 1:41 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > Hey,
> >
> > So my mx6cuboxi was out of my lab for a bit, and that's how this
> > regression got in mainline.  With:
> > 4223fb0ee18d11462c55ac94198fdc2055f2c27c is the first bad commit
> > commit 4223fb0ee18d11462c55ac94198fdc2055f2c27c
> > Author: Tim Harvey <tharvey@gateworks.com>
> > Date:   Tue Mar 1 12:15:01 2022 -0800
> >
> >     net: fec: prevent undesired de-assertion of phy-reset on request
> >
> > I now see:
> > => dhcp
> > ethernet@2188000 Waiting for PHY auto negotiation to complete......... TIMEOUT !
> > Could not initialize PHY ethernet@2188000
> > BOOTP broadcast 1
> > BOOTP broadcast 2
> > BOOTP broadcast 3
> > BOOTP broadcast 4
> > BOOTP broadcast 5
> > BOOTP broadcast 6
> > BOOTP broadcast 7
> > BOOTP broadcast 8
> > BOOTP broadcast 9
> > BOOTP broadcast 10
> > BOOTP broadcast 11
> > BOOTP broadcast 12
> > BOOTP broadcast 13
> > BOOTP broadcast 14
> > BOOTP broadcast 15
> > BOOTP broadcast 16
> >
> > Any ideas?  Thanks!
> >
> 
> Tom,
> 
> What PHY is used on that board and can you verify the PHY reset is
> properly defined in the dt polarity and all?
> 
> What I found is that before commit 4223fb0ee18d11 ("net: fec: prevent
> undesired de-assertion of phy-reset on request") my board's
> (imx8mm-venice-gw73xx) PHY_RST would driver high during the
> gpio-request before it was driven low then high again. The PHY used on
> my board (at least new revisions) is the MaxLinear GPY111 and we it
> was extremely sensitive to multiple reset events and this behavior
> would make it unreliable.

Thanks for the hint, Tim!  Fabio, the dts needs to be re-synced with
Linux as upstream it says:
        /*
         * The PHY seems to require a long-enough reset duration to avoid
         * some rare issues where the PHY gets stuck in an inconsistent and
         * non-functional state at boot-up. 10ms proved to be fine .
         */
        phy-reset-duration = <10>;

But we have this set to 2, and indeed bumping it up to 10 to match fixes
the network tests for me.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: U-Boot and ethernet regression on mx6cuboxi

[Fabio Estevam]

Hi Tom,

On Fri, Apr 29, 2022 at 9:44 AM Tom Rini <trini@konsulko.com> wrote:

> Thanks for the hint, Tim!  Fabio, the dts needs to be re-synced with
> Linux as upstream it says:
>         /*
>          * The PHY seems to require a long-enough reset duration to avoid
>          * some rare issues where the PHY gets stuck in an inconsistent and
>          * non-functional state at boot-up. 10ms proved to be fine .
>          */
>         phy-reset-duration = <10>;
>
> But we have this set to 2, and indeed bumping it up to 10 to match fixes
> the network tests for me.

Great, care to send a patch to U-Boot that aligns this cubox dts with upstream?

I do have a preliminary patch that syncs all imx6dl/q dts with upstream.

I haven't submitted it yet, as it needs lots of careful manual
inspection, especially with the alias nodes.

Still want to submit it, but it is not a trivial one due to the high
chances of boot regressions.

Thanks

Re: U-Boot and ethernet regression on mx6cuboxi

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

On Fri, Apr 29, 2022 at 10:31:05AM -0300, Fabio Estevam wrote:
> Hi Tom,
> 
> On Fri, Apr 29, 2022 at 9:44 AM Tom Rini <trini@konsulko.com> wrote:
> 
> > Thanks for the hint, Tim!  Fabio, the dts needs to be re-synced with
> > Linux as upstream it says:
> >         /*
> >          * The PHY seems to require a long-enough reset duration to avoid
> >          * some rare issues where the PHY gets stuck in an inconsistent and
> >          * non-functional state at boot-up. 10ms proved to be fine .
> >          */
> >         phy-reset-duration = <10>;
> >
> > But we have this set to 2, and indeed bumping it up to 10 to match fixes
> > the network tests for me.
> 
> Great, care to send a patch to U-Boot that aligns this cubox dts with upstream?
> 
> I do have a preliminary patch that syncs all imx6dl/q dts with upstream.
> 
> I haven't submitted it yet, as it needs lots of careful manual
> inspection, especially with the alias nodes.
> 
> Still want to submit it, but it is not a trivial one due to the high
> chances of boot regressions.

I'd rather test your overall sync because I assume based on doing other
resyncs before it'll end up pulling in a lot of other dts files.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]