ARM: mx6: Add support for Kosagi Novena

board/kosagi/novena/novena_spl.c new file +10 -0

+/*
+ * SPI
+ */
+#ifdef CONFIG_MXC_SPI
+static iomux_v3_cfg_t ecspi1_pads[] = {
+	/* SS1 */
+	MX6_PAD_EIM_D19__GPIO3_IO19   | MUX_PAD_CTRL(SPI_PAD_CTRL),
+	MX6_PAD_EIM_D17__ECSPI1_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
+	MX6_PAD_EIM_D18__ECSPI1_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
+	MX6_PAD_EIM_D16__ECSPI1_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),

Hi Marek,

Some comments about SPI:

Quoted 16 lines · Marek Vasut

board/kosagi/novena/novena_spl.c new file +16 -0

+/*
+ * SPI
+ */
+#ifdef CONFIG_MXC_SPI
+static iomux_v3_cfg_t ecspi1_pads[] = {
+	/* SS1 */
+	MX6_PAD_EIM_D19__GPIO3_IO19   | MUX_PAD_CTRL(SPI_PAD_CTRL),
+	MX6_PAD_EIM_D17__ECSPI1_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
+	MX6_PAD_EIM_D18__ECSPI1_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
+	MX6_PAD_EIM_D16__ECSPI1_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),
+};
+
+static void novena_spl_setup_iomux_spi(void)
+{
+	imx_iomux_v3_setup_multiple_pads(ecspi1_pads, ARRAY_SIZE(ecspi1_pads));
+	gpio_direction_output(CONFIG_SF_DEFAULT_CS, 1);

board/kosagi/novena/novena_spl.c line 304

Quoted 4 lines

board/kosagi/novena/novena_spl.c new file +4 -0

+}
+#else
+static void novena_spl_setup_iomux_spi(void) {}
+#endif

I checked the schematic and didn't saw any usage of ECSPI1. In addition, these pads (EIM D16/17/18/19) are used by other interfaces. Can you please also double-check this?

Also, can you please review the entire thing so I don't have to retest and resend the patch every day with one minor modification each time? Thanks Best regards, Marek Vasut

Hi Marek,

Quoted 3 lines · Marek Vasut

Also, can you please review the entire thing so I don't have to retest and resend the patch every day with one minor modification each time? Thanks Best regards, Marek Vasut

Sorry about that :(. I definitely understand. Unfortunately it just happens that I have limited hours to help mostly during the night, so I decided to send immediately my findings instead of keeping them for myself for days/weeks. I'll definitely consider your request for my next comments.

Hi Marek,

Following are some comments about FEC Ethernet:

board/kosagi/novena/novena_spl.c line 43

Quoted 5 lines · Marek Vasut

board/kosagi/novena/novena_spl.c new file +5 -0

+#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).

board/kosagi/novena/novena_spl.c line 133

Quoted 13 lines

board/kosagi/novena/novena_spl.c new file +13 -0

+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.

board/kosagi/novena/novena.c line 243

Quoted 11 lines

board/kosagi/novena/novena.c new file +11 -0

+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().

Quoted 13 lines · Nikolay Dimitrov

Hi Marek,

Following are some comments about FEC Ethernet:

board/kosagi/novena/novena_spl.c line 43

Quoted 5 lines · Marek Vasut

board/kosagi/novena/novena_spl.c new file +5 -0

+#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).

Quoted 1 line

Special note: PAD_CTL_DSE_40ohm is defined as 0b110, which is

documented

Quoted 2 lines

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,

Quoted 1 line

but I can extrapolate that if the 125 MHz reference clock is routed

as

Quoted 2 lines

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

Quoted 2 lines

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

Quoted 1 line

reading an updated FSL PDF).

Sean, can you comment on this ?

Quoted 3 lines

board/kosagi/novena/novena_spl.c

Quoted 3 lines

board/kosagi/novena/novena_spl.c new file +3 -0

+static void novena_spl_setup_iomux_enet(void)
+{
+	imx_iomux_v3_setup_multiple_pads(enet_pads1,

ARRAY_SIZE(enet_pads1));

Quoted 1 line

Review

Quoted 1 line

(quoted diff) +1 -0

+	imx_iomux_v3_setup_multiple_pads(enet_pads2,

ARRAY_SIZE(enet_pads2));

Quoted 11 lines

board/kosagi/novena/novena_spl.c line 133

Quoted 9 lines

board/kosagi/novena/novena_spl.c new file +9 -0

+
+	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

Quoted 4 lines

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

Quoted 2 lines

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

Quoted 1 line

pins are becoming outputs and driving the same lines, which is not

good.

Quoted 17 lines

I'm giving a proposal how to fix this in the end.

board/kosagi/novena/novena.c line 243

Quoted 11 lines

board/kosagi/novena/novena.c new file +11 -0

+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

Quoted 1 line

only mentioned time is min. 10ms after power-on, and nothing about

RESET

Quoted 38 lines

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),
};

Quoted 3 lines

static void novena_spl_setup_iomux_enet(void) {
imx_iomux_v3_setup_multiple_pads(enet_pads1,

ARRAY_SIZE(enet_pads1));

Quoted 13 lines

	/* 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 */

Quoted 8 lines

	/* 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));

Quoted 2 lines

	/* PHY datasheet recommends on p.53 to wait at least 100us before

using

Quoted 5 lines

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.

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

Quoted 15 lines · Marek Vasut

On Wednesday, September 24, 2014 at 04:46:42 AM, Nikolay Dimitrov

Quoted 12 lines · wrote:

Hi Marek,

Following are some comments about FEC Ethernet:

board/kosagi/novena/novena_spl.c line 43

Quoted 5 lines · Marek Vasut

board/kosagi/novena/novena_spl.c new file +5 -0

+#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).

Quoted 12 lines

Quoted 11 lines

board/kosagi/novena/novena_spl.c line 133

Quoted 9 lines

board/kosagi/novena/novena_spl.c new file +9 -0

+
+	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

Quoted 4 lines

doesn't

Quoted 2 lines

achieve the intended goal. After the 2nd iomux setup, the pads are connected to the FEC, not to the GPIOs.

Quoted 12 lines · Nikolay Dimitrov

Hi Marek,

Following are some comments about FEC Ethernet:

board/kosagi/novena/novena_spl.c line 43

Quoted 5 lines · Marek Vasut

board/kosagi/novena/novena_spl.c new file +5 -0

+#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).

Quoted 9 lines

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 ?

Quoted 102 lines

board/kosagi/novena/novena_spl.c line 133

Quoted 13 lines

board/kosagi/novena/novena_spl.c new file +13 -0

+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.

board/kosagi/novena/novena.c line 243

Quoted 11 lines

board/kosagi/novena/novena.c new file +11 -0

+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));

Quoted 6 lines

	/* 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.

Hi Marek, Nikolay,

I thought I responded, but it might have gotten lost. I'm sorry about that.

I've taken a closer look, and responded below.

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.

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);
}

Hi Marek, Sean,

Do you have any comments on the PHY signal driving conflict and reset timing issue (see below)?

Quoted 4 lines · Nikolay Dimitrov

Hi Marek, Sean,

Do you have any comments on the PHY signal driving conflict and reset timing issue (see below)?

I don't, I sense expert knowledge from you. Now we need to wait for the authors.

I spent this weekend showing Novena board off at a local conference and somehow it became the center of attention without much help ;-) I see Novena is like the epitome of awesomeness :)

Hi Marek,

Quoted 9 lines · Marek Vasut

Quoted 4 lines · Nikolay Dimitrov

Hi Marek, Sean,

Do you have any comments on the PHY signal driving conflict and reset timing issue (see below)?

I don't, I sense expert knowledge from you. Now we need to wait for the authors.

Quoted 3 lines

I spent this weekend showing Novena board off at a local conference and somehow it became the center of attention without much help ;-) I see Novena is like the epitome of awesomeness :)

Well, after signing NDAs with our own blood for years, everyone seems to be happy to see a product that's just designed to be hacked (and to hack other gadgets with it, of course).

+#define NOVENA_USB_HUB_RESET IMX_GPIO_NR(7, 12)

board/kosagi/novena/novena.c new file +5 -0

+/*
+ * USB
+ */
+#ifdef CONFIG_USB_EHCI_MX6
+int board_ehci_hcd_init(int port)

+#define NOVENA_AUDIO_PWRON IMX_GPIO_NR(5, 17)

+#define NOVENA_HDMI_GHOST_HPD IMX_GPIO_NR(5, 4)

+ * Environment is on MMC, starting at offset 64KiB from start of the

+#define CONFIG_ENV_OFFSET (512 * 1024)