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

[Hans de Goede]

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.

Are any other sunxi boards impacted by the same problem that you know ?

Regards,

Hans