Skip to contentSkip to conversation

mx6cuboxi: Fix Ethernet PHY detection problem

PATCH New Fabio Estevam 4 participants 10 messages May 4, 2015

lore
Share & tools
lore
#0 lore raw

PATCH v2 1/2 mx6cuboxi: Fix Ethernet PHY detection problem

mx6cuboxi sometimes fails to recognize the Ethernet PHY:

Net: Phy 0 not found

The explanation for this behavior comes from from Rabeeh Khoury:

"The LED_ACT pin on the carrier-one boards had a pull down that forces the phy address to 0x0; where on CuBox-i and the production HummingBoard that pin is connected directly to LED that depending on the pull down strength of the LED it might be sampled as '0' or '1' thus the phy address might appear as either address 0x0 or 0x4."

"This is AR8035 implementation; in reset stage the LED pin is configured as input, and pull up/down does matter. In this case it configures the PHY address.

After reset is deasserted the same LED pin becomes output and then according to the previous pull/up it should be active high/low"

One way to properly fix this behavior is to place external pull-up/down resistors in the LED line, but from a software standpoint we can fix it by telling phy_find_by_mask() to scan the PHY at addresses 0x0 and 0x4.

---
Changes since v1:
- Explain what the proper hardware fix would be as suggested by Nikolay
- Remove error message from fec_probe as this function already prints on error.

 board/solidrun/mx6cuboxi/mx6cuboxi.c | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)
board/solidrun/mx6cuboxi/mx6cuboxi.c +28 -1
index 9aa0259..e83d2fe 100644
@@ -25,6 +25,7 @@
 #include <asm/imx-common/video.h>
 #include <mmc.h>
 #include <fsl_esdhc.h>
+#include <malloc.h>
 #include <miiphy.h>
 #include <netdev.h>
 #include <asm/arch/crm_regs.h>
@@ -152,9 +153,14 @@ int board_phy_config(struct phy_device *phydev)
 	return 0;
 }
 
+/* On Cuboxi Ethernet PHY can be located at addresses 0x0 or 0x4 */
+#define ETH_PHY_MASK	((1 << 0x0) | (1 << 0x4))
+
 int board_eth_init(bd_t *bis)
 {
 	struct iomuxc *const iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
+	struct mii_dev *bus;
+	struct phy_device *phydev;
 
 	int ret = enable_fec_anatop_clock(ENET_25MHZ);
 	if (ret)
@@ -165,7 +171,28 @@ int board_eth_init(bd_t *bis)
 
 	setup_iomux_enet();
 
-	return cpu_eth_init(bis);
+	bus = fec_get_miibus(IMX_FEC_BASE, -1);
+	if (!bus)
+		return -EINVAL;
+
+	phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII);
+	if (!phydev) {
+		ret = -EINVAL;
+		goto free_bus;
+	}
+
+	debug("using phy@address %d\n", phydev->addr);
+	ret = fec_probe(bis, -1, IMX_FEC_BASE, bus, phydev);
+	if (ret)
+		goto free_phydev;
+
+	return 0;
+
+free_phydev:
+	free(phydev);
+free_bus:
+	free(bus);
+	return ret;
 }
 
 #ifdef CONFIG_VIDEO_IPUV3
Signature · 1 line
1.9.1
#1 lore raw

PATCH v2 2/2 mx6cuboxi: Pull down PAD_ENET_RXD0/RXD1

Configure PAD_ENET_RXD0/RXD1 pads as pull down because these pads are directly connected to the Atheros 8035/8030 although they should be functional only in the RMII mode - 8030.

---
Changes since v1:
- None

 board/solidrun/mx6cuboxi/mx6cuboxi.c | 2 ++
 1 file changed, 2 insertions(+)
board/solidrun/mx6cuboxi/mx6cuboxi.c +2 -0
index ff018e1..8fb6004 100644
@@ -134,6 +134,8 @@ static iomux_v3_cfg_t const enet_pads[] = {
 	IOMUX_PADS(PAD_RGMII_RD2__RGMII_RD2 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
 	IOMUX_PADS(PAD_RGMII_RD3__RGMII_RD3 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
 	IOMUX_PADS(PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
+	IOMUX_PADS(PAD_ENET_RXD0__GPIO1_IO27 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
+	IOMUX_PADS(PAD_ENET_RXD1__GPIO1_IO26 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
 };
 
 static void setup_iomux_enet(void)
Signature · 1 line
1.9.1
#2 lore raw

PATCH v2 2/2 mx6cuboxi: Pull down PAD_ENET_RXD0/RXD1

Hi Fabio,

Quoted 18 lines · Fabio Estevam

Configure PAD_ENET_RXD0/RXD1 pads as pull down because these pads are directly connected to the Atheros 8035/8030 although they should be functional only in the RMII mode - 8030.

---
Changes since v1:
- None

 board/solidrun/mx6cuboxi/mx6cuboxi.c | 2 ++
 1 file changed, 2 insertions(+)
board/solidrun/mx6cuboxi/mx6cuboxi.c +0 -0
index ff018e1..8fb6004 100644

board/solidrun/mx6cuboxi/mx6cuboxi.c static iomux_v3_cfg_t const enet_pads[] = { · line 141

Quoted 8 lines
board/solidrun/mx6cuboxi/mx6cuboxi.c +2 -0
@@ -134,6 +134,8 @@ static iomux_v3_cfg_t const enet_pads[] = {
 	IOMUX_PADS(PAD_RGMII_RD2__RGMII_RD2 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
 	IOMUX_PADS(PAD_RGMII_RD3__RGMII_RD3 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
 	IOMUX_PADS(PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
+	IOMUX_PADS(PAD_ENET_RXD0__GPIO1_IO27 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
+	IOMUX_PADS(PAD_ENET_RXD1__GPIO1_IO26 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
 };
 
 static void setup_iomux_enet(void)

Best regards,
Stefano Babic

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
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
=====================================================================
#3 lore raw

PATCH v2 2/2 mx6cuboxi: Pull down PAD_ENET_RXD0/RXD1

In reply to Fabio Estevam
Quoted 6 lines · Fabio Estevam

Configure PAD_ENET_RXD0/RXD1 pads as pull down because these pads are directly connected to the Atheros 8035/8030 although they should be functional only in the RMII mode - 8030.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150504/375015b0/attachment.sig>
#4 lore raw

PATCH v2 2/2 mx6cuboxi: Pull down PAD_ENET_RXD0/RXD1

In reply to Fabio Estevam
Quoted 27 lines · Fabio Estevam

Configure PAD_ENET_RXD0/RXD1 pads as pull down because these pads are directly connected to the Atheros 8035/8030 although they should be functional only in the RMII mode - 8030.

---
Changes since v1:
- None

 board/solidrun/mx6cuboxi/mx6cuboxi.c | 2 ++
 1 file changed, 2 insertions(+)
board/solidrun/mx6cuboxi/mx6cuboxi.c +2 -0
index ff018e1..8fb6004 100644
@@ -134,6 +134,8 @@ static iomux_v3_cfg_t const enet_pads[] = {
 	IOMUX_PADS(PAD_RGMII_RD2__RGMII_RD2 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
 	IOMUX_PADS(PAD_RGMII_RD3__RGMII_RD3 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
 	IOMUX_PADS(PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
+	IOMUX_PADS(PAD_ENET_RXD0__GPIO1_IO27 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
+	IOMUX_PADS(PAD_ENET_RXD1__GPIO1_IO26 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
 };
 
 static void setup_iomux_enet(void)
Signature · 1 line
1.9.1

Tested on cubox-i4pro and hummingboard-i2ex.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150504/a8df287c/attachment.sig>

#5 lore raw

PATCH v2 2/2 mx6cuboxi: Pull down PAD_ENET_RXD0/RXD1

In reply to Fabio Estevam

Hi Fabio,

Quoted 7 lines · Fabio Estevam

Configure PAD_ENET_RXD0/RXD1 pads as pull down because these pads are directly connected to the Atheros 8035/8030 although they should be functional only in the RMII mode - 8030.

---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
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
=====================================================================
#6 lore raw

PATCH v2 1/2 mx6cuboxi: Fix Ethernet PHY detection problem

In reply to Fabio Estevam

Hi Fabio,

Quoted 83 lines · Fabio Estevam

mx6cuboxi sometimes fails to recognize the Ethernet PHY:

Net: Phy 0 not found

The explanation for this behavior comes from from Rabeeh Khoury:

"The LED_ACT pin on the carrier-one boards had a pull down that forces the phy address to 0x0; where on CuBox-i and the production HummingBoard that pin is connected directly to LED that depending on the pull down strength of the LED it might be sampled as '0' or '1' thus the phy address might appear as either address 0x0 or 0x4."

"This is AR8035 implementation; in reset stage the LED pin is configured as input, and pull up/down does matter. In this case it configures the PHY address.

After reset is deasserted the same LED pin becomes output and then according to the previous pull/up it should be active high/low"

One way to properly fix this behavior is to place external pull-up/down resistors in the LED line, but from a software standpoint we can fix it by telling phy_find_by_mask() to scan the PHY at addresses 0x0 and 0x4.

---
Changes since v1:
- Explain what the proper hardware fix would be as suggested by Nikolay
- Remove error message from fec_probe as this function already prints on error.

 board/solidrun/mx6cuboxi/mx6cuboxi.c | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)
board/solidrun/mx6cuboxi/mx6cuboxi.c +21 -1
index 9aa0259..e83d2fe 100644
@@ -25,6 +25,7 @@
 #include <asm/imx-common/video.h>
 #include <mmc.h>
 #include <fsl_esdhc.h>
+#include <malloc.h>
 #include <miiphy.h>
 #include <netdev.h>
 #include <asm/arch/crm_regs.h>
@@ -152,9 +153,14 @@ int board_phy_config(struct phy_device *phydev)
 	return 0;
 }
 
+/* On Cuboxi Ethernet PHY can be located at addresses 0x0 or 0x4 */
+#define ETH_PHY_MASK	((1 << 0x0) | (1 << 0x4))
+
 int board_eth_init(bd_t *bis)
 {
 	struct iomuxc *const iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
+	struct mii_dev *bus;
+	struct phy_device *phydev;
 
 	int ret = enable_fec_anatop_clock(ENET_25MHZ);
 	if (ret)
@@ -165,7 +171,28 @@ int board_eth_init(bd_t *bis)
 
 	setup_iomux_enet();
 
-	return cpu_eth_init(bis);
+	bus = fec_get_miibus(IMX_FEC_BASE, -1);
+	if (!bus)
+		return -EINVAL;
+
+	phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII);
+	if (!phydev) {
+		ret = -EINVAL;
+		goto free_bus;
+	}
+
+	debug("using phy at address %d\n", phydev->addr);
+	ret = fec_probe(bis, -1, IMX_FEC_BASE, bus, phydev);
+	if (ret)
+		goto free_phydev;
+

board/solidrun/mx6cuboxi/mx6cuboxi.c int board_eth_init(bd_t *bis) · line 198

Quoted 10 lines
board/solidrun/mx6cuboxi/mx6cuboxi.c +7 -0
+	return 0;
+
+free_phydev:
+	free(phydev);
+free_bus:
+	free(bus);
+	return ret;
 }
 
 #ifdef CONFIG_VIDEO_IPUV3

Best regards,
Stefano Babic

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
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
=====================================================================
#7 lore raw

PATCH v2 1/2 mx6cuboxi: Fix Ethernet PHY detection problem

In reply to Fabio Estevam
Quoted 19 lines · Fabio Estevam

mx6cuboxi sometimes fails to recognize the Ethernet PHY:

Net: Phy 0 not found

The explanation for this behavior comes from from Rabeeh Khoury:

"The LED_ACT pin on the carrier-one boards had a pull down that forces the phy address to 0x0; where on CuBox-i and the production HummingBoard that pin is connected directly to LED that depending on the pull down strength of the LED it might be sampled as '0' or '1' thus the phy address might appear as either address 0x0 or 0x4."

"This is AR8035 implementation; in reset stage the LED pin is configured as input, and pull up/down does matter. In this case it configures the PHY address.

After reset is deasserted the same LED pin becomes output and then according to the previous pull/up it should be active high/low"

Quoted 8 lines

One way to properly fix this behavior is to place external pull-up/down resistors in the LED line, but from a software standpoint we can fix it by telling phy_find_by_mask() to scan the PHY at addresses 0x0 and 0x4.

Signature · 1 line
Tom
#8 lore raw

PATCH v2 1/2 mx6cuboxi: Fix Ethernet PHY detection problem

In reply to Fabio Estevam
Quoted 94 lines · Fabio Estevam

mx6cuboxi sometimes fails to recognize the Ethernet PHY:

Net: Phy 0 not found

The explanation for this behavior comes from from Rabeeh Khoury:

"The LED_ACT pin on the carrier-one boards had a pull down that forces the phy address to 0x0; where on CuBox-i and the production HummingBoard that pin is connected directly to LED that depending on the pull down strength of the LED it might be sampled as '0' or '1' thus the phy address might appear as either address 0x0 or 0x4."

"This is AR8035 implementation; in reset stage the LED pin is configured as input, and pull up/down does matter. In this case it configures the PHY address.

After reset is deasserted the same LED pin becomes output and then according to the previous pull/up it should be active high/low"

One way to properly fix this behavior is to place external pull-up/down resistors in the LED line, but from a software standpoint we can fix it by telling phy_find_by_mask() to scan the PHY at addresses 0x0 and 0x4.

---
Changes since v1:
- Explain what the proper hardware fix would be as suggested by Nikolay
- Remove error message from fec_probe as this function already prints on error.

 board/solidrun/mx6cuboxi/mx6cuboxi.c | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)
board/solidrun/mx6cuboxi/mx6cuboxi.c +28 -1
index 9aa0259..e83d2fe 100644
@@ -25,6 +25,7 @@
 #include <asm/imx-common/video.h>
 #include <mmc.h>
 #include <fsl_esdhc.h>
+#include <malloc.h>
 #include <miiphy.h>
 #include <netdev.h>
 #include <asm/arch/crm_regs.h>
@@ -152,9 +153,14 @@ int board_phy_config(struct phy_device *phydev)
 	return 0;
 }
 
+/* On Cuboxi Ethernet PHY can be located at addresses 0x0 or 0x4 */
+#define ETH_PHY_MASK	((1 << 0x0) | (1 << 0x4))
+
 int board_eth_init(bd_t *bis)
 {
 	struct iomuxc *const iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
+	struct mii_dev *bus;
+	struct phy_device *phydev;
 
 	int ret = enable_fec_anatop_clock(ENET_25MHZ);
 	if (ret)
@@ -165,7 +171,28 @@ int board_eth_init(bd_t *bis)
 
 	setup_iomux_enet();
 
-	return cpu_eth_init(bis);
+	bus = fec_get_miibus(IMX_FEC_BASE, -1);
+	if (!bus)
+		return -EINVAL;
+
+	phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII);
+	if (!phydev) {
+		ret = -EINVAL;
+		goto free_bus;
+	}
+
+	debug("using phy at address %d\n", phydev->addr);
+	ret = fec_probe(bis, -1, IMX_FEC_BASE, bus, phydev);
+	if (ret)
+		goto free_phydev;
+
+	return 0;
+
+free_phydev:
+	free(phydev);
+free_bus:
+	free(bus);
+	return ret;
 }
 
 #ifdef CONFIG_VIDEO_IPUV3
Signature · 1 line
1.9.1

Tested on cubox-i4pro and hummingboard-i2ex.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150504/febe8241/attachment.sig>

#9 lore raw

PATCH v2 1/2 mx6cuboxi: Fix Ethernet PHY detection problem

In reply to Fabio Estevam

Hi Fabio,

Quoted 24 lines · Fabio Estevam

mx6cuboxi sometimes fails to recognize the Ethernet PHY:

Net: Phy 0 not found

The explanation for this behavior comes from from Rabeeh Khoury:

"The LED_ACT pin on the carrier-one boards had a pull down that forces the phy address to 0x0; where on CuBox-i and the production HummingBoard that pin is connected directly to LED that depending on the pull down strength of the LED it might be sampled as '0' or '1' thus the phy address might appear as either address 0x0 or 0x4."

"This is AR8035 implementation; in reset stage the LED pin is configured as input, and pull up/down does matter. In this case it configures the PHY address.

After reset is deasserted the same LED pin becomes output and then according to the previous pull/up it should be active high/low"

One way to properly fix this behavior is to place external pull-up/down resistors in the LED line, but from a software standpoint we can fix it by telling phy_find_by_mask() to scan the PHY at addresses 0x0 and 0x4.

Quoted 4 lines

---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
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
=====================================================================