imx8mq-evk: Outbound network packets lost

imx8mq-evk: Outbound network packets lost

[Chris Spencer]

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 30be0000.ethernet: 30be0000.ethernet supply phy not
found, using dummy regulator
[    0.564204] fec 30be0000.ethernet: Linked as a consumer to regulator.0
[    0.575518] libphy: fec_enet_mii_bus: probed
...
[    6.479277] fec 30be0000.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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: imx8mq-evk: Outbound network packets lost

[Chris Spencer]

On Thu, 3 Jan 2019 at 12:53, Chris Spencer <spencercw@gmail.com> 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 30be0000.ethernet: 30be0000.ethernet supply phy not
> found, using dummy regulator
> [    0.564204] fec 30be0000.ethernet: Linked as a consumer to regulator.0
> [    0.575518] libphy: fec_enet_mii_bus: probed
> ...
> [    6.479277] fec 30be0000.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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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@30be0000
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@30be0000
u-boot=> mii info
PHY 0x00: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x01: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x02: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x03: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x04: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x05: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x06: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x07: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x08: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x09: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0A: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0B: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0C: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0D: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0E: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0F: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x10: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x11: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x12: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x13: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x14: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x15: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x16: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x17: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x18: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x19: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1A: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1B: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1C: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1D: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1E: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1F: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
u-boot=> mii read 0 2
0000
u-boot=> mii read 0 3
0000

I have added some tracing to drivers/net/fec_mxc.c:fec_mdio_read() and
the read seems to be proceeding normally (i.e., it gets an interrupt
indicating that the read has completed), but the value always comes
back as zero.

# Clear MII interrupt in ENET_EIR
writel(800000, 30be0004)
# Re-check ENET_EIR; as expected, the interrupt is not set
readl(30be0004) => 0
# Issue a read request to ENET_MMFR for phy 0 reg 2
writel(600a0000, 30be0040)
# Check ENET_EIR; the MII interrupt has been set, indicating the
transfer has completed
readl(30be0004) => 800000
# Clear the interrupt
writel(800000, 30be0004)
# Read the data from ENET_MMFR; the value is zero. I would expect to
see 004d in the lower 16 bits here
readl(30be0040) => 600a0000

There's a decent chance I'm missing something obvious, but I'm not seeing it..

Thanks,
Chris

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[U-Boot] imx8mq-evk: Outbound network packets lost

[Chris Spencer]

On Thu, 3 Jan 2019 at 12:53, Chris Spencer <spencercw@gmail.com> 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 30be0000.ethernet: 30be0000.ethernet supply phy not
> found, using dummy regulator
> [    0.564204] fec 30be0000.ethernet: Linked as a consumer to regulator.0
> [    0.575518] libphy: fec_enet_mii_bus: probed
> ...
> [    6.479277] fec 30be0000.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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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 at 30be0000
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 at 30be0000
u-boot=> mii info
PHY 0x00: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x01: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x02: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x03: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x04: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x05: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x06: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x07: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x08: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x09: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0A: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0B: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0C: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0D: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0E: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x0F: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x10: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x11: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x12: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x13: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x14: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x15: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x16: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x17: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x18: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x19: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1A: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1B: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1C: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1D: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1E: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
PHY 0x1F: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
u-boot=> mii read 0 2
0000
u-boot=> mii read 0 3
0000

I have added some tracing to drivers/net/fec_mxc.c:fec_mdio_read() and
the read seems to be proceeding normally (i.e., it gets an interrupt
indicating that the read has completed), but the value always comes
back as zero.

# Clear MII interrupt in ENET_EIR
writel(800000, 30be0004)
# Re-check ENET_EIR; as expected, the interrupt is not set
readl(30be0004) => 0
# Issue a read request to ENET_MMFR for phy 0 reg 2
writel(600a0000, 30be0040)
# Check ENET_EIR; the MII interrupt has been set, indicating the
transfer has completed
readl(30be0004) => 800000
# Clear the interrupt
writel(800000, 30be0004)
# Read the data from ENET_MMFR; the value is zero. I would expect to
see 004d in the lower 16 bits here
readl(30be0040) => 600a0000

There's a decent chance I'm missing something obvious, but I'm not seeing it..

Thanks,
Chris

Re: imx8mq-evk: Outbound network packets lost

[Chris Spencer]

On Fri, 4 Jan 2019 at 15:33, Chris Spencer <spencercw@gmail.com> wrote:
>
> On Thu, 3 Jan 2019 at 12:53, Chris Spencer <spencercw@gmail.com> 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 30be0000.ethernet: 30be0000.ethernet supply phy not
> > found, using dummy regulator
> > [    0.564204] fec 30be0000.ethernet: Linked as a consumer to regulator.0
> > [    0.575518] libphy: fec_enet_mii_bus: probed
> > ...
> > [    6.479277] fec 30be0000.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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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@30be0000
> 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@30be0000
> u-boot=> mii info
> PHY 0x00: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x01: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x02: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x03: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x04: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x05: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x06: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x07: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x08: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x09: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x0A: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x0B: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x0C: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x0D: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x0E: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x0F: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x10: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x11: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x12: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x13: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x14: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x15: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x16: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x17: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x18: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x19: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x1A: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x1B: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x1C: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x1D: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x1E: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x1F: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> u-boot=> mii read 0 2
> 0000
> u-boot=> mii read 0 3
> 0000
>
> I have added some tracing to drivers/net/fec_mxc.c:fec_mdio_read() and
> the read seems to be proceeding normally (i.e., it gets an interrupt
> indicating that the read has completed), but the value always comes
> back as zero.
>
> # Clear MII interrupt in ENET_EIR
> writel(800000, 30be0004)
> # Re-check ENET_EIR; as expected, the interrupt is not set
> readl(30be0004) => 0
> # Issue a read request to ENET_MMFR for phy 0 reg 2
> writel(600a0000, 30be0040)
> # Check ENET_EIR; the MII interrupt has been set, indicating the
> transfer has completed
> readl(30be0004) => 800000
> # Clear the interrupt
> writel(800000, 30be0004)
> # Read the data from ENET_MMFR; the value is zero. I would expect to
> see 004d in the lower 16 bits here
> readl(30be0040) => 600a0000
>
> There's a decent chance I'm missing something obvious, but I'm not seeing it..
>
> Thanks,
> Chris

The plot thickens... I updated my Trusted Firmware-A BL31 [1] and that
seems to have fixed the problem on the Linux side. I'm not sure what
revision I was on before, but it would have been around 2-3 weeks out
of date. It still doesn't work at all in U-Boot, although I'm not
going to lose too much sleep if I can't get that to work.

Chris

[1] https://github.com/ARM-software/arm-trusted-firmware
9a207532f8216bf83fed0891fed9ed0bc72ca450

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[U-Boot] imx8mq-evk: Outbound network packets lost

[Chris Spencer]

On Fri, 4 Jan 2019 at 15:33, Chris Spencer <spencercw@gmail.com> wrote:
>
> On Thu, 3 Jan 2019 at 12:53, Chris Spencer <spencercw@gmail.com> 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 30be0000.ethernet: 30be0000.ethernet supply phy not
> > found, using dummy regulator
> > [    0.564204] fec 30be0000.ethernet: Linked as a consumer to regulator.0
> > [    0.575518] libphy: fec_enet_mii_bus: probed
> > ...
> > [    6.479277] fec 30be0000.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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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 at 30be0000
> 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 at 30be0000
> u-boot=> mii info
> PHY 0x00: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x01: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x02: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x03: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x04: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x05: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x06: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x07: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x08: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x09: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x0A: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x0B: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x0C: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x0D: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x0E: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x0F: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x10: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x11: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x12: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x13: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x14: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x15: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x16: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x17: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x18: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x19: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x1A: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x1B: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x1C: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x1D: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x1E: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> PHY 0x1F: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> u-boot=> mii read 0 2
> 0000
> u-boot=> mii read 0 3
> 0000
>
> I have added some tracing to drivers/net/fec_mxc.c:fec_mdio_read() and
> the read seems to be proceeding normally (i.e., it gets an interrupt
> indicating that the read has completed), but the value always comes
> back as zero.
>
> # Clear MII interrupt in ENET_EIR
> writel(800000, 30be0004)
> # Re-check ENET_EIR; as expected, the interrupt is not set
> readl(30be0004) => 0
> # Issue a read request to ENET_MMFR for phy 0 reg 2
> writel(600a0000, 30be0040)
> # Check ENET_EIR; the MII interrupt has been set, indicating the
> transfer has completed
> readl(30be0004) => 800000
> # Clear the interrupt
> writel(800000, 30be0004)
> # Read the data from ENET_MMFR; the value is zero. I would expect to
> see 004d in the lower 16 bits here
> readl(30be0040) => 600a0000
>
> There's a decent chance I'm missing something obvious, but I'm not seeing it..
>
> Thanks,
> Chris

The plot thickens... I updated my Trusted Firmware-A BL31 [1] and that
seems to have fixed the problem on the Linux side. I'm not sure what
revision I was on before, but it would have been around 2-3 weeks out
of date. It still doesn't work at all in U-Boot, although I'm not
going to lose too much sleep if I can't get that to work.

Chris

[1] https://github.com/ARM-software/arm-trusted-firmware
9a207532f8216bf83fed0891fed9ed0bc72ca450

Re: imx8mq-evk: Outbound network packets lost

[Chris Spencer]

On Fri, 4 Jan 2019 at 16:52, Chris Spencer <spencercw@gmail.com> wrote:
> On Fri, 4 Jan 2019 at 15:33, Chris Spencer <spencercw@gmail.com> wrote:
> > On Thu, 3 Jan 2019 at 12:53, Chris Spencer <spencercw@gmail.com> 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 30be0000.ethernet: 30be0000.ethernet supply phy not
> > > found, using dummy regulator
> > > [    0.564204] fec 30be0000.ethernet: Linked as a consumer to regulator.0
> > > [    0.575518] libphy: fec_enet_mii_bus: probed
> > > ...
> > > [    6.479277] fec 30be0000.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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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@30be0000
> > 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@30be0000
> > u-boot=> mii info
> > PHY 0x00: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x01: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x02: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x03: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x04: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x05: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x06: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x07: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x08: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x09: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x0A: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x0B: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x0C: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x0D: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x0E: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x0F: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x10: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x11: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x12: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x13: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x14: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x15: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x16: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x17: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x18: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x19: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x1A: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x1B: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x1C: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x1D: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x1E: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > PHY 0x1F: OUI = 0x0000, Model = 0x00, Rev = 0x00,  10baseT, HDX
> > u-boot=> mii read 0 2
> > 0000
> > u-boot=> mii read 0 3
> > 0000
> >
> > I have added some tracing to drivers/net/fec_mxc.c:fec_mdio_read() and
> > the read seems to be proceeding normally (i.e., it gets an interrupt
> > indicating that the read has completed), but the value always comes
> > back as zero.
> >
> > # Clear MII interrupt in ENET_EIR
> > writel(800000, 30be0004)
> > # Re-check ENET_EIR; as expected, the interrupt is not set
> > readl(30be0004) => 0
> > # Issue a read request to ENET_MMFR for phy 0 reg 2
> > writel(600a0000, 30be0040)
> > # Check ENET_EIR; the MII interrupt has been set, indicating the
> > transfer has completed
> > readl(30be0004) => 800000
> > # Clear the interrupt
> > writel(800000, 30be0004)
> > # Read the data from ENET_MMFR; the value is zero. I would expect to
> > see 004d in the lower 16 bits here
> > readl(30be0040) => 600a0000
> >
> > There's a decent chance I'm missing something obvious, but I'm not seeing it..
> >
> > Thanks,
> > Chris
>
> The plot thickens... I updated my Trusted Firmware-A BL31 [1] and that
> seems to have fixed the problem on the Linux side. I'm not sure what
> revision I was on before, but it would have been around 2-3 weeks out
> of date. It still doesn't work at all in U-Boot, although I'm not
> going to lose too much sleep if I can't get that to work.
>
> Chris
>
> [1] https://github.com/ARM-software/arm-trusted-firmware
> 9a207532f8216bf83fed0891fed9ed0bc72ca450

Any chance somebody from NXP can comment on this?

It seems updating the TF-A didn't actually do anything, it's just the
problem is erratic.

I have added some trace logging to the Linux 5.0-rc1 fec_main.c and
have found that the very first MDIO read often incorrectly returns
zero:

[    0.584706] fec_enet_mdio_read(mii_id = 0, regnum = 2) => 0
[    0.590566] fec_enet_mdio_read(mii_id = 0, regnum = 3) => d074

This results in the Generic PHY driver being used instead of the
Atheros 8031 and things don't work properly. Occasionally, the correct
value will be returned any everything works fine:

[    0.584674] fec_enet_mdio_read(mii_id = 0, regnum = 2) => 4d
[    0.590623] fec_enet_mdio_read(mii_id = 0, regnum = 3) => d074

I can work around the issue with this patch:

diff --git a/drivers/net/ethernet/freescale/fec_main.c
b/drivers/net/ethernet/freescale/fec_main.c
index ae0f88bce9aa..802f51308b2d 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1789,6 +1789,7 @@ static int fec_enet_mdio_read(struct mii_bus
*bus, int mii_id, int regnum)
         goto out;
     }

+    udelay(100);
     ret = FEC_MMFR_DATA(readl(fep->hwp + FEC_MII_DATA));

 out:

It seems that the interrupt is being triggered before the register is
actually ready to be read. I tried a 10us delay but the value returned
from the very first read was random and incorrect.

Thanks,
Chris

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[U-Boot] imx8mq-evk: Outbound network packets lost

[Chris Spencer]

On Thu, 24 Jan 2019 at 23:51, Sergey Kubushyn <ksi@koi8.net> 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] imx8mq-evk: Outbound network packets lost

[Sergey Kubushyn]

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 <ksi@koi8.net> 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 at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot] imx8mq-evk: Outbound network packets lost

[Chris Spencer]

On Sat, 26 Jan 2019 at 01:14, Sergey Kubushyn <ksi@koi8.net> 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] imx8mq-evk: Outbound network packets lost

[Sergey Kubushyn]

On Sat, 26 Jan 2019, Chris Spencer wrote:

> On Sat, 26 Jan 2019 at 01:14, Sergey Kubushyn <ksi@koi8.net> 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 at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot] imx8mq-evk: Outbound network packets lost

[Chris Spencer]

On Wed, 30 Jan 2019 at 00:44, Sergey Kubushyn <ksi@koi8.net> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-imx8mq_evk_defconfig-Enable-pinctrl-driver.patch
Type: text/x-patch
Size: 889 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190131/bab8579b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-pinctrl-Add-pinctrl-driver-for-i.MX8M.patch
Type: text/x-patch
Size: 3155 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190131/bab8579b/attachment-0001.bin>

[U-Boot] imx8mq-evk: Outbound network packets lost

[Sergey Kubushyn]

On Thu, 31 Jan 2019, Chris Spencer wrote:

> On Wed, 30 Jan 2019 at 00:44, Sergey Kubushyn <ksi@koi8.net> 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 at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot] imx8mq-evk: Outbound network packets lost

[Chris Spencer]

On Thu, 31 Jan 2019 at 18:43, Sergey Kubushyn <ksi@koi8.net> 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] imx8mq-evk: Outbound network packets lost

[Sergey Kubushyn]

On Fri, 1 Feb 2019, Chris Spencer wrote:

> On Thu, 31 Jan 2019 at 18:43, Sergey Kubushyn <ksi@koi8.net> 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 at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot] imx8mq-evk: Outbound network packets lost

[Chris Spencer]

On Fri, 1 Feb 2019 at 16:10, Sergey Kubushyn <ksi@koi8.net> 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] imx8mq-evk: Outbound network packets lost

[Sergey Kubushyn]

On Fri, 1 Feb 2019, Chris Spencer wrote:

> On Fri, 1 Feb 2019 at 16:10, Sergey Kubushyn <ksi@koi8.net> 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 at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************