From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Sun, 20 Mar 2016 19:51:20 +0100 Subject: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2 In-Reply-To: <56EEC18A.1040807@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> <56EEA975.6060301@redhat.com> <56EEC18A.1040807@computerlinguist.org> Message-ID: <56EEF128.4020704@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 20-03-16 16:28, Michael Haas wrote: > 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. Ack, I already understood that. What I mean is that even if you limit the fix to just apply to rtl8211cl phys, that that is still a somewhat big hammer if the problem only happens on the lime2. Always applying the workaround if the phy is a rtl8211cl means also applying it on other sunxi boards and likely also on boards with a completely different soc which also happen to use the rtl8211cl, which is why I suggest that you wrap it in #ifdef CONFIG_REALTEK_PHY_FORCE_MASTER and a matching Kconfig bool, which defaults to false. > I have started a new thread > asking about that. Ack I've seen 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 :) Ok, so for now lets put this fix / workaround behind a #ifdef then, and enable it only on the lime2 Regards, Hans