From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Mon, 21 Mar 2016 22:01:46 +0100 Subject: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2 In-Reply-To: <56F060A6.1080002@redhat.com> References: <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> <56EEF128.4020704@redhat.com> <20160321154714.GA4751@excalibur.cnev.de> <56F04437.5010205@computerlinguist.org> <56F060A6.1080002@redhat.com> Message-ID: <56F0613A.2080400@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 21-03-16 21:59, Hans de Goede wrote: > Hi, > > On 21-03-16 19:57, Michael Haas wrote: >> On 03/21/2016 04:47 PM, Karsten Merker wrote: >>>>>> 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 :) >>> At least the Olimex A20-SOM-EVB (which uses the same RTL8211CL >>> PHY) has the same issue and forcing master mode helps there as >>> well. With the above change added on top of v2016.01, I can >>> successfully boot via tftp on a gigabit link on both the Lime2 >>> and the A20-SOM-EVB, which was impossible before. >> Great news! >> >>> >>> Some quick iperf measurements on the A20-SOM-EVB with the patch >>> applied show network throughput comparable to what I get with >>> other A20-based systems. >>> >>> All my other A20-based boards - which don't have problems on >>> gigabit links - use an RTL8211E instead of the RTL8211CL. I had >>> been looking into the source of the gigabit problems on the >>> A20-SOM-EVB for a while already and talked with Olimex about >>> them. Olimex has also been trying to debug the issue and told me >>> that the problem doesn't seem to occur on all boards, and that >>> during their tests different RTL8211CL chips (i.e. same chip >>> model, but with different production date codes) behaved >>> differently. This would fit into the hypothesis that there might >>> be some kind of erratum in at least some series of the RTL8211CL. >>> >>> >> >> So, Olimex knows about these issues? :/ Perhaps you can CC your contact >> there once we have a final patch. >> >> By the way, I just searched the web for "rtl8211c master mode" and found >> this [0]: >> >> ---%-- >> >> // The EVK board with RTL8211C requires this sequence per information >> // Realtek. >> // 1. Register 0x1F, write 0005 -> Page 5 >> // 2. Register 0x0C, write 0000 >> // 3. Register 0x01, change bit [7] to 1 >> // 4. Register 0x1F, write 0000 -> Page 0 >> >> // However, please note that it is not recommended to use the RTL8211CL 125MHz clock output because >> // it is not stable when link at Slave mode. If you need the clock output, >> // please consider using RTL8211E instead. >> // 5. Force manual "master" mode in auto-negotiation. >> >> #if defined(CONFIG_DIGICOLOR_MAINBOARD_THUNDERBOLT_REV1) >> if (!RTL8211C_hack) { >> // Enable 125 Mhz clock output >> gmac_mdio_write(ei, phy_id, 0x1f, 5); >> gmac_mdio_write(ei, phy_id, 0x0c, 0); >> gmac_mdio_read (ei, phy_id, 0x01, &data); >> data |= 0x80; >> gmac_mdio_write(ei, phy_id, 0x01, data); >> gmac_mdio_write(ei, phy_id, 0x1f, 0); >> // Set Manual MASTER Mode >> gmac_mdio_read (ei, phy_id, 0x09, &data); >> data |= 0x1800; >> gmac_mdio_write(ei, phy_id, 0x09, data); >> // Restart Autonegotiation >> gmac_mdio_read (ei, phy_id, 0x00, &data); >> data |= 0x0200; >> gmac_mdio_write(ei, phy_id, 0x00, data); >> // All done now. >> RTL8211C_hack = 1; >> } >> #endif >> >> %--- >> >> >> I guess we are not the first to find this out the hard way. If the issue >> is related to an internal clock of the RTL8211C, is there perhaps an >> external clock we can use? > > Oh good catch, so I believe that we should submit a patch to the u-boot > realtek phy driver which: > > 1) Adds a seperate init function for the RTL8211C > 2) In that function set the force master mode bit and then > call the init function currently used for RTL8211C and others, > this assumes that the more generic init function will not reset > the force master mode bit. > > Good work! I believe we're quite close to a fix now :) Hmm, I just realized / read that RTL8211B and RTL8211C have the same phyid, maybe there is some other reg which we can use to differentiate between them ? Otherwise we are back to having a #ifdef for the fix ... Regards, Hans