Other Parts Discussed in Thread: TCA9535
Greetings! We're trying to integrate the DP83826 phy into our custom baseboard. We use an i.MX8QXP-based SoM running an Yocto-based linux distro, currently on kernel version 5.4.3.
I think we got at least some things right, as right now we're able to bring up the eth interface and connect the MAC to the PHY sucessfully, but there are never any TX or RX packets. I'll list below the steps we've been through to configure the device.
1) In the image below there is part of our schematics, regarding the eth phy.
Strap4 is pulled up to enable RMII in basic mode.
The imx8qxp processor has 2 FEC (fast ethernet controllers) MACs (ENET0, ENET1). We're using the enet1 pins (I'll provide some part of the device tree below).
2) The dp83822 driver (which supports the 83826 IC) isn't fully updated on the 5.4.3 upstream kernel, so I took the updated version of the dp83822.c file from https://www.ti.com/tool/ETHERNET-SW . I patched it into our kernel, which required a small patch on phy_core.c and phy_device.c to add some defines and a helper method that the driver uses.
3) Enabled driver through CONFIG_DP83822, compiled successfully.
4) Related device tree nodes:
pinctrl_fec2_enet1: fec2_grp {
fsl,pins = <
IMX8QXP_SPDIF0_RX_CONN_ENET1_RGMII_RXD0 0x00000040
IMX8QXP_ESAI0_TX3_RX2_CONN_ENET1_RGMII_RXD1 0x00000040
IMX8QXP_ESAI0_TX2_RX3_CONN_ENET1_RMII_RX_ER 0x00000040
IMX8QXP_SPDIF0_TX_CONN_ENET1_RGMII_RX_CTL 0x00000040
IMX8QXP_ESAI0_TX4_RX1_CONN_ENET1_RGMII_TXD0 0x00000040
IMX8QXP_ESAI0_TX5_RX0_CONN_ENET1_RGMII_TXD1 0x00000040
IMX8QXP_ESAI0_SCKR_CONN_ENET1_RGMII_TX_CTL 0x00000040
IMX8QXP_ENET0_MDIO_CONN_ENET1_MDIO 0x00000020
IMX8QXP_ENET0_MDC_CONN_ENET1_MDC 0x00000040
IMX8QXP_ESAI0_FSR_CONN_ENET1_RCLK50M_IN 0x00000040
// PWRD / INT#
IMX8QXP_MIPI_DSI1_GPIO0_01_LSIO_GPIO2_IO00 0x00000060
>;
};
// Ethernet 1 (FEC2)
&fec2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_fec2_enet1>;
phy-supply = <®_3v3>;
phy-mode = "rmii";
phy-handle = <ðphy>;
fsl,magic-packet;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
max-speed = <100>;
status = "okay";
phy-reset-gpios = <&tca9535_expander 15 GPIO_ACTIVE_LOW>;
phy-reset-duration = <200>;
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <1>;
};
};
};
5 ) The phy is properly found on the bus and attached to. Here's the output of "dmesg | grep eth"
[ 2.288987] fec 5b050000.ethernet eth0: registered PHC device 0
[ 7.335403] TI DP83826NC 5b050000.ethernet-1:01: attached PHY driver [TI DP83826NC] (mii_bus:phy_addr=5b050000.ethernet-1:01, irq=POLL)
[ 9.407544] fec 5b050000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[ 9.415564] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
However we're not able to transmit any data or use the eth0 interface in any meaningful way. Here's some information that might be useful:
- ethtool:
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Link detected: yes
- ethtool -S eth0:
Everything is 0.
- ifconfig eth0:
eth0 Link encap:Ethernet HWaddr 00:d0:93:51:22:e0
inet addr:192.168.0.100 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::2d0:93ff:fe51:22e0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Currently not sure where the 192.168.0.100 IP is coming from, it's not dhcp.
6) We've also used phytool (https://github.com/wkz/phytool) to read some registers on the DP83826 through the MDIO bus, but there seem to be a lot of inconsistencies, so I'm not sure what data we can trust and what is incorrect. For example, register 0x467 is supposed to return the strap status when the phy was initialized. Reading it returns 0x2001, which would imply that the PHY address is not 0x01, which is incorrect, since it is.
Some relevant registers and their content:
0x00 = 0x3100
0x09 = 0000
0x0A = 0x0100
0x0B = 0000
0x10 = 0x5115
0x11 = 0x010b
0x17 = 0x0065
0x19 = 0xbc01
0x467 = 0x2001
0x468 = 0000
7) We've measured the TX_EN and RX0, TX0 signals. There seems to be some activity on the RX pins, but the TX pins (EN and TX[1:0]) remain still.
8) We've measured RST_N (pin 32) and PWRDN/INT (pin 21) and both are on high. Weirdly, the registers seems to indicate that the PWRDN pin is being used as an interrupt, which isn't supposed to happen without explict register configuration.
9) Sporadically we also get TX ring dumps, which look something like this:
------------[ cut here ]------------
[ 263.915343] NETDEV WATCHDOG: eth0 (fec): transmit queue 0 timed out
[ 263.921736] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:454 dev_watchdog+0x2fc/0x308
[ 263.930009] Modules linked in: crct10dif_ce asix usbnet fsl_imx8_ddr_perf flexcan can_dev galcore(O)
[ 263.939172] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G O 5.4.3-tq+g02868ec #1
[ 263.947444] Hardware name: Hexagon Agriculture i.MX8QXP TQMa8XQP4 on ATBN 1.0 (DT)
[ 263.955022] pstate: 20000005 (nzCv daif -PAN -UAO)
[ 263.959818] pc : dev_watchdog+0x2fc/0x308
[ 263.963829] lr : dev_watchdog+0x2fc/0x308
[ 263.967841] sp : ffff80001001bdb0
[ 263.971158] x29: ffff80001001bdb0 x28: ffff0000794e8300
[ 263.976475] x27: 0000000000000004 x26: 0000000000000140
[ 263.981791] x25: 00000000ffffffff x24: ffff0000786cf000
[ 263.987108] x23: ffff0000786cf39c x22: ffff0000786cefb8
[ 263.992425] x21: ffff0000786cf3b8 x20: ffff800011876000
[ 263.997741] x19: 0000000000000000 x18: 0000000000000010
[ 264.003058] x17: 0000000000000000 x16: 0000000000000000
[ 264.008375] x15: ffff0000780b3c70 x14: ffffffffffffffff
[ 264.013692] x13: ffff80009001bb17 x12: ffff80001001bb1f
[ 264.019008] x11: 0000000000000000 x10: 0000000000000000
[ 264.024325] x9 : 0000000000000000 x8 : ffff8000119a3000
[ 264.029642] x7 : ffff8000106ad930 x6 : 0000000000000181
[ 264.034958] x5 : 0000000000000000 x4 : 0000000000000008
[ 264.040275] x3 : 0000000000000004 x2 : 0000000000000100
[ 264.045592] x1 : 1bcbcda14a1fc800 x0 : 0000000000000000
[ 264.050911] Call trace:
[ 264.053367] dev_watchdog+0x2fc/0x308
[ 264.057034] call_timer_fn.isra.0+0x20/0x78
[ 264.061218] run_timer_softirq+0x1a0/0x408
[ 264.065320] __do_softirq+0x120/0x23c
[ 264.068985] irq_exit+0xb8/0xd8
[ 264.072131] __handle_domain_irq+0x64/0xb8
[ 264.076227] gic_handle_irq+0x5c/0x148
[ 264.079982] el1_irq+0xb8/0x180
[ 264.083128] arch_cpu_idle+0x10/0x18
[ 264.086709] do_idle+0x200/0x280
[ 264.089936] cpu_startup_entry+0x20/0x40
[ 264.093868] secondary_start_kernel+0x154/0x190
[ 264.098396] ---[ end trace 6670558fa7ef539a ]---
[ 264.103053] fec 5b050000.ethernet eth0: TX ring dump
followed by a dump of the tx ring buffer. This seems to indicate the phy is unable to comply with the kernel's request to send the packets.
Right now we kinda don't know what else to investigate. Ideas would be appreciated.
Kind regards,
Alex
