From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Haas Date: Sun, 20 Mar 2016 16:28:10 +0100 Subject: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2 In-Reply-To: <56EEA975.6060301@redhat.com> 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> <56EEA975.6060301@redhat.com> Message-ID: <56EEC18A.1040807@computerlinguist.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 03/20/2016 02:45 PM, Hans de Goede wrote: > 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. I was going to add that in realtek.c, not in phy.c - as soon as I figure out which section there is applicable. I have started a new thread asking about that. > > Are any other sunxi boards impacted by the same problem that you know ? > No, I don't know of any other boards, but I have not looked very hard :) Michael