Re: U-Boot atheros PHY support and cubox ethernet
Hi Soeren, On Thu, Jun 25, 2020 at 6:56 AM Soeren Moch wrote: > The phy-handle was missing in the fec node. With this added everything > works fine: Ops :-) Yes, I will submit this patch for U-Boot. Thanks
Re: U-Boot atheros PHY support and cubox ethernet
Hi Fabio,
On 25.06.20 01:19, Fabio Estevam wrote:
> Hi Soeren,
>
> On Wed, Jun 24, 2020 at 7:29 PM Soeren Moch wrote:
>
>> Unfortunately I have no access to my usual development board (and will
>> not have until the v2020.07 release). I only can use an old board
>> without working USB-OTG, limited to eMMC boot. So I tried to avoid
>> bisecting, because a bad commit could completely brick this board.
> Ok, understood.
>
> We could check if the issue on your board is due to:
>
> commit 6333cbb3817ed551cd7d4e92f7359c73ccc567fc
> Author: Michael Walle
> Date: Thu May 7 00:11:58 2020 +0200
>
> phy: atheros: ar8035: remove static clock config
>
> We can configure the clock output in the device tree. Disable the
> hardcoded one in here. This is highly board-specific and should have
> never been enabled in the PHY driver.
>
> If bisecting shows that this commit breaks your board it probably
> depends on the clock output of your Atheros AR8035 PHY. Please have a
> look at doc/device-tree-bindings/net/phy/atheros.txt. You need to set
> "clk-out-frequency = <12500>" because that value was the hardcoded
> value until this commit.
>
> Signed-off-by: Michael Walle
> Acked-by: Joe Hershberger
>
> On your board, are you able to measure with a scope the AR8035 CLK_25M pin?
>
> Prior to this commit the CLK_25M was hardcoded to output a 125MHz clock.
>
> Now that this setting from the ar8035 phy driver is gone we should
> pass this information in some form:
>
> - We tried via devicetree with the "qca,clk-out-frequency" property,
> but it did not work. This is an area where you could add some debug
> prints inside drivers/net/phy/atheros.c and see if if
> qca,clk-out-frequency is being parsed correctly to configure a 125MHz
> clock output. This is the method I used on mx6cuboxi last week and it
> works.
The phy-handle was missing in the fec node. With this added everything
works fine:
---8<---
diff --git a/arch/arm/dts/imx6q-tbs2910.dts b/arch/arm/dts/imx6q-tbs2910.dts
index cc5df37b46..5b9b025bb6 100644
--- a/arch/arm/dts/imx6q-tbs2910.dts
+++ b/arch/arm/dts/imx6q-tbs2910.dts
@@ -105,9 +105,20 @@
{
pinctrl-names = "default";
pinctrl-0 = <_enet>;
+ phy-handle = <>;
phy-mode = "rgmii-id";
phy-reset-gpios = < 25 GPIO_ACTIVE_LOW>;
status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy: ethernet-phy@4 {
+ reg = <4>;
+ qca,clk-out-frequency = <12500>;
+ };
+ };
};
{
---8<---
>
> - Other way to configure the AR803x is via board code. Please try to
> copy the ar8031_phy_fixup() and board_phy_config() from
> board/freescale/mx6sabresd/mx6sabresd.c into your board file.
>
> (I plan to remove this board PHY code in mx6sabresd after 2020.07 and
> use "qca,clk-out-frequency" to do the job).
OK, so I think we should use the dts patch as fix for u-boot now and
sync that to linux afterwards.
Do you want to send a proper patch for that? Otherwise I can do so.
Thanks for your help and suggestions,
Soeren
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, Jun 24, 2020 at 8:19 PM Fabio Estevam wrote: > - We tried via devicetree with the "qca,clk-out-frequency" property, > but it did not work. This is an area where you could add some debug > prints inside drivers/net/phy/atheros.c and see if if > qca,clk-out-frequency is being parsed correctly to configure a 125MHz > clock output. This is the method I used on mx6cuboxi last week and it > works. To help debugging why "qca,clk-out-frequency" is not taking effect you could try this debug patch: https://pastebin.com/raw/RKG63JGJ This is the result on a imx6 hummingboard: Net: ar803x_of_init: found PHY node: ethernet-phy@0 ** clk out frequency is 12500 ar803x_of_init: flags=0 clk_25m_reg=0018 clk_25m_mask=0018 PHY mode is 8 Warning: ethernet@2188000 using MAC address from ROM eth0: ethernet@2188000 Hit any key to stop autoboot: 0 =>
Re: U-Boot atheros PHY support and cubox ethernet
Hi Soeren, On Wed, Jun 24, 2020 at 7:29 PM Soeren Moch wrote: > Unfortunately I have no access to my usual development board (and will > not have until the v2020.07 release). I only can use an old board > without working USB-OTG, limited to eMMC boot. So I tried to avoid > bisecting, because a bad commit could completely brick this board. Ok, understood. We could check if the issue on your board is due to: commit 6333cbb3817ed551cd7d4e92f7359c73ccc567fc Author: Michael Walle Date: Thu May 7 00:11:58 2020 +0200 phy: atheros: ar8035: remove static clock config We can configure the clock output in the device tree. Disable the hardcoded one in here. This is highly board-specific and should have never been enabled in the PHY driver. If bisecting shows that this commit breaks your board it probably depends on the clock output of your Atheros AR8035 PHY. Please have a look at doc/device-tree-bindings/net/phy/atheros.txt. You need to set "clk-out-frequency = <12500>" because that value was the hardcoded value until this commit. Signed-off-by: Michael Walle Acked-by: Joe Hershberger On your board, are you able to measure with a scope the AR8035 CLK_25M pin? Prior to this commit the CLK_25M was hardcoded to output a 125MHz clock. Now that this setting from the ar8035 phy driver is gone we should pass this information in some form: - We tried via devicetree with the "qca,clk-out-frequency" property, but it did not work. This is an area where you could add some debug prints inside drivers/net/phy/atheros.c and see if if qca,clk-out-frequency is being parsed correctly to configure a 125MHz clock output. This is the method I used on mx6cuboxi last week and it works. - Other way to configure the AR803x is via board code. Please try to copy the ar8031_phy_fixup() and board_phy_config() from board/freescale/mx6sabresd/mx6sabresd.c into your board file. (I plan to remove this board PHY code in mx6sabresd after 2020.07 and use "qca,clk-out-frequency" to do the job).
Re: U-Boot atheros PHY support and cubox ethernet
Hi Fabio, On 24.06.20 23:35, Fabio Estevam wrote: > Hi Soeren, > > On Wed, Jun 24, 2020 at 5:45 PM Sören Moch wrote: > >> Still no luck: > > mx6cuboxi has an AR8035 too and it is working fine in U-Boot mainline. > > I am not sure why tbs2910 is failing. Could you try to bisect? > Unfortunately I have no access to my usual development board (and will not have until the v2020.07 release). I only can use an old board without working USB-OTG, limited to eMMC boot. So I tried to avoid bisecting, because a bad commit could completely brick this board. Is there a reliable way to start a new u-boot directly from a running u-boot? Soeren
Re: U-Boot atheros PHY support and cubox ethernet
Hi Soeren, On Wed, Jun 24, 2020 at 5:45 PM Sören Moch wrote: > Still no luck: mx6cuboxi has an AR8035 too and it is working fine in U-Boot mainline. I am not sure why tbs2910 is failing. Could you try to bisect?
Re: U-Boot atheros PHY support and cubox ethernet
Hi Fabio, On 24.06.20 22:29, Fabio Estevam wrote: > Hi Soeren, > > On Wed, Jun 24, 2020 at 5:13 PM Soeren Moch wrote: > >> Schematics are at >> https://www.tbsdtv.com/download/document/tbs2910/TBS2910-Matrix-ARM-mini-PC-SCH_rev2.1.pdf > Here is another patch for you to try: > https://pastebin.com/raw/Dkipgq1n Still no luck: U-Boot 2020.07-rc5-00039-g4ff63383e3-dirty (Jun 24 2020 - 22:36:43 +0200) CPU: Freescale i.MX6Q rev1.2 at 792MHz CPU: Commercial temperature grade (0C to 95C) at 47C Reset cause: POR Model: TBS2910 Matrix ARM mini PC DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... OK No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: vga Err: vga Net: eth0: ethernet@2188000 PCI: PCI: pcie phy link never came up No such bus starting USB... Bus usb@2184000: usb dr_mode not found Bus usb@2184200: USB EHCI 1.00 scanning bus usb@2184000 for devices... 1 USB Device(s) found scanning bus usb@2184200 for devices... 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Matrix U-Boot> dhcp BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 BOOTP broadcast 8 BOOTP broadcast 9 BOOTP broadcast 10 BOOTP broadcast 11 BOOTP broadcast 12 BOOTP broadcast 13 BOOTP broadcast 14 BOOTP broadcast 15 BOOTP broadcast 16 BOOTP broadcast 17 Retry time exceeded; starting again Matrix U-Boot> mdio list FEC0: 4 - AR8035 <--> ethernet@2188000 Matrix U-Boot>
Re: U-Boot atheros PHY support and cubox ethernet
Hi Soeren, On Wed, Jun 24, 2020 at 5:13 PM Soeren Moch wrote: > Schematics are at > https://www.tbsdtv.com/download/document/tbs2910/TBS2910-Matrix-ARM-mini-PC-SCH_rev2.1.pdf Here is another patch for you to try: https://pastebin.com/raw/Dkipgq1n
Re: U-Boot atheros PHY support and cubox ethernet
Hi Fabio On 24.06.20 21:39, Fabio Estevam wrote: > Hi Soeren, > > On Wed, Jun 24, 2020 at 4:20 PM Soeren Moch wrote: > >> 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? > I just tested mainline U-Boot and Ethernet works fine on a imx6qp sabresd > board: > > U-Boot SPL 2020.07-rc5-00052-g922c6d5d00 (Jun 24 2020 - 16:21:27 -0300) > Trying to boot from MMC1 > > > U-Boot 2020.07-rc5-00052-g922c6d5d00 (Jun 24 2020 - 16:21:27 -0300) > > CPU: Freescale i.MX6QP rev1.0 996 MHz (running at 792 MHz) > CPU: Automotive temperature grade (-40C to 125C) at 30C > Reset cause: POR > Model: Freescale i.MX6 Quad Plus SABRE Smart Device Board > Board: MX6-SabreSD > I2C: ready > DRAM: 1 GiB > PMIC: PFUZE100 ID=0x10 > MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 3 > Loading Environment from MMC... OK > No panel detected: default to Hannstar-XGA > Display: Hannstar-XGA (1024x768) > In:serial > Out: serial > Err: serial > Net: eth0: ethernet@2188000 > Hit any key to stop autoboot: 0 > => dhcp zImage > BOOTP broadcast 1 > DHCP client bound to address 192.168.0.24 (50 ms) > Using ethernet@2188000 device > TFTP from server 192.168.0.12; our IP address is 192.168.0.24 > Filename 'zImage'. > Load address: 0x1200 > Loading: # > # > # > # > # > # > # > # > # > # > 1.3 MiB/s > done > Bytes transferred = 9468928 (907c00 hex) > => mdio list > FEC0: > 1 - AR8031/AR8033 <--> ethernet@2188000 > => > > What is the exact failure you see? Is the Ethernet PHY found at the > correct address and probed? From what I see nothing is obviously wrong, just no ethernet connection: U-Boot 2020.07-rc5-00039-g4ff63383e3-dirty (Jun 24 2020 - 21:48:31 +0200) CPU: Freescale i.MX6Q rev1.2 at 792MHz CPU: Commercial temperature grade (0C to 95C) at 42C Reset cause: POR Model: TBS2910 Matrix ARM mini PC DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... OK No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: vga Err: vga Net: eth0: ethernet@2188000 PCI: PCI: pcie phy link never came up No such bus starting USB... Bus usb@2184000: usb dr_mode not found Bus usb@2184200: USB EHCI 1.00 scanning bus usb@2184000 for devices... 1 USB Device(s) found scanning bus usb@2184200 for devices... 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Matrix U-Boot> dhcp BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4
Re: U-Boot atheros PHY support and cubox ethernet
Hi Soeren,
On Wed, Jun 24, 2020 at 4:20 PM Soeren Moch wrote:
> 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?
I just tested mainline U-Boot and Ethernet works fine on a imx6qp sabresd board:
U-Boot SPL 2020.07-rc5-00052-g922c6d5d00 (Jun 24 2020 - 16:21:27 -0300)
Trying to boot from MMC1
U-Boot 2020.07-rc5-00052-g922c6d5d00 (Jun 24 2020 - 16:21:27 -0300)
CPU: Freescale i.MX6QP rev1.0 996 MHz (running at 792 MHz)
CPU: Automotive temperature grade (-40C to 125C) at 30C
Reset cause: POR
Model: Freescale i.MX6 Quad Plus SABRE Smart Device Board
Board: MX6-SabreSD
I2C: ready
DRAM: 1 GiB
PMIC: PFUZE100 ID=0x10
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 3
Loading Environment from MMC... OK
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In:serial
Out: serial
Err: serial
Net: eth0: ethernet@2188000
Hit any key to stop autoboot: 0
=> dhcp zImage
BOOTP broadcast 1
DHCP client bound to address 192.168.0.24 (50 ms)
Using ethernet@2188000 device
TFTP from server 192.168.0.12; our IP address is 192.168.0.24
Filename 'zImage'.
Load address: 0x1200
Loading: #
#
#
#
#
#
#
#
#
#
1.3 MiB/s
done
Bytes transferred = 9468928 (907c00 hex)
=> mdio list
FEC0:
1 - AR8031/AR8033 <--> ethernet@2188000
=>
What is the exact failure you see? Is the Ethernet PHY found at the
correct address and probed?
On tbs2910 does the AR8031 generate a 125MHz clock to the i.MX6Q Ethernet?
If so, does the change below help (I am assuming the PHY is located at
address 1, if not, please adjust the @ and reg accordingly)?
--- a/arch/arm/dts/imx6q-tbs2910.dts
+++ b/arch/arm/dts/imx6q-tbs2910.dts
@@ -108,6 +108,16 @@
phy-mode = "rgmii-id";
phy-reset-gpios = < 25 GPIO_ACTIVE_LOW>;
status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy: ethernet-phy@1 {
+ reg = <1>;
+ qca,clk-out-frequency = <12500>;
+ };
+ };
};
In case you still have issues, please share the tbs2910 schematics
with me offline so I can try to understand the failure.
Re: U-Boot atheros PHY support and cubox ethernet
On 20.06.20 04:14, Fabio Estevam wrote: > Hi Tom, > > On Thu, Jun 18, 2020 at 10:39 AM Tom Rini 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
Re: U-Boot atheros PHY support and cubox ethernet
Hi Tom, On Thu, Jun 18, 2020 at 10:39 AM Tom Rini 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.
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, Jun 17, 2020 at 09:41:17PM -0300, Fabio Estevam wrote: > On Wed, Jun 17, 2020 at 6:30 PM Tom Rini 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? -- Tom signature.asc Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
Hi Tom, On Wed, Jun 17, 2020 at 6:28 PM Fabio Estevam wrote: > > Hi Tom, > > On Wed, Jun 17, 2020 at 4:00 PM Tom Rini 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(_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.
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, Jun 17, 2020 at 6:30 PM Tom Rini 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?
Re: U-Boot atheros PHY support and cubox ethernet
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 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(_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? -- Tom signature.asc Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
Hi Tom, On Wed, Jun 17, 2020 at 4:00 PM Tom Rini 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(_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.
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, Jun 17, 2020 at 04:18:27PM -0300, Fabio Estevam wrote: > On Wed, Jun 17, 2020 at 4:09 PM Fabio Estevam wrote: > > > Does it still probe if you remove the PHY reset from the board code? > > Another suggestion: please use the ar8031_phy_fixup() and > board_phy_config() from mx6sabresd into cubox board file to see if > Ethernet works. Literal copy and paste and same failure. -- Tom signature.asc Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, Jun 17, 2020 at 04:09:19PM -0300, Fabio Estevam wrote:
> On Wed, Jun 17, 2020 at 4:00 PM Tom Rini wrote:
>
> > +#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(_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK);
> > +
> > + /* Reset PHY */
> > + ret = dm_gpio_lookup_name("GPIO4_15", );
> > + if (ret) {
> > + printf("%s: phy reset lookup failed\n", __func__);
> > + return ret;
> > + }
> > +
> > + ret = dm_gpio_request(, "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);
>
> The Ethernet PHY reset can be done via device tree.
>
> It seems we need to change it like this:
>
> --- a/arch/arm/dts/imx6qdl-sr-som.dtsi
> +++ b/arch/arm/dts/imx6qdl-sr-som.dtsi
> @@ -54,7 +54,8 @@
> pinctrl-names = "default";
> pinctrl-0 = <_microsom_enet_ar8035>;
> phy-mode = "rgmii-id";
> - phy-reset-duration = <2>;
> + phy-reset-duration = <10>;
> + phy-reset-post-delay = <1>;
> phy-reset-gpios = < 15 GPIO_ACTIVE_LOW>;
> status = "okay";
> };
>
> Does it still probe if you remove the PHY reset from the board code?
Nope, same "Could not get PHY for FEC0: addr 0". I gather from another
part of this thread there's some further breakage / unexpected changes,
so I'll chime in there next.
--
Tom
signature.asc
Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, Jun 17, 2020 at 4:09 PM Fabio Estevam wrote: > Does it still probe if you remove the PHY reset from the board code? Another suggestion: please use the ar8031_phy_fixup() and board_phy_config() from mx6sabresd into cubox board file to see if Ethernet works.
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, Jun 17, 2020 at 4:00 PM Tom Rini wrote:
> +#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(_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK);
> +
> + /* Reset PHY */
> + ret = dm_gpio_lookup_name("GPIO4_15", );
> + if (ret) {
> + printf("%s: phy reset lookup failed\n", __func__);
> + return ret;
> + }
> +
> + ret = dm_gpio_request(, "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);
The Ethernet PHY reset can be done via device tree.
It seems we need to change it like this:
--- a/arch/arm/dts/imx6qdl-sr-som.dtsi
+++ b/arch/arm/dts/imx6qdl-sr-som.dtsi
@@ -54,7 +54,8 @@
pinctrl-names = "default";
pinctrl-0 = <_microsom_enet_ar8035>;
phy-mode = "rgmii-id";
- phy-reset-duration = <2>;
+ phy-reset-duration = <10>;
+ phy-reset-post-delay = <1>;
phy-reset-gpios = < 15 GPIO_ACTIVE_LOW>;
status = "okay";
};
Does it still probe if you remove the PHY reset from the board code?
Re: U-Boot atheros PHY support and cubox ethernet
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 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", );
> - if (ret) {
> - printf("%s: phy reset lookup failed\n", __func__);
> - return;
> - }
> -
> - ret = dm_gpio_request(, "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(, 1);
Don't we need that still, but in a setup_fec() call? I have a quick
test with:
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
#include
#include
+#include
#include
#include
#include
@@ -33,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -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_VBUSIMX_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(_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK);
+
+ /* Reset PHY */
+ ret = dm_gpio_lookup_name("GPIO4_15", );
+ if (ret) {
+ printf("%s: phy reset lookup failed\n", __func__);
+ return ret;
+ }
+
+ ret = dm_gpio_request(, "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(, 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
And at run-time I get:
Warning: ethernet@2188000 using MAC address from ROM
eth0: ethernet@2188000
...
=> mdio list
FEC0:
0 - AR8035 <--> ethernet@2188000
And I did the mdio write/read's from the previous part of the thread and
get the same values.
--
Tom
signature.asc
Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, Jun 17, 2020 at 10:23 AM Tom Rini wrote: > You probably need 5f09f9af3cc335fe6a74c031cfa0b1d8bdf4b9db applied when > you see that failure, or a smaller make -j number. Ok, I fixed the issue for mx6sabresd. It was dts problem. I will send the patch.
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, Jun 17, 2020 at 10:06:25AM -0300, Fabio Estevam wrote:
> On Wed, Jun 17, 2020 at 9:04 AM Fabio Estevam wrote:
> >
> > Hi Tom,
> >
> > On Tue, Jun 16, 2020 at 7:30 PM Tom Rini 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.
>
> Just tested Ethernet on a mx6qsabresd board and I see Ethernet is
> broken in master. It works fine in 2020.04.
>
> Reverting 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually
> configurable for AR8035") did not help.
>
> git bisect is running into problems:
>
> Error: Cannot open output file
> scripts/Makefile.spl:465: recipe for target 'spl/dts/imx6dl-sabresd.dtb'
> failed
> make[1]: *** [spl/dts/imx6dl-sabresd.dtb] Error 1
> make[1]: *** Waiting for unfinished jobs
> UPD spl/./include/generated/asm-offsets.h
> UPD spl/./include/generated/generic-asm-offsets.h
> Makefile:1940: recipe for target 'spl/u-boot-spl' failed
> make: *** [spl/u-boot-spl] Error 2
>
> So not able to run a bit bisect.
You probably need 5f09f9af3cc335fe6a74c031cfa0b1d8bdf4b9db applied when
you see that failure, or a smaller make -j number.
--
Tom
signature.asc
Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, Jun 17, 2020 at 9:04 AM Fabio Estevam wrote:
>
> Hi Tom,
>
> On Tue, Jun 16, 2020 at 7:30 PM Tom Rini 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.
Just tested Ethernet on a mx6qsabresd board and I see Ethernet is
broken in master. It works fine in 2020.04.
Reverting 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually
configurable for AR8035") did not help.
git bisect is running into problems:
Error: Cannot open output file
scripts/Makefile.spl:465: recipe for target 'spl/dts/imx6dl-sabresd.dtb' failed
make[1]: *** [spl/dts/imx6dl-sabresd.dtb] Error 1
make[1]: *** Waiting for unfinished jobs
UPD spl/./include/generated/asm-offsets.h
UPD spl/./include/generated/generic-asm-offsets.h
Makefile:1940: recipe for target 'spl/u-boot-spl' failed
make: *** [spl/u-boot-spl] Error 2
So not able to run a bit bisect.
Re: U-Boot atheros PHY support and cubox ethernet
Hi Tom,
On Tue, Jun 16, 2020 at 7:30 PM Tom Rini 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.
From 6b6500681ea6ff9fdaf387f7f37865b4185bd776 Mon Sep 17 00:00:00 2001
From: Fabio Estevam
Date: Wed, 17 Jun 2020 08:52:03 -0300
Subject: [PATCH 1/2] ARM: dts: imx6qdl-sr-som: Sync with kernel 5.8-rc1
Sync the device tree with 5.8-rc1.
It basically contains the following kernel commit:
commit 86b08bd5b99480b79a25343f24c1b8c4ddcb5c09
Author: Russell King
Date: Wed Apr 15 16:44:17 2020 +0100
ARM: dts: imx6-sr-som: add ethernet PHY configuration
Add ethernet PHY configuration ahead of removing the quirk that
configures the clocking mode for the PHY. The RGMII delay is
already set correctly.
Signed-off-by: Russell King
Reviewed-by: Fabio Estevam
Signed-off-by: Shawn Guo
, which passes the 'qca,clk-out-frequency' property.
Signed-off-by: Fabio Estevam
---
arch/arm/dts/imx6qdl-sr-som.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/dts/imx6qdl-sr-som.dtsi b/arch/arm/dts/imx6qdl-sr-som.dtsi
index 6d7f6b9035..b06577808f 100644
--- a/arch/arm/dts/imx6qdl-sr-som.dtsi
+++ b/arch/arm/dts/imx6qdl-sr-som.dtsi
@@ -53,10 +53,21 @@
{
pinctrl-names = "default";
pinctrl-0 = <_microsom_enet_ar8035>;
+ phy-handle = <>;
phy-mode = "rgmii-id";
phy-reset-duration = <2>;
phy-reset-gpios = < 15 GPIO_ACTIVE_LOW>;
status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy: ethernet-phy@0 {
+ reg = <0>;
+ qca,clk-out-frequency = <12500>;
+ };
+ };
};
{
--
2.17.1
From 5125a9948a20f0e404c879bd4e477304909d9f02 Mon Sep 17 00:00:00 2001
From: Fabio Estevam
Date: Wed, 17 Jun 2020 08:55:27 -0300
Subject: [PATCH 2/2] mx6cuboxi: Convert to DM_ETH
Convert to Ethernet Driver Model.
Signed-off-by: Fabio Estevam
---
board/solidrun/mx6cuboxi/mx6cuboxi.c | 106 ---
configs/mx6cuboxi_defconfig | 4 +
include/configs/mx6cuboxi.h | 6 --
3 files changed, 4 insertions(+), 112 deletions(-)
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 94707bccb2..a2c2bb9e35 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -34,7 +33,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -237,110 +235,6 @@ int board_mmc_init(bd_t *bis)
return 0;
}
-static iomux_v3_cfg_t const enet_pads[] = {
- IOMUX_PADS(PAD_ENET_MDIO__ENET_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL)),
- IOMUX_PADS(PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL)),
- /* AR8035 reset */
- IOMUX_PADS(PAD_KEY_ROW4__GPIO4_IO15 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
- /* AR8035 interrupt */
- IOMUX_PADS(PAD_DI0_PIN2__GPIO4_IO18 | MUX_PAD_CTRL(NO_PAD_CTRL)),
- /* GPIO16 -> AR8035 25MHz */
- IOMUX_PADS(PAD_GPIO_16__ENET_REF_CLK | MUX_PAD_CTRL(NO_PAD_CTRL)),
- IOMUX_PADS(PAD_RGMII_TXC__RGMII_TXC | MUX_PAD_CTRL(NO_PAD_CTRL)),
- IOMUX_PADS(PAD_RGMII_TD0__RGMII_TD0 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
- IOMUX_PADS(PAD_RGMII_TD1__RGMII_TD1 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
- IOMUX_PADS(PAD_RGMII_TD2__RGMII_TD2 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
- IOMUX_PADS(PAD_RGMII_TD3__RGMII_TD3 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
- IOMUX_PADS(PAD_RGMII_TX_CTL__RGMII_TX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL)),
- /* AR8035 CLK_25M --> ENET_REF_CLK (V22) */
- IOMUX_PADS(PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL_CLK)),
- IOMUX_PADS(PAD_RGMII_RXC__RGMII_RXC | MUX_PAD_CTRL(ENET_PAD_CTRL)),
- IOMUX_PADS(PAD_RGMII_RD0__RGMII_RD0 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
- IOMUX_PADS(PAD_RGMII_RD1__RGMII_RD1 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
- 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)
-{
- struct gpio_desc desc;
- int ret;
-
- SETUP_IOMUX_PADS(enet_pads);
-
- ret = dm_gpio_lookup_name("GPIO4_15", );
- if (ret) {
- printf("%s: phy reset lookup failed\n", __func__);
- return;
- }
-
- ret = dm_gpio_request(, "phy-reset");
- if (ret) {
- printf("%s: phy reset request failed\n", __func__);
- return;
Re: U-Boot atheros PHY support and cubox ethernet
Am 2020-06-16 23:57, schrieb Vladimir Oltean:
On Wed, 17 Jun 2020 at 00:35, Tom Rini wrote:
On Tue, Jun 16, 2020 at 11:37:17PM +0300, Vladimir Oltean wrote:
> On Tue, 16 Jun 2020 at 23:31, Tom Rini wrote:
> >
> > On Tue, Jun 16, 2020 at 11:21:08PM +0300, Vladimir Oltean wrote:
> > > On Tue, 16 Jun 2020 at 23:10, Tom Rini wrote:
> > > >
> > > > On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Tue, 16 Jun 2020 at 22:55, Tom Rini wrote:
> > > > > >
> > > > > > Hey all,
> > > > > >
> > > > > > In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually
> > > > > > configurable for AR8035") we brought in changes to get in to line
with
> > > > > > upstream linux kernel support for this PHY and in turn deal with
more
> > > > > > "driver was wrong, DT was wrong too" changes. Now the problem I
have is
> > > > > > that ethernet on my Hummingboard doesn't work AND as far as I can
tell,
> > > > > > the DTB is correct and saying phy-mode = "rgmii-id" now not
"rgmii". It
> > > > > > also looks to match what's in v5.7 for the kernel. What do I need
to do
> > > > > > here next? Thanks!
> > > > > >
> > > > > > --
> > > > > > Tom
> > > > >
> > > > > Reverting 4346df3392c0 makes your interface work?
> > > >
> > > > Yup.
> > > >
> > > > > What is the DTS path that your hummingboard uses?
> > > >
> > > > Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c:
> > > > /*
> > > > * This is not a perfect match. Avoid dependency on the DM GPIO driver
> > > > * needed
> > > > * for accurate board detection. Hummingboard2 DT is good enough for
> > > > * U-Boot on
> > > > * all Hummingboard/Cubox-i platforms.
> > > > */
> > > > so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base. But
> > > > the board really is the original hummingboard platform. Thanks!
> > > >
> > > > --
> > > > Tom
> > >
> > > Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here?
> > >
https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L1232
> >
> > No change. And to be clear, I bisect'd the issue down and at that
> > commit, reverting it fixes ethernet. It doesn't revert cleanly (nor
> > obviously to me) on master.
> >
> > --
> > Tom
>
> On master, the revert would look like this:
>
> diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c
> index 13f7275d1706..5ba639e8119f 100644
> --- a/drivers/net/phy/atheros.c
> +++ b/drivers/net/phy/atheros.c
> @@ -124,6 +124,7 @@ static int ar8021_config(struct phy_device *phydev)
>
> static int ar803x_delay_config(struct phy_device *phydev)
> {
> + int regval;
> int ret;
>
> if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
> @@ -138,6 +139,10 @@ static int ar803x_delay_config(struct phy_device *phydev)
> else
> ret = ar803x_enable_rx_delay(phydev, false);
>
> + phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
> + regval = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e);
> + phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, (regval|0x0100));
> +
> return ret;
> }
This alone is not enough.
So if this is not enough, then I'd go back to bisecting. I'd rebase
right after 8737c65fe4e3 ("phy: atheros: consolidate
{ar8031|ar8035}_config()"), create a new patch on
board/solidrun/mx6cuboxi/mx6cuboxi.c which changes RGMII to RGMII_ID,
confirm it works (according to what you've said so far, it should),
then bless it as "git bisect good", and let the fun start :)
If these are the correct schematics, it looks like you also need the
rgmii clock:
https://developer.solid-run.com/download/i-mx6-som-simplified-schematics-rev-1-5/
https://gitlab.denx.de/u-boot/u-boot/-/commit/6333cbb3817ed551cd7d4e92f7359c73ccc567fc
So I guess you'd need both, the clock output and the correct RGMII pad
delay.
-michael
Re: U-Boot atheros PHY support and cubox ethernet
On Tue, Jun 16, 2020 at 06:01:24PM -0300, Fabio Estevam wrote: > On Tue, Jun 16, 2020 at 5:58 PM Tom Rini wrote: > > > I'm looking at the conversion now, thanks. > > When doing the DM_ETH conversion, this kernel commit may also help as > 'qca,clk-out-frequency' is also supported in U-Boot: > > commit 86b08bd5b99480b79a25343f24c1b8c4ddcb5c09 > Author: Russell King > Date: Wed Apr 15 16:44:17 2020 +0100 > > ARM: dts: imx6-sr-som: add ethernet PHY configuration > > Add ethernet PHY configuration ahead of removing the quirk that > configures the clocking mode for the PHY. The RGMII delay is > already set correctly. > > Signed-off-by: Russell King > Reviewed-by: Fabio Estevam > Signed-off-by: Shawn Guo 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. -- Tom signature.asc Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, 17 Jun 2020 at 00:35, Tom Rini wrote:
>
> On Tue, Jun 16, 2020 at 11:37:17PM +0300, Vladimir Oltean wrote:
> > On Tue, 16 Jun 2020 at 23:31, Tom Rini wrote:
> > >
> > > On Tue, Jun 16, 2020 at 11:21:08PM +0300, Vladimir Oltean wrote:
> > > > On Tue, 16 Jun 2020 at 23:10, Tom Rini wrote:
> > > > >
> > > > > On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Tue, 16 Jun 2020 at 22:55, Tom Rini wrote:
> > > > > > >
> > > > > > > Hey all,
> > > > > > >
> > > > > > > In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays
> > > > > > > actually
> > > > > > > configurable for AR8035") we brought in changes to get in to line
> > > > > > > with
> > > > > > > upstream linux kernel support for this PHY and in turn deal with
> > > > > > > more
> > > > > > > "driver was wrong, DT was wrong too" changes. Now the problem I
> > > > > > > have is
> > > > > > > that ethernet on my Hummingboard doesn't work AND as far as I can
> > > > > > > tell,
> > > > > > > the DTB is correct and saying phy-mode = "rgmii-id" now not
> > > > > > > "rgmii". It
> > > > > > > also looks to match what's in v5.7 for the kernel. What do I
> > > > > > > need to do
> > > > > > > here next? Thanks!
> > > > > > >
> > > > > > > --
> > > > > > > Tom
> > > > > >
> > > > > > Reverting 4346df3392c0 makes your interface work?
> > > > >
> > > > > Yup.
> > > > >
> > > > > > What is the DTS path that your hummingboard uses?
> > > > >
> > > > > Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c:
> > > > > /*
> > > > > * This is not a perfect match. Avoid dependency on the DM GPIO driver
> > > > > * needed
> > > > > * for accurate board detection. Hummingboard2 DT is good enough for
> > > > > * U-Boot on
> > > > > * all Hummingboard/Cubox-i platforms.
> > > > > */
> > > > > so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base.
> > > > > But
> > > > > the board really is the original hummingboard platform. Thanks!
> > > > >
> > > > > --
> > > > > Tom
> > > >
> > > > Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here?
> > > > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L1232
> > >
> > > No change. And to be clear, I bisect'd the issue down and at that
> > > commit, reverting it fixes ethernet. It doesn't revert cleanly (nor
> > > obviously to me) on master.
> > >
> > > --
> > > Tom
> >
> > On master, the revert would look like this:
> >
> > diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c
> > index 13f7275d1706..5ba639e8119f 100644
> > --- a/drivers/net/phy/atheros.c
> > +++ b/drivers/net/phy/atheros.c
> > @@ -124,6 +124,7 @@ static int ar8021_config(struct phy_device *phydev)
> >
> > static int ar803x_delay_config(struct phy_device *phydev)
> > {
> > + int regval;
> > int ret;
> >
> > if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
> > @@ -138,6 +139,10 @@ static int ar803x_delay_config(struct phy_device
> > *phydev)
> > else
> > ret = ar803x_enable_rx_delay(phydev, false);
> >
> > + phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
> > + regval = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e);
> > + phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, (regval|0x0100));
> > +
> > return ret;
> > }
>
> This alone is not enough.
>
So if this is not enough, then I'd go back to bisecting. I'd rebase
right after 8737c65fe4e3 ("phy: atheros: consolidate
{ar8031|ar8035}_config()"), create a new patch on
board/solidrun/mx6cuboxi/mx6cuboxi.c which changes RGMII to RGMII_ID,
confirm it works (according to what you've said so far, it should),
then bless it as "git bisect good", and let the fun start :)
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, 17 Jun 2020 at 00:57, Tom Rini wrote:
>
> On Wed, Jun 17, 2020 at 12:04:16AM +0300, Vladimir Oltean wrote:
> > On Wed, 17 Jun 2020 at 00:01, Vladimir Oltean wrote:
> > >
> > > On Tue, 16 Jun 2020 at 23:58, Tom Rini wrote:
> > > >
> > > > On Tue, Jun 16, 2020 at 05:55:10PM -0300, Fabio Estevam wrote:
> > > > > On Tue, Jun 16, 2020 at 5:51 PM Tom Rini wrote:
> > > > >
> > > > > > Ah. So this is probably why the DT being right isn't helping then.
> > > > > > If
> > > > > > you want to blind-convert I'm happy to test, otherwise do you have a
> > > > > > similar board conversion for me to look at? Thanks!
> > > > >
> > > > > Please try Vladimir's suggestion as it seems to be the less intrusive
> > > > > approach:
> > > > >
> > > > > --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > > > +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > > > @@ -321,7 +321,7 @@ int board_eth_init(bd_t *bis)
> > > > > if (!bus)
> > > > > return -EINVAL;
> > > > >
> > > > > - phydev = phy_find_by_mask(bus, ETH_PHY_MASK,
> > > > > PHY_INTERFACE_MODE_RGMII);
> > > > > + phydev = phy_find_by_mask(bus, ETH_PHY_MASK,
> > > > > PHY_INTERFACE_MODE_RGMII_ID);
> > > > > if (!phydev) {
> > > > > ret = -EINVAL;
> > > > > goto free_bus;
> > > > >
> > > >
> > > > OK, tried that and not enough. Console says PHY autoneg completes, but
> > > > DHCP still doesn't reply.
> > > >
> > >
> > > What about with the manual revert in place? What does
> > > phydev->interface print? Not only in atheros.c, but also in
> > > mx6cuboxi.c, right below this phy_find_by_mask call.
> > > Trying to understand if this is your only problem or if there are more.
> >
> > In fact there's one more 'manual' thing you can do.
>
> For this test, based on your previous email and the kernel dts files, I
> made the change to mx6cuboxi.c to pass PHY_INTERFACE_MODE_RGMII_ID to
> phy_find_by_mask(...).
>
> > Check if RX delay is enabled (bit 15 of debug register 0):
> > => mdio write eTSEC1 0x1D 0
> > => mdio read eTSEC1 0x1E
> > => mdio write eTSEC1 0x1E
>
> => mdio list
> FEC:
> 0 - AR8035 <--> FEC
> => mdio write FEC 0x1D 0
> => mdio read FEC 0x1E
> Reading from bus FEC
> PHY at address 0:
> 30 - 0x82ee
> ... so it's enabled already.
>
> > Check if TX delay is enabled (bit 8 of debug register 5):
> > => mdio write eTSEC1 0x1D 5
> > => mdio read eTSEC1 0x1E
> > => mdio write eTSEC1 0x1E
>
> => mdio write FEC 0x1D 5
> => mdio read FEC 0x1E
> Reading from bus FEC
> PHY at address 0:
> 30 - 0x2d47
> ... so it's enabled already.
>
> Or did I make a mistake? Thanks!
>
> --
> Tom
Yes, the PHY has RGMII delays enabled in both directions.
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, Jun 17, 2020 at 12:01:39AM +0300, Vladimir Oltean wrote:
> On Tue, 16 Jun 2020 at 23:58, Tom Rini wrote:
> >
> > On Tue, Jun 16, 2020 at 05:55:10PM -0300, Fabio Estevam wrote:
> > > On Tue, Jun 16, 2020 at 5:51 PM Tom Rini wrote:
> > >
> > > > Ah. So this is probably why the DT being right isn't helping then. If
> > > > you want to blind-convert I'm happy to test, otherwise do you have a
> > > > similar board conversion for me to look at? Thanks!
> > >
> > > Please try Vladimir's suggestion as it seems to be the less intrusive
> > > approach:
> > >
> > > --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > @@ -321,7 +321,7 @@ int board_eth_init(bd_t *bis)
> > > if (!bus)
> > > return -EINVAL;
> > >
> > > - phydev = phy_find_by_mask(bus, ETH_PHY_MASK,
> > > PHY_INTERFACE_MODE_RGMII);
> > > + phydev = phy_find_by_mask(bus, ETH_PHY_MASK,
> > > PHY_INTERFACE_MODE_RGMII_ID);
> > > if (!phydev) {
> > > ret = -EINVAL;
> > > goto free_bus;
> > >
> >
> > OK, tried that and not enough. Console says PHY autoneg completes, but
> > DHCP still doesn't reply.
> >
>
> What about with the manual revert in place? What does
> phydev->interface print? Not only in atheros.c, but also in
> mx6cuboxi.c, right below this phy_find_by_mask call.
> Trying to understand if this is your only problem or if there are more.
In both functions the value printed out for phydev->interface is the
value passed to phy_find_by_mask(...).
--
Tom
signature.asc
Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, Jun 17, 2020 at 12:04:16AM +0300, Vladimir Oltean wrote:
> On Wed, 17 Jun 2020 at 00:01, Vladimir Oltean wrote:
> >
> > On Tue, 16 Jun 2020 at 23:58, Tom Rini wrote:
> > >
> > > On Tue, Jun 16, 2020 at 05:55:10PM -0300, Fabio Estevam wrote:
> > > > On Tue, Jun 16, 2020 at 5:51 PM Tom Rini wrote:
> > > >
> > > > > Ah. So this is probably why the DT being right isn't helping then.
> > > > > If
> > > > > you want to blind-convert I'm happy to test, otherwise do you have a
> > > > > similar board conversion for me to look at? Thanks!
> > > >
> > > > Please try Vladimir's suggestion as it seems to be the less intrusive
> > > > approach:
> > > >
> > > > --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > > +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > > @@ -321,7 +321,7 @@ int board_eth_init(bd_t *bis)
> > > > if (!bus)
> > > > return -EINVAL;
> > > >
> > > > - phydev = phy_find_by_mask(bus, ETH_PHY_MASK,
> > > > PHY_INTERFACE_MODE_RGMII);
> > > > + phydev = phy_find_by_mask(bus, ETH_PHY_MASK,
> > > > PHY_INTERFACE_MODE_RGMII_ID);
> > > > if (!phydev) {
> > > > ret = -EINVAL;
> > > > goto free_bus;
> > > >
> > >
> > > OK, tried that and not enough. Console says PHY autoneg completes, but
> > > DHCP still doesn't reply.
> > >
> >
> > What about with the manual revert in place? What does
> > phydev->interface print? Not only in atheros.c, but also in
> > mx6cuboxi.c, right below this phy_find_by_mask call.
> > Trying to understand if this is your only problem or if there are more.
>
> In fact there's one more 'manual' thing you can do.
For this test, based on your previous email and the kernel dts files, I
made the change to mx6cuboxi.c to pass PHY_INTERFACE_MODE_RGMII_ID to
phy_find_by_mask(...).
> Check if RX delay is enabled (bit 15 of debug register 0):
> => mdio write eTSEC1 0x1D 0
> => mdio read eTSEC1 0x1E
> => mdio write eTSEC1 0x1E
=> mdio list
FEC:
0 - AR8035 <--> FEC
=> mdio write FEC 0x1D 0
=> mdio read FEC 0x1E
Reading from bus FEC
PHY at address 0:
30 - 0x82ee
... so it's enabled already.
> Check if TX delay is enabled (bit 8 of debug register 5):
> => mdio write eTSEC1 0x1D 5
> => mdio read eTSEC1 0x1E
> => mdio write eTSEC1 0x1E
=> mdio write FEC 0x1D 5
=> mdio read FEC 0x1E
Reading from bus FEC
PHY at address 0:
30 - 0x2d47
... so it's enabled already.
Or did I make a mistake? Thanks!
--
Tom
signature.asc
Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
On Tue, Jun 16, 2020 at 11:30:00PM +0200, Michael Walle wrote:
> Am 16. Juni 2020 22:21:08 MESZ schrieb Vladimir Oltean :
> >On Tue, 16 Jun 2020 at 23:10, Tom Rini wrote:
> >>
> >> On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
> >> > Hi Tom,
> >> >
> >> > On Tue, 16 Jun 2020 at 22:55, Tom Rini wrote:
> >> > >
> >> > > Hey all,
> >> > >
> >> > > In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays
> >actually
> >> > > configurable for AR8035") we brought in changes to get in to line
> >with
> >> > > upstream linux kernel support for this PHY and in turn deal with
> >more
> >> > > "driver was wrong, DT was wrong too" changes. Now the problem I
> >have is
> >> > > that ethernet on my Hummingboard doesn't work AND as far as I can
> >tell,
> >> > > the DTB is correct and saying phy-mode = "rgmii-id" now not
> >"rgmii". It
> >> > > also looks to match what's in v5.7 for the kernel. What do I
> >need to do
> >> > > here next? Thanks!
> >> > >
> >> > > --
> >> > > Tom
> >> >
> >> > Reverting 4346df3392c0 makes your interface work?
> >>
> >> Yup.
> >>
> >> > What is the DTS path that your hummingboard uses?
> >>
> >> Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c:
> >> /*
> >> * This is not a perfect match. Avoid dependency on the DM GPIO
> >driver
> >> * needed
> >> * for accurate board detection. Hummingboard2 DT is good enough for
> >> * U-Boot on
> >> * all Hummingboard/Cubox-i platforms.
> >> */
> >> so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base.
> >But
> >> the board really is the original hummingboard platform. Thanks!
> >>
> >> --
> >> Tom
> >
> >Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here?
> >https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L1232
>
> it should be PHY_INTERFACE_MODE_RGMII_TXID to get the original behavior,
> shouldn't it? The commit in question only removes the hardcoded TX delay.
This change alone also still fails on master for me.
--
Tom
signature.asc
Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
On Tue, Jun 16, 2020 at 11:37:17PM +0300, Vladimir Oltean wrote:
> On Tue, 16 Jun 2020 at 23:31, Tom Rini wrote:
> >
> > On Tue, Jun 16, 2020 at 11:21:08PM +0300, Vladimir Oltean wrote:
> > > On Tue, 16 Jun 2020 at 23:10, Tom Rini wrote:
> > > >
> > > > On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Tue, 16 Jun 2020 at 22:55, Tom Rini wrote:
> > > > > >
> > > > > > Hey all,
> > > > > >
> > > > > > In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually
> > > > > > configurable for AR8035") we brought in changes to get in to line
> > > > > > with
> > > > > > upstream linux kernel support for this PHY and in turn deal with
> > > > > > more
> > > > > > "driver was wrong, DT was wrong too" changes. Now the problem I
> > > > > > have is
> > > > > > that ethernet on my Hummingboard doesn't work AND as far as I can
> > > > > > tell,
> > > > > > the DTB is correct and saying phy-mode = "rgmii-id" now not
> > > > > > "rgmii". It
> > > > > > also looks to match what's in v5.7 for the kernel. What do I need
> > > > > > to do
> > > > > > here next? Thanks!
> > > > > >
> > > > > > --
> > > > > > Tom
> > > > >
> > > > > Reverting 4346df3392c0 makes your interface work?
> > > >
> > > > Yup.
> > > >
> > > > > What is the DTS path that your hummingboard uses?
> > > >
> > > > Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c:
> > > > /*
> > > > * This is not a perfect match. Avoid dependency on the DM GPIO driver
> > > > * needed
> > > > * for accurate board detection. Hummingboard2 DT is good enough for
> > > > * U-Boot on
> > > > * all Hummingboard/Cubox-i platforms.
> > > > */
> > > > so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base. But
> > > > the board really is the original hummingboard platform. Thanks!
> > > >
> > > > --
> > > > Tom
> > >
> > > Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here?
> > > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L1232
> >
> > No change. And to be clear, I bisect'd the issue down and at that
> > commit, reverting it fixes ethernet. It doesn't revert cleanly (nor
> > obviously to me) on master.
> >
> > --
> > Tom
>
> On master, the revert would look like this:
>
> diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c
> index 13f7275d1706..5ba639e8119f 100644
> --- a/drivers/net/phy/atheros.c
> +++ b/drivers/net/phy/atheros.c
> @@ -124,6 +124,7 @@ static int ar8021_config(struct phy_device *phydev)
>
> static int ar803x_delay_config(struct phy_device *phydev)
> {
> + int regval;
> int ret;
>
> if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
> @@ -138,6 +139,10 @@ static int ar803x_delay_config(struct phy_device *phydev)
> else
> ret = ar803x_enable_rx_delay(phydev, false);
>
> + phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
> + regval = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e);
> + phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, (regval|0x0100));
> +
> return ret;
> }
This alone is not enough.
> The next thing to check is to print the value of phydev->interface there.
> 7 is PHY_INTERFACE_MODE_RGMII,
> 8 is PHY_INTERFACE_MODE_RGMII_ID,
> 9 is PHY_INTERFACE_MODE_RGMII_RXID,
> 10 is PHY_INTERFACE_MODE_RGMII_TXID,
With only this patch, it's 7. With this added to mx6cuboxi.c:
- phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII);
+ phydev = phy_find_by_mask(bus, ETH_PHY_MASK,
PHY_INTERFACE_MODE_RGMII_ID);
it's 8, and doesn't work either. Moving on to the next emails now.
--
Tom
signature.asc
Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
Am 16. Juni 2020 22:21:08 MESZ schrieb Vladimir Oltean :
>On Tue, 16 Jun 2020 at 23:10, Tom Rini wrote:
>>
>> On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
>> > Hi Tom,
>> >
>> > On Tue, 16 Jun 2020 at 22:55, Tom Rini wrote:
>> > >
>> > > Hey all,
>> > >
>> > > In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays
>actually
>> > > configurable for AR8035") we brought in changes to get in to line
>with
>> > > upstream linux kernel support for this PHY and in turn deal with
>more
>> > > "driver was wrong, DT was wrong too" changes. Now the problem I
>have is
>> > > that ethernet on my Hummingboard doesn't work AND as far as I can
>tell,
>> > > the DTB is correct and saying phy-mode = "rgmii-id" now not
>"rgmii". It
>> > > also looks to match what's in v5.7 for the kernel. What do I
>need to do
>> > > here next? Thanks!
>> > >
>> > > --
>> > > Tom
>> >
>> > Reverting 4346df3392c0 makes your interface work?
>>
>> Yup.
>>
>> > What is the DTS path that your hummingboard uses?
>>
>> Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c:
>> /*
>> * This is not a perfect match. Avoid dependency on the DM GPIO
>driver
>> * needed
>> * for accurate board detection. Hummingboard2 DT is good enough for
>> * U-Boot on
>> * all Hummingboard/Cubox-i platforms.
>> */
>> so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base.
>But
>> the board really is the original hummingboard platform. Thanks!
>>
>> --
>> Tom
>
>Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here?
>https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L1232
it should be PHY_INTERFACE_MODE_RGMII_TXID to get the original behavior,
shouldn't it? The commit in question only removes the hardcoded TX delay.
-michael
Re: U-Boot atheros PHY support and cubox ethernet
On Wed, 17 Jun 2020 at 00:01, Vladimir Oltean wrote:
>
> On Tue, 16 Jun 2020 at 23:58, Tom Rini wrote:
> >
> > On Tue, Jun 16, 2020 at 05:55:10PM -0300, Fabio Estevam wrote:
> > > On Tue, Jun 16, 2020 at 5:51 PM Tom Rini wrote:
> > >
> > > > Ah. So this is probably why the DT being right isn't helping then. If
> > > > you want to blind-convert I'm happy to test, otherwise do you have a
> > > > similar board conversion for me to look at? Thanks!
> > >
> > > Please try Vladimir's suggestion as it seems to be the less intrusive
> > > approach:
> > >
> > > --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > > @@ -321,7 +321,7 @@ int board_eth_init(bd_t *bis)
> > > if (!bus)
> > > return -EINVAL;
> > >
> > > - phydev = phy_find_by_mask(bus, ETH_PHY_MASK,
> > > PHY_INTERFACE_MODE_RGMII);
> > > + phydev = phy_find_by_mask(bus, ETH_PHY_MASK,
> > > PHY_INTERFACE_MODE_RGMII_ID);
> > > if (!phydev) {
> > > ret = -EINVAL;
> > > goto free_bus;
> > >
> >
> > OK, tried that and not enough. Console says PHY autoneg completes, but
> > DHCP still doesn't reply.
> >
>
> What about with the manual revert in place? What does
> phydev->interface print? Not only in atheros.c, but also in
> mx6cuboxi.c, right below this phy_find_by_mask call.
> Trying to understand if this is your only problem or if there are more.
In fact there's one more 'manual' thing you can do.
Check if RX delay is enabled (bit 15 of debug register 0):
=> mdio write eTSEC1 0x1D 0
=> mdio read eTSEC1 0x1E
=> mdio write eTSEC1 0x1E
Check if TX delay is enabled (bit 8 of debug register 5):
=> mdio write eTSEC1 0x1D 5
=> mdio read eTSEC1 0x1E
=> mdio write eTSEC1 0x1E
(replace eTSEC1 with your mdio bus name from "mdio list")
Re: U-Boot atheros PHY support and cubox ethernet
On Tue, 16 Jun 2020 at 23:58, Tom Rini wrote:
>
> On Tue, Jun 16, 2020 at 05:55:10PM -0300, Fabio Estevam wrote:
> > On Tue, Jun 16, 2020 at 5:51 PM Tom Rini wrote:
> >
> > > Ah. So this is probably why the DT being right isn't helping then. If
> > > you want to blind-convert I'm happy to test, otherwise do you have a
> > > similar board conversion for me to look at? Thanks!
> >
> > Please try Vladimir's suggestion as it seems to be the less intrusive
> > approach:
> >
> > --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> > @@ -321,7 +321,7 @@ int board_eth_init(bd_t *bis)
> > if (!bus)
> > return -EINVAL;
> >
> > - phydev = phy_find_by_mask(bus, ETH_PHY_MASK,
> > PHY_INTERFACE_MODE_RGMII);
> > + phydev = phy_find_by_mask(bus, ETH_PHY_MASK,
> > PHY_INTERFACE_MODE_RGMII_ID);
> > if (!phydev) {
> > ret = -EINVAL;
> > goto free_bus;
> >
>
> OK, tried that and not enough. Console says PHY autoneg completes, but
> DHCP still doesn't reply.
>
What about with the manual revert in place? What does
phydev->interface print? Not only in atheros.c, but also in
mx6cuboxi.c, right below this phy_find_by_mask call.
Trying to understand if this is your only problem or if there are more.
Re: U-Boot atheros PHY support and cubox ethernet
On Tue, Jun 16, 2020 at 5:58 PM Tom Rini wrote: > I'm looking at the conversion now, thanks. When doing the DM_ETH conversion, this kernel commit may also help as 'qca,clk-out-frequency' is also supported in U-Boot: commit 86b08bd5b99480b79a25343f24c1b8c4ddcb5c09 Author: Russell King Date: Wed Apr 15 16:44:17 2020 +0100 ARM: dts: imx6-sr-som: add ethernet PHY configuration Add ethernet PHY configuration ahead of removing the quirk that configures the clocking mode for the PHY. The RGMII delay is already set correctly. Signed-off-by: Russell King Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo
Re: U-Boot atheros PHY support and cubox ethernet
On Tue, Jun 16, 2020 at 05:55:10PM -0300, Fabio Estevam wrote:
> On Tue, Jun 16, 2020 at 5:51 PM Tom Rini wrote:
>
> > Ah. So this is probably why the DT being right isn't helping then. If
> > you want to blind-convert I'm happy to test, otherwise do you have a
> > similar board conversion for me to look at? Thanks!
>
> Please try Vladimir's suggestion as it seems to be the less intrusive
> approach:
>
> --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> @@ -321,7 +321,7 @@ int board_eth_init(bd_t *bis)
> if (!bus)
> return -EINVAL;
>
> - phydev = phy_find_by_mask(bus, ETH_PHY_MASK,
> PHY_INTERFACE_MODE_RGMII);
> + phydev = phy_find_by_mask(bus, ETH_PHY_MASK,
> PHY_INTERFACE_MODE_RGMII_ID);
> if (!phydev) {
> ret = -EINVAL;
> goto free_bus;
>
OK, tried that and not enough. Console says PHY autoneg completes, but
DHCP still doesn't reply.
> Here is a similar DM_ETH board conversion:
>
> commit 02ee7a4aa57b37d6003263b69b1852c4cda5975e
> Author: Alifer Moraes
> Date: Mon Feb 10 11:28:01 2020 -0300
>
> mx6sabresd: Convert ethernet to driver model
>
> Convert imx6sabresd ethernet to driver model to fix the following warning:
>
> = WARNING ==
> This board does not use CONFIG_DM_ETH (Driver Model
> for Ethernet drivers). Please update the board to use
> CONFIG_DM_ETH before the v2020.07 release. Failure to
> update by the deadline may result in board removal.
> See doc/driver-model/migration.rst for more info.
>
>
> Signed-off-by: Alifer Moraes
> Reviewed-by: Fabio Estevam
>
> Let us know if this helps.
I'm looking at the conversion now, thanks.
--
Tom
signature.asc
Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
On Tue, Jun 16, 2020 at 5:51 PM Tom Rini wrote:
> Ah. So this is probably why the DT being right isn't helping then. If
> you want to blind-convert I'm happy to test, otherwise do you have a
> similar board conversion for me to look at? Thanks!
Please try Vladimir's suggestion as it seems to be the less intrusive approach:
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -321,7 +321,7 @@ int board_eth_init(bd_t *bis)
if (!bus)
return -EINVAL;
- phydev = phy_find_by_mask(bus, ETH_PHY_MASK, PHY_INTERFACE_MODE_RGMII);
+ phydev = phy_find_by_mask(bus, ETH_PHY_MASK,
PHY_INTERFACE_MODE_RGMII_ID);
if (!phydev) {
ret = -EINVAL;
goto free_bus;
Here is a similar DM_ETH board conversion:
commit 02ee7a4aa57b37d6003263b69b1852c4cda5975e
Author: Alifer Moraes
Date: Mon Feb 10 11:28:01 2020 -0300
mx6sabresd: Convert ethernet to driver model
Convert imx6sabresd ethernet to driver model to fix the following warning:
= WARNING ==
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
Signed-off-by: Alifer Moraes
Reviewed-by: Fabio Estevam
Let us know if this helps.
Re: U-Boot atheros PHY support and cubox ethernet
On Tue, Jun 16, 2020 at 05:42:34PM -0300, Fabio Estevam wrote:
> Hi Tom,
>
> On Tue, Jun 16, 2020 at 4:55 PM Tom Rini wrote:
> >
> > Hey all,
> >
> > In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually
> > configurable for AR8035") we brought in changes to get in to line with
> > upstream linux kernel support for this PHY and in turn deal with more
> > "driver was wrong, DT was wrong too" changes. Now the problem I have is
> > that ethernet on my Hummingboard doesn't work AND as far as I can tell,
> > the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It
> > also looks to match what's in v5.7 for the kernel. What do I need to do
> > here next? Thanks!
>
> mx6cuboxi_defconfig still needs to be converted to DM_ETH.
>
> Unfortunately, I don't have access to my mx6cuboxi board to work on this.
Ah. So this is probably why the DT being right isn't helping then. If
you want to blind-convert I'm happy to test, otherwise do you have a
similar board conversion for me to look at? Thanks!
--
Tom
signature.asc
Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
On Tue, 16 Jun 2020 at 23:43, Fabio Estevam wrote:
>
> Hi Tom,
>
> On Tue, Jun 16, 2020 at 4:55 PM Tom Rini wrote:
> >
> > Hey all,
> >
> > In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually
> > configurable for AR8035") we brought in changes to get in to line with
> > upstream linux kernel support for this PHY and in turn deal with more
> > "driver was wrong, DT was wrong too" changes. Now the problem I have is
> > that ethernet on my Hummingboard doesn't work AND as far as I can tell,
> > the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It
> > also looks to match what's in v5.7 for the kernel. What do I need to do
> > here next? Thanks!
>
> mx6cuboxi_defconfig still needs to be converted to DM_ETH.
>
> Unfortunately, I don't have access to my mx6cuboxi board to work on this.
Oh, cool, thanks for the tip.
Tom, I'll spare you the suffering.
It's this one:
https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/solidrun/mx6cuboxi/mx6cuboxi.c#L324
-Vladimir
Re: U-Boot atheros PHY support and cubox ethernet
Hi Tom,
On Tue, Jun 16, 2020 at 4:55 PM Tom Rini wrote:
>
> Hey all,
>
> In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually
> configurable for AR8035") we brought in changes to get in to line with
> upstream linux kernel support for this PHY and in turn deal with more
> "driver was wrong, DT was wrong too" changes. Now the problem I have is
> that ethernet on my Hummingboard doesn't work AND as far as I can tell,
> the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It
> also looks to match what's in v5.7 for the kernel. What do I need to do
> here next? Thanks!
mx6cuboxi_defconfig still needs to be converted to DM_ETH.
Unfortunately, I don't have access to my mx6cuboxi board to work on this.
Re: U-Boot atheros PHY support and cubox ethernet
On Tue, 16 Jun 2020 at 23:31, Tom Rini wrote:
>
> On Tue, Jun 16, 2020 at 11:21:08PM +0300, Vladimir Oltean wrote:
> > On Tue, 16 Jun 2020 at 23:10, Tom Rini wrote:
> > >
> > > On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, 16 Jun 2020 at 22:55, Tom Rini wrote:
> > > > >
> > > > > Hey all,
> > > > >
> > > > > In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually
> > > > > configurable for AR8035") we brought in changes to get in to line with
> > > > > upstream linux kernel support for this PHY and in turn deal with more
> > > > > "driver was wrong, DT was wrong too" changes. Now the problem I have
> > > > > is
> > > > > that ethernet on my Hummingboard doesn't work AND as far as I can
> > > > > tell,
> > > > > the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii".
> > > > > It
> > > > > also looks to match what's in v5.7 for the kernel. What do I need to
> > > > > do
> > > > > here next? Thanks!
> > > > >
> > > > > --
> > > > > Tom
> > > >
> > > > Reverting 4346df3392c0 makes your interface work?
> > >
> > > Yup.
> > >
> > > > What is the DTS path that your hummingboard uses?
> > >
> > > Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c:
> > > /*
> > > * This is not a perfect match. Avoid dependency on the DM GPIO driver
> > > * needed
> > > * for accurate board detection. Hummingboard2 DT is good enough for
> > > * U-Boot on
> > > * all Hummingboard/Cubox-i platforms.
> > > */
> > > so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base. But
> > > the board really is the original hummingboard platform. Thanks!
> > >
> > > --
> > > Tom
> >
> > Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here?
> > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L1232
>
> No change. And to be clear, I bisect'd the issue down and at that
> commit, reverting it fixes ethernet. It doesn't revert cleanly (nor
> obviously to me) on master.
>
> --
> Tom
On master, the revert would look like this:
diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c
index 13f7275d1706..5ba639e8119f 100644
--- a/drivers/net/phy/atheros.c
+++ b/drivers/net/phy/atheros.c
@@ -124,6 +124,7 @@ static int ar8021_config(struct phy_device *phydev)
static int ar803x_delay_config(struct phy_device *phydev)
{
+ int regval;
int ret;
if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
@@ -138,6 +139,10 @@ static int ar803x_delay_config(struct phy_device *phydev)
else
ret = ar803x_enable_rx_delay(phydev, false);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
+ regval = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, (regval|0x0100));
+
return ret;
}
The next thing to check is to print the value of phydev->interface there.
7 is PHY_INTERFACE_MODE_RGMII,
8 is PHY_INTERFACE_MODE_RGMII_ID,
9 is PHY_INTERFACE_MODE_RGMII_RXID,
10 is PHY_INTERFACE_MODE_RGMII_TXID,
You want it to be 8.
Thanks,
-Vladimir
Re: U-Boot atheros PHY support and cubox ethernet
On Tue, Jun 16, 2020 at 11:21:08PM +0300, Vladimir Oltean wrote:
> On Tue, 16 Jun 2020 at 23:10, Tom Rini wrote:
> >
> > On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
> > > Hi Tom,
> > >
> > > On Tue, 16 Jun 2020 at 22:55, Tom Rini wrote:
> > > >
> > > > Hey all,
> > > >
> > > > In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually
> > > > configurable for AR8035") we brought in changes to get in to line with
> > > > upstream linux kernel support for this PHY and in turn deal with more
> > > > "driver was wrong, DT was wrong too" changes. Now the problem I have is
> > > > that ethernet on my Hummingboard doesn't work AND as far as I can tell,
> > > > the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It
> > > > also looks to match what's in v5.7 for the kernel. What do I need to do
> > > > here next? Thanks!
> > > >
> > > > --
> > > > Tom
> > >
> > > Reverting 4346df3392c0 makes your interface work?
> >
> > Yup.
> >
> > > What is the DTS path that your hummingboard uses?
> >
> > Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c:
> > /*
> > * This is not a perfect match. Avoid dependency on the DM GPIO driver
> > * needed
> > * for accurate board detection. Hummingboard2 DT is good enough for
> > * U-Boot on
> > * all Hummingboard/Cubox-i platforms.
> > */
> > so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base. But
> > the board really is the original hummingboard platform. Thanks!
> >
> > --
> > Tom
>
> Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here?
> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L1232
No change. And to be clear, I bisect'd the issue down and at that
commit, reverting it fixes ethernet. It doesn't revert cleanly (nor
obviously to me) on master.
--
Tom
signature.asc
Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
On Tue, 16 Jun 2020 at 23:10, Tom Rini wrote:
>
> On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
> > Hi Tom,
> >
> > On Tue, 16 Jun 2020 at 22:55, Tom Rini wrote:
> > >
> > > Hey all,
> > >
> > > In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually
> > > configurable for AR8035") we brought in changes to get in to line with
> > > upstream linux kernel support for this PHY and in turn deal with more
> > > "driver was wrong, DT was wrong too" changes. Now the problem I have is
> > > that ethernet on my Hummingboard doesn't work AND as far as I can tell,
> > > the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It
> > > also looks to match what's in v5.7 for the kernel. What do I need to do
> > > here next? Thanks!
> > >
> > > --
> > > Tom
> >
> > Reverting 4346df3392c0 makes your interface work?
>
> Yup.
>
> > What is the DTS path that your hummingboard uses?
>
> Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c:
> /*
> * This is not a perfect match. Avoid dependency on the DM GPIO driver
> * needed
> * for accurate board detection. Hummingboard2 DT is good enough for
> * U-Boot on
> * all Hummingboard/Cubox-i platforms.
> */
> so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base. But
> the board really is the original hummingboard platform. Thanks!
>
> --
> Tom
Does it work if you say PHY_INTERFACE_MODE_RGMII_ID here?
https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/net/fec_mxc.c#L1232
-Vladimir
Re: U-Boot atheros PHY support and cubox ethernet
On Tue, Jun 16, 2020 at 10:58:26PM +0300, Vladimir Oltean wrote:
> Hi Tom,
>
> On Tue, 16 Jun 2020 at 22:55, Tom Rini wrote:
> >
> > Hey all,
> >
> > In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually
> > configurable for AR8035") we brought in changes to get in to line with
> > upstream linux kernel support for this PHY and in turn deal with more
> > "driver was wrong, DT was wrong too" changes. Now the problem I have is
> > that ethernet on my Hummingboard doesn't work AND as far as I can tell,
> > the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It
> > also looks to match what's in v5.7 for the kernel. What do I need to do
> > here next? Thanks!
> >
> > --
> > Tom
>
> Reverting 4346df3392c0 makes your interface work?
Yup.
> What is the DTS path that your hummingboard uses?
Good question. Per board/solidrun/mx6cuboxi/mx6cuboxi.c:
/*
* This is not a perfect match. Avoid dependency on the DM GPIO driver
* needed
* for accurate board detection. Hummingboard2 DT is good enough for
* U-Boot on
* all Hummingboard/Cubox-i platforms.
*/
so arch/arm/dts/imx6dl-hummingboard2-emmc-som-v15.dts is the base. But
the board really is the original hummingboard platform. Thanks!
--
Tom
signature.asc
Description: PGP signature
Re: U-Boot atheros PHY support and cubox ethernet
Hi Tom,
On Tue, 16 Jun 2020 at 22:55, Tom Rini wrote:
>
> Hey all,
>
> In commit 4346df3392c0 ("phy: atheros: Make RGMII Tx delays actually
> configurable for AR8035") we brought in changes to get in to line with
> upstream linux kernel support for this PHY and in turn deal with more
> "driver was wrong, DT was wrong too" changes. Now the problem I have is
> that ethernet on my Hummingboard doesn't work AND as far as I can tell,
> the DTB is correct and saying phy-mode = "rgmii-id" now not "rgmii". It
> also looks to match what's in v5.7 for the kernel. What do I need to do
> here next? Thanks!
>
> --
> Tom
Reverting 4346df3392c0 makes your interface work?
What is the DTS path that your hummingboard uses?
Thanks,
-Vladimir
