From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Sun, 20 Mar 2016 14:45:25 +0100 Subject: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2 In-Reply-To: <56ED56BF.8040304@computerlinguist.org> References: <1458020499-9506-1-git-send-email-haas@computerlinguist.org> <20160315180914.GA1878@excalibur.cnev.de> <56E91A12.8080506@computerlinguist.org> <56E9278F.7060801@redhat.com> <20160316203642.GC1817@excalibur.cnev.de> <56EA4097.3010500@computerlinguist.org> <56EA8C5E.1070701@redhat.com> <56EC78F7.80507@computerlinguist.org> <56ed1046.857ac20a.dc7f4.ffffb08e@mx.google.com> <56ED1C96.30708@redhat.com> <56ED56BF.8040304@computerlinguist.org> Message-ID: <56EEA975.6060301@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 19-03-16 14:40, Michael Haas wrote: > On 03/19/2016 10:32 AM, Hans de Goede wrote: >> Hi, >> >> On 19-03-16 09:39, Fran?ois-David Collin wrote: >>> Hi, >>> >>> As I?m banging my head on this too, please allow me to provide some >>> details >>> I got two stable situations : >>> The Lime2 is connected directly to the Gbit interface of my laptop, >>> speed are OK: >> >> Michael Haas' work to debug this by looking at the phy registers >> seems to be the most promising so-far, the clk reg and axp209 >> registers all seem to be identical between good and bad setups. >> >> Can you try to: >> >> 1) Stop the boot in u-boot (press a key on the serial console) >> 2) Bring up the network, e.g. type "dhcp" then ctrl+c when it tries >> to tftp >> 3) Do: "mii read 1 0x11" in u-boot and record the output ? >> >> Regards, >> >> Hans > > Hi all, > > i have diffed and cross-compared logs of several working and broken tftp > downloads. The most significant > difference between working and broken was registers 0xa, 0x1c and 0x2a > in the first MII page. > > These registers started making sense when I looked at the datasheet for > the RTL8211CL. Previously, I was looking at the RTL8211E. > > 0xA was set to 7800 for working runs and 3800 for broken runs. The > difference is bit 14 in the GBSR: 'MASTER/SLAVE Configuration > Resolution'. In the broken runs, the autonegotation configured the > OlinuXino to 'slave'. I have whipped up a quick patch which disable the > master/slave part of the autonegotiation and force master mode. > > The patch itself is quite terrible as it's forcing the master mode bits > for every phy, not just for the RTL8211CL. It's good enough for testing, > however, and I seem to be getting consistent download speeds. There are > occasional hangs when booting the downloaded kernel, but that is > probably a different issue. > > diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c > index 51b5746..484b2be 100644 > --- a/drivers/net/phy/phy.c > +++ b/drivers/net/phy/phy.c > @@ -170,6 +170,7 @@ int genphy_restart_aneg(struct phy_device *phydev) > int genphy_config_aneg(struct phy_device *phydev) > { > int result; > + phy_write(phydev, MDIO_DEVAD_NONE, 0x09, 0x1A00); > > if (AUTONEG_ENABLE != phydev->autoneg) > return genphy_setup_forced(phydev); > > Please test this change and let me know. If it's successful, I will > submit a proper version. Good catch, I wonder why we need this. I believe that the proper version should probably be wrapped in a #ifdef CONFIG_REALTEK_PHY_FORCE_MASTER and then add a Kconfig option for this (and enable it in the lime2 defconfig), forcing this on all rtl8211cl phy-s seems wrong, unless someone can dig up an errata from realtek which said we should. Are any other sunxi boards impacted by the same problem that you know ? Regards, Hans