Hi,
I cant get ethernet to work on iMX8QXP MEK board with latest sources (tried v2019.01 as well). Is this a bug or work in progress?
---
U-Boot SPL 2019.04-rc2-00134-g783e66816d (Feb 28 2019 - 13:15:40 +0100) Normal Boot Trying to boot from MMC2_2
U-Boot 2019.04-rc2-00134-g783e66816d (Feb 28 2019 - 13:15:40 +0100)
CPU: NXP i.MX8QXP RevB A35 at 147228 MHz
Model: Freescale i.MX8QXP MEK Board: iMX8QXP MEK Build: SCFW 3301c1a9 Boot: SD1 DRAM: 3 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... OK In: serial@5a060000 Out: serial@5a060000 Err: serial@5a060000 Net: eth-1: ethernet@5b040000 Hit any key to stop autoboot: 0 => dhcp No ethernet found.
---
Best regards, Andrejs Cainikovs.
Hi,
On Thu, 28 Feb 2019 12:27:45 +0000 Andrejs Cainikovs Andrejs.Cainikovs@netmodule.com wrote:
Hi,
I cant get ethernet to work on iMX8QXP MEK board with latest sources (tried v2019.01 as well). Is this a bug or work in progress?
This is probably due to the missing delay after PHY reset in fec_gpio_reset().
Please try with attached patch, it worked for me on MEK board with RevA CPU.
-- Anatolij
Hi,
On 28/02/2019 23:45, Anatolij Gustschin wrote:
I cant get ethernet to work on iMX8QXP MEK board with latest sources (tried v2019.01 as well). Is this a bug or work in progress?
This is probably due to the missing delay after PHY reset in fec_gpio_reset().
Please try with attached patch, it worked for me on MEK board with RevA CPU.
Thanks a lot! It works now.
Best regards, Andrejs Cainikovs.
Hi,
On Fri, 1 Mar 2019 09:50:06 +0000 Andrejs Cainikovs Andrejs.Cainikovs@netmodule.com wrote: ...
Thanks a lot! It works now.
Great, thanks for testing! I don't like the patch however and I'm still not sure how we should fix it in a proper way for upcoming release. Unfortunately, currently I don't have time to work on a suitable fix.
-- Anatolij
On 01/03/19 11:05, Anatolij Gustschin wrote:
Hi,
On Fri, 1 Mar 2019 09:50:06 +0000 Andrejs Cainikovs Andrejs.Cainikovs@netmodule.com wrote: ...
Thanks a lot! It works now.
Great, thanks for testing! I don't like the patch however and I'm still not sure how we should fix it in a proper way for upcoming release. Unfortunately, currently I don't have time to work on a suitable fix.
What about to change this in DT ?
diff --git a/arch/arm/dts/fsl-imx8qxp-mek.dts b/arch/arm/dts/fsl-imx8qxp-mek.dts index 41f7ec1763..b6c4593334 100644 --- a/arch/arm/dts/fsl-imx8qxp-mek.dts +++ b/arch/arm/dts/fsl-imx8qxp-mek.dts @@ -223,7 +223,7 @@ fsl,magic-packet; status = "okay"; phy-reset-gpios = <&pca9557_a 4 GPIO_ACTIVE_LOW>; - phy-reset-duration = <10>; + phy-reset-duration = <150>;
mdio { #address-cells = <1>;
Best regards, Stefano
Hi Stefano,
On Fri, 1 Mar 2019 12:19:41 +0100 Stefano Babic sbabic@denx.de wrote: ...
What about to change this in DT ?
diff --git a/arch/arm/dts/fsl-imx8qxp-mek.dts b/arch/arm/dts/fsl-imx8qxp-mek.dts index 41f7ec1763..b6c4593334 100644 --- a/arch/arm/dts/fsl-imx8qxp-mek.dts +++ b/arch/arm/dts/fsl-imx8qxp-mek.dts @@ -223,7 +223,7 @@ fsl,magic-packet; status = "okay"; phy-reset-gpios = <&pca9557_a 4 GPIO_ACTIVE_LOW>;
phy-reset-duration = <10>;
phy-reset-duration = <150>;
This will extend the time for holding the PHY in reset state, but 10ms was already enough to reset the PHY. The problem is that after reset state is deactivated, the PHY cannot be detected unless we wait about 150 ms in fec_gpio_reset() after removing the reset level. I don't now the reason why this happens.
-- Anatolij
Hi Stefano,
On 01/03/2019 12:19, Stefano Babic wrote:
What about to change this in DT ?
diff --git a/arch/arm/dts/fsl-imx8qxp-mek.dts b/arch/arm/dts/fsl-imx8qxp-mek.dts index 41f7ec1763..b6c4593334 100644 --- a/arch/arm/dts/fsl-imx8qxp-mek.dts +++ b/arch/arm/dts/fsl-imx8qxp-mek.dts @@ -223,7 +223,7 @@ fsl,magic-packet; status = "okay"; phy-reset-gpios = <&pca9557_a 4 GPIO_ACTIVE_LOW>;
phy-reset-duration = <10>;
phy-reset-duration = <150>; mdio { #address-cells = <1>;
Nope, didn't worked. This parameter is a pulse width of a reset, but the issue is about having a delay *after* reset. However, introducing a new `phy-reset-wait` is a reasonable option. Thanks for idea, I will make a patch, and then it's up to you and Anatolij to decide whether it is a ok or not.
Best regards, Andrejs Cainikovs.
On 01/03/19 13:30, Andrejs Cainikovs wrote:
Hi Stefano,
On 01/03/2019 12:19, Stefano Babic wrote:
What about to change this in DT ?
diff --git a/arch/arm/dts/fsl-imx8qxp-mek.dts b/arch/arm/dts/fsl-imx8qxp-mek.dts index 41f7ec1763..b6c4593334 100644 --- a/arch/arm/dts/fsl-imx8qxp-mek.dts +++ b/arch/arm/dts/fsl-imx8qxp-mek.dts @@ -223,7 +223,7 @@ fsl,magic-packet; status = "okay"; phy-reset-gpios = <&pca9557_a 4 GPIO_ACTIVE_LOW>;
phy-reset-duration = <10>;
phy-reset-duration = <150>; mdio { #address-cells = <1>;Nope, didn't worked. This parameter is a pulse width of a reset, but the issue is about having a delay *after* reset. However, introducing a new `phy-reset-wait` is a reasonable option.
Right, I think this is a way to do.
Thanks for idea, I will make a patch, and then it's up to you and Anatolij to decide whether it is a ok or not.
Just post the patch to Joe Hershberger, too, because he's the network maintainer.
Regards, Stefano
Hi all,
On Fri, 1 Mar 2019 13:36:17 +0100 Stefano Babic sbabic@denx.de wrote: ...
Nope, didn't worked. This parameter is a pulse width of a reset, but the issue is about having a delay *after* reset. However, introducing a new `phy-reset-wait` is a reasonable option.
Right, I think this is a way to do.
yes, this is much better than ifdef. I'd suggest using 'phy-reset-post-delay' property instead of 'phy-reset-wait'. Linux has already such binding, i.e. see Documentation/devicetree/bindings/net/fsl-fec.txt and the driver drivers/net/ethernet/freescale/fec_main.c.
-- Anatolij
On 01/03/2019 14:00, Anatolij Gustschin wrote:
Hi all,
On Fri, 1 Mar 2019 13:36:17 +0100 Stefano Babic sbabic@denx.de wrote:
Right, I think this is a way to do.
yes, this is much better than ifdef. I'd suggest using 'phy-reset-post-delay' property instead of 'phy-reset-wait'. Linux has already such binding, i.e. see Documentation/devicetree/bindings/net/fsl-fec.txt and the driver drivers/net/ethernet/freescale/fec_main.c.
Done. Please review.
participants (3)
-
Anatolij Gustschin -
Andrejs Cainikovs -
Stefano Babic