i.MX ProcessorsのトピックRe: Ethernet problem with i.MX 7Dual and DP83849IVS PHY

Ethernet problem with i.MX 7Dual and DP83849IVS PHY

rasmusrahunen — Fri, 16 Dec 2016 14:34:24 GMT

Hi all,

We have built our own i.MX 7Dual prototype board and its design is mostly based on i.MX 7Dual SABRE development kit reference design. But there are a few hardware changes; We have replaced the ethernet PHY chip with Texas Instruments DP83849IVS and we are using the RMII interface to connect to the PHY. We also use an external oscillator (ASFL1-50.000MHZ-EC-T) to provide the RMII reference clock.

We are using Yocto / Krogoth environment from https://github.com/Freescale/fsl-community-bsp-platform and our board configuration is based on the imx7dsabresd machine configuration. The Linux kernel version is 4.1.35. I have attached the ethernet device configuration and the pin muxing parts from the Linux device tree below that we have modified from the imx7d-sdb.dts.

The problem with our setup is that the ethernet connection doesn't seem to work at all. When checking the RMII TX data lines (ENET1_TDATA0, ENET1_TDATA1) with an oscilloscope, there is no activity on those lines at all... On the RX data lines, there seems to be some activity (ENET1_RDATA0, ENET1_RDATA1). But based on Linux boot logs, the device seems to boot up without major errors. If the network interface is brought down, the following error gets printed:

fec 30be0000.ethernet eth0: Graceful transmit stop did not complete!
We are also trying to bridge the connection from eth0 to eth1, this is made with a startup script and visible in the log where the "Graceful transmit stop did not complete!" occurs.

I have filtered some network related prints from the Linux boot log below. As you can see from the log, I haven't yet assigned MAC addresses, so Linux will use random MAC addresses. Can this cause problems? I've also tried setting the real MAC addresses in U-Boot and/or in Linux device tree, but it didn't change anything...

I have seen other users having similar problems here on the NXP community discussion groups and tried some of the suggested fix proposals. Here is a list of changes that have been made:

The device tree file changes to imx7d-sdb.dts are attached below
The DP8384x.c driver has been integrated from https://github.com/opennetworklinux/linux-3.8.13/blob/master/drivers/net/phy/dp8384x.c
Commented out "fec_enet_clk_enable(ndev, false);" from fec_probe function in fec_main.c as suggested in https://community.nxp.com/thread/389902
Also tried to configure the IMX7D_GPR1_ENET_TX_CLK_SEL_MASK bits to 1, since we are using external 50MHz clock source for the RMII interface

Can you see if there are any serious problems in the device tree configuration and the pin mux? What could explain the total silence in the data lines?

Also do I need to somehow configure the 50MHz clock to the fec1 and fec2 devices, since in our case it's provided from the external clock source and not from the processor PLL?

Best regards,
Rasmus Rahunen

UPDATE: 20-Dec-2016:

Corrected the comment that there is no activity on the TX data lines, but some traffic on RX data lines.

Device tree file:

&fec1 {

pinctrl-names = "default";

pinctrl-0 = <&pinctrl_enet1>;

pinctrl-assert-gpios = <&gpio7 15 GPIO_ACTIVE_HIGH>;

clocks = <&clks IMX7D_ENET_AXI_ROOT_CLK>,

<&clks IMX7D_ENET_AXI_ROOT_CLK>,

<&clks IMX7D_ENET1_TIME_ROOT_CLK>,

<&clks IMX7D_PLL_ENET_MAIN_50M_CLK>,

<&clks IMX7D_ENET1_REF_ROOT_CLK>;

clock-names = "ipg", "ahb", "ptp",

"enet_clk_ref", "enet_out";

assigned-clocks = <&clks IMX7D_ENET1_TIME_ROOT_SRC>,

<&clks IMX7D_ENET1_TIME_ROOT_CLK>;

assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;

assigned-clock-rates = <0>, <100000000>;

phy-mode = "rmii";

phy-handle = <&ethphy0>;

fsl,magic-packet;

status = "okay";

mdio {

#address-cells = <1>;

#size-cells = <0>;

ethphy0: ethernet-phy@0 {

compatible = "ethernet-phy-ieee802.3-c22";

reg = <0>;

};

ethphy1: ethernet-phy@1 {

compatible = "ethernet-phy-ieee802.3-c22";

reg = <1>;

};

&fec2 {

pinctrl-names = "default";

pinctrl-0 = <&pinctrl_enet2>;

clocks = <&clks IMX7D_ENET_AXI_ROOT_CLK>,

<&clks IMX7D_ENET_AXI_ROOT_CLK>,

<&clks IMX7D_ENET2_TIME_ROOT_CLK>,

<&clks IMX7D_PLL_ENET_MAIN_50M_CLK>,

<&clks IMX7D_ENET2_REF_ROOT_CLK>;

clock-names = "ipg", "ahb", "ptp",

"enet_clk_ref", "enet_out";

assigned-clocks = <&clks IMX7D_ENET2_TIME_ROOT_SRC>,

<&clks IMX7D_ENET2_TIME_ROOT_CLK>;

assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;

assigned-clock-rates = <0>, <100000000>;

phy-mode = "rmii";

phy-handle = <&ethphy1>;

fsl,magic-packet;

status = "okay";

};

&iomuxc {

imx7d-sdb {

pinctrl_enet1: pinctrl_enet1grp {

fsl,pins = <

MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 0x00000001

MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 0x00000001

MX7D_PAD_ENET1_RGMII_RXC__ENET1_RGMII_RXC 0x00000001

MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL 0x00000001

MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 0x00000001

MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 0x00000001

MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL 0x00000001

MX7D_PAD_ENET1_TX_CLK__ENET1_TX_CLK 0x40000001

MX7D_PAD_GPIO1_IO10__ENET1_MDIO 0x00000003

MX7D_PAD_GPIO1_IO11__ENET1_MDC 0x00000003

MX7D_PAD_ENET1_COL__GPIO7_IO15 0x00000034

>;

};

pinctrl_enet2: pinctrl_enet2grp {

fsl,pins = <

MX7D_PAD_EPDC_BDR0__ENET2_TX_CLK 0x40000001

MX7D_PAD_EPDC_GDRL__ENET2_RGMII_TX_CTL 0x00000001

MX7D_PAD_EPDC_SDCE0__ENET2_RGMII_RX_CTL 0x00000001

MX7D_PAD_EPDC_SDCE1__ENET2_RX_ER 0x00000001

MX7D_PAD_EPDC_SDCE2__ENET2_RGMII_TD0 0x00000001

MX7D_PAD_EPDC_SDCE3__ENET2_RGMII_TD1 0x00000001

MX7D_PAD_EPDC_SDCLK__ENET2_RGMII_RD0 0x00000001

MX7D_PAD_EPDC_SDLE__ENET2_RGMII_RD1 0x00000001

>;

};

...

Filtered Linux boot log:

NET: Registered protocol family 16

NET: Registered protocol family 2

TCP established hash table entries: 8192 (order: 3, 32768 bytes)

TCP bind hash table entries: 8192 (order: 4, 65536 bytes)

TCP: Hash tables configured (established 8192 bind 8192)

UDP hash table entries: 512 (order: 2, 16384 bytes)

UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)

NET: Registered protocol family 1

RPC: Registered named UNIX socket transport module.

RPC: Registered udp transport module.

RPC: Registered tcp transport module.

RPC: Registered tcp NFSv4.1 backchannel transport module.

30be0000.ethernet supply phy not found, using dummy regulator

pps pps0: new PPS source ptp0

fec 30be0000.ethernet (unnamed net_device) (uninitialized): Invalid MAC address: 00:00:00:00:00:00

fec 30be0000.ethernet (unnamed net_device) (uninitialized): Using random MAC address: c2:d4:df:69:a4:50

libphy: fec_enet_mii_bus: probed

fec 30be0000.ethernet eth0: registered PHC device 0

30bf0000.ethernet supply phy not found, using dummy regulator

pps pps1: new PPS source ptp1

fec 30bf0000.ethernet (unnamed net_device) (uninitialized): Invalid MAC address: 00:00:00:00:00:00

fec 30bf0000.ethernet (unnamed net_device) (uninitialized): Using random MAC address: d6:51:d1:2d:7c:14

fec 30bf0000.ethernet eth1: registered PHC device 1

NET: Registered protocol family 26

NET: Registered protocol family 10

sit: IPv6 over IPv4 tunneling driver

NET: Registered protocol family 17

bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.

8021q: 802.1Q VLAN Support v1.8

Key type dns_resolver registered

INIT: Entering runlevel: 5

Configuring network interfaces... fec 30be0000.ethernet eth0: Freescale FEC PHY driver [NatSemi DP83849] (mii_bus:phy_addr=30be0000.etherne:

00, irq=-1)

IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

fec 30be0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off

IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

done.

Starting system message bus: dbus.

Starting Dropbear SSH server: dropbear.

Starting rpcbind daemon...done.

Starting bluetooth

bluetoothd

Starting syslogd/klogd: done

* Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon [ ok ]

Starting Telephony daemon

Starting Linux NFC daemon

Running local boot scripts (/etc/rc.local)fec 30be0000.ethernet eth0: Graceful transmit stop did not complete!

device eth0 entered promiscuous mode

device eth1 entered promiscuous mode

fec 30be0000.ethernet eth0: Freescale FEC PHY driver [NatSemi DP83849] (mii_bus:phy_addr=30be0000.etherne:00, irq=-1)

fec 30bf0000.ethernet eth1: Freescale FEC PHY driver [NatSemi DP83849] (mii_bus:phy_addr=30be0000.etherne:01, irq=-1)

IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready

br0: port 1(eth0) entered forwarding state

br0: port 1(eth0) entered disabled state

fec 30be0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off

br0: port 1(eth0) entered forwarding state

fec 30bf0000.ethernet eth1: Link is Up - 100Mbps/Full - flow control rx/tx

IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

br0: port 2(eth1) entered forwarding state

br0: port 1(eth0) entered forwarding state

br0: port 2(eth1) entered forwarding state

.

Re: Ethernet problem with i.MX 7Dual and DP83849IVS PHY

rasmusrahunen — Wed, 21 Dec 2016 06:58:43 GMT

We have also tested with real MAC addresses written into i.MX7 OTP registers, but that did not have effect on the behavior, so uninitialized MAC addresses were not the root cause.

Re: Ethernet problem with i.MX 7Dual and DP83849IVS PHY

jimmychan — Wed, 21 Dec 2016 09:27:23 GMT

It is better to use the official BSP from linux-2.6-imx.git - Freescale i.MX Linux Tree

For details, please read the i.MX_Yocto_Project_User's_Guide in

L4.1.15_2.0.0_LINUX_DOCS

Re: Ethernet problem with i.MX 7Dual and DP83849IVS PHY

rasmusrahunen — Thu, 22 Dec 2016 09:00:15 GMT

Hi Jimmy,

Thank you for the suggestion. However, we were able to solve the problem by modifying the pin mux for ENET1_TX_CLK and ENET2_TX_CLK in the device tree file. I have highlighted the changed lines in red color below:

pinctrl_enet1: pinctrl_enet1grp {
   fsl,pins = <
      MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 0x00000001
      MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 0x00000001
      MX7D_PAD_ENET1_RGMII_RXC__ENET1_RGMII_RXC 0x00000001
      MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL 0x00000001
      MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 0x00000001
      MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 0x00000001
      MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL 0x00000001
      MX7D_PAD_ENET1_TX_CLK__CCM_ENET_REF_CLK1 0x40000001
      MX7D_PAD_GPIO1_IO10__ENET1_MDIO 0x00000003
      MX7D_PAD_GPIO1_IO11__ENET1_MDC 0x00000003
      MX7D_PAD_ENET1_COL__GPIO7_IO15 0x00000034
   >;
};

pinctrl_enet2: pinctrl_enet2grp {
   fsl,pins = <
      MX7D_PAD_EPDC_BDR0__CCM_ENET_REF_CLK2 0x40000001
      MX7D_PAD_EPDC_GDRL__ENET2_RGMII_TX_CTL 0x00000001
      MX7D_PAD_EPDC_SDCE0__ENET2_RGMII_RX_CTL 0x00000001
      MX7D_PAD_EPDC_SDCE1__ENET2_RX_ER 0x00000001
      MX7D_PAD_EPDC_SDCE2__ENET2_RGMII_TD0 0x00000001
      MX7D_PAD_EPDC_SDCE3__ENET2_RGMII_TD1 0x00000001
      MX7D_PAD_EPDC_SDCLK__ENET2_RGMII_RD0 0x00000001
      MX7D_PAD_EPDC_SDLE__ENET2_RGMII_RD1 0x00000001
   >;
};

In addition, we have disabled the "enet_out" for both fec1 and fec2, by renaming the clock name to "no_enet_out". This change was not probably mandatory, but since we have an external clock, it does seem to make sense to disable the internal clock.

Both of these modifications were inspired by the device tree file in http://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/boot/dts/imx7-colibri.dtsi?h=toradex_imx_4.1.15_1.0.0_ga

The ethernet is now working fine.

Best regards,

Rasmus

Re: Ethernet problem with i.MX 7Dual and DP83849IVS PHY

svenbrauch — Thu, 15 Feb 2018 13:08:40 GMT

Thank your very much for posting this solution, I had the exact same setup and problem and it helped me a lot. Works now here as well. :-)

Re: Ethernet problem with i.MX 7Dual and DP83849IVS PHY

rasmusrahunen — Thu, 15 Feb 2018 14:31:50 GMT

Hi Sven,

Great! It's good to hear this post has been helpful to someone else. :smileyhappy:

Best regards,

Rasmus

Re: Ethernet problem with i.MX 7Dual and DP83849IVS PHY

x10 — Wed, 20 Jun 2018 07:05:41 GMT

Hi, Rasmus

I have problem on config fec2 with rmii in my design.

In Table 5-10 of RM, the direction of signal CCM_ENET2_REF_CLK is defined as output only, but it was configured as input (MX7D_PAD_EPDC_BDR0__CCM_ENET_REF_CLK2 0x40000001) in your dts which confused me. Thanks for your explain in advance.

Cheng Shi

Re: Ethernet problem with i.MX 7Dual and DP83849IVS PHY

rasmusrahunen — Wed, 20 Jun 2018 13:48:41 GMT

Hi Cheng,

I admit that it is a bit confusing and I suspect that there is a mistake in the reference manual and the pin can also act as input.

For us this configuration made Ethernet working since the clock was coming from an external oscillator, but I also agree that this setup seems to contradict with the reference manual...

BR, Rasmus

Re: Ethernet problem with i.MX 7Dual and DP83849IVS PHY

x10 — Thu, 21 Jun 2018 07:30:45 GMT

Hi Rasmus

Thanks for your confirmation. I checked and found the level of external 50MHz clock is bit low, and changed to use CCM_ENET_PHY_REF_CLK as external clock source, with 50MHz configuration of course. FEC2 is working now. Thanks for your help.

Cheng Shi

Re: Ethernet problem with i.MX 7Dual and DP83849IVS PHY

rasmusrahunen — Thu, 21 Jun 2018 12:19:17 GMT

Hi Cheng,

Great to hear you got it working!

BR, Rasmus

Re: Ethernet problem with i.MX 7Dual and DP83849IVS PHY

triedgetech — Mon, 14 Feb 2022 05:11:51 GMT

hello I have similar issue with "Could not activate connection: Connection 'Ifupdown (eth0)' is not available on device eth0 because device has no carrier.

I did notice PHY's (KSZ8091) 50MHz clock, which is derived from a 25Mhz oscillator on its XO/XI pins, is rather low in amplitude, but you said you fixed it in software?

Do you add CCM_ENET_PHY_REF_CLK in dtsi file?

Doesn't that pin physically differ from TD2 one? Like you'd have to physically connect REF_CLK pin of PHY to corresponding pin? Did you have to connect pins differently?

Here's relevant thread of mine.