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

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

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