Re: [U-Boot] imx8mq-evk: Outbound network packets lost
On Fri, 1 Feb 2019, Chris Spencer wrote: On Fri, 1 Feb 2019 at 16:10, Sergey Kubushyn wrote: Turns out there's already a patch to add the driver as part of the i.MX8MM patch series. [1] Go figure. What the fcuk is i.MX8MM? Are they going to do anything with their i.MX8MQ documentation? It is currently at Rev.0 dated January 8, 2018. In its present state it is not even a joke -- it is way worse than that. It is missing lots of info while including hundreds and hundreds of pages that has absolutely no relevance to i.MX8MQ like e.g. 120 pages long description of different interfaces to LCDIF that simply don't apply to what's in that chip. On the other hand there is _ABSOLUTELY_ nothing about e.g. USB PHYs in that, sorry for an expression, documentation. Nada, zero, zilch. Not a word about SIP. And it is all around their documentation. Hell, just try to find out what those 4 input clock sources are to their PWM that are selectable from a per-PWM configuration register... And their only reaction for e.g. missing USB PHY information was "We told design/documentation guys to include it in the future revisions" somewhen around August last year. There we no revisions for a whole year since the initial Rev.0 was released. Zero. Nada. Zilch. It is still that stinking pile of manure, Rev.0 on NXP site. Looks like the i.MX8M Mini. The naming of the i.MX8 variants seems to be almost deliberatly confusing. So they put some yet non-existing chip first in their priority list and totally abandoned i.MX8MQ that is just year (?) old. Of course, they needed yet another undocumented chip badly so everything else could wait. Then there will be yet another one and so on. I bet i.MX8MM documentation will be even worse than that of i.MX8MQ that is almost impossible task -- that pile of manure was created by copypasting pieces from those different IPs they somehow glued together to make that chip. Those pieces were not edited, no glue description, many pieces are totally missing and so on. This is not what one would expect from a company that is supposed to be a decent semiconductor manufacturer. It looks like the entire i.MX family is doomed. The last decent one was i.MX6Q from Freescale. Once they got sold to NXP all that went downhill and going to its death with constantly increasing speed. Time to switch to Rockchip and its siblings and totally forget everything not designed and made in China -- Chinese stuff is at least 2x better than everything else while at least 2x cheaper. Documentation is way better and their teams are very active here in U-Boot development unlike NXP. I haven't had to do much with the documentation, but yeah it's kind of inscrutable. Just finding anything is challenging. If it is there at all. Like e.g. USB PHY. Or ethernet clocks. Or hundreds of other things. Then one should somehow sort out what actually applies to this particular chip and what just came in from copypasted IP desription and totally bogus. I guess that everything else must just happen to be usable in the default reset state. It won't work. Pins come up as GPIOs on powerup and something _MUST_ reconfigure them for Ethernet. If there is no driver and they are not reconfigured in board files there will be no Ethernet. Same is true with USB. DTS files reference USB PHY that doesn't have a driver in U-Boot. DWC3 USB references driver that doesn't exist in U-Boot. There is no wonder nothing works. Sorry, I meant stuff like the usdhc (i.e., the bare minimum that needs to work to boot into Linux). Something must do at least some initialisation here to load U-Boot in the first place. I'm guessing the Ethernet doesn't work for anyone using this chip at the moment on the upstream U-Boot. USDHC is initialized in non-DM fashion in SPL so it is still same old thing... As for Ethernet not working it is far from a single defficiency. There is no USB, no PWM, no any signs of Video (LCDIF and friends) and much more. But hey, they are busy working on that i.MX8MM that doesn't even exist yet so we're good :( That means we either have to take everything in our own hands and forget about NXP or switch to something better. That actually makes sense -- what would be the reason for holding on NXP vaporware when there are better, cheaper, actively developed chips like e.g. RK3328 or even RK3399? Just look at www.pine64.org and try to give a single reason why one would even think of using any of those NXP chips. And whatever is on pine64.org is real, existing things. I do even have ROCKPro64 on my desk now that I paid a whopping $79 for the whole SBC with 4GBytes of RAM. And there is even stock Fedora for Pine64 family... Unfortunately our higher-ups made their choice in favor of i.MX8MQ on some SOMs so I have no other choice but working on that Frankenstein... --- ** * KSI@homeKOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < >
Re: [U-Boot] imx8mq-evk: Outbound network packets lost
On Fri, 1 Feb 2019 at 16:10, Sergey Kubushyn wrote: > > Turns out there's already a patch to add the driver as part of the > > i.MX8MM patch series. [1] Go figure. > > What the fcuk is i.MX8MM? Are they going to do anything with their i.MX8MQ > documentation? It is currently at Rev.0 dated January 8, 2018. In its > present state it is not even a joke -- it is way worse than that. It is > missing lots of info while including hundreds and hundreds of pages that has > absolutely no relevance to i.MX8MQ like e.g. 120 pages long description of > different interfaces to LCDIF that simply don't apply to what's in that > chip. On the other hand there is _ABSOLUTELY_ nothing about e.g. USB PHYs in > that, sorry for an expression, documentation. Nada, zero, zilch. Not a word > about SIP. And it is all around their documentation. Hell, just try to find > out what those 4 input clock sources are to their PWM that are selectable > from a per-PWM configuration register... > > And their only reaction for e.g. missing USB PHY information was "We told > design/documentation guys to include it in the future revisions" somewhen > around August last year. There we no revisions for a whole year since the > initial Rev.0 was released. Zero. Nada. Zilch. It is still that stinking > pile of manure, Rev.0 on NXP site. Looks like the i.MX8M Mini. The naming of the i.MX8 variants seems to be almost deliberatly confusing. I haven't had to do much with the documentation, but yeah it's kind of inscrutable. Just finding anything is challenging. > > I guess that everything else must just happen to be usable in the > > default reset state. > > It won't work. Pins come up as GPIOs on powerup and something _MUST_ > reconfigure them for Ethernet. If there is no driver and they are not > reconfigured in board files there will be no Ethernet. > > Same is true with USB. DTS files reference USB PHY that doesn't have a > driver in U-Boot. DWC3 USB references driver that doesn't exist in U-Boot. > There is no wonder nothing works. Sorry, I meant stuff like the usdhc (i.e., the bare minimum that needs to work to boot into Linux). Something must do at least some initialisation here to load U-Boot in the first place. I'm guessing the Ethernet doesn't work for anyone using this chip at the moment on the upstream U-Boot. Chris ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] imx8mq-evk: Outbound network packets lost
On Fri, 1 Feb 2019, Chris Spencer wrote: On Thu, 31 Jan 2019 at 18:43, Sergey Kubushyn wrote: OK, it worked. The second patch is irrelevant for me because I'm working on a custom device, not MCIMX8M-EVK (I don't have that, just using its schematic from time to time as reference to its drivers and such) and I _DID_ have "CONFIG_PINCTRL_IMX8M=y" in my config that made no good without actual driver... I wonder how come nobody noticed that so far? It should affect other functionality that relies on proper pin muxing... Anyway, it is solved so I'm on USB (host and peripheral) now. Next come PWM/backlight/LCDIF->DSI->SN65DSI84->LVDS Panel (1024x768)... Turns out there's already a patch to add the driver as part of the i.MX8MM patch series. [1] Go figure. What the fcuk is i.MX8MM? Are they going to do anything with their i.MX8MQ documentation? It is currently at Rev.0 dated January 8, 2018. In its present state it is not even a joke -- it is way worse than that. It is missing lots of info while including hundreds and hundreds of pages that has absolutely no relevance to i.MX8MQ like e.g. 120 pages long description of different interfaces to LCDIF that simply don't apply to what's in that chip. On the other hand there is _ABSOLUTELY_ nothing about e.g. USB PHYs in that, sorry for an expression, documentation. Nada, zero, zilch. Not a word about SIP. And it is all around their documentation. Hell, just try to find out what those 4 input clock sources are to their PWM that are selectable from a per-PWM configuration register... And their only reaction for e.g. missing USB PHY information was "We told design/documentation guys to include it in the future revisions" somewhen around August last year. There we no revisions for a whole year since the initial Rev.0 was released. Zero. Nada. Zilch. It is still that stinking pile of manure, Rev.0 on NXP site. I guess that everything else must just happen to be usable in the default reset state. It won't work. Pins come up as GPIOs on powerup and something _MUST_ reconfigure them for Ethernet. If there is no driver and they are not reconfigured in board files there will be no Ethernet. Same is true with USB. DTS files reference USB PHY that doesn't have a driver in U-Boot. DWC3 USB references driver that doesn't exist in U-Boot. There is no wonder nothing works. --- ** * KSI@homeKOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] imx8mq-evk: Outbound network packets lost
On Thu, 31 Jan 2019 at 18:43, Sergey Kubushyn wrote: > OK, it worked. The second patch is irrelevant for me because I'm working on > a custom device, not MCIMX8M-EVK (I don't have that, just using its > schematic from time to time as reference to its drivers and such) and I > _DID_ have "CONFIG_PINCTRL_IMX8M=y" in my config that made no good without > actual driver... > > I wonder how come nobody noticed that so far? It should affect other > functionality that relies on proper pin muxing... > > Anyway, it is solved so I'm on USB (host and peripheral) now. Next come > PWM/backlight/LCDIF->DSI->SN65DSI84->LVDS Panel (1024x768)... Turns out there's already a patch to add the driver as part of the i.MX8MM patch series. [1] Go figure. I guess that everything else must just happen to be usable in the default reset state. Chris [1] https://lists.denx.de/pipermail/u-boot/2019-January/356400.html ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] imx8mq-evk: Outbound network packets lost
On Thu, 31 Jan 2019, Chris Spencer wrote: On Wed, 30 Jan 2019 at 00:44, Sergey Kubushyn wrote: OK, I've got it working. The problem was DM FEC driver does _NOT_ do pin muxing and FEC pins in i.MX8MQ come up as GPIOs after rest so no wonder it can't talk to the PHY or whatever else. I don't know yet if there is some setting that I've missed to force it to do pin muxing but didn't find anything appropriate in reference fsl-imx8mq-evk board configs or board source files. Once pin muxing is done in the board file FEC comes up as expected, finds the PHY and all network stuff works as expected. Dedicated "regulator" and PHY reset works OK from DTB provided FEC driver is patched for regulator (regulator_set_enable instead of regulator_autoset) and PHY reset GPIO set "ACTIVE_LOW" in the board's DTS file (fec driver sets it to "1" to reset then resets it to "0"). So it is either pin muxing is missing and one should do it in his board's file or I've missed some setting that I can't find to get the DM FEC driver to do it itself from DTS file. Welp. There's no pinctrl driver. That would explain a lot... The attached patches fix the networking in U-Boot for me (I can at least ping; haven't tried anything else). If it works for you then I will submit the patches properly with your Tested-by. Weirdly, I still get the issue in Linux where it intermittently uses the wrong phy driver, but, with this change, the generic phy driver now seems to work fine. I guess maybe U-Boot is now leaving the phy in a different state that happens to work. OK, it worked. The second patch is irrelevant for me because I'm working on a custom device, not MCIMX8M-EVK (I don't have that, just using its schematic from time to time as reference to its drivers and such) and I _DID_ have "CONFIG_PINCTRL_IMX8M=y" in my config that made no good without actual driver... I wonder how come nobody noticed that so far? It should affect other functionality that relies on proper pin muxing... Anyway, it is solved so I'm on USB (host and peripheral) now. Next come PWM/backlight/LCDIF->DSI->SN65DSI84->LVDS Panel (1024x768)... --- ** * KSI@homeKOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] imx8mq-evk: Outbound network packets lost
On Wed, 30 Jan 2019 at 00:44, Sergey Kubushyn wrote:
> OK, I've got it working. The problem was DM FEC driver does _NOT_ do pin
> muxing and FEC pins in i.MX8MQ come up as GPIOs after rest so no wonder it
> can't talk to the PHY or whatever else.
>
> I don't know yet if there is some setting that I've missed to force it to do
> pin muxing but didn't find anything appropriate in reference fsl-imx8mq-evk
> board configs or board source files.
>
> Once pin muxing is done in the board file FEC comes up as expected, finds
> the PHY and all network stuff works as expected.
>
> Dedicated "regulator" and PHY reset works OK from DTB provided FEC driver is
> patched for regulator (regulator_set_enable instead of regulator_autoset)
> and PHY reset GPIO set "ACTIVE_LOW" in the board's DTS file (fec driver sets
> it to "1" to reset then resets it to "0").
>
> So it is either pin muxing is missing and one should do it in his board's
> file or I've missed some setting that I can't find to get the DM FEC driver
> to do it itself from DTS file.
Welp. There's no pinctrl driver. That would explain a lot...
The attached patches fix the networking in U-Boot for me (I can at
least ping; haven't tried anything else). If it works for you then I
will submit the patches properly with your Tested-by.
Weirdly, I still get the issue in Linux where it intermittently uses
the wrong phy driver, but, with this change, the generic phy driver
now seems to work fine. I guess maybe U-Boot is now leaving the phy in
a different state that happens to work.
Chris
From 5af35b93185541245b7d77fd8e73e616c4219086 Mon Sep 17 00:00:00 2001
From: Chris Spencer
Date: Wed, 30 Jan 2019 18:02:02 +
Subject: [PATCH 2/2] imx8mq_evk_defconfig: Enable pinctrl driver
The Ethernet controller is not able to initialise correctly without the
pinctrl driver.
Fixes: 86ac7a9a5d0c ("imx: add i.MX8MQ EVK support")
Signed-off-by: Chris Spencer
---
configs/imx8mq_evk_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/imx8mq_evk_defconfig b/configs/imx8mq_evk_defconfig
index 53025e45bc..68656b0cd3 100644
--- a/configs/imx8mq_evk_defconfig
+++ b/configs/imx8mq_evk_defconfig
@@ -29,6 +29,7 @@ CONFIG_SYS_I2C_MXC=y
CONFIG_DM_MMC=y
CONFIG_DM_ETH=y
CONFIG_PINCTRL=y
+CONFIG_PINCTRL_IMX8M=y
CONFIG_DM_REGULATOR=y
CONFIG_DM_REGULATOR_FIXED=y
CONFIG_DM_REGULATOR_GPIO=y
--
2.17.1
From d37b1c7f1049a9db95cdb8e90fc1d770267894ac Mon Sep 17 00:00:00 2001
From: Chris Spencer
Date: Wed, 30 Jan 2019 17:52:35 +
Subject: [PATCH 1/2] pinctrl: Add pinctrl driver for i.MX8M
This driver is required by fsl-imx8mq.dtsi but was not previously
added.
Fixes: 52df705c9669 ("imx: imx8mq: add dtsi file")
Signed-off-by: Chris Spencer
---
drivers/pinctrl/nxp/Kconfig | 14
drivers/pinctrl/nxp/Makefile| 1 +
drivers/pinctrl/nxp/pinctrl-imx8m.c | 35 +
3 files changed, 50 insertions(+)
create mode 100644 drivers/pinctrl/nxp/pinctrl-imx8m.c
diff --git a/drivers/pinctrl/nxp/Kconfig b/drivers/pinctrl/nxp/Kconfig
index f1d5a5c50d..61f93be42d 100644
--- a/drivers/pinctrl/nxp/Kconfig
+++ b/drivers/pinctrl/nxp/Kconfig
@@ -75,6 +75,20 @@ config PINCTRL_IMX8
only parses the 'fsl,pins' property and configures related
registers.
+config PINCTRL_IMX8M
+ bool "IMX8M pinctrl driver"
+ depends on ARCH_IMX8M && PINCTRL_FULL
+ select DEVRES
+ select PINCTRL_IMX
+ help
+ Say Y here to enable the imx8m pinctrl driver
+
+ This provides a simple pinctrl driver for i.MX8M SoC familiy.
+ This feature depends on device tree configuration. This driver
+ is different from the linux one, this is a simple implementation,
+ only parses the 'fsl,pins' property and configure related
+ registers.
+
config PINCTRL_VYBRID
bool "Vybrid (vf610) pinctrl driver"
depends on ARCH_VF610 && PINCTRL_FULL
diff --git a/drivers/pinctrl/nxp/Makefile b/drivers/pinctrl/nxp/Makefile
index 891ee6e477..b340d9448a 100644
--- a/drivers/pinctrl/nxp/Makefile
+++ b/drivers/pinctrl/nxp/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_PINCTRL_IMX7) += pinctrl-imx7.o
obj-$(CONFIG_PINCTRL_IMX7ULP) += pinctrl-imx7ulp.o
obj-$(CONFIG_PINCTRL_IMX_SCU) += pinctrl-scu.o
obj-$(CONFIG_PINCTRL_IMX8) += pinctrl-imx8.o
+obj-$(CONFIG_PINCTRL_IMX8M) += pinctrl-imx8m.o
obj-$(CONFIG_PINCTRL_VYBRID) += pinctrl-vf610.o
diff --git a/drivers/pinctrl/nxp/pinctrl-imx8m.c b/drivers/pinctrl/nxp/pinctrl-imx8m.c
new file mode 100644
index 00..471e0c8170
--- /dev/null
+++ b/drivers/pinctrl/nxp/pinctrl-imx8m.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2017 NXP
+ */
+
+#include
+#include
+
+#include "pinctrl-imx.h"
+
+static struct imx_pinctrl_soc_info imx8mq_pinctrl_soc_info;
+
+static int imx8mq_pinctrl_probe(struct udevice *dev)
+{
+ struct imx_pinctrl_soc_info *info =
+ (struct imx_pinctrl_soc_info *)dev_get_driver_data(dev);
+
+ return imx_pinctrl_probe(dev, info);
+}
+
+static const struct udevice_id
Re: [U-Boot] imx8mq-evk: Outbound network packets lost
On Sat, 26 Jan 2019, Chris Spencer wrote: On Sat, 26 Jan 2019 at 01:14, Sergey Kubushyn wrote: Thanks for a reply. The problem here is not with leftover descriptors -- it is MDIO bus not working at all. It is either bogus speed/clock in DM mode or something else that I haven't found yet. Reading all zeroes means there is no communication with the PHY whatsoever, it comes from bare wire. And there is no need for the PHY to be present at all for an MDIO transaction to complete successfully -- PHY is a slave device with all clocks coming from FEC MDIO so it WILL complete successfully even if it not connected to a PHY. It is kinda like SPI that always succeeds for the master. What I found when debugging the Linux driver is that an MII interrupt was being delivered too early after the first MDIO read the driver issues, resulting in it reading back the wrong value. I was able to reliably stop this from happening by zeroing out ENET_MMFR immediately before the driver sets ENET_MSCR. If I disable networking in U-Boot then the problem in the Linux driver doesn't occur at all, so the only explanation I can come up with is that U-Boot is somehow leaving something in ENET_MMFR which is being unintentionally triggered when the Linux driver sets ENET_MSCR. You have a very good point though because the reads are still completing in U-Boot, even if they always come back zero, so I'm not really sure how there would end up being something left over in ENET_MMFR. OK, I've got it working. The problem was DM FEC driver does _NOT_ do pin muxing and FEC pins in i.MX8MQ come up as GPIOs after rest so no wonder it can't talk to the PHY or whatever else. I don't know yet if there is some setting that I've missed to force it to do pin muxing but didn't find anything appropriate in reference fsl-imx8mq-evk board configs or board source files. Once pin muxing is done in the board file FEC comes up as expected, finds the PHY and all network stuff works as expected. Dedicated "regulator" and PHY reset works OK from DTB provided FEC driver is patched for regulator (regulator_set_enable instead of regulator_autoset) and PHY reset GPIO set "ACTIVE_LOW" in the board's DTS file (fec driver sets it to "1" to reset then resets it to "0"). So it is either pin muxing is missing and one should do it in his board's file or I've missed some setting that I can't find to get the DM FEC driver to do it itself from DTS file. --- ** * KSI@homeKOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] imx8mq-evk: Outbound network packets lost
On Sat, 26 Jan 2019 at 01:14, Sergey Kubushyn wrote: > Thanks for a reply. The problem here is not with leftover descriptors -- it > is MDIO bus not working at all. It is either bogus speed/clock in DM mode or > something else that I haven't found yet. Reading all zeroes means there is > no communication with the PHY whatsoever, it comes from bare wire. And there > is no need for the PHY to be present at all for an MDIO transaction to > complete successfully -- PHY is a slave device with all clocks coming from > FEC MDIO so it WILL complete successfully even if it not connected to a PHY. > It is kinda like SPI that always succeeds for the master. What I found when debugging the Linux driver is that an MII interrupt was being delivered too early after the first MDIO read the driver issues, resulting in it reading back the wrong value. I was able to reliably stop this from happening by zeroing out ENET_MMFR immediately before the driver sets ENET_MSCR. If I disable networking in U-Boot then the problem in the Linux driver doesn't occur at all, so the only explanation I can come up with is that U-Boot is somehow leaving something in ENET_MMFR which is being unintentionally triggered when the Linux driver sets ENET_MSCR. You have a very good point though because the reads are still completing in U-Boot, even if they always come back zero, so I'm not really sure how there would end up being something left over in ENET_MMFR. Chris ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] imx8mq-evk: Outbound network packets lost
On Fri, 25 Jan 2019, Chris Spencer wrote: Thanks for a reply. The problem here is not with leftover descriptors -- it is MDIO bus not working at all. It is either bogus speed/clock in DM mode or something else that I haven't found yet. Reading all zeroes means there is no communication with the PHY whatsoever, it comes from bare wire. And there is no need for the PHY to be present at all for an MDIO transaction to complete successfully -- PHY is a slave device with all clocks coming from FEC MDIO so it WILL complete successfully even if it not connected to a PHY. It is kinda like SPI that always succeeds for the master. Unfortunately NXPs, sorry for an expression, documentation is totally useless -- for ENET clocks their RM (see p. 4335, 11.4.4) only tells "The table found here describes the clock sources for ENET" and that's all information available. There is no table "here" :) And that is not an exception -- such "information" is all over their 6,800 pages thick Reference Manual while stuffed with hundreds of totally bogus pages absolutely irrelevant for i.MX8MQ SoC (see e.g. their 120+ pages long description of LCDIF interfaces and external pins.) Damn, Freescale was pretty decent on documentation but NXP is absolute disaster... On Thu, 24 Jan 2019 at 23:51, Sergey Kubushyn wrote: On Fri, 4 Jan 2019, Chris Spencer wrote: Hi Chris, Did you figure out what was wrong with the PHY always reading zeroes over MDIO? I have exactly same problem here with out i.MX8MQ-based device -- it worked just fine with older U-Boot without DM_ETH but always reads zeroes over MDIO with 2019.01... I'm still fighting and will probably find the culprit but it would've saved me some time if you had found what was wrong... Your reply is highly appreciated. My best regards, Sergey. Hi Sergey, I never quite got to the bottom of why it doesn't work in U-Boot, but I did discover that U-Boot's failure to correctly initialise the Ethernet controller is what was breaking the Linux driver. Basically, it's leaving behind an 'unspent' transfer request in the ENET_MMFR register (otherwise known as FEC_MII_DATA in the Linux driver) which gets triggered when the Linux driver starts initialising the Ethernet controller. This has a nasty habit of interfering with the first transfer request the driver tries to make. If you don't need networking in U-Boot then you can just set CONFIG_CMD_NET=n in your build config and that will fix the Linux driver. I'm afraid I can't offer any further insight if you do need networking in U-Boot. Thanks, Chris --- ** * KSI@homeKOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] imx8mq-evk: Outbound network packets lost
On Thu, 24 Jan 2019 at 23:51, Sergey Kubushyn wrote: > On Fri, 4 Jan 2019, Chris Spencer wrote: > Hi Chris, > > Did you figure out what was wrong with the PHY always reading zeroes over > MDIO? > > I have exactly same problem here with out i.MX8MQ-based device -- it worked > just fine with older U-Boot without DM_ETH but always reads zeroes over MDIO > with 2019.01... > > I'm still fighting and will probably find the culprit but it would've saved > me some time if you had found what was wrong... > > Your reply is highly appreciated. > > My best regards, > Sergey. Hi Sergey, I never quite got to the bottom of why it doesn't work in U-Boot, but I did discover that U-Boot's failure to correctly initialise the Ethernet controller is what was breaking the Linux driver. Basically, it's leaving behind an 'unspent' transfer request in the ENET_MMFR register (otherwise known as FEC_MII_DATA in the Linux driver) which gets triggered when the Linux driver starts initialising the Ethernet controller. This has a nasty habit of interfering with the first transfer request the driver tries to make. If you don't need networking in U-Boot then you can just set CONFIG_CMD_NET=n in your build config and that will fix the Linux driver. I'm afraid I can't offer any further insight if you do need networking in U-Boot. Thanks, Chris ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] imx8mq-evk: Outbound network packets lost
On Fri, 4 Jan 2019 at 15:33, Chris Spencer wrote: > > On Thu, 3 Jan 2019 at 12:53, Chris Spencer wrote: > > Hi, > > > > I'm trying to get the i.MX8MQ-EVK board up and running with the > > recently added kernel support (I'm currently working off > > arm-soc/for-next) and am having some trouble with the networking. If I > > issue a ping from my test machine with tcpdump running on both sides I > > see this: > > > > On dev machine: > > 10:57:52.655882 ARP, Request who-has 10.60.9.15 tell linux-dev, length 28 > > 10:57:53.677046 ARP, Request who-has 10.60.9.15 tell linux-dev, length 28 > > 10:57:54.701024 ARP, Request who-has 10.60.9.15 tell linux-dev, length 28 > > 10:57:55.725050 ARP, Request who-has 10.60.9.15 tell linux-dev, length 28 > > > > On imx8: > > 00:05:16.514604 ARP, Request who-has 10.60.9.15 tell 10.60.9.101, length 46 > > 00:05:16.514651 ARP, Reply 10.60.9.15 is-at 00:04:9f:05:a5:a5 (oui > > Freescale), length 28 > > 00:05:17.578275 ARP, Request who-has 10.60.9.15 tell 10.60.9.101, length 46 > > 00:05:17.578298 ARP, Reply 10.60.9.15 is-at 00:04:9f:05:a5:a5 (oui > > Freescale), length 28 > > 00:05:18.644896 ARP, Request who-has 10.60.9.15 tell 10.60.9.101, length 46 > > 00:05:18.644932 ARP, Reply 10.60.9.15 is-at 00:04:9f:05:a5:a5 (oui > > Freescale), length 28 > > 00:05:19.711548 ARP, Request who-has 10.60.9.15 tell 10.60.9.101, length 46 > > 00:05:19.711561 ARP, Reply 10.60.9.15 is-at 00:04:9f:05:a5:a5 (oui > > Freescale), length 28 > > > > So the imx8 can receive packets, but anything it sends back seems to > > be lost. The machines are connected directly with a standard patch > > cable. I have tried with two different test machines and network > > cables with the same results. Firewalls are disabled on both sides. > > tcpdump shows 0 packets dropped by kernel on both sides. > > > > Kernel output related to the Ethernet controller: > > [0.550204] libphy: Fixed MDIO Bus: probed > > [0.555023] fec 30be.ethernet: 30be.ethernet supply phy not > > found, using dummy regulator > > [0.564204] fec 30be.ethernet: Linked as a consumer to regulator.0 > > [0.575518] libphy: fec_enet_mii_bus: probed > > ... > > [6.479277] fec 30be.ethernet eth0: Link is Up - 1Gbps/Full - > > flow control rx/tx > > [6.487386] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > > > Potentially useful command output: > > # ip addr > > ... > > 2: eth0: mtu 1500 qdisc mq qlen 1000 > > link/ether 00:04:9f:05:a5:a5 brd ff:ff:ff:ff:ff:ff > > inet 10.60.9.15/24 brd 10.60.9.255 scope global eth0 > >valid_lft forever preferred_lft forever > > inet6 fe80::204:9fff:fe05:a5a5/64 scope link > >valid_lft forever preferred_lft forever > > # ifconfig eth0 > > eth0 Link encap:Ethernet HWaddr 00:04:9F:05:A5:A5 > > inet addr:10.60.9.15 Bcast:10.60.9.255 Mask:255.255.255.0 > > inet6 addr: fe80::204:9fff:fe05:a5a5/64 Scope:Link > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > RX packets:32 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:20 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:1000 > > RX bytes:2332 (2.2 KiB) TX bytes:1080 (1.0 KiB) > > > > Is anyone able to provide some insight on what might be happening here? > > > > Thanks, > > Chris > > I've been digging into this further and it seems to be potentially > related to U-Boot. If I use the version of U-Boot that is shipped with > the device on the eMMC and use that to manually boot into my SD card > then the Ethernet controller seems to work fine. > > It looks like perhaps the physical layer is not being initialised > properly. If I execute the following commands on the bundled U-Boot > everything looks normal: > > u-boot=> mdio list > FEC0: > 0 - AR8031/AR8033 <--> ethernet@30be > u-boot=> mii info > PHY 0x00: OUI = 0x1374, Model = 0x07, Rev = 0x04, 1000baseX, FDX > u-boot=> mii read 0 2 > 004D > u-boot=> mii read 0 3 > D074 > > But on my own build of U-Boot (current master > 7436f5e54d35bcad53befec90e2e67288071f74e), it seems every request to > the physical layer is returning zero, resulting in it using the > generic PHY driver instead of the AR8031: > > u-boot=> mdio list > FEC0: > 0 - Generic PHY <--> ethernet@30be > u-boot=> mii info > PHY 0x00: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX > PHY 0x01: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX > PHY 0x02: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX > PHY 0x03: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX > PHY 0x04: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX > PHY 0x05: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX > PHY 0x06: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX > PHY 0x07: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX > PHY 0x08: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX > PHY 0x09: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX
Re: [U-Boot] imx8mq-evk: Outbound network packets lost
On Thu, 3 Jan 2019 at 12:53, Chris Spencer wrote: > Hi, > > I'm trying to get the i.MX8MQ-EVK board up and running with the > recently added kernel support (I'm currently working off > arm-soc/for-next) and am having some trouble with the networking. If I > issue a ping from my test machine with tcpdump running on both sides I > see this: > > On dev machine: > 10:57:52.655882 ARP, Request who-has 10.60.9.15 tell linux-dev, length 28 > 10:57:53.677046 ARP, Request who-has 10.60.9.15 tell linux-dev, length 28 > 10:57:54.701024 ARP, Request who-has 10.60.9.15 tell linux-dev, length 28 > 10:57:55.725050 ARP, Request who-has 10.60.9.15 tell linux-dev, length 28 > > On imx8: > 00:05:16.514604 ARP, Request who-has 10.60.9.15 tell 10.60.9.101, length 46 > 00:05:16.514651 ARP, Reply 10.60.9.15 is-at 00:04:9f:05:a5:a5 (oui > Freescale), length 28 > 00:05:17.578275 ARP, Request who-has 10.60.9.15 tell 10.60.9.101, length 46 > 00:05:17.578298 ARP, Reply 10.60.9.15 is-at 00:04:9f:05:a5:a5 (oui > Freescale), length 28 > 00:05:18.644896 ARP, Request who-has 10.60.9.15 tell 10.60.9.101, length 46 > 00:05:18.644932 ARP, Reply 10.60.9.15 is-at 00:04:9f:05:a5:a5 (oui > Freescale), length 28 > 00:05:19.711548 ARP, Request who-has 10.60.9.15 tell 10.60.9.101, length 46 > 00:05:19.711561 ARP, Reply 10.60.9.15 is-at 00:04:9f:05:a5:a5 (oui > Freescale), length 28 > > So the imx8 can receive packets, but anything it sends back seems to > be lost. The machines are connected directly with a standard patch > cable. I have tried with two different test machines and network > cables with the same results. Firewalls are disabled on both sides. > tcpdump shows 0 packets dropped by kernel on both sides. > > Kernel output related to the Ethernet controller: > [0.550204] libphy: Fixed MDIO Bus: probed > [0.555023] fec 30be.ethernet: 30be.ethernet supply phy not > found, using dummy regulator > [0.564204] fec 30be.ethernet: Linked as a consumer to regulator.0 > [0.575518] libphy: fec_enet_mii_bus: probed > ... > [6.479277] fec 30be.ethernet eth0: Link is Up - 1Gbps/Full - > flow control rx/tx > [6.487386] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > Potentially useful command output: > # ip addr > ... > 2: eth0: mtu 1500 qdisc mq qlen 1000 > link/ether 00:04:9f:05:a5:a5 brd ff:ff:ff:ff:ff:ff > inet 10.60.9.15/24 brd 10.60.9.255 scope global eth0 >valid_lft forever preferred_lft forever > inet6 fe80::204:9fff:fe05:a5a5/64 scope link >valid_lft forever preferred_lft forever > # ifconfig eth0 > eth0 Link encap:Ethernet HWaddr 00:04:9F:05:A5:A5 > inet addr:10.60.9.15 Bcast:10.60.9.255 Mask:255.255.255.0 > inet6 addr: fe80::204:9fff:fe05:a5a5/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:32 errors:0 dropped:0 overruns:0 frame:0 > TX packets:20 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:2332 (2.2 KiB) TX bytes:1080 (1.0 KiB) > > Is anyone able to provide some insight on what might be happening here? > > Thanks, > Chris I've been digging into this further and it seems to be potentially related to U-Boot. If I use the version of U-Boot that is shipped with the device on the eMMC and use that to manually boot into my SD card then the Ethernet controller seems to work fine. It looks like perhaps the physical layer is not being initialised properly. If I execute the following commands on the bundled U-Boot everything looks normal: u-boot=> mdio list FEC0: 0 - AR8031/AR8033 <--> ethernet@30be u-boot=> mii info PHY 0x00: OUI = 0x1374, Model = 0x07, Rev = 0x04, 1000baseX, FDX u-boot=> mii read 0 2 004D u-boot=> mii read 0 3 D074 But on my own build of U-Boot (current master 7436f5e54d35bcad53befec90e2e67288071f74e), it seems every request to the physical layer is returning zero, resulting in it using the generic PHY driver instead of the AR8031: u-boot=> mdio list FEC0: 0 - Generic PHY <--> ethernet@30be u-boot=> mii info PHY 0x00: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x01: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x02: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x03: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x04: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x05: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x06: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x07: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x08: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x09: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x0A: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x0B: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x0C: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY 0x0D: OUI = 0x, Model = 0x00, Rev = 0x00, 10baseT, HDX PHY
