| Message ID | 1451925378-14121-2-git-send-email-festevam@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
On Mon, Jan 04, 2016 at 02:36:18PM -0200, Fabio Estevam wrote: > From: Fabio Estevam <fabio.estevam@nxp.com> > > Since commit 59370f3fcd1350 ("net: phy: delay only if reset handler is > registered") Ethernet is no longer functional: > > Booting from net ... > FEC Waiting for PHY auto negotiation to complete......... TIMEOUT ! > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > BOOTP broadcast 4 > > This commit does not have an issue in itself, but it revelead a problem > with the Ethernet initialization. > > Configure the AR8035 PHY in the same manner as done in mx6sabresd > and wandboard, so that we can get a reliable Ethernet operation. > > Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Note: CPU: Freescale i.MX6D rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 14C Reset cause: POR Board: MX6 Hummingboard ... => setenv autoload no => dhcp FEC Waiting for PHY auto negotiation to complete......... TIMEOUT ! BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 DHCP client bound to address 192.168.0.219 (7901 ms) => tftp ramdisk-pm.gz Using FEC device TFTP from server 192.168.0.3; our IP address is 192.168.0.219 Filename 'ramdisk-pm.gz'. Load address: 0x12000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ###### 1.4 MiB/s done Bytes transferred = 2022580 (1edcb4 hex) => crc32 $loadaddr $filesize CRC32 for 12000000 ... 121edcb3 ==> 775dd44d => CRC32 matches: $ rhash -C /tftpboot/ramdisk-pm.gz ; Generated by RHash v1.2.8 on 2016-01-04 at 12:04.37 ; Written by Aleksey (Akademgorodok) - http://rhash.sourceforge.net/ ; ; 2022580 13:41.29 2013-06-25 /tftpboot/ramdisk-pm.gz /tftpboot/ramdisk-pm.gz 775DD44D Tested-by: Tom Rini <trini@konsulko.com>
On 1/4/2016 9:36 AM, Fabio Estevam wrote: > From: Fabio Estevam <fabio.estevam@nxp.com> > > Since commit 59370f3fcd1350 ("net: phy: delay only if reset handler is > registered") Ethernet is no longer functional: > > Booting from net ... > FEC Waiting for PHY auto negotiation to complete......... TIMEOUT ! > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > BOOTP broadcast 4 > > This commit does not have an issue in itself, but it revelead a problem > with the Ethernet initialization. > > Configure the AR8035 PHY in the same manner as done in mx6sabresd > and wandboard, so that we can get a reliable Ethernet operation. > > Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> > --- > board/solidrun/mx6cuboxi/mx6cuboxi.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c > index 20faffc..3bb7573 100644 > --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c > +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c > @@ -147,8 +147,33 @@ static void setup_iomux_enet(void) > gpio_set_value(ETH_PHY_RESET, 1); > } > > +static int mx6_rgmii_rework(struct phy_device *phydev) > +{ > + unsigned short val; > + > + /* Enable AR8035 ouput a 125MHz clk from CLK_25M */ > + phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x7); > + phy_write(phydev, MDIO_DEVAD_NONE, 0xe, 0x8016); > + phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x4007); > + > + val = phy_read(phydev, MDIO_DEVAD_NONE, 0xe); > + val &= 0xffe3; > + val |= 0x18; Except for clearing bit 2 (which is undocumented), this looks just like the default implementation, which you are still calling below. So, it looks like this subroutine can be replaced with an appropriate delay. If bit 2 does matter, perhaps the default ar8035_config should be changed instead. > + phy_write(phydev, MDIO_DEVAD_NONE, 0xe, val); > + > + /* introduce tx clock delay */ > + phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x5); > + val = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e); > + val |= 0x0100; > + phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, val); > + > + return 0; > +} > + > int board_phy_config(struct phy_device *phydev) > { > + mx6_rgmii_rework(phydev); > + > if (phydev->drv->config) > phydev->drv->config(phydev); > > As a test perhaps you can call config twice instead of mx6_rgmii_rework if (phydev->drv->config) { phydev->drv->config(phydev); phydev->drv->config(phydev); }
Hi Troy, On Mon, Jan 4, 2016 at 6:40 PM, Troy Kisky <troy.kisky@boundarydevices.com> wrote: > Except for clearing bit 2 (which is undocumented), this looks just like the default > implementation, which you are still calling below. > > So, it looks like this subroutine can be replaced with an appropriate delay. > If bit 2 does matter, perhaps the default ar8035_config should be changed instead. Just realized that ar8035_config() is never called in my case, so doing: int board_phy_config(struct phy_device *phydev) { mx6_rgmii_rework(phydev); return 0; } , is enough here. Any idea as to why ar8035_config() is never called?
On 1/4/2016 2:50 PM, Fabio Estevam wrote: > Hi Troy, > > On Mon, Jan 4, 2016 at 6:40 PM, Troy Kisky > <troy.kisky@boundarydevices.com> wrote: > >> Except for clearing bit 2 (which is undocumented), this looks just like the default >> implementation, which you are still calling below. >> >> So, it looks like this subroutine can be replaced with an appropriate delay. >> If bit 2 does matter, perhaps the default ar8035_config should be changed instead. > > Just realized that ar8035_config() is never called in my case, so doing: > > int board_phy_config(struct phy_device *phydev) > { > mx6_rgmii_rework(phydev); > > return 0; > } > > , is enough here. > > Any idea as to why ar8035_config() is never called? > => mii read 6 2 004D => mii read 6 3 D072 => Do you get a different value?
On Mon, Jan 4, 2016 at 8:06 PM, Troy Kisky <troy.kisky@boundarydevices.com> wrote: > => mii read 6 2 > 004D > => mii read 6 3 > D072 > => > > Do you get a different value? Yes, I get all FFFF: => mii read 6 3 FFFF => mii read 6 2 FFFF
On Mon, Jan 4, 2016 at 8:08 PM, Fabio Estevam <festevam@gmail.com> wrote: > On Mon, Jan 4, 2016 at 8:06 PM, Troy Kisky > <troy.kisky@boundarydevices.com> wrote: > >> => mii read 6 2 >> 004D >> => mii read 6 3 >> D072 >> => >> >> Do you get a different value? > > Yes, I get all FFFF: > > => mii read 6 3 > FFFF > => mii read 6 2 > FFFF Ops, in my case the PHY address is 0. By adjust the address I get the same values as you reported: => mii read 0 2 004D => mii read 0 3 D072
On 1/4/2016 3:08 PM, Fabio Estevam wrote: > On Mon, Jan 4, 2016 at 8:06 PM, Troy Kisky > <troy.kisky@boundarydevices.com> wrote: > >> => mii read 6 2 >> 004D >> => mii read 6 3 >> D072 >> => >> >> Do you get a different value? > > Yes, I get all FFFF: > > => mii read 6 3 > FFFF > => mii read 6 2 > FFFF > . > Sorry, your phy is not at 6, you can either print it out, or try 0 to 7
On 1/4/2016 3:10 PM, Fabio Estevam wrote: > On Mon, Jan 4, 2016 at 8:08 PM, Fabio Estevam <festevam@gmail.com> wrote: >> On Mon, Jan 4, 2016 at 8:06 PM, Troy Kisky >> <troy.kisky@boundarydevices.com> wrote: >> >>> => mii read 6 2 >>> 004D >>> => mii read 6 3 >>> D072 >>> => >>> >>> Do you get a different value? >> >> Yes, I get all FFFF: >> >> => mii read 6 3 >> FFFF >> => mii read 6 2 >> FFFF > > Ops, in my case the PHY address is 0. > > By adjust the address I get the same values as you reported: > > => mii read 0 2 > 004D > => mii read 0 3 > D072 > Can you add printf("%s at %d\n", phydev->drv->name, phydev->addr);
On Mon, Jan 4, 2016 at 8:45 PM, Troy Kisky <troy.kisky@boundarydevices.com> wrote: > Can you add > > printf("%s at %d\n", phydev->drv->name, phydev->addr); It prints: Generic PHY at 0 Not sure why it picks the Generic PHY driver instead of the Atheros PHY one.
On 1/4/2016 3:50 PM, Fabio Estevam wrote: > On Mon, Jan 4, 2016 at 8:45 PM, Troy Kisky > <troy.kisky@boundarydevices.com> wrote: > >> Can you add >> >> printf("%s at %d\n", phydev->drv->name, phydev->addr); > > It prints: > > Generic PHY at 0 > > Not sure why it picks the Generic PHY driver instead of the Atheros PHY one. > Try adding a delay after releasing reset mdelay(2); gpio_set_value(ETH_PHY_RESET, 1); udelay(100); Perhaps the first time it didn't read 4dd072
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c index 20faffc..3bb7573 100644 --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -147,8 +147,33 @@ static void setup_iomux_enet(void) gpio_set_value(ETH_PHY_RESET, 1); } +static int mx6_rgmii_rework(struct phy_device *phydev) +{ + unsigned short val; + + /* Enable AR8035 ouput a 125MHz clk from CLK_25M */ + phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x7); + phy_write(phydev, MDIO_DEVAD_NONE, 0xe, 0x8016); + phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x4007); + + val = phy_read(phydev, MDIO_DEVAD_NONE, 0xe); + val &= 0xffe3; + val |= 0x18; + phy_write(phydev, MDIO_DEVAD_NONE, 0xe, val); + + /* introduce tx clock delay */ + phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x5); + val = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e); + val |= 0x0100; + phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, val); + + return 0; +} + int board_phy_config(struct phy_device *phydev) { + mx6_rgmii_rework(phydev); + if (phydev->drv->config) phydev->drv->config(phydev);