Issue with colibri imx6ull 2nd ethernet interface (external PHY) in custom carrier board

Hello all.

Please we need assitance from Technical Support, urgent!

We have a Colibri module (imx6ULL) mounted in a custom carrier board and we want to use both of the ethernet interfaces available, the 1st one (with the PHY already integrated in the colibri module) and the 2nd one with an external PHY (in our case, we use the KSZ8081RNA).

We are experiencing a rare behaviour of the 2nd interface. The 2nd ethernet interface only works if the ethernet cable is connected in the 1st ethernet interface. Otherwise, the 2nd interface never comes up and doesn’t response. In other words, our sceneario is like this:

1st interface: cable connected
2nd interface: cable disconnected
=> 1st interface working just fine

1st interface: cable connected
2nd interface: cable connected
=> 1st and 2nd interface working just fine

1st interface: cable disconnected
2nd interface: cable connected
=> no activity in 2nd interface (and it doesn’t even detect the carrier)

Below is all the info regarding our SO, device tree, and console screen during and after booting.

Info about our SO and image (console screen during booting):

U-Boot 2020.07-5.7.0-devel+git.1cbeecee44a8 (Jun 27 2022 - 13:27:02 +0000)

CPU: Freescale i.MX6ULL rev1.1 900 MHz (running at 396 MHz)
CPU: Commercial temperature grade (0C to 95C) at 37C
Reset cause: POR
DRAM: 512 MiB
NAND: 512 MiB
MMC: FSL_SDHC: 0
Loading Environment from NAND… OK
In: serial
Out: serial
Err: serial
Model: Toradex Colibri iMX6ULL 512MB Wi-Fi / Bluetooth V1.1A, Serial# 06487386
Net: eth0: ethernet@20b4000
Hit any key to stop autoboot: 0
Booting from NAND…
ubi0: default fastmap pool size: 200
ubi0: default fastmap WL pool size: 100
ubi0: attaching mtd5
ubi0: scanning is finished
ubi0: attached mtd5 (name “ubi”, size 508 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 4057, bad PEBs: 7, corrupted PEBs: 0
ubi0: user volume: 4, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 102/55, WL threshold: 4096, image sequence number: 657248818
ubi0: available PEBs: 0, total reserved PEBs: 4057, PEBs reserved for bad PEB handling: 73
No size specified → Using max size (6731448)
Read 6731448 bytes from volume kernel to 81000000
No size specified → Using max size (55505)
Read 55505 bytes from volume dtb to 82100000
Kernel image @ 0x81000000 [ 0x000000 - 0x66b6b8 ]
'## Flattened Device Tree blob at 82100000
Booting using the fdt blob at 0x82100000
Loading Device Tree to 8ffef000, end 8ffff8d0 … OK
Updating MTD partitions…

Device tree:

imx6ul.dtsi

...
fec1: ethernet@2188000 {
				compatible = "fsl,imx6ul-fec", "fsl,imx6q-fec";
				reg = <0x02188000 0x4000>;
				interrupt-names = "int0", "pps";
				interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
					     <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
				clocks = <&clks IMX6UL_CLK_ENET>,
					 <&clks IMX6UL_CLK_ENET_AHB>,
					 <&clks IMX6UL_CLK_ENET_PTP>,
					 <&clks IMX6UL_CLK_ENET_REF>,
					 <&clks IMX6UL_CLK_ENET_REF>;
				clock-names = "ipg", "ahb", "ptp",
					      "enet_clk_ref", "enet_out";
				fsl,num-tx-queues = <1>;
				fsl,num-rx-queues = <1>;
				stop-mode = <&gpr 0x10 3>;
				fsl,magic-packet;
				fsl,wakeup_irq = <0>;
				status = "disabled";
			};
...
fec2: ethernet@20b4000 {
				compatible = "fsl,imx6ul-fec", "fsl,imx6q-fec";
				reg = <0x020b4000 0x4000>;
				interrupt-names = "int0", "pps";
				interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
					     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
				clocks = <&clks IMX6UL_CLK_ENET>,
					 <&clks IMX6UL_CLK_ENET_AHB>,
					 <&clks IMX6UL_CLK_ENET_PTP>,
					 <&clks IMX6UL_CLK_ENET2_REF_125M>,
					 <&clks IMX6UL_CLK_ENET2_REF_125M>;
				clock-names = "ipg", "ahb", "ptp",
					      "enet_clk_ref", "enet_out";
				fsl,num-tx-queues = <1>;
				fsl,num-rx-queues = <1>;
				stop-mode = <&gpr 0x10 4>;
				fsl,magic-packet;
				fsl,wakeup_irq = <0>;
				status = "disabled";
			};
...

imx6ull-colibri.dtsi:

...
{
 	aliases {
 		ethernet0 = &fec2;
 		ethernet1 = &fec1;
 };
...
 
 &fec2 {
 	pinctrl-names = "default", "sleep";
 	pinctrl-0 = <&pinctrl_enet2>;
 	pinctrl-1 = <&pinctrl_enet2_sleep>;
 	phy-mode = "rmii";
 	phy-handle = <&ethphy1>;
 	phy-supply = <&reg_eth_phy>;
 	status = "okay";
 
 	mdio {
 		#address-cells = <1>;
 		#size-cells = <0>;
 
 		ethphy1: ethernet-phy@2 {
 			compatible = "ethernet-phy-ieee802.3-c22";
 			max-speed = <100>;
 			reg = <2>;
 		};
 	};
 };
 ...
 (inside &iomuxc, among other modules):
 pinctrl_enet2: enet2-grp {
 			fsl,pins = <
 				MX6UL_PAD_GPIO1_IO06__ENET2_MDIO	0x1b0b0
 				MX6UL_PAD_GPIO1_IO07__ENET2_MDC		0x1b0b0
 				MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00	0x1b0b0
 				MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01	0x1b0b0
 				MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN	0x1b0b0
 				MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER	0x1b0b0
 				MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2	0x4001b031
 				MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00	0x1b0b0
 				MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01	0x1b0b0
 				MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN	0x1b0b0
 			>;
 		};
 
 		pinctrl_enet2_sleep: enet2sleepgrp {
 			fsl,pins = <
 				MX6UL_PAD_GPIO1_IO06__GPIO1_IO06	0x0
 				MX6UL_PAD_GPIO1_IO07__GPIO1_IO07	0x0
 				MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08	0x0
 				MX6UL_PAD_ENET2_RX_DATA1__GPIO2_IO09	0x0
 				MX6UL_PAD_ENET2_RX_EN__GPIO2_IO10	0x0
 				MX6UL_PAD_ENET2_RX_ER__GPIO2_IO15	0x0
 				MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2	0x4001b031
 				MX6UL_PAD_ENET2_TX_DATA0__GPIO2_IO11	0x0
 				MX6UL_PAD_ENET2_TX_DATA1__GPIO2_IO12	0x0
 				MX6UL_PAD_ENET2_TX_EN__GPIO2_IO13	0x0
 			>;
 		};

imx6ull-colibri-eval-v3.dtsi: (our board is a custom board, we left the name of the eval-v3, but we are not using that board)

...
&fec1 {
   	pinctrl-names = "default", "sleep";
   	pinctrl-0 = <&pinctrl_enet1>;
   	pinctrl-1 = <&pinctrl_enet1_sleep>;
   	phy-mode = "rmii";
   	phy-reset-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
   	phy-handle = <&ethphy0>;
   	phy-supply = <&reg_eth_phy>;
   	status = "okay";
 };
 &fec2 {
 	mdio {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		
 		ethphy0: ethernet-phy@0 {
 			compatible = "ethernet-phy-ieee802.3-c22";
 			max-speed = <100>;
 			reg = <0>;
 		};	
 		ethphy1: ethernet-phy@2 {
 			compatible = "ethernet-phy-ieee802.3-c22";
 			max-speed = <100>;
 			reg = <2>;
 		};
 	};
 };
 ...
 &iomuxc {
 	imx6ull-colibri {
 		pinctrl_enet1: enet1-grp {
 			fsl,pins = <
 				MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00	0x1b0b0
 				MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01	0x1b0b0
 				MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN		0x1b0b0
 				MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER		0x1b0b0
 				MX6UL_PAD_GPIO1_IO04__ENET1_REF_CLK1	0x4001b031
 				MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00	0x1b0b0
 				MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01	0x1b0b0
 				MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 		0x1b0b0
 				//Reset PHY
 				MX6ULL_PAD_SNVS_TAMPER4__GPIO5_IO04		0xb0
 			>;
 		};
 		pinctrl_enet1_sleep: enet1sleepgrp {
 			fsl,pins = <
 				MX6UL_PAD_ENET1_RX_DATA0__GPIO2_IO00	0x0
 				MX6UL_PAD_ENET1_RX_DATA1__GPIO2_IO01	0x0
 				MX6UL_PAD_ENET1_RX_EN__GPIO2_IO02	0x0
 				MX6UL_PAD_ENET1_RX_ER__GPIO2_IO07	0x0
 				MX6UL_PAD_GPIO1_IO04__ENET1_REF_CLK1	0x4001b031
 				MX6UL_PAD_ENET1_TX_DATA0__GPIO2_IO03	0x0
 				MX6UL_PAD_ENET1_TX_DATA1__GPIO2_IO04	0x0
 				MX6UL_PAD_ENET1_TX_EN__GPIO2_IO05	0x0
 			>;
 		};
 	};
 };

Console screen (during boot):

(some other lines)

[ 1.440329] fec 20b4000.ethernet eth0: registered PHC device 0
[ 1.451462] pps pps1: new PPS source ptp1
[ 1.458622] fec 2188000.ethernet eth1: registered PHC device 1

(some other lines)

Starting WPA supplicant…
[ 17.243461] Micrel KSZ8041 20b4000.ethernet-1:02: attached PHY driver [Micrel KSZ8041] (mii_bus:phy_addr=20b4000.ethernet-1:02, irq=POLL)
[ 17.295618] Generic PHY 20b4000.ethernet-1:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=20b4000.ethernet-1:00, irq=POLL)

(some other lines)

Console screen (ifconfig and networkctl commands):

(no cables connected)
ifconfig
eth0 Link encap:Ethernet HWaddr 00:14:2D:62:FD:5A
UP BROADCAST 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)

eth1 Link encap:Ethernet HWaddr 00:14:2D:72:FD:5A
UP BROADCAST 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)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:696 (696.0 B) TX bytes:696 (696.0 B)

root@colibri-imx6ull-06487386:~# networkctl -a
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether no-carrier unmanaged
3 eth1 ether no-carrier unmanaged

3 links listed.

(1st ethernet interface with cable connected)

root@colibri-imx6ull-06487386:~# [ 95.286050] fec 20b4000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[ 95.294628] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
networkctl -a
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable unmanaged
3 eth1 ether no-carrier unmanaged

(with the cable connected in the 1st interface, 2nd ethernet interface with cable connected)
root@colibri-imx6ull-06487386:~# [ 108.806041] fec 2188000.ethernet eth1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 108.814591] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

root@colibri-imx6ull-06487386:~# networkctl -a
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable unmanaged
3 eth1 ether routable unmanaged

3 links listed.

root@colibri-imx6ull-06487386:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:14:2D:62:FD:5A
inet addr:192.168.1.65 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::214:2dff:fe62:fd5a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:706 errors:0 dropped:0 overruns:0 frame:0
TX packets:101 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:59359 (57.9 KiB) TX bytes:15887 (15.5 KiB)

eth1 Link encap:Ethernet HWaddr 00:14:2D:72:FD:5A
inet addr:192.168.1.93 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::214:2dff:fe72:fd5a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:464 errors:30 dropped:0 overruns:0 frame:30
TX packets:52 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:37185 (36.3 KiB) TX bytes:9709 (9.4 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:28 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2251 (2.1 KiB) TX bytes:2251 (2.1 KiB)

(with only the 2nd interface with the cable connected)
root@colibri-imx6ull-06487386:~# networkctl -a
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether no-carrier unmanaged
3 eth1 ether no-carrier unmanaged

3 links listed.

root@colibri-imx6ull-06487386:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:14:2D:62:FD:5A
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:761 errors:0 dropped:0 overruns:0 frame:0
TX packets:105 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:63252 (61.7 KiB) TX bytes:17091 (16.6 KiB)

eth1 Link encap:Ethernet HWaddr 00:14:2D:72:FD:5A
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:516 errors:38 dropped:0 overruns:0 frame:38
TX packets:52 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:41571 (40.5 KiB) TX bytes:9709 (9.4 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:44 errors:0 dropped:0 overruns:0 frame:0
TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3315 (3.2 KiB) TX bytes:3315 (3.2 KiB)

It seems like the 2nd interface is correlated in some way with the 1st one. If the cable is connected in the 1st interface, the 2nd one works perfect. But alone, it doesn’t.

From the hardware point of view, there is nothing thats make us suspect there is a problem.

We really don’t know if there is a problem with the driver assigned to the 2nd PHY or in the initialization of the PHY, or something in the device tree.

Hope a soon response.

Best regards,
Martin

Hi @martin_mig !

Thanks a lot for the detailed question!

I saw that you guys added both ethphy0 and ethphy1 inside fec2, why exactly did you do this? Is the second phy connected to fec1 in another place? If not, can you please try to add it and see if it solves the issue?

For example:

&fec1 {
   	pinctrl-names = "default", "sleep";
   	pinctrl-0 = <&pinctrl_enet1>;
   	pinctrl-1 = <&pinctrl_enet1_sleep>;
   	phy-mode = "rmii";
   	phy-reset-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
   	phy-handle = <&ethphy0>;
   	phy-supply = <&reg_eth_phy>;
    status = "okay";

 	mdio {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		
 		ethphy0: ethernet-phy@0 {
 			compatible = "ethernet-phy-ieee802.3-c22";
 			max-speed = <100>;
 			reg = <0>;
 		};
 	};
 };

 &fec2 {
 	mdio {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		
 		ethphy1: ethernet-phy@2 {
 			compatible = "ethernet-phy-ieee802.3-c22";
 			max-speed = <100>;
 			reg = <2>;
 		};
 	};
 };

Best regards,
Daniel Morais

Hi @daniel_m.tx

Thanks for the response!

We followed your instructions, and here are the results:

Console screen (during boot):

(some other lines)

[ 1.453073] fec 20b4000.ethernet eth0: registered PHC device 0
[ 1.464184] pps pps1: new PPS source ptp1
[ 1.471388] fec 2188000.ethernet eth1: registered PHC device 1

(some other lines)

    Starting WPA supplicant...

[ 17.312105] Micrel KSZ8041 20b4000.ethernet-1:02: attached PHY driver [Micrel KSZ8041]
(mii_bus:phy_addr=20b4000.ethernet-1:02, irq=POLL)
[ 17.367692] fec 2188000.ethernet eth1: Unable to connect to phy

(some other lines)

Console screen (ifconfig and networkctl commands):

(no cable connected in neither interfaces)
root@colibri-imx6ull-06487386:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:14:2D:62:FD:5A
UP BROADCAST 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)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:696 (696.0 B) TX bytes:696 (696.0 B)

networkctl -a
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether no-carrier unmanaged
3 eth1 ether off unmanaged

3 links listed.

With your code, it seems like the driver can’t communicate with the PHY. No interface is shown neither with the ifconfig and networkctl -a commands.

We know that the MDIO/MDC pins are shared between the two interfaces (it’s only one bus). The pinctrl tag which define the pins for MDIO/MDC are in the fec2, but when we define the subnode mdio inside the fec1, there is no pinctrl definition for the MDIO/MDC pins because they are the same as the fec2, thats why we did it like that.

Please, tell us if we must define the pins MDIO/MDC in the pinctrl enet1, even though the same pins are already defined in pinctrl enet2. Or how is the correct way to define the device tree in order to have the two PHYs working independently.

Hope a soon response.

Best regards,
Martin

Hi @martin_mig ,

Checking the NXP community and some examples, the correct way is adding both ethphys into the same fec, since Colibri iMX6ULL shares the MDIO between the PHYs. Please undo the changes I commented on before.

I’m still verifying what can be causing this issue but didn’t find any solution yet. I will come to you as soon as I have an answer or a test to ask.

One question, when you connect only the second ethernet, do you see something on dmesg? Or the link is not initialized?

Best regards,
Daniel Morais

Hi @daniel_m.tx

As I mentioned in the first post, when I connect the ethernet cable only in the 2nd interface, nothing happens on the console (I don’t see any “link becomes ready”).

Console screen (during boot):

(some other lines)

[ 1.453514] fec 20b4000.ethernet eth0: registered PHC device 0
[ 1.464641] pps pps1: new PPS source ptp1
[ 1.471816] fec 2188000.ethernet eth1: registered PHC device 1

(some other lines)

Starting WPA supplicant…
[ 17.283037] Micrel KSZ8041 20b4000.ethernet-1:02: attached PHY driver [Micrel KSZ8041] (mii_bus:phy_addr=20b4000.ethernet-1:02, irq=POLL)
[ 17.339048] Generic PHY 20b4000.ethernet-1:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=20b4000.ethernet-1:00, irq=POLL)

(some other lines)

I performed this commands with only the 2nd interface connected and this is what I got:

root@colibri-imx6ull-06487386:~# dmesg | grep -i eth1
[ 1.471816] fec 2188000.ethernet eth1: registered PHC device 1

(which is the same message shown in the boot time).

Although nothing happens on the console when only the 2nd interface is connected, the driver seems to see the interface and seems to be initialized, but somehow it’s attached to the first interface.
Again, the 2nd interface is detected by the ifconfig command.

Hope a soon response.

Best regards,
Martin

Hi @martin_mig ,

Can you please try to execute the ethtool into the second ethernet as explained here?

What is strange is that when no cables are connected we are seeing off unmanaged, when we expect to see no-carrier unmanaged too, as we can see below:

And after connecting the first cable, we see the correct setup:

With the cables disconnected, what is the status of the eth1 on ip show? If you bring up the interface using these commands, does the output of the networkctl -a change?

If the above info doesn’t work, can you please add the following variable on the bootloader to enable the dynamic debug and send us the entire dmesg after the tests?

setenv tdxargs 'dyndbg=\\"file phy.c +p;\\"'

Best regards,
Daniel Morais

Hi @daniel_m.tx

First, we cannot execute the ethtool command because we don’t have it installed in our image, and we don’t have the apt get install utility installed either.

Second, you missunderstood the captures i sent. Let me explain.

The capture below corresponds to the test we made with your proposed changes in the device tree where the mdio subnodes where separated inside each fec interface.

networkctl -a
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether no-carrier unmanaged
3 eth1 ether off unmanaged

3 links listed.

In this case, the 2nd interface (eth1) it’s not even listed with ifconfig.

On other hand, the second capture below, corresponds to the first test we made where the device tree had the two mdio subnodes inside fec2 and with a cable connected only in the first interface.

networkctl -a
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable unmanaged
3 eth1 ether no-carrier unmanaged

So to sum up:
*- with no cables connected => both interfaces are in no-carrier state.
*- with cable connected only on eth0 => eth0 is routable and eth1 is no-carrier.
*- with cable connected on eth0 and eth1 => both iterfaces are in routable state.
*- with cable connected only on eth1 => both interfaces are in no-carrier state.

Let me know if that clarifies the whole thing.

We did the setenv tdxargs ‘dyndbg=\“file phy.c +p;\”’, but then we don’t know how to print out the log or messagges you requested. Please explain us how to do that.

We are stil struggling with this issue.

Is there any kernel option or something in the toradex images thats relates to two ethernet interfaces bonded like this?

Hope a soon response.

Best regards,
Martin

Hi @martin_mig ,

Sorry for the delay in answering!

Were you able to advance on this issue?

Best regards,
Daniel Morais

Hi @daniel_m.tx,

We are still not able to make it work. The second ethernet is still somehow tied to the first interface.

We got the second interface recognized by the OS and, coupled with the generic PHY driver, we can connect to the two interfaces independently. But, the performance of the interfaces is quite poor. We tested them using two different networks and using two laptops pinging each of the interfaces. When we disconnect the first interface, the second interface stops sending the ping response and a few seconds later it starts responding again, but it is not a stable ping response. Then if we plug the cable back to the first interface, it starts to respond but also with unstable response. Thats where we got so far.

Changing the subject, I want to ask you if there is any module or SoC that can provide two independent ethernet interfaces that support fiber.

Thanks in advanced.

Looking forward a soon response.

Regards,
Martin

Hi @martin_mig ,

Thanks for the update. I don’t have the hardware to do some tests with dual ethernet on iMX6ULL, I’m verifying internally if we can do some tests on this in order to help you.

About your doubt, on the Colibri family, we have the Colibri iMX7 that has another RGMII independent of the first one, in this case, you can add one PHY with fiber support. The Colibri iMX7 uses the PHY KSZ8041NL for the first ethernet, which by default doesn’t support fiber, one solution to add fiber could be adding an Ethernet Switch which features copper and fiber ports. The copper part could be coupled capacitively. This means instead of magnetics, only capacitors are required. However, the switch solution is probably quite expensive and not an energy-efficient solution.

For curiosity, we also have other options on the Verdin Family, where we have by default the Verdin Development Board with dual ethernet that may help with the tests.

Best regards,
Daniel Morais

If it is still relevant, I will answer all those who will work with KSZ8041. The fact is that KSZ8041 responds by default at address 0 in addition to its own address (carefully look at the data sheet). This is not a bug, but a feature and you will have to live with it) You will have to transfer the second phy to an address other than 0 or programmatically