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
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 v2 1/2] 85xx/mpc8536ds: Use is_serdes_configured()to determine of PCIe enabled
>>Subject: [U-Boot] [PATCH v2 1/2] 85xx/mpc8536ds: Use >>is_serdes_configured()to determine of PCIe enabled >> >>The new is_serdes_configured covers a broader range of >devices than the >>PCI specific code. Use it instead as we convert away from the >>is_fsl_pci_cfg() code. >> >>Additionally move to setting LAWs for PCI based on if its configured. >>Also updated PCI FDT fixup code to remove PCI controllers from dtb if >>they are configured. >> >>Signed-off-by: Kumar Gala >>--- >>* Added code to handle dynamic LAW setup for PCI >>* Added removing of PCI controller nodes from dtb if not cfg >> >> arch/powerpc/cpu/mpc8xxx/pci_cfg.c| 12 >> board/freescale/mpc8536ds/law.c |8 >> board/freescale/mpc8536ds/mpc8536ds.c | 33 >>+ > >Wouldn't it be better to share the PCIE initialization code >through all the MPC85xx boards? Like in the P2020 serdes >patch series I proposed last year. What do you think? The patch can be referenced at http://www.mail-archive.com/u-boot@lists.denx.de/msg26339.html - Leo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] 85xx/mpc8536ds: Use is_serdes_configured()to determine of PCIe enabled
>Subject: [U-Boot] [PATCH v2 1/2] 85xx/mpc8536ds: Use >is_serdes_configured()to determine of PCIe enabled > >The new is_serdes_configured covers a broader range of devices than the >PCI specific code. Use it instead as we convert away from the >is_fsl_pci_cfg() code. > >Additionally move to setting LAWs for PCI based on if its configured. >Also updated PCI FDT fixup code to remove PCI controllers from dtb if >they are configured. > >Signed-off-by: Kumar Gala >--- >* Added code to handle dynamic LAW setup for PCI >* Added removing of PCI controller nodes from dtb if not cfg > > arch/powerpc/cpu/mpc8xxx/pci_cfg.c| 12 > board/freescale/mpc8536ds/law.c |8 > board/freescale/mpc8536ds/mpc8536ds.c | 33 >+ Wouldn't it be better to share the PCIE initialization code through all the MPC85xx boards? Like in the P2020 serdes patch series I proposed last year. What do you think? - Leo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] 85xx: Add is_serdes_configured() support toMPC8536 SERDES
>Subject: [U-Boot] [PATCH 2/4] 85xx: Add is_serdes_configured() >support toMPC8536 SERDES > >Add the ability to determine if a given IP block connected on SERDES is >configured. This is useful for things like PCIe and SRIO >since they are >only ever connected on SERDES. > >Signed-off-by: Kumar Gala >--- > arch/ppc/cpu/mpc85xx/mpc8536_serdes.c | 79 >++-- > arch/ppc/include/asm/fsl_serdes.h | 53 +- The header change is already in the P2020 serdes patch series. Would you help to merge that patch series and deal with the conflict also? Thanks, Leo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Patch status update
{snip}
>5438 12/10 Li Yang[U-Boot] [PATCH 1/5] fdt: add
>fdt_del_node_by_path() API
>
>http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72559
>5440 12/10 Li Yang[U-Boot] [PATCH 3/5] 85xx: add
>common serdes ports configuration code
>
>http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72557
>5441 12/10 Li Yang[U-Boot] [PATCH 4/5] p2020: add
>serdes status code complying to fsl_serdes APIs
>
>http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72560
>5442 12/10 Li Yang[U-Boot] [PATCH 5/5] p2020ds:
>use common code to initialize serdes ports
>
>http://article.gmane.org/gmane.comp.boot-loaders.u-boot/72561
Hi Kumar,
I got no feedback on this series for almost 2 months. Do you have
further comment?
- Leo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] p2020ds: use maximum timeout for esdhc
>On Jan 7, 2010, at 2:00 AM, Li Yang wrote: > >> From: Jin Qing >> >> Use timeout value to maximum due to hardware problem. The hardware >> may take longer to timeout, but it's much better than having >a too-short timeout value. >> >> Signed-off-by: Jin Qing >> Signed-off-by: Li Yang >> --- >> drivers/mmc/fsl_esdhc.c |4 >> include/configs/P2020DS.h |1 + >> 2 files changed, 5 insertions(+), 0 deletions(-) > >Is this associated with an errata on P2020, a board issue? I'm not very sure. Looks like a silicon issue. We are using the same workaround as in kernel. - Leo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] fdt: add fdt_del_node_by_path() API
>Subject: Re: [U-Boot] [PATCH 2/3] fdt: add fdt_del_node_by_path() API > >Dear "Li Yang-R58472", > >In message ><3a45394fd742fa419b760bb8d398f9ede66...@zch01exm26.fsl.freescal >e.net> you wrote: >> >> It will be used in patches to be submitted, we want to remove the >> nodes of devices which are not enabled depending on the >board configuration. > >The rule is that we don't add dead code, so this patch should >be part of a patch series that also adds users of this new code. All right. I will include this in the patch series to come. - Leo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] fdt: add fdt_del_node_by_path() API
>Subject: Re: [U-Boot] [PATCH 2/3] fdt: add fdt_del_node_by_path() API
>
>Hi Li,
>
>Li Yang wrote:
>> For removing node easily by path or alias.
>>
>> Signed-off-by: Li Yang
>> ---
>> common/fdt_support.c | 10 ++
>> include/fdt_support.h |1 +
>> 2 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/common/fdt_support.c b/common/fdt_support.c index
>> f89a3ee..8f1186e 100644
>> --- a/common/fdt_support.c
>> +++ b/common/fdt_support.c
>> @@ -757,3 +757,13 @@ int fdt_fixup_nor_flash_size(void
>*blob, int cs, u32 size)
>> return -1;
>> }
>> #endif
>> +
>> +int fdt_del_node_by_path(void *fdt, const char *path) {
>> +int off = fdt_path_offset(fdt, path);
>> +
>> +if (off >= 0)
>> +return fdt_del_node(fdt, off);
>> +else
>> +return off;
>> +}
>> diff --git a/include/fdt_support.h b/include/fdt_support.h index
>> 0a9dd0d..d0705d1 100644
>> --- a/include/fdt_support.h
>> +++ b/include/fdt_support.h
>> @@ -80,6 +80,7 @@ void set_working_fdt_addr(void *addr); int
>> fdt_resize(void *blob);
>>
>> int fdt_fixup_nor_flash_size(void *blob, int cs, u32 size);
>> +int fdt_del_node_by_path(void *fdt, const char *path);
>>
>> #endif /* ifdef CONFIG_OF_LIBFDT */
>> #endif /* ifndef __FDT_SUPPORT_H */
>
>This seems like a reasonable function, but I don't see it used
>anywhere?
It will be used in patches to be submitted, we want to remove the nodes
of devices which are not enabled depending on the board configuration.
- Leo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] Update Makefile for new dirs to be included in tag list
>Subject: Re: [U-Boot] [PATCH 1/3] Update Makefile for new dirs >to be included in tag list > >Dear Li Yang, > >In message ><1260339968-28169-1-git-send-email-le...@freescale.com> you wrote: >> Signed-off-by: Li Yang >> --- >> Makefile |3 +++ >> 1 files changed, 3 insertions(+), 0 deletions(-) >> >> diff --git a/Makefile b/Makefile >> index bcb3fe9..4d71366 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -406,6 +406,8 @@ TAG_SUBDIRS += include TAG_SUBDIRS += >lib_generic >> board/$(BOARDDIR) TAG_SUBDIRS += cpu/$(CPU) TAG_SUBDIRS += >> lib_$(ARCH) >> +TAG_SUBDIRS += $(shell if [ -d board/$(VENDOR)/common ]; then echo \ >> +"board/$(VENDOR)/common"; fi) > >Would it not be easier to do something like > > TAG_SUBDIRS = $(dir $(LIBS)) Should be $(__LIBS) > >and get rid of all these duplicated settings? Great idea! I will come up a patch. - Leo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
