diff mbox series

U-Boot atheros PHY support and cubox ethernet

Message ID 20200617190020.GF27801@bill-the-cat
State New
Headers show
Series U-Boot atheros PHY support and cubox ethernet | expand

Commit Message

Tom Rini June 17, 2020, 7 p.m. UTC 
On Wed, Jun 17, 2020 at 09:04:44AM -0300, Fabio Estevam wrote:
> Hi Tom,
> 
> On Tue, Jun 16, 2020 at 7:30 PM Tom Rini <trini at konsulko.com> wrote:
> 
> > Yeah, OK, I got far enough on trying to convert this that I see I don't
> > quite have time to pick it up and run with it.  It looks like there's
> > going to be some extra fun around resetting the PHY perhaps?  My quick
> > pass got things seeing a generic PHY and not the atheros one.  If you
> > have time to make something you'd like me to test for conversion let me
> > know.  But I'm going to pick up debugging the problem I see on the
> > platform right now in case there's a wider problem it's showing.
> 
> Here are two untested patches you could try.

Based on your follow-up patches, I think you'll be unsurprised it
doesn't work.  I get:
Net:   Could not get PHY for FEC0: addr 0

Now, question:
> -	ret = dm_gpio_lookup_name("GPIO4_15", &desc);
> -	if (ret) {
> -		printf("%s: phy reset lookup failed\n", __func__);
> -		return;
> -	}
> -
> -	ret = dm_gpio_request(&desc, "phy-reset");
> -	if (ret) {
> -		printf("%s: phy reset request failed\n", __func__);
> -		return;
> -	}
> -
> -	gpio_direction_output(ETH_PHY_RESET, 0);
> -	mdelay(10);
> -	gpio_set_value(ETH_PHY_RESET, 1);
> -	udelay(100);
> -
> -	gpio_free_list_nodev(&desc, 1);

Don't we need that still, but in a setup_fec() call?  I have a quick
test with:


And at run-time I get:
Warning: ethernet at 2188000 using MAC address from ROM
eth0: ethernet at 2188000
...
=> mdio list
FEC0:
0 - AR8035 <--> ethernet at 2188000

And I did the mdio write/read's from the previous part of the thread and
get the same values.

Comments

Fabio Estevam June 17, 2020, 9:28 p.m. UTC | #1 
Hi Tom,

On Wed, Jun 17, 2020 at 4:00 PM Tom Rini <trini at konsulko.com> wrote:

> Based on your follow-up patches, I think you'll be unsurprised it
> doesn't work.  I get:
> Net:   Could not get PHY for FEC0: addr 0

Now I understand why the PHY could not be found with the patches I sent.

On mx6cubox the AR8035 is clocked from a 25MHz clock coming from the
i.MX6 GPIO16 pin.

My patch incorrectly removed this setting.

> +       int ret = enable_fec_anatop_clock(0, ENET_25MHZ);
> +       if (ret)
> +               return ret;
> +
> +       /* set gpr1[ENET_CLK_SEL] */
> +       setbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK);

enable_fec_anatop_clock() and GPR1 settings above must remain.

In order to get patch 1 to work (the one that adds the
qca,clk-out-frequency property ) you also need this FEC change:
https://pastebin.com/raw/mcKdwwTs

I hope this helps.
Tom Rini June 17, 2020, 9:30 p.m. UTC | #2 
On Wed, Jun 17, 2020 at 06:28:37PM -0300, Fabio Estevam wrote:
> Hi Tom,
> 
> On Wed, Jun 17, 2020 at 4:00 PM Tom Rini <trini at konsulko.com> wrote:
> 
> > Based on your follow-up patches, I think you'll be unsurprised it
> > doesn't work.  I get:
> > Net:   Could not get PHY for FEC0: addr 0
> 
> Now I understand why the PHY could not be found with the patches I sent.
> 
> On mx6cubox the AR8035 is clocked from a 25MHz clock coming from the
> i.MX6 GPIO16 pin.
> 
> My patch incorrectly removed this setting.
> 
> > +       int ret = enable_fec_anatop_clock(0, ENET_25MHZ);
> > +       if (ret)
> > +               return ret;
> > +
> > +       /* set gpr1[ENET_CLK_SEL] */
> > +       setbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK);
> 
> enable_fec_anatop_clock() and GPR1 settings above must remain.
> 
> In order to get patch 1 to work (the one that adds the
> qca,clk-out-frequency property ) you also need this FEC change:
> https://pastebin.com/raw/mcKdwwTs
> 
> I hope this helps.

I'll test that out tomorrow.  But my question now is, what do you want
to do about the various platforms where ethernet isn't working?
Fabio Estevam June 18, 2020, 12:41 a.m. UTC | #3 
On Wed, Jun 17, 2020 at 6:30 PM Tom Rini <trini at konsulko.com> wrote:

> I'll test that out tomorrow.  But my question now is, what do you want
> to do about the various platforms where ethernet isn't working?

I fixed the mx6sabresd Ethernet regression today and I can also try to
convert other imx platforms from rgmii to rgmi-id.

We still don't have the root cause for the mx6cuboxi regression.

What are the other platforms where ethernet isn't working?
Fabio Estevam June 18, 2020, 3:05 a.m. UTC | #4 
Hi Tom,

On Wed, Jun 17, 2020 at 6:28 PM Fabio Estevam <festevam at gmail.com> wrote:
>
> Hi Tom,
>
> On Wed, Jun 17, 2020 at 4:00 PM Tom Rini <trini at konsulko.com> wrote:
>
> > Based on your follow-up patches, I think you'll be unsurprised it
> > doesn't work.  I get:
> > Net:   Could not get PHY for FEC0: addr 0
>
> Now I understand why the PHY could not be found with the patches I sent.
>
> On mx6cubox the AR8035 is clocked from a 25MHz clock coming from the
> i.MX6 GPIO16 pin.
>
> My patch incorrectly removed this setting.
>
> > +       int ret = enable_fec_anatop_clock(0, ENET_25MHZ);
> > +       if (ret)
> > +               return ret;
> > +
> > +       /* set gpr1[ENET_CLK_SEL] */
> > +       setbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK);
>
> enable_fec_anatop_clock() and GPR1 settings above must remain.
>
> In order to get patch 1 to work (the one that adds the
> qca,clk-out-frequency property ) you also need this FEC change:
> https://pastebin.com/raw/mcKdwwTs
>
> I hope this helps.

Good news! I managed to get access to an imx6 humming board and
managed to fix the Eternet issue.

I will submit the AR8035 fix.
Tom Rini June 18, 2020, 1:39 p.m. UTC | #5 
On Wed, Jun 17, 2020 at 09:41:17PM -0300, Fabio Estevam wrote:
> On Wed, Jun 17, 2020 at 6:30 PM Tom Rini <trini at konsulko.com> wrote:
> 
> > I'll test that out tomorrow.  But my question now is, what do you want
> > to do about the various platforms where ethernet isn't working?
> 
> I fixed the mx6sabresd Ethernet regression today and I can also try to
> convert other imx platforms from rgmii to rgmi-id.
> 
> We still don't have the root cause for the mx6cuboxi regression.
> 
> What are the other platforms where ethernet isn't working?

It's a good question what else doesn't work.  What has been actively
verified at this point?
Fabio Estevam June 20, 2020, 2:14 a.m. UTC | #6 
Hi Tom,

On Thu, Jun 18, 2020 at 10:39 AM Tom Rini <trini at konsulko.com> wrote:

> It's a good question what else doesn't work.  What has been actively
> verified at this point?

After the fixes I sent yesterday, the few imx boards I have access at
the moment have Ethernet working well.
Soeren Moch June 24, 2020, 7:20 p.m. UTC | #7 
On 20.06.20 04:14, Fabio Estevam wrote:
> Hi Tom,
>
> On Thu, Jun 18, 2020 at 10:39 AM Tom Rini <trini at konsulko.com> wrote:
>
>> It's a good question what else doesn't work.  What has been actively
>> verified at this point?
>
> After the fixes I sent yesterday, the few imx boards I have access at
> the moment have Ethernet working well.
>

I tested current master (v2020.07-rc5 + imx fixes) on tbs2910 (imx6q +
atheros PHY).
Unfortunately ethernet is broken now, while it used to work well on
u-boot version v2020.04. Ethernet support was copied from imx6q-sabresd,
the recently for sabresd fixed phy-mode already is rgmii-id for tbs2910.

Any ideas what could be wrong?

Thanks,
Soeren
diff mbox series

Patch

diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index a2c2bb9e354e..89b0d8680658 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -17,6 +17,7 @@ 
 #include <image.h>
 #include <init.h>
 #include <log.h>
+#include <net.h>
 #include <asm/arch/clock.h>
 #include <asm/arch/imx-regs.h>
 #include <asm/arch/iomux.h>
@@ -33,6 +34,7 @@ 
 #include <fsl_esdhc_imx.h>
 #include <malloc.h>
 #include <miiphy.h>
+#include <netdev.h>
 #include <asm/arch/crm_regs.h>
 #include <asm/io.h>
 #include <asm/arch/sys_proto.h>
@@ -50,15 +52,6 @@  DECLARE_GLOBAL_DATA_PTR;
 	PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm |			\
 	PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
 
-#define ENET_PAD_CTRL  (PAD_CTL_PUS_100K_UP |			\
-	PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
-
-#define ENET_PAD_CTRL_PD  (PAD_CTL_PUS_100K_DOWN |		\
-	PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
-
-#define ENET_PAD_CTRL_CLK  ((PAD_CTL_PUS_100K_UP & ~PAD_CTL_PKE) | \
-	PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
-
 #define ETH_PHY_RESET	IMX_GPIO_NR(4, 15)
 #define USB_H1_VBUS	IMX_GPIO_NR(1, 0)
 
@@ -235,6 +228,51 @@  int board_mmc_init(bd_t *bis)
 	return 0;
 }
 
+#ifdef CONFIG_FEC_MXC
+static int setup_fec(void)
+{
+	struct iomuxc *const iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
+	struct gpio_desc desc;
+
+	int ret = enable_fec_anatop_clock(0, ENET_25MHZ);
+	if (ret)
+		return ret;
+
+	/* set gpr1[ENET_CLK_SEL] */
+	setbits_le32(&iomuxc_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK);
+
+	/* Reset PHY */
+	ret = dm_gpio_lookup_name("GPIO4_15", &desc);
+	if (ret) {
+		printf("%s: phy reset lookup failed\n", __func__);
+		return ret;
+	}
+
+	ret = dm_gpio_request(&desc, "phy-reset");
+	if (ret) {
+		printf("%s: phy reset request failed\n", __func__);
+		return ret;
+	}
+
+	gpio_direction_output(ETH_PHY_RESET, 0);
+	mdelay(10);
+	gpio_set_value(ETH_PHY_RESET, 1);
+	udelay(100);
+
+	gpio_free_list_nodev(&desc, 1);
+
+	return 0;
+}
+#endif
+
+int board_phy_config(struct phy_device *phydev)
+{
+	if (phydev->drv->config)
+		phydev->drv->config(phydev);
+
+	return 0;
+}
+
 #ifdef CONFIG_VIDEO_IPUV3
 static void do_enable_hdmi(struct display_info_t const *dev)
 {
@@ -344,6 +382,12 @@  int board_init(void)
 	/* address of boot parameters */
 	gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
 
+#ifdef CONFIG_FEC_MXC
+	ret = setup_fec();
+	if (ret)
+		return ret;
+#endif
+
 #ifdef CONFIG_VIDEO_IPUV3
 	ret = setup_display();
 #endif