[U-Boot] Link problem with eTSEC2 on P2020RDB
Hi,
eTSEC2 is unusable with TOT master on P2020RDB RevC. The following example demonstrates the problem:
=> setenv ethact eTSEC2 => ping 10.0.0.10 Waiting for PHY auto negotiation to complete...... TIMEOUT ! eTSEC2: No link.
eTSEC2 on P2020RDB is connected to Vitesse SGMII PHY VSC8221.
Git bisect shows that the problem was introduced by the following commit:
46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4 is first bad commit commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4 Author: Peter Tyser ptyser@xes-inc.com Date: Tue Nov 3 17:52:07 2009 -0600
tsec: Force TBI PHY to 1000Mbps full duplex in SGMII mode
Reverting this commit makes the problem go away.
Felix.
Felix,
nice to hear that your problem is fixed.
Since I'm using VSC8601 PHY with RGMII interface this looks like a different issue.
Cheers, André
On Tue, 2010-06-22 at 23:04 +0300, Felix Radensky wrote:
Hi,
eTSEC2 is unusable with TOT master on P2020RDB RevC. The following example demonstrates the problem:
=> setenv ethact eTSEC2 => ping 10.0.0.10 Waiting for PHY auto negotiation to complete...... TIMEOUT ! eTSEC2: No link.
eTSEC2 on P2020RDB is connected to Vitesse SGMII PHY VSC8221.
Git bisect shows that the problem was introduced by the following commit:
46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4 is first bad commit commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4 Author: Peter Tyser ptyser@xes-inc.com Date: Tue Nov 3 17:52:07 2009 -0600
tsec: Force TBI PHY to 1000Mbps full duplex in SGMII modeReverting this commit makes the problem go away.
Felix.
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Felix Radensky Sent: Wednesday, June 23, 2010 1:34 AM To: U-Boot-Denx; André Schwarz; Kumar Gala; ptyser@xes-inc.com Subject: [U-Boot] Link problem with eTSEC2 on P2020RDB
Hi,
eTSEC2 is unusable with TOT master on P2020RDB RevC. The following example demonstrates the problem:
=> setenv ethact eTSEC2 => ping 10.0.0.10 Waiting for PHY auto negotiation to complete...... TIMEOUT ! eTSEC2: No link.
eTSEC2 on P2020RDB is connected to Vitesse SGMII PHY VSC8221.
Git bisect shows that the problem was introduced by the following commit:
46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4 is first bad commit commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4 Author: Peter Tyser ptyser@xes-inc.com Date: Tue Nov 3 17:52:07 2009 -0600
tsec: Force TBI PHY to 1000Mbps full duplex in SGMII modeReverting this commit makes the problem go away.
Hello Peter Do we need to make any changes in P2020RDB port to make SGMII port work? Kind Regards Poonam
Felix.
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Ben,
Peter Tyser seems to be OOO until Monday, so maybe you can comment on this problem, as it's network related.
Peter's patch comes to fix a problem with ethernet not working on XES 8572 board using BCM5482S PHY in SGMII mode. On the other hand it breaks eTSEC2 on P2020RDB board using VSC8211 PHY in SGMII mode. On P2020RDB not only u-boot, but also Linux cannot use eTSEC2.
Do you have any suggestions how to make both boards happy ?
Thanks.
Felix. Felix Radensky wrote:
Hi,
eTSEC2 is unusable with TOT master on P2020RDB RevC. The following example demonstrates the problem:
=> setenv ethact eTSEC2 => ping 10.0.0.10 Waiting for PHY auto negotiation to complete...... TIMEOUT ! eTSEC2: No link.
eTSEC2 on P2020RDB is connected to Vitesse SGMII PHY VSC8221.
Git bisect shows that the problem was introduced by the following commit:
46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4 is first bad commit commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4 Author: Peter Tyser ptyser@xes-inc.com Date: Tue Nov 3 17:52:07 2009 -0600
tsec: Force TBI PHY to 1000Mbps full duplex in SGMII modeReverting this commit makes the problem go away.
Felix.
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Felix,
On Fri, Jun 25, 2010 at 4:33 AM, Felix Radensky felix@embedded-sol.comwrote:
Hi Ben,
Peter Tyser seems to be OOO until Monday, so maybe you can comment on this problem, as it's network related.
Peter's patch comes to fix a problem with ethernet not working on XES 8572 board using BCM5482S PHY in SGMII mode. On the other hand it breaks eTSEC2 on P2020RDB board using VSC8211 PHY in SGMII mode. On P2020RDB not only u-boot, but also Linux cannot use eTSEC2.
Do you have any suggestions how to make both boards happy ?
I'm not familiar with how SGMII is configured on this controller, but it
appears that Peter's patch turned of Autonegotiation. Why this would make a PHY work and a switch not work is curious... Maybe we should have a CONFIG option for SGMII parameters. Settings could default to the ones Peter set (since he submitted it in November and problems are surfacing now), but could be overriden. Does that sound reasonable? Something like:
#ifndef CONFIG TSEC_TBICR_SETTINGS
#define TBICR_SETTINGS ( \ TBICR_PHY_RESET \ | TBICR_FULL_DUPLEX \ | TBICR_SPEED1_SET \ )
#else
#define TBICR_SETTINGS CONFIG_TSEC_TBICR_SETTINGS
#endif
Thanks.
Felix.
If you put together a patch that does this and test it on your board, that should be good enough. Peter can try it out when he gets back.
regards, Ben
Hi Ben,
On 6/26/2010 8:22 AM, Ben Warren wrote:
Hi Felix,
On Fri, Jun 25, 2010 at 4:33 AM, Felix Radensky <felix@embedded-sol.com mailto:felix@embedded-sol.com> wrote:
Hi Ben, Peter Tyser seems to be OOO until Monday, so maybe you can comment on this problem, as it's network related. Peter's patch comes to fix a problem with ethernet not working on XES 8572 board using BCM5482S PHY in SGMII mode. On the other hand it breaks eTSEC2 on P2020RDB board using VSC8211 PHY in SGMII mode. On P2020RDB not only u-boot, but also Linux cannot use eTSEC2. Do you have any suggestions how to make both boards happy ?I'm not familiar with how SGMII is configured on this controller, but it appears that Peter's patch turned of Autonegotiation. Why this would make a PHY work and a switch not work is curious...
VSC8211 on P2020RDB is a PHY, not a switch. There can be some SGMII related problem in MPC8572 that was fixed in P2020, but it's just a wild guess.
Maybe we should have a CONFIG option for SGMII parameters. Settings could default to the ones Peter set (since he submitted it in November and problems are surfacing now), but could be overriden. Does that sound reasonable? Something like:
#ifndef CONFIG TSEC_TBICR_SETTINGS #define TBICR_SETTINGS ( \ TBICR_PHY_RESET \ | TBICR_FULL_DUPLEX \ | TBICR_SPEED1_SET \ ) #else #define TBICR_SETTINGS CONFIG_TSEC_TBICR_SETTINGS #endif
Thanks. Felix.If you put together a patch that does this and test it on your board, that should be good enough. Peter can try it out when he gets back.
I'll create a patch based on your suggestion later today or tomorrow and test it on P2020RDB and P1020RDB.
Felix.
Hi Felix,
On Fri, Jun 25, 2010 at 4:33 AM, Felix Radensky felix@embedded-sol.com wrote: Hi Ben,
Peter Tyser seems to be OOO until Monday, so maybe you can comment on this problem, as it's network related. Peter's patch comes to fix a problem with ethernet not working on XES 8572 board using BCM5482S PHY in SGMII mode. On the other hand it breaks eTSEC2 on P2020RDB board using VSC8211 PHY in SGMII mode. On P2020RDB not only u-boot, but also Linux cannot use eTSEC2. Do you have any suggestions how to make both boards happy ?
My company talked with a Freescale field application engineer about this issue quite a bit a while back, and the application note at http://www.freescale.com/files/32bit/doc/app_note/AN3869.pdf also provides some good info. I can forward relevant snippets of the discussion with the Freescale FAE when I get back into the office on Monday. For reference, we are using the BCM5482S PHY connected to a MPC8572 via SMGII, with both copper and fiber interfaces on the remote side of the PHY.
In any case, our testing and the Freescale FAE's input showed that in-band auto-negotiation on the SGMII interface didn't work, thus I submitted the change you referenced. If my memory is correct, empirically it looked like the MPC8572 did support 1000 base-X auto-negotiation, but not SGMII auto-negotiation. Can you validate you're using SGMII and not 1000 base-X to connect the P2020 to the VSC8211 PHY? A simple way to test this should be to connect the VSC8211 to a 100 mpbs switch - this should work fine via SGMII but not 1000 base-X (assuming you're using a copper interface).
Unfortunately our newer P2020 products don't use SGMII interfaces so I can't investigate the differences between the P2020 vs MPC8572.
I'm not familiar with how SGMII is configured on this controller, but it appears that Peter's patch turned of Autonegotiation. Why this would make a PHY work and a switch not work is curious... Maybe we should have a CONFIG option for SGMII parameters. Settings could default to the ones Peter set (since he submitted it in November and problems are surfacing now), but could be overriden. Does that sound reasonable? Something like:
#ifndef CONFIG TSEC_TBICR_SETTINGS #define TBICR_SETTINGS ( \ TBICR_PHY_RESET \ | TBICR_FULL_DUPLEX \ | TBICR_SPEED1_SET \ ) #else #define TBICR_SETTINGS CONFIG_TSEC_TBICR_SETTINGS #endif Thanks.
This solution is fine by me. I'd be curious if anyone at Freescale has a definitive answer about SGMII and auto-negotiation. I'm happy to try any patch on Monday
Best, Peter
Hi Peter,
On 6/26/2010 4:19 PM, Peter Tyser wrote:
Hi Felix,
In any case, our testing and the Freescale FAE's input showed that in-band auto-negotiation on the SGMII interface didn't work, thus I submitted the change you referenced. If my memory is correct, empirically it looked like the MPC8572 did support 1000 base-X auto-negotiation, but not SGMII auto-negotiation. Can you validate you're using SGMII and not 1000 base-X to connect the P2020 to the VSC8211 PHY? A simple way to test this should be to connect the VSC8211 to a 100 mpbs switch - this should work fine via SGMII but not 1000 base-X (assuming you're using a copper interface).
I'm definitely using SGMII with eTSEC2. This is documented in board user manual. Also, eTSEC2 works when connected to 100 mbps switch.
I'm not familiar with how SGMII is configured on this controller, but it appears that Peter's patch turned of Autonegotiation. Why this would make a PHY work and a switch not work is curious... Maybe we should have a CONFIG option for SGMII parameters. Settings could default to the ones Peter set (since he submitted it in November and problems are surfacing now), but could be overriden. Does that sound reasonable? Something like:
#ifndef CONFIG TSEC_TBICR_SETTINGS #define TBICR_SETTINGS ( \ TBICR_PHY_RESET \ | TBICR_FULL_DUPLEX \ | TBICR_SPEED1_SET \ ) #else #define TBICR_SETTINGS CONFIG_TSEC_TBICR_SETTINGS #endif Thanks.
This solution is fine by me. I'd be curious if anyone at Freescale has a definitive answer about SGMII and auto-negotiation. I'm happy to try any patch on Monday
I've posted a patch, see http://lists.denx.de/pipermail/u-boot/2010-June/073208.html
Can you please test it ?
Thanks.
Felix.
participants (5)
-
Aggrwal Poonam-B10812 -
André Schwarz -
Ben Warren -
Felix Radensky -
Peter Tyser