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