* imx8mq-evk: Outbound network packets lost
@ 2019-01-03 12:53 Chris Spencer
2019-01-04 15:33 ` Chris Spencer
0 siblings, 1 reply; 4+ messages in thread
From: Chris Spencer @ 2019-01-03 12:53 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: imx8mq-evk: Outbound network packets lost
2019-01-03 12:53 imx8mq-evk: Outbound network packets lost Chris Spencer
@ 2019-01-04 15:33 ` Chris Spencer
2019-01-04 16:52 ` Chris Spencer
0 siblings, 1 reply; 4+ messages in thread
From: Chris Spencer @ 2019-01-04 15:33 UTC (permalink / raw)
To: linux-imx, U-Boot-Denx, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: imx8mq-evk: Outbound network packets lost
2019-01-04 15:33 ` Chris Spencer
@ 2019-01-04 16:52 ` Chris Spencer
2019-01-07 9:42 ` Chris Spencer
0 siblings, 1 reply; 4+ messages in thread
From: Chris Spencer @ 2019-01-04 16:52 UTC (permalink / raw)
To: linux-imx, U-Boot-Denx, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: imx8mq-evk: Outbound network packets lost
2019-01-04 16:52 ` Chris Spencer
@ 2019-01-07 9:42 ` Chris Spencer
0 siblings, 0 replies; 4+ messages in thread
From: Chris Spencer @ 2019-01-07 9:42 UTC (permalink / raw)
To: linux-imx, aisheng.dong, abel.vesa; +Cc: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-01-07 9:42 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-01-03 12:53 imx8mq-evk: Outbound network packets lost Chris Spencer
2019-01-04 15:33 ` Chris Spencer
2019-01-04 16:52 ` Chris Spencer
2019-01-07 9:42 ` Chris Spencer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).