* imx8mq-evk: Outbound network packets lost
@ 2019-01-03 12:53 Chris Spencer
2019-01-04 15:33 ` [U-Boot] " Chris Spencer
0 siblings, 1 reply; 16+ 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] 16+ 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 0 siblings, 0 replies; 16+ 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] 16+ messages in thread
* [U-Boot] imx8mq-evk: Outbound network packets lost @ 2019-01-04 15:33 ` Chris Spencer 0 siblings, 0 replies; 16+ messages in thread From: Chris Spencer @ 2019-01-04 15:33 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: imx8mq-evk: Outbound network packets lost 2019-01-04 15:33 ` [U-Boot] " Chris Spencer @ 2019-01-04 16:52 ` Chris Spencer -1 siblings, 0 replies; 16+ 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] 16+ messages in thread
* [U-Boot] imx8mq-evk: Outbound network packets lost @ 2019-01-04 16:52 ` Chris Spencer 0 siblings, 0 replies; 16+ messages in thread From: Chris Spencer @ 2019-01-04 16:52 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: imx8mq-evk: Outbound network packets lost 2019-01-04 16:52 ` [U-Boot] " Chris Spencer (?) @ 2019-01-07 9:42 ` Chris Spencer -1 siblings, 0 replies; 16+ 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] 16+ messages in thread
[parent not found: <alpine.LFD.2.21.1901241547420.33885@maverick.koi8.net>]
* [U-Boot] imx8mq-evk: Outbound network packets lost [not found] ` <alpine.LFD.2.21.1901241547420.33885@maverick.koi8.net> @ 2019-01-25 8:15 ` Chris Spencer 2019-01-26 1:14 ` Sergey Kubushyn 0 siblings, 1 reply; 16+ messages in thread From: Chris Spencer @ 2019-01-25 8:15 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] imx8mq-evk: Outbound network packets lost 2019-01-25 8:15 ` [U-Boot] " Chris Spencer @ 2019-01-26 1:14 ` Sergey Kubushyn 2019-01-26 10:26 ` Chris Spencer 0 siblings, 1 reply; 16+ messages in thread From: Sergey Kubushyn @ 2019-01-26 1:14 UTC (permalink / raw) To: u-boot 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. * ****************************************************************** ^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] imx8mq-evk: Outbound network packets lost 2019-01-26 1:14 ` Sergey Kubushyn @ 2019-01-26 10:26 ` Chris Spencer 2019-01-30 0:43 ` Sergey Kubushyn 0 siblings, 1 reply; 16+ messages in thread From: Chris Spencer @ 2019-01-26 10:26 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] imx8mq-evk: Outbound network packets lost 2019-01-26 10:26 ` Chris Spencer @ 2019-01-30 0:43 ` Sergey Kubushyn 2019-01-31 8:02 ` Chris Spencer 0 siblings, 1 reply; 16+ messages in thread From: Sergey Kubushyn @ 2019-01-30 0:43 UTC (permalink / raw) To: u-boot 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. * ****************************************************************** ^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] imx8mq-evk: Outbound network packets lost 2019-01-30 0:43 ` Sergey Kubushyn @ 2019-01-31 8:02 ` Chris Spencer 2019-01-31 18:43 ` Sergey Kubushyn 0 siblings, 1 reply; 16+ messages in thread From: Chris Spencer @ 2019-01-31 8:02 UTC (permalink / raw) To: u-boot 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> ^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] imx8mq-evk: Outbound network packets lost 2019-01-31 8:02 ` Chris Spencer @ 2019-01-31 18:43 ` Sergey Kubushyn 2019-02-01 7:06 ` Chris Spencer 0 siblings, 1 reply; 16+ messages in thread From: Sergey Kubushyn @ 2019-01-31 18:43 UTC (permalink / raw) To: u-boot 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. * ****************************************************************** ^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] imx8mq-evk: Outbound network packets lost 2019-01-31 18:43 ` Sergey Kubushyn @ 2019-02-01 7:06 ` Chris Spencer 2019-02-01 16:10 ` Sergey Kubushyn 0 siblings, 1 reply; 16+ messages in thread From: Chris Spencer @ 2019-02-01 7:06 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] imx8mq-evk: Outbound network packets lost 2019-02-01 7:06 ` Chris Spencer @ 2019-02-01 16:10 ` Sergey Kubushyn 2019-02-01 16:49 ` Chris Spencer 0 siblings, 1 reply; 16+ messages in thread From: Sergey Kubushyn @ 2019-02-01 16:10 UTC (permalink / raw) To: u-boot 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. * ****************************************************************** ^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] imx8mq-evk: Outbound network packets lost 2019-02-01 16:10 ` Sergey Kubushyn @ 2019-02-01 16:49 ` Chris Spencer 2019-02-01 18:25 ` Sergey Kubushyn 0 siblings, 1 reply; 16+ messages in thread From: Chris Spencer @ 2019-02-01 16:49 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [U-Boot] imx8mq-evk: Outbound network packets lost 2019-02-01 16:49 ` Chris Spencer @ 2019-02-01 18:25 ` Sergey Kubushyn 0 siblings, 0 replies; 16+ messages in thread From: Sergey Kubushyn @ 2019-02-01 18:25 UTC (permalink / raw) To: u-boot 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. * ****************************************************************** ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2019-02-01 18:25 UTC | newest]
Thread overview: 16+ 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 15:33 ` [U-Boot] " Chris Spencer
2019-01-04 16:52 ` Chris Spencer
2019-01-04 16:52 ` [U-Boot] " Chris Spencer
2019-01-07 9:42 ` Chris Spencer
[not found] ` <alpine.LFD.2.21.1901241547420.33885@maverick.koi8.net>
2019-01-25 8:15 ` [U-Boot] " Chris Spencer
2019-01-26 1:14 ` Sergey Kubushyn
2019-01-26 10:26 ` Chris Spencer
2019-01-30 0:43 ` Sergey Kubushyn
2019-01-31 8:02 ` Chris Spencer
2019-01-31 18:43 ` Sergey Kubushyn
2019-02-01 7:06 ` Chris Spencer
2019-02-01 16:10 ` Sergey Kubushyn
2019-02-01 16:49 ` Chris Spencer
2019-02-01 18:25 ` Sergey Kubushyn
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.