[U-Boot] [PATCH V4] ARM: mx6: Add support for Kosagi Novena

Sean Cross
2014-09-27T16:46:24Z

I asked Bunnie about this, and the routing is 50 ohms.

On 24 September, 2014 5:40:59 pm GMT+08:00, Marek Vasut <marex@denx.de> wrote:
>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.

--
Sean