[U-Boot] [PATCH 1/2] mx6cuboxi: Fix Ethernet PHY detection problem

[U-Boot] [PATCH 1/2] mx6cuboxi: Fix Ethernet PHY detection problem

[Fabio Estevam]

From: Fabio Estevam <fabio.estevam@freescale.com>

mx6cuboxi sometimes fails to recognize the Ethernet PHY:

Net:   Phy 0 not found

The explanation comes from a patch from Rabeeh:

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

So fix this problem by telling phy_find_by_mask() to scan the PHY at addresses
0x0 and 0x4.

Reported-by: Vagrant Cascadian <vagrant@aikidev.net>
Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
 board/solidrun/mx6cuboxi/mx6cuboxi.c | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 9aa0259..ff018e1 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -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,30 @@ 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) {
+		printf("FEC MXC: %s:failed\n", __func__);
+		goto free_phydev;
+	}
+
+	return 0;
+
+free_phydev:
+	free(phydev);
+free_bus:
+	free(bus);
+	return ret;
 }
 
 #ifdef CONFIG_VIDEO_IPUV3
-- 
1.9.1

[U-Boot] [PATCH 2/2] mx6cuboxi: Pull down PAD_ENET_RXD0/RXD1

[Fabio Estevam]

From: Fabio Estevam <fabio.estevam@freescale.com>

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.

Signed-off-by: Rabeeh Khoury <rabeeh@solid-run.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
 board/solidrun/mx6cuboxi/mx6cuboxi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index ff018e1..8fb6004 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -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)
-- 
1.9.1

[U-Boot] [PATCH 1/2] mx6cuboxi: Fix Ethernet PHY detection problem

[Nikolay Dimitrov]

Hi Fabio,

On 05/04/2015 06:30 AM, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> mx6cuboxi sometimes fails to recognize the Ethernet PHY:
>
> Net:   Phy 0 not found
>
> The explanation comes from a patch from Rabeeh:
>
> "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."

There's no such thing as "LED pull-down". The forward voltage drop of a
LED is between 1.65V (red low-power LEDs) to 2.1V (green LEDs) to even
more for blue LEDs. Even the lowest Vf doesn't qualify as logic "0" for
LVCMOS33, which is around 1V max (Vil). The LED just can't pull-down the
voltage level low enough.

So, unless you have some control over the pin (via a programmable
on-chip pull-up or pull-down) which I doubt as it's a PHY pin, the
actual behavior is that the pin is floating, and samples a random value
at boot. Which means, the hardware is just buggy.

Kind regards,
Nikolay

[U-Boot] [PATCH 1/2] mx6cuboxi: Fix Ethernet PHY detection problem

[Fabio Estevam]

Hi Nikolay,

On Mon, May 4, 2015 at 1:18 AM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> Hi Fabio,
>
> On 05/04/2015 06:30 AM, Fabio Estevam wrote:
>>
>> From: Fabio Estevam <fabio.estevam@freescale.com>
>>
>> mx6cuboxi sometimes fails to recognize the Ethernet PHY:
>>
>> Net:   Phy 0 not found
>>
>> The explanation comes from a patch from Rabeeh:
>>
>> "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."
>
>
> There's no such thing as "LED pull-down". The forward voltage drop of a
> LED is between 1.65V (red low-power LEDs) to 2.1V (green LEDs) to even
> more for blue LEDs. Even the lowest Vf doesn't qualify as logic "0" for
> LVCMOS33, which is around 1V max (Vil). The LED just can't pull-down the
> voltage level low enough.
>
> So, unless you have some control over the pin (via a programmable
> on-chip pull-up or pull-down) which I doubt as it's a PHY pin, the
> actual behavior is that the pin is floating, and samples a random value
> at boot. Which means, the hardware is just buggy.

As mentioned in the commit log this explanation comes from Solid-run.

The key point here is that the PHY can appear at 0x0 and 0x4, so this
patch handles such case.

Regards,

Fabio Estevam

[U-Boot] [PATCH 1/2] mx6cuboxi: Fix Ethernet PHY detection problem

[Rabeeh Khoury]

On 05/04/2015 07:18 AM, Nikolay Dimitrov wrote:
> Hi Fabio,
>
> On 05/04/2015 06:30 AM, Fabio Estevam wrote:
>> From: Fabio Estevam <fabio.estevam@freescale.com>
>>
>> mx6cuboxi sometimes fails to recognize the Ethernet PHY:
>>
>> Net:   Phy 0 not found
>>
>> The explanation comes from a patch from Rabeeh:
>>
>> "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."
>
> There's no such thing as "LED pull-down". The forward voltage drop of a
> LED is between 1.65V (red low-power LEDs) to 2.1V (green LEDs) to even
> more for blue LEDs. Even the lowest Vf doesn't qualify as logic "0" for
> LVCMOS33, which is around 1V max (Vil). The LED just can't pull-down the
> voltage level low enough.
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 (i.e. 
driver or sink).

[U-Boot] [PATCH 1/2] mx6cuboxi: Fix Ethernet PHY detection problem

[Nikolay Dimitrov]

Hi Rabeeh,

On 05/04/2015 03:35 PM, Rabeeh Khoury wrote:
> On 05/04/2015 07:18 AM, Nikolay Dimitrov wrote:
>> Hi Fabio,
>>
>> On 05/04/2015 06:30 AM, Fabio Estevam wrote:
>>> From: Fabio Estevam <fabio.estevam@freescale.com>
>>>
>>> mx6cuboxi sometimes fails to recognize the Ethernet PHY:
>>>
>>> Net:   Phy 0 not found
>>>
>>> The explanation comes from a patch from Rabeeh:
>>>
>>> "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."
>>
>> There's no such thing as "LED pull-down". The forward voltage drop
>> of a LED is between 1.65V (red low-power LEDs) to 2.1V (green LEDs)
>> to even more for blue LEDs. Even the lowest Vf doesn't qualify as
>> logic "0" for LVCMOS33, which is around 1V max (Vil). The LED just
>> can't pull-down the voltage level low enough.
> 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 (i.e.
>  driver or sink).

I know this. This is why I said that the pin is floating and the R+LED
can't define a proper logic level during configuration bootstrapping. In
such situations there should be an external pull-up/pull-down to make
sure things work properly.

Regards,
Nikolay

[U-Boot] [PATCH 1/2] mx6cuboxi: Fix Ethernet PHY detection problem

[Nikolay Dimitrov]

Hi Fabio,

On 05/04/2015 03:22 PM, Fabio Estevam wrote:
> Hi Nikolay,
>
> On Mon, May 4, 2015 at 1:18 AM, Nikolay Dimitrov <picmaster@mail.bg>
> wrote:
>> Hi Fabio,
>>
>> On 05/04/2015 06:30 AM, Fabio Estevam wrote:
>>>
>>> From: Fabio Estevam <fabio.estevam@freescale.com>
>>>
>>> mx6cuboxi sometimes fails to recognize the Ethernet PHY:
>>>
>>> Net:   Phy 0 not found
>>>
>>> The explanation comes from a patch from Rabeeh:
>>>
>>> "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."
>>
>>
>> There's no such thing as "LED pull-down". The forward voltage drop
>> of a LED is between 1.65V (red low-power LEDs) to 2.1V (green
>> LEDs) to even more for blue LEDs. Even the lowest Vf doesn't
>> qualify as logic "0" for LVCMOS33, which is around 1V max (Vil).
>> The LED just can't pull-down the voltage level low enough.
>>
>> So, unless you have some control over the pin (via a programmable
>> on-chip pull-up or pull-down) which I doubt as it's a PHY pin, the
>>  actual behavior is that the pin is floating, and samples a random
>> value at boot. Which means, the hardware is just buggy.
>
> As mentioned in the commit log this explanation comes from
> Solid-run.
>
> The key point here is that the PHY can appear at 0x0 and 0x4, so this
> patch handles such case.

Yes, I saw that. Sorry for the off-topic. The reason I allowed myself to
comment is that this text will go into git log, and people can treat it
as the proper way to configure boot-strapable pins, which I don't think
it is.

Otherwise your patch is completely OK - this is the only way to fix such
behavior of the hardware.

Kind regards,
Nikolay