Message ID | 20101117131429.9F55E14E646@gemini.denx.de |
---|---|
State | Superseded |
Delegated to: | Kumar Gala |
Headers | show |
Hi Zhao, > In message <1289986984-2314-1-git-send-email-b26998@freescale.com> you wrote: > > On P2020DS and MPC8572DS, the link to SGMII card which use Vitesse > > VSC8234 PHY can't come up. Current TBI PHY settings(TBICR_SETTINGS) > > for SGMII mode cause link problems. > > > > Revert commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4, and fix it. Based on my company's discussions with Freescale and Freescale's appnotes I believe that the current implementation is correct. I make reference to some of this in the original patch: http://old.nabble.com/-U-Boot---PATCH--tsec:-Force-TBI-PHY-to-1000Mbps-full-duplex-in-SGMII-mode-td26188785.html We use Broadcom PHYs on our boards, which likely has something to do with the discrepancies between the P2020DS/MPC8572DS vs the XPedite5370/XPedite5500. Unless you have additional information that shows that in-band SGMII auto-negotiation does work per the spec I'd prefer to keep the current tsec.c code and add CONFIG_TSEC_TBICR_SETTINGS workarounds to the P2020DS (already done in commit 90b5bf211b85eee10c34cbeb907ce381142b7c99?) and MPC8572DS. Best, Peter
>Subject: Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps full >duplex in SGMII mode" > >Hi Zhao, > >> In message <1289986984-2314-1-git-send-email-b26998@freescale.com> you >wrote: >> > On P2020DS and MPC8572DS, the link to SGMII card which use Vitesse >> > VSC8234 PHY can't come up. Current TBI PHY settings(TBICR_SETTINGS) >> > for SGMII mode cause link problems. >> > >> > Revert commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4, and fix it. > >Based on my company's discussions with Freescale and Freescale's appnotes >I believe that the current implementation is correct. I make reference to >some of this in the original patch: >http://old.nabble.com/-U-Boot---PATCH--tsec:-Force-TBI-PHY-to-1000Mbps- >full-duplex-in-SGMII-mode-td26188785.html > >We use Broadcom PHYs on our boards, which likely has something to do with >the discrepancies between the P2020DS/MPC8572DS vs the >XPedite5370/XPedite5500. Unless you have additional information that >shows that in-band SGMII auto-negotiation does work per the spec I'd >prefer to keep the current tsec.c code and add CONFIG_TSEC_TBICR_SETTINGS >workarounds to the P2020DS (already done in commit >90b5bf211b85eee10c34cbeb907ce381142b7c99?) and MPC8572DS. Hi Peter, From the App Note you mentioned, I didn't find that the auto-negotiation can't be used. Actually we need the auto-negotiation enabled for almost all Freescale reference boards such as P2020DS, MPC8572DS and P1/P2 RDB boards. If we disable the auto-negotiation on these boards, the SGMII link won't work. So I guess it might be more common to use auto-negotiation, and a fixed 1000M link is more like a special case. I'm not sure what's the recommended way for SGMII PHY interconnect though. - Leo
On Wed, 2010-11-17 at 21:13 -0700, Li Yang-R58472 wrote: > >Subject: Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps full > >duplex in SGMII mode" > > > >Hi Zhao, > > > >> In message <1289986984-2314-1-git-send-email-b26998@freescale.com> you > >wrote: > >> > On P2020DS and MPC8572DS, the link to SGMII card which use Vitesse > >> > VSC8234 PHY can't come up. Current TBI PHY settings(TBICR_SETTINGS) > >> > for SGMII mode cause link problems. > >> > > >> > Revert commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4, and fix it. > > > >Based on my company's discussions with Freescale and Freescale's appnotes > >I believe that the current implementation is correct. I make reference to > >some of this in the original patch: > >http://old.nabble.com/-U-Boot---PATCH--tsec:-Force-TBI-PHY-to-1000Mbps- > >full-duplex-in-SGMII-mode-td26188785.html > > > >We use Broadcom PHYs on our boards, which likely has something to do with > >the discrepancies between the P2020DS/MPC8572DS vs the > >XPedite5370/XPedite5500. Unless you have additional information that > >shows that in-band SGMII auto-negotiation does work per the spec I'd > >prefer to keep the current tsec.c code and add CONFIG_TSEC_TBICR_SETTINGS > >workarounds to the P2020DS (already done in commit > >90b5bf211b85eee10c34cbeb907ce381142b7c99?) and MPC8572DS. > > > Hi Peter, > > From the App Note you mentioned, I didn't find that the auto-negotiation can't be used. My understanding is that the SGMII link is always at 1000Mbps speed - see figure 1 from the app note. Additionally look at figure 3. My understand from it, and the app note's text is that SGMII auto-negotiation doesn't really occur - its just passing the PHY-side auto-negotiation results to the Freescale MAC, which software then configures. I'm not sure what the purpose of the "SGMII auto-negotiation" is - its not really auto-negotiating and the same information can be read from the PHY via its MDIO interface, which is what is happening on X-ES boards currently. We were told by a Freescale FAE that SGMII auto-negotiation wasn't supported, although 1000 BASE-X auto-negotation was (which mirrored our test results). I can dig up the old emails tomorrow at the office with the details. > Actually we need the auto-negotiation enabled for almost all Freescale reference boards such as P2020DS, MPC8572DS and P1/P2 RDB boards. If we disable the auto-negotiation on these boards, the SGMII link won't work. So I guess it might be more common to use auto-negotiation, and a fixed 1000M link is more like a special case. I'm not sure what's the recommended way for SGMII PHY interconnect though. And auto-negotation doesn't work on X-ES hardware which all use Broadcom PHYs - which is why I made the original change after consulting a Freescale FAE. Its not a huge deal to me either way as long as the XPedite5370 and XPedite5500 continue to not use SGMII auto-negotiation. Can someone at Freescale provide a definitive answer about what the proper SGMII auto-negotiation scheme is? And has anyone used it successfully or unsuccessfully with a non-Vitesse PHY? Best, Peter
>Subject: RE: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps >fullduplex in SGMII mode" > >On Wed, 2010-11-17 at 21:13 -0700, Li Yang-R58472 wrote: >> >Subject: Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps >> >full duplex in SGMII mode" >> > >> >Hi Zhao, >> > >> >> In message <1289986984-2314-1-git-send-email-b26998@freescale.com> >> >> you >> >wrote: >> >> > On P2020DS and MPC8572DS, the link to SGMII card which use >> >> > Vitesse >> >> > VSC8234 PHY can't come up. Current TBI PHY >> >> > settings(TBICR_SETTINGS) for SGMII mode cause link problems. >> >> > >> >> > Revert commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4, and fix it. >> > >> >Based on my company's discussions with Freescale and Freescale's >> >appnotes I believe that the current implementation is correct. I >> >make reference to some of this in the original patch: >> >http://old.nabble.com/-U-Boot---PATCH--tsec:-Force-TBI-PHY-to-1000Mbp >> >s- full-duplex-in-SGMII-mode-td26188785.html >> > >> >We use Broadcom PHYs on our boards, which likely has something to do >> >with the discrepancies between the P2020DS/MPC8572DS vs the >> >XPedite5370/XPedite5500. Unless you have additional information that >> >shows that in-band SGMII auto-negotiation does work per the spec I'd >> >prefer to keep the current tsec.c code and add >> >CONFIG_TSEC_TBICR_SETTINGS workarounds to the P2020DS (already done >> >in commit >> >90b5bf211b85eee10c34cbeb907ce381142b7c99?) and MPC8572DS. >> >> >> Hi Peter, >> >> From the App Note you mentioned, I didn't find that the auto-negotiation >can't be used. > >My understanding is that the SGMII link is always at 1000Mbps speed - see >figure 1 from the app note. Additionally look at figure 3. My understand >from it, and the app note's text is that SGMII auto-negotiation doesn't >really occur - its just passing the PHY-side auto-negotiation results to >the Freescale MAC, which software then configures. I'm not sure what the >purpose of the "SGMII auto-negotiation" is - its not really auto- >negotiating and the same information can be read from the PHY via its MDIO >interface, which is what is happening on X-ES boards currently. I guess the point is to save MDIO signals to the external PHY and read the negotiated result from the internal TBI PHY. > >We were told by a Freescale FAE that SGMII auto-negotiation wasn't >supported, although 1000 BASE-X auto-negotation was (which mirrored our >test results). I can dig up the old emails tomorrow at the office with >the details. > >> Actually we need the auto-negotiation enabled for almost all Freescale >reference boards such as P2020DS, MPC8572DS and P1/P2 RDB boards. If we >disable the auto-negotiation on these boards, the SGMII link won't >work. So I guess it might be more common to use auto-negotiation, and a >fixed 1000M link is more like a special case. I'm not sure what's the >recommended way for SGMII PHY interconnect though. > >And auto-negotation doesn't work on X-ES hardware which all use Broadcom >PHYs - which is why I made the original change after consulting a >Freescale FAE. Its not a huge deal to me either way as long as the >XPedite5370 and XPedite5500 continue to not use SGMII auto-negotiation. >Can someone at Freescale provide a definitive answer about what the proper >SGMII auto-negotiation scheme is? And has anyone used it successfully or >unsuccessfully with a non-Vitesse PHY? > >Best, >Peter
<snip> > >My understanding is that the SGMII link is always at 1000Mbps speed - see > >figure 1 from the app note. Additionally look at figure 3. My understand > >from it, and the app note's text is that SGMII auto-negotiation doesn't > >really occur - its just passing the PHY-side auto-negotiation results to > >the Freescale MAC, which software then configures. I'm not sure what the > >purpose of the "SGMII auto-negotiation" is - its not really auto- > >negotiating and the same information can be read from the PHY via its MDIO > >interface, which is what is happening on X-ES boards currently. > > I guess the point is to save MDIO signals to the external PHY and read the > negotiated result from the internal TBI PHY. Do the P2020DS, MPC8572DS and P1/P2 RDB boards not have an MDIO interface to their PHYs'? I've never heard of a board that doesn't, and would guess the tsec driver in U-Boot requires a PHY to be accessible via MDIO to use the corresponding network interface. I can forward you the email thread about SGMII auto-negotiation with Freescale's FAE off-list if you'd like as well. Best, Peter
><snip> > >> >My understanding is that the SGMII link is always at 1000Mbps speed - >> >see figure 1 from the app note. Additionally look at figure 3. My >> >understand from it, and the app note's text is that SGMII >> >auto-negotiation doesn't really occur - its just passing the PHY-side >> >auto-negotiation results to the Freescale MAC, which software then >> >configures. I'm not sure what the purpose of the "SGMII >> >auto-negotiation" is - its not really auto- negotiating and the same >> >information can be read from the PHY via its MDIO interface, which is >what is happening on X-ES boards currently. >> >> I guess the point is to save MDIO signals to the external PHY and read >> the negotiated result from the internal TBI PHY. > >Do the P2020DS, MPC8572DS and P1/P2 RDB boards not have an MDIO interface >to their PHYs'? I've never heard of a board that doesn't, and would guess >the tsec driver in U-Boot requires a PHY to be accessible via MDIO to use >the corresponding network interface. I'm not sure which specific silicon omits the MDIO signal. But quoting from the app note you mentioned: " Depending on the PowerQUICC part used, some eTSEC’s may or may not provide an external MDIO management interface. However, the TBI block for each eTSEC is associated in a one to one manner, even if that eTSEC does not have an external MDIO connection." The auto-negotiation mechanism between TBI PHY and real PHY does make it possible to save external MDIO signals if only SGMII interface is used. > >I can forward you the email thread about SGMII auto-negotiation with >Freescale's FAE off-list if you'd like as well. Yes, please. Thanks - Leo
On Fri, 2010-11-19 at 13:53 +0800, Li Yang wrote: > ><snip> > > > >> >My understanding is that the SGMII link is always at 1000Mbps speed - > >> >see figure 1 from the app note. Additionally look at figure 3. My > >> >understand from it, and the app note's text is that SGMII > >> >auto-negotiation doesn't really occur - its just passing the PHY-side > >> >auto-negotiation results to the Freescale MAC, which software then > >> >configures. I'm not sure what the purpose of the "SGMII > >> >auto-negotiation" is - its not really auto- negotiating and the same > >> >information can be read from the PHY via its MDIO interface, which is > >what is happening on X-ES boards currently. > >> > >> I guess the point is to save MDIO signals to the external PHY and read > >> the negotiated result from the internal TBI PHY. > > > >Do the P2020DS, MPC8572DS and P1/P2 RDB boards not have an MDIO interface > >to their PHYs'? I've never heard of a board that doesn't, and would guess > >the tsec driver in U-Boot requires a PHY to be accessible via MDIO to use > >the corresponding network interface. > > I'm not sure which specific silicon omits the MDIO signal. But quoting from > the app note you mentioned: > > " Depending on the PowerQUICC part used, some eTSEC’s may or may not > provide an external > MDIO management interface. However, the TBI block for each eTSEC is > associated in a one to one > manner, even if that eTSEC does not have an external MDIO connection." I believe some parts don't have an external MDIO interface for every eTSEC. if my memory is correct the MPC8572 only has 2 MDIO ports and 3 eTSECS. But 1 MDIO port can be used to communicate with all 3 eTSECS' PHYs assuming each PHY has a unique address. (eg eTSEC1, 2, and 3 use eTSEC1's MDIO port). > The auto-negotiation mechanism between TBI PHY and real PHY does make > it possible > to save external MDIO signals if only SGMII interface is used. That seems like an awfully big sacrifice to save routing 2 signals. I've never heard of anyone doing this. I don't think the current tsec driver in U-Boot would support this configuration either, so I'm not sure how much weight it holds. > >I can forward you the email thread about SGMII auto-negotiation with > >Freescale's FAE off-list if you'd like as well. > > Yes, please. Thanks I just forwarded it. Best, Peter
On Nov 17, 2010, at 11:01 PM, Peter Tyser wrote: > On Wed, 2010-11-17 at 21:13 -0700, Li Yang-R58472 wrote: >>> Subject: Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps full >>> duplex in SGMII mode" >>> >>> Hi Zhao, >>> >>>> In message <1289986984-2314-1-git-send-email-b26998@freescale.com> you >>> wrote: >>>>> On P2020DS and MPC8572DS, the link to SGMII card which use Vitesse >>>>> VSC8234 PHY can't come up. Current TBI PHY settings(TBICR_SETTINGS) >>>>> for SGMII mode cause link problems. >>>>> >>>>> Revert commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4, and fix it. >>> >>> Based on my company's discussions with Freescale and Freescale's appnotes >>> I believe that the current implementation is correct. I make reference to >>> some of this in the original patch: >>> http://old.nabble.com/-U-Boot---PATCH--tsec:-Force-TBI-PHY-to-1000Mbps- >>> full-duplex-in-SGMII-mode-td26188785.html >>> >>> We use Broadcom PHYs on our boards, which likely has something to do with >>> the discrepancies between the P2020DS/MPC8572DS vs the >>> XPedite5370/XPedite5500. Unless you have additional information that >>> shows that in-band SGMII auto-negotiation does work per the spec I'd >>> prefer to keep the current tsec.c code and add CONFIG_TSEC_TBICR_SETTINGS >>> workarounds to the P2020DS (already done in commit >>> 90b5bf211b85eee10c34cbeb907ce381142b7c99?) and MPC8572DS. >> >> >> Hi Peter, >> >> From the App Note you mentioned, I didn't find that the auto-negotiation can't be used. > > My understanding is that the SGMII link is always at 1000Mbps speed - > see figure 1 from the app note. Additionally look at figure 3. My > understand from it, and the app note's text is that SGMII > auto-negotiation doesn't really occur - its just passing the PHY-side > auto-negotiation results to the Freescale MAC, which software then > configures. I'm not sure what the purpose of the "SGMII > auto-negotiation" is - its not really auto-negotiating and the same > information can be read from the PHY via its MDIO interface, which is > what is happening on X-ES boards currently. > > We were told by a Freescale FAE that SGMII auto-negotiation wasn't > supported, although 1000 BASE-X auto-negotation was (which mirrored our > test results). I can dig up the old emails tomorrow at the office with > the details. > >> Actually we need the auto-negotiation enabled for almost all Freescale reference boards such as P2020DS, MPC8572DS and P1/P2 RDB boards. If we disable the auto-negotiation on these boards, the SGMII link won't work. So I guess it might be more common to use auto-negotiation, and a fixed 1000M link is more like a special case. I'm not sure what's the recommended way for SGMII PHY interconnect though. > > And auto-negotation doesn't work on X-ES hardware which all use Broadcom > PHYs - which is why I made the original change after consulting a > Freescale FAE. Its not a huge deal to me either way as long as the > XPedite5370 and XPedite5500 continue to not use SGMII auto-negotiation. > Can someone at Freescale provide a definitive answer about what the > proper SGMII auto-negotiation scheme is? And has anyone used it > successfully or unsuccessfully with a non-Vitesse PHY? So I believe we do in-band autoneg, it just doesn't convey all the way back as you'd expect. We've also see Marvell PHYs work in SGMII mode. I'm going to go back to the way it was and explicitly set CONFIG_TSEC_TBICR_SETTINGS in xpedite537x.h & xpedite550x.h - k
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index 9b5dd92..c205a7e 100644 --- a/drivers/net/tsec.c +++ b/drivers/net/tsec.c @@ -292,13 +292,11 @@ static uint tsec_local_mdio_read(volatile tsec_mdio_t *phyregs, /* By default force the TBI PHY into 1000Mbps full duplex when in SGMII mode */ #ifndef CONFIG_TSEC_TBICR_SETTINGS -#define TBICR_SETTINGS ( \ +#define CONFIG_TSEC_TBICR_SETTINGS ( \ TBICR_PHY_RESET \ | TBICR_FULL_DUPLEX \ | TBICR_SPEED1_SET \ ) -#else -#define TBICR_SETTINGS CONFIG_TSEC_TBICR_SETTINGS #endif /* CONFIG_TSEC_TBICR_SETTINGS */ /* Configure the TBI for SGMII operation */ @@ -311,7 +309,7 @@ static void tsec_configure_serdes(struct tsec_private *priv) tsec_local_mdio_write(priv->phyregs_sgmii, priv->regs->tbipa, TBI_TBICON, TBICON_CLK_SELECT); tsec_local_mdio_write(priv->phyregs_sgmii, priv->regs->tbipa, TBI_CR, - TBICR_SETTINGS); + CONFIG_TSEC_TBICR_SETTINGS); } /* Discover which PHY is attached to the device, and configure it