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

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

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 :)

Regards,

Hans