[PATCH] net: eqos: connect and config PHY from probe stage instead of starting EQOS

Joakim Zhang qiangqing.zhang at nxp.com
Tue Nov 16 12:02:31 CET 2021


> -----Original Message-----
> From: Ramon Fried <rfried.dev at gmail.com>
> Sent: 2021年11月16日 18:45
> To: Joakim Zhang <qiangqing.zhang at nxp.com>
> Cc: Joe Hershberger <joe.hershberger at ni.com>; U-Boot Mailing List
> <u-boot at lists.denx.de>; Ye Li <ye.li at nxp.com>; Patrick Delaunay
> <patrick.delaunay at foss.st.com>; Daniil Stas <daniil.stas at posteo.net>;
> Stephen Warren <swarren at nvidia.com>
> Subject: Re: [PATCH] net: eqos: connect and config PHY from probe stage
> instead of starting EQOS
> 
> On Tue, Nov 16, 2021 at 10:04 AM Joakim Zhang <qiangqing.zhang at nxp.com>
> wrote:
> >
> >
> > Hi Ramon,
> >
> > > -----Original Message-----
> > > From: Ramon Fried <rfried.dev at gmail.com>
> > > Sent: 2021年11月16日 13:57
> > > To: Joakim Zhang <qiangqing.zhang at nxp.com>
> > > Cc: Joe Hershberger <joe.hershberger at ni.com>; U-Boot Mailing List
> > > <u-boot at lists.denx.de>; Ye Li <ye.li at nxp.com>; Patrick Delaunay
> > > <patrick.delaunay at foss.st.com>; Daniil Stas
> > > <daniil.stas at posteo.net>; Stephen Warren <swarren at nvidia.com>
> > > Subject: Re: [PATCH] net: eqos: connect and config PHY from probe
> > > stage instead of starting EQOS
> > >
> > > On Wed, Nov 10, 2021 at 7:42 AM Joakim Zhang
> > > <qiangqing.zhang at nxp.com>
> > > wrote:
> > > >
> > > > For EQOS ethernet, it will do phy_connect() and phy_config() when
> > > > start the ethernet (eqos_srart()), users need wait seconds for PHY
> > > > auto negotiation to complete when do tftp boot.
> > > >     phy_config()
> > > >             -> board_phy_config()
> > > >                     -> phydev->drv->config() // i.MX8MP/DXL use
> > > realtek PHY
> > > >                             -> rtl8211f_config()
> > > >                                     -> genphy_config_aneg()
> > > >                                             ->
> > > genphy_restart_aneg()
> > > > // restart auto-nego, then need seconds to complete
> > > >
> > > > To avoid wasting time, we can move PHY connection and
> > > > configuration from
> > > > eqos_start() to eqos_probe(). This patch also moves clock setting
> > > > from
> > > > eqos_start() to eqos_probe() as MDIO access need CSR clock, there
> > > > is no function change.
> > > >
> > > > Tested-on: i.MX8MP & i.MX8DXL
> > > >
> > > > Before:
> > > > u-boot=> run netboot
> > > > Booting from net ...
> > > > ethernet at 30bf0000 Waiting for PHY auto negotiation to complete.......
> > > > done BOOTP broadcast 1 DHCP client bound to address 10.193.102.192
> > > > (313 ms) Using ethernet at 30bf0000 device TFTP from server
> > > > 10.193.108.176; our IP address is 10.193.102.192; sending through
> > > > gateway 10.193.102.254
> > > > After:
> > > > u-boot=> run netboot
> > > > Booting from net ...
> > > > BOOTP broadcast 1
> > > > DHCP client bound to address 10.193.102.192 (454 ms) Using
> > > > ethernet at 30bf0000 device TFTP from server 10.193.108.176; our IP
> > > > address is 10.193.102.192; sending through gateway 10.193.102.254
> > > >
> > > How much time do you save exactly, Is it the ~140ms you show here at
> > > the commit log ?
> >
> > Exactly not. This time points to DHCP client bound to address, not the time
> this patch saves.
> >
> > How can we evaluate the time we save? Please see the log:
> >
> > Before:
> >     Booting from net ...
> >     ethernet at 30bf0000 Waiting for PHY auto negotiation to complete.......
> done
> >     BOOTP broadcast 1
> > After:
> >     Booting from net ...
> >     BOOTP broadcast 1
> >
> > And you need to check the related code:
> > drivers/net/dwc_eth_qos.c: phy_startup ->...->
> > drivers/net/phy/phy.c: genphy_update_link()
> >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour
> >
> ce.denx.de%2Fu-boot%2Fu-boot%2F-%2Fblob%2Fmaster%2Fdrivers%2Fnet
> %2Fphy
> > %2Fphy.c%23L225&data=04%7C01%7Cqiangqing.zhang%40nxp.com%
> 7C59322db
> >
> 193a54788a09308d9a8ee2cfc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7
> >
> C637726563178464522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIj
> >
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=usRIR7L
> exBnk
> > dnDO3U8hHYtMAIWT8bJ0Q7wgTElUjHs%3D&reserved=0
> >
> >                 while (!(mii_reg & BMSR_ANEGCOMPLETE)) {
> >                         /*
> >                          * Timeout reached ?
> >                          */
> >                         if (i > (PHY_ANEG_TIMEOUT / 50)) {
> >                                 printf(" TIMEOUT !\n");
> >                                 phydev->link = 0;
> >                                 return -ETIMEDOUT;
> >                         }
> >
> >                         if (ctrlc()) {
> >                                 puts("user interrupt!\n");
> >                                 phydev->link = 0;
> >                                 return -EINTR;
> >                         }
> >
> >                         if ((i++ % 10) == 0)
> >                                 printf(".");
> >
> >                         mii_reg = phy_read(phydev,
> MDIO_DEVAD_NONE, MII_BMSR);
> >                         mdelay(50);     /* 50 ms */
> >                 }
> >
> > We can see that one "." is about 500ms, so from the log, we save about
> 500*7=3500ms=3.5s, this also means that PHY needs about 3.5s to complete
> auto-nego.
> >
> > I also described this in the commit message, "users need wait seconds for
> PHY auto negotiation to complete when do tftp boot", may not quite clear, I
> will improve it.
> >
> > Best Regards,
> > Joakim Zhang
> 
> NACK.
> Hi Joakim.
> It's currently working like that for all network drivers, it's not specific What
> you're currently suggesting is that the link will be brought up automatically
> for all users, even if they're not interested in network booting.
> That won't work.

Hi Ramon,

I am not quite understand you mean, I only connect and config the PHY in the MAC probe stage, yes, the link should be brought up,
but startup PHY still in MAC open operation, just attaching PHY to MAC in MAC probe, seems not a problem. Is there any side effect?

We did the same thing in FEC driver: https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L1522

Best Regards,
Joakim Zhang
> Thanks,
> Ramon


More information about the U-Boot mailing list