Re: [U-Boot] [PATCH] revert tsec: Force TBI PHY to 1000Mbps full duplex in SGMII mode
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-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-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 ___ 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 full duplex in SGMII mode
On Wednesday, November 17, 2010 04:43:04 Zhao Chenhui 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. revert and fix is not a revert. the summary you used is reserved for pure reverts of commits which this is not that. so fix your summary or split the changes into two commits. -mike signature.asc Description: This is a digitally signed message part. ___ 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 full duplex in SGMII mode
Dear Zhao Chenhui, 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. This patch description is wrong, as you do not simply revert that patch. Instead, you modify the code, shifting the setting from a geric one into a XPEDITE5370 specific one. When doing so, you should at least put the respective board maintainer on CC. I understand your patch was not even tested on the XPEDITE5370 board? But actually I think your approach is wrong - Peter's solution looks reasobanle to me. When your boards with a specific PHY have problems, then your boards should add appropriate CONFIG_TSEC_TBICR_SETTINGS to their board config files. If you insist in changing this code, you might as well clean it up a bit, like that: 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 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de An Elephant is a mouse with an Operating System. - Knuth ___ 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 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-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 ___ 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 full duplex in SGMII mode
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-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 ___ 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 full duplex 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-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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
