[U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2

[Michael Haas <haas@computerlinguist.org>]

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