[U-Boot] Link problem with eTSEC2 on P2020RDB

[U-Boot] Link problem with eTSEC2 on P2020RDB

[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 <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.

[U-Boot] Link problem with eTSEC2 on P2020RDB

[André Schwarz]

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

[U-Boot] Link problem with eTSEC2 on P2020RDB

[Aggrwal Poonam-B10812]

> -----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:
> 
> 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.
>
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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Link problem with eTSEC2 on P2020RDB

[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.
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 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
>   

[U-Boot] Link problem with eTSEC2 on P2020RDB

[Ben Warren]

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 ?
>
> 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

[U-Boot] Link problem with eTSEC2 on P2020RDB

[Felix Radensky]

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 at 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.

[U-Boot] Link problem with eTSEC2 on P2020RDB

[Peter Tyser]

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

[U-Boot] Link problem with eTSEC2 on P2020RDB

[Felix Radensky]

  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.