[U-Boot] [PATCH] ARM: mxs: Do not reconfigure FEC clock in FEC init
Stefano Babic
sbabic at denx.de
Mon Oct 14 10:34:25 CEST 2013
Hi Marek,
On 13/10/2013 17:20, Marek Vasut wrote:
> Do not reconfigure the FEC clock during board_eth_init(), otherwise
> the FEC might have stability issues, refuse to autonegotiate link
> entirely or even corrupt packets while indicating correct checksum
> on them. Instead, move the FEC clock init to board_early_init_f(),
> where all the other upstream clock are initialized and also make
> sure there is proper stabilization delay.
However, it seems to me that moving the code remove the problem on the
mx28evk without finding the cause. Really there is still a big chunk of
time between the initialization of the clock and the first packet is
sent to the network, when the autonegotiation should occur.
>
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Fabio Estevam <fabio.estevam at freescale.com>
> Cc: Hector Palacios <hector.palacios at digi.com>
> Cc: Oliver Metz <oliver at freetz.org>
> Cc: Otavio Salvador <otavio at ossystems.com.br>
> Cc: Stefano Babic <sbabic at denx.de>
> Cc: Tom Rini <trini at ti.com>
> ---
> board/bluegiga/apx4devkit/apx4devkit.c | 10 ++++------
> board/denx/m28evk/m28evk.c | 21 +++++++++++----------
> board/freescale/mx28evk/mx28evk.c | 9 +++++----
> board/schulercontrol/sc_sps_1/sc_sps_1.c | 19 +++++++++++--------
> 4 files changed, 31 insertions(+), 28 deletions(-)
>
> NOTE: I'd like to get this into current release as it fixes a serious
> issue I observe here on the MX28EVK (packets being corrupted on
> long transfers initiated early after boot). Please test this and
> report back ASAP.
>
> diff --git a/board/bluegiga/apx4devkit/apx4devkit.c b/board/bluegiga/apx4devkit/apx4devkit.c
> index 08e79bd..044a182 100644
> --- a/board/bluegiga/apx4devkit/apx4devkit.c
> +++ b/board/bluegiga/apx4devkit/apx4devkit.c
> @@ -39,6 +39,10 @@ int board_early_init_f(void)
> /* SSP0 clock at 96MHz */
> mxs_set_sspclk(MXC_SSPCLK0, 96000, 0);
>
> +#ifdef CONFIG_CMD_NET
> + cpu_eth_init(NULL);
> + udelay(10000);
> +#endif
This looks like a hack...
Calling cpu_eth_init() without parameters is absolutely an exception in
u-boot, there is no other instance / SOC doing this.
Are we sure that the issue you see on mx28evk are reproducible on the
other boards ? You are starting to fix all boards, but you report
corruption only on one board.
> return 0;
> }
>
> @@ -79,12 +83,6 @@ int board_eth_init(bd_t *bis)
> int ret;
> struct eth_device *dev;
>
> - ret = cpu_eth_init(bis);
> - if (ret) {
> - printf("FEC MXS: Unable to init FEC clocks\n");
> - return ret;
> - }
> -
> ret = fecmxc_initialize(bis);
> if (ret) {
> printf("FEC MXS: Unable to init FEC\n");
> diff --git a/board/denx/m28evk/m28evk.c b/board/denx/m28evk/m28evk.c
> index 33d38cf..5065ee8 100644
> --- a/board/denx/m28evk/m28evk.c
> +++ b/board/denx/m28evk/m28evk.c
> @@ -26,6 +26,9 @@ DECLARE_GLOBAL_DATA_PTR;
> */
> int board_early_init_f(void)
> {
> + struct mxs_clkctrl_regs *clkctrl_regs =
> + (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
> +
> /* IO0 clock at 480MHz */
> mxs_set_ioclk(MXC_IOCLK0, 480000);
> /* IO1 clock at 480MHz */
> @@ -36,6 +39,14 @@ int board_early_init_f(void)
> /* SSP2 clock at 160MHz */
> mxs_set_sspclk(MXC_SSPCLK2, 160000, 0);
>
> +#ifdef CONFIG_CMD_NET
> + cpu_eth_init(NULL);
> + clrsetbits_le32(&clkctrl_regs->hw_clkctrl_enet,
> + CLKCTRL_ENET_TIME_SEL_MASK | CLKCTRL_ENET_CLK_OUT_EN,
> + CLKCTRL_ENET_TIME_SEL_RMII_CLK);
> + udelay(10000);
It seems to me that the most obvious change is the 10mS delay you added
after setting the clock. If we find that such delay is really necessary,
should we not fix it insife the cpu_eth_init() else in all board
initialization functions ?
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================
More information about the U-Boot
mailing list