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

[Hans de Goede <hdegoede@redhat.com>]

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