Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps fullduplex in SGMII mode"
On Fri, 2010-11-19 at 13:53 +0800, Li Yang wrote: > > > > > >> >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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps fullduplex in SGMII mode"
> > >> >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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps fullduplex in SGMII mode"
> >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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps fullduplex in SGMII mode"
>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-b26...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
