On Wednesday, September 24, 2014 at 04:46:42 AM, Nikolay Dimitrov wrote:
> Hi Marek,
>
> Following are some comments about FEC Ethernet:
>
> On 09/23/2014 01:18 PM, Marek Vasut wrote:
> > +#define ENET_PAD_CTRL \
> > + (PAD_CTL_PKE | PAD_CTL_PUE | \
> > + PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
> > + PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
> > +
>
> PAD_CTL_SPEED_MED falls on reserved bits (7-6).
>
> Special note: PAD_CTL_DSE_40ohm is defined as 0b110, which is documented
> as "37/27 ohm @2.5V". I didn't saw any notes on the PHY spec or the
> Novena schematic about the routing guidelines of the RGMII data lines,
> but I can extrapolate that if the 125 MHz reference clock is routed as
> 50-ohm line (this one is documented in the datasheet), then the data
> lines are probably routed in a similar way. So the DSE value should be
> 0b100, which is "57/43 ohm @ 2.5V", which in turn is defined in the
> headers as PAD_CTL_DSE_60ohm (this is either a bug in the header, or I'm
> reading an updated FSL PDF).
Sean, can you comment on this ?
> > +static void novena_spl_setup_iomux_enet(void)
> > +{
> > + imx_iomux_v3_setup_multiple_pads(enet_pads1, ARRAY_SIZE(enet_pads1));
> > + imx_iomux_v3_setup_multiple_pads(enet_pads2, ARRAY_SIZE(enet_pads2));
> > +
> > + gpio_direction_output(IMX_GPIO_NR(3, 23), 0);
> > + gpio_direction_output(IMX_GPIO_NR(6, 30), 1);
> > + gpio_direction_output(IMX_GPIO_NR(6, 25), 1);
> > + gpio_direction_output(IMX_GPIO_NR(6, 27), 1);
> > + gpio_direction_output(IMX_GPIO_NR(6, 28), 1);
> > + gpio_direction_output(IMX_GPIO_NR(6, 29), 1);
> > + gpio_direction_output(IMX_GPIO_NR(6, 24), 1);
> > +}
>
> I think that setting the iomuxes immediately one after the other doesn't
> achieve the intended goal. After the 2nd iomux setup, the pads are
> connected to the FEC, not to the GPIOs.
>
> There's one more issue here - when you get the PHY out of reset, you'll
> have to both de-assert the RESET line while keeping the strapping
> signals stable so the PHY can read them, but at the same time the PHY RX
> pins are becoming outputs and driving the same lines, which is not good.
> I'm giving a proposal how to fix this in the end.
>
> > +int board_early_init_f(void)
> > +{
> > +#if defined(CONFIG_VIDEO_IPUV3)
> > + setup_display();
> > +#endif
> > +
> > + /* Bring Ethernet PHY out of reset. */
> > + gpio_set_value(IMX_GPIO_NR(3, 23), 1);
> > +
> > + return 0;
> > +}
>
> Getting the PHY out of reset at this point causes unpredictable reset
> timing - e.g. you can't guarantee how much time the chip was held in
> reset. The PHY datasheet is quite unclear about this reset timing, the
> only mentioned time is min. 10ms after power-on, and nothing about RESET
> assertion/de-assertion. I can throw a wild guess that the reset pulse
> should have similar duration, e.g. 10ms.
>
> Here's my proposal how to fix both (line driving conflict and reset
> timing) issues:
>
> #define ENET_PHY_CFG_PC \
> (PAD_CTL_HYS | PAD_CTL_PUS_22K_UP | PAD_CTL_PUE | PAD_CTL_PKE)
>
> static iomux_v3_cfg_t enet_pads1[] = {
> MX6_PAD_ENET_MDIO__ENET_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL),
> MX6_PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
>
> MX6_PAD_RGMII_TXC__RGMII_TXC | MUX_PAD_CTRL(ENET_PAD_CTRL),
> MX6_PAD_RGMII_TD0__RGMII_TD0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
> MX6_PAD_RGMII_TD1__RGMII_TD1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
> MX6_PAD_RGMII_TD2__RGMII_TD2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
> MX6_PAD_RGMII_TD3__RGMII_TD3 | MUX_PAD_CTRL(ENET_PAD_CTRL),
> MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL| MUX_PAD_CTRL(ENET_PAD_CTRL),
> MX6_PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL),
>
> /* pin 35, PHY_AD2 */
> MX6_PAD_RGMII_RXC__GPIO6_IO30 | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
> /* pin 32, MODE0 */
> MX6_PAD_RGMII_RD0__GPIO6_IO25 | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
> /* pin 31, MODE1 */
> MX6_PAD_RGMII_RD1__GPIO6_IO27 | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
> /* pin 28, MODE2 */
> MX6_PAD_RGMII_RD2__GPIO6_IO28 | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
> /* pin 27, MODE3 */
> MX6_PAD_RGMII_RD3__GPIO6_IO29 | MUX_PAD_CTRL(ENET_PHY_CFG_PC),
> /* pin 33, CLK125_EN */
> MX6_PAD_RGMII_RX_CTL__GPIO6_IO24| MUX_PAD_CTRL(ENET_PHY_CFG_PC),
>
> /* PHY nRST */
> MX6_PAD_EIM_D23__GPIO3_IO23 | MUX_PAD_CTRL(NO_PAD_CTRL),
> };
>
> static void novena_spl_setup_iomux_enet(void)
> {
> imx_iomux_v3_setup_multiple_pads(enet_pads1, ARRAY_SIZE(enet_pads1));
>
> /* Assert Ethernet PHY nRST */
> gpio_direction_output(IMX_GPIO_NR(3, 23), 0);
>
> /* Using imx6 internal pull-ups to drive PHY config pins during PHY
> reset */
> gpio_direction_input(IMX_GPIO_NR(6, 30)); /* PHY_AD2 = 1 */
> gpio_direction_input(IMX_GPIO_NR(6, 25)); /* MODE0 = 1 */
> gpio_direction_input(IMX_GPIO_NR(6, 27)); /* MODE1 = 1 */
> gpio_direction_input(IMX_GPIO_NR(6, 28)); /* MODE2 = 1 */
> gpio_direction_input(IMX_GPIO_NR(6, 29)); /* MODE3 = 1 */
> gpio_direction_input(IMX_GPIO_NR(6, 24)); /* CLK125_EN = 1 */
>
> /* Interpreting fig.8 from the PHY datasheet */
> mdelay(10);
>
> /* De-assert Ethernet PHY nRST */
> gpio_set_value(IMX_GPIO_NR(3, 23), 1);
>
> /* After PHY is configured, we can finally connect our FEC */
> imx_iomux_v3_setup_multiple_pads(enet_pads2, ARRAY_SIZE(enet_pads2));
>
> /* PHY datasheet recommends on p.53 to wait at least 100us before using
> MII, so we enforce this delay here */
> udelay(100);
> }
>
> And I would ditch the PHY un-reset code from board_early_init_f().
Again, this is a question for the hardware guys. Also, it would be nice if you
could prepare a patch, so you get the credit.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
