Re: [U-Boot] [PATCH] Add CONFIG_GMAC_TX_DELAY=4 for OlinuXino Lime2
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?
[0] http://mydc-proj.googlecode.com/svn/trunk/linux/target/u-boot/2010.09-cnxt/b...
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
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:
- Adds a seperate init function for the RTL8211C
- 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
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
The BSD people seem to key off a revision field, which has value 3 for the rtl8211c:
https://lists.freebsd.org/pipermail/svn-src-stable-9/2015-March/007669.html
Excuse the bad quoting, I am on mobile and the client is broken.
Hi,
On 21-03-16 22:47, Michael Haas wrote:
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
The BSD people seem to key off a revision field, which has value 3 for the rtl8211c:
https://lists.freebsd.org/pipermail/svn-src-stable-9/2015-March/007669.html
And another good catch, yes that looks like it should work.
Now all we need to do is turn all this info into a proper patch.
Regards,
Hans
On 03/21/2016 11:00 PM, Hans de Goede wrote:
Hi,
On 21-03-16 22:47, Michael Haas wrote:
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
The BSD people seem to key off a revision field, which has value 3 for the rtl8211c:
https://lists.freebsd.org/pipermail/svn-src-stable-9/2015-March/007669.html
And another good catch, yes that looks like it should work.
Now all we need to do is turn all this info into a proper patch.
Regards,
Hans
I'm going to work on that. I'd like to have the bragging rights for having a patch in Das U-Boot :)
Michael
"Hans" == Hans de Goede hdegoede@redhat.com writes:
Hi,
Oh good catch, so I believe that we should submit a patch to the u-boot realtek phy driver which:
- Adds a seperate init function for the RTL8211C
- 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.
So what happens if you connect two of these boards together without a switch in between? Will they be able to autonegotiate?
Hi,
On 22-03-16 09:46, Peter Korsgaard wrote:
"Hans" == Hans de Goede hdegoede@redhat.com writes:
Hi,
Oh good catch, so I believe that we should submit a patch to the u-boot realtek phy driver which:
- Adds a seperate init function for the RTL8211C
- 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.
So what happens if you connect two of these boards together without a switch in between? Will they be able to autonegotiate?
Likely not, but without this fix, they would and they would have an unreliable connection. Arguably no connection is better then an unreliable one.
Regards,
Hans
Am 22. März 2016 09:57:16 MEZ, schrieb Hans de Goede hdegoede@redhat.com:
Hi,
On 22-03-16 09:46, Peter Korsgaard wrote:
> "Hans" == Hans de Goede hdegoede@redhat.com writes:
Hi,
Oh good catch, so I believe that we should submit a patch to the
u-boot
realtek phy driver which:
- Adds a seperate init function for the RTL8211C
- 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.
So what happens if you connect two of these boards together without a switch in between? Will they be able to autonegotiate?
Likely not, but without this fix, they would and they would have an unreliable connection. Arguably no connection is better then an unreliable one.
Regards,
Hans
I assume that forcing the link to 100mbps would work for this case. After all, the fix should only apply for GBit mode.
"Hans" == Hans de Goede hdegoede@redhat.com writes:
So what happens if you connect two of these boards together without a switch in between? Will they be able to autonegotiate?
Likely not, but without this fix, they would and they would have an unreliable connection. Arguably no connection is better then an unreliable one.
True.
participants (3)
-
Hans de Goede -
Michael Haas -
Peter Korsgaard