(re formatting to avoid top posting)

Hi Clement,

On Sat, Sep 9, 2017 at 1:07 AM, Clément Péron peron.clem@gmail.com wrote:

...

2017-08-31 11:12 GMT+02:00 Clément Péron peron.clem@gmail.com: Hi,

I try to update my u-boot with the latest version 2017.07.

My board is an Altera SocFPGA CycloneV and I have a mv88e61xx switch.

My board is working fine except I got an issue with the new switch driver. If autoneg is set to enable, negotation never complete and i got a timeout. If I let the autoneg disable, I have ethernet working but with slow speed 10mbits / half duplex.

Not sure if i'm doing something wrong or if there is a bug in the new driver.

Could you please help me to debug this issue ?

Thanks for your help, Regards, Clement

KConfig #################################### --- Marvel MV88E61xx Ethernet switch PHY support. (5) CPU Port (0x1F) Bitmask of PHY Ports (0x0) Bitmask of PHYless serdes Ports

board.c #################################### int mv88e61xx_hw_reset(struct phy_device *phydev) { struct mii_dev *bus = phydev->bus;

     /* RGMII delay - Physical Control register bit[15:14] */
     debug("setting port%d RGMII rx/tx delay\n", CONFIG_MV88E61XX_CPU_PORT);
     /* forced 1000mbps full-duplex link */
     bus->write(bus, 0x10 + CONFIG_MV88E61XX_CPU_PORT, 0, 1, 0xc0fe);
     phydev->autoneg = AUTONEG_ENABLE;
     phydev->speed = SPEED_1000;
     phydev->duplex = DUPLEX_FULL;

     return 0;

}

serial #################################### U-Boot SPL 2017.07-00009-g9f00f9622e-dirty (Aug 31 2017 - 10:52:53) drivers/ddr/altera/sequencer.c: Preparing to start memory calibration drivers/ddr/altera/sequencer.c: CALIBRATION PASSED drivers/ddr/altera/sequencer.c: Calibration complete Trying to boot from SPI

U-Boot 2017.07-00009-g9f00f9622e-dirty (Aug 31 2017 - 10:52:53 +0200)

CPU: Altera SoCFPGA Platform FPGA: Altera Cyclone V, SE/A4 or SX/C4, version 0x0 BOOT: QSPI Flash (3.0V) Watchdog enabled DRAM: 512 MiB MMC: dwmmc0@ff704000: 0 *** Warning - bad CRC, using default environment

In: serial Out: serial Err: serial Model: Board Net: setting port5 RGMII rx/tx delay

Warning: ethernet@ff702000 (eth0) using random MAC address - 2e:91:a1:21:8e:38 eth0: ethernet@ff702000 Hit any key to stop autoboot: 0 => tftp ${rootaddr} rootfs.cpio.uboot; tftp ${dtb_loadaddr} board.dtb; tftp ${loadaddr} uImage; bootm ${loadaddr} ${rootaddr} ${dtb_loadadd} ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000: No link. ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000: No link. ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! ethernet@ff702000: No link. ...

Hi,

After some investigation i found that the phy_reset of the Marvell doesn't reup the PHY and the ANEG bits.

The issue has been introduce by the commit a058052c358c3ecf5f394ff37def6a45eb26768c

"net: phy: do not read configuration register on reset

When doing a software reset, the reset flag should be written without
other bits set. Writing the current state will lead to restoring the
state of the PHY (e.g. Powerdown), which is not what is expected from
a software reset."

Regards, Clement

Does that mean with this commit reverted your board is working?

I have some older boards using a 88e6097 (compatible with 88e61xx). I've been looking for an excuse to get them working against the latest u-boot. Last time I tried the new 88e61xx driver was also problematic but I ran out of time to look into why. I'm travelling for a couple of weeks at the moment but when I get back I can try them out with the newer code.