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

Chris Spencer spencercw at gmail.com
Fri Jan 4 15:33:05 UTC 2019


On Thu, 3 Jan 2019 at 12:53, Chris Spencer <spencercw at 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


More information about the U-Boot mailing list