Skip to contentSkip to conversation

Link problem with eTSEC2 on P2020RDB

U-Boot Felix Radensky 5 participants 8 messages Jun 22, 2010 – Jun 29, 2010

lore
Share & tools
lore

Felix Radensky

author
#0 lore raw

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 <[email protected]>
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.

#1 lore raw

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?

Quoted 16 lines · Felix Radensky

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

Quoted 10 lines
Author: Peter Tyser <[email protected]>
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.

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich

#2 lore raw
In reply to Felix Radensky
Quoted 23 lines

-----Original Message-----
From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at 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 at 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:

Quoted 9 lines

46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4 is first bad commit commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4

Author: Peter Tyser <[email protected]>
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.

Hello Peter
Do we need to make any changes in P2020RDB port to make SGMII port work?
Kind Regards
Poonam

Quoted 7 lines

Felix.

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

author
#3 lore raw
In reply to Felix Radensky

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.

Quoted 31 lines · Felix Radensky

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 <[email protected]>
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.

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

#4 lore raw

Hi Felix,

Quoted 6 lines · Felix Radensky

Hi Ben,

Peter Tyser seems to be OOO until Monday, so maybe you can comment on this problem,
as it's network related.

Quoted 8 lines

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 ?

Quoted 2 lines

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

Quoted 3 lines

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

author
#5 lore raw

Hi Ben,

Quoted 20 lines · Ben Warren

Hi Felix,

On Fri, Jun 25, 2010 at 4:33 AM, Felix Radensky
<felix at embedded-sol.com <mailto:[email protected]>> 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.

Quoted 5 lines

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.

Quoted 15 lines

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

Quoted 7 lines

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.

#6 lore raw
In reply to Ben Warren

Hi Felix,

Quoted 18 lines

On Fri, Jun 25, 2010 at 4:33 AM, Felix Radensky
<[email protected]> 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.

Quoted 1 line

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.

Quoted 15 lines

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 \
                )
Quoted 4 lines

#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

author
#7 lore raw

Hi Peter,

Quoted 11 lines · Peter Tyser

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.

Quoted 19 lines
Quoted 15 lines

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 \
                 )
Quoted 4 lines

#else
#define TBICR_SETTINGS CONFIG_TSEC_TBICR_SETTINGS
#endif
Thanks.

Quoted 3 lines

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.