Verdin Ethernet being disabled by system

Technical Support
, , , ,
1

Hello,
We are having an issue where we cannot communicate via Ethernet using the Verdin imx8mm on the Verdin Development Board. I receive the following messages after every boot:

user@localhost:~$ dmesg | tail
[    6.336541] mwifiex_sdio mmc2:0001:1: WLAN FW is active
[    6.336915] btmrvl_sdio mmc2:0001:2: sdio device tree data not available
[    6.376967] mwifiex_sdio mmc2:0001:1: Unknown api_id: 3
[    6.376975] mwifiex_sdio mmc2:0001:1: Unknown api_id: 4
[    6.376982] mwifiex_sdio mmc2:0001:1: Unknown GET_HW_SPEC TLV type: 0x217
[    6.395868] mwifiex_sdio mmc2:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (16.68.1.p197)
[    6.395883] mwifiex_sdio mmc2:0001:1: driver_version = mwifiex 1.0 (16.68.1.p197)
[   33.764560] REG_MIPI_PHY: disabling
[   33.764567] V3.3_ETH: disabling
[   33.764572] usb_otg1_vbus: disabling

The Ethernet LEDs are illuminated before this message and turn off as soon as the message is sent.
However, if I quickly log in before the disabling message is sent, I am still unable to detect the Ethernet port with ifconfig, lshw, etc.
When I add a second Ethernet port using the PCIe bus, the new port behaves fine.
Do you have any guidance on why these functions are being disabled and how to reactivate them?

Thanks!

Verdin iMX8MM Q 2GB WB IT V1.1A
Verdin Development Board V1.0B
Linux BSP 5.4.0
Ubuntu 20.04

2

Hi @esilva

The Verdin Development Board version you have had some issues and was replaced. It’s very possible that replacing your Development Board with a 1.1A or newer will resolve this issue. I think @michael.tx can help with this.

More details here and here.

Drew

3

Hi Drew,

I think it’s highly unlikely that the cause of our issues is the carrier board. We are using the X25 connector on the development board, which is basically just a straight bus between the connector and the Verdin module. Also, when we load the Easy Installer on this device, it lists images from the internet on the display, indicating that it is able to connect.

Thanks

4

@esilva it could be related to the fact that the newer BSPs explicitly do not support that older board revision. TEZI may be running on a different BSP version.

When you boot the board, can you interrupt it in U-Boot and see if you can get an IP address there using the dhcp command?

Drew

5

Hi Drew,

Sorry for the delay in my response, was kept away from this for a bit. Running dhcp in U-Boot does cause it to find an IP address from the network, so that appears to be working normally before the rest of the system has loaded.

Given the observations I made in the original post, do you have any thoughts on why the system is disabling these functions and how to reactivate them?

Thanks

6

I don’t have any thoughts off the top of my head but I am asking around internally.

Do you have just the one SOM and carrier board? Are you able to reproduce this on any other hardware?

Are you using a custom Yocto build or one of our reference images?

Drew

7

Hi Drew,

We have a custom carrier board that I have tested with and found the same behavior on the Ethernet port, including the functioning during U-Boot.

We are using a reference image and following the instructions listed here: Build U-Boot and Linux Kernel from Source Code | Toradex Developer Center

Thanks

8

Hi @esilva

We tried internally using the same board revision combination that you have with both the 5.4.0 and 5.1.0 stock reference images from our TEZI feed and could not reproduce this issue.

The link you provided is for building the kernel and u-boot but I am also curious about the rest of the image. Are you able to reproduce this issue with our stock reference images? You can build your own using this but ideally, you can test using the prebuilt versions available from our TEZI feeds.

Drew

9

You mean the V3.3_ETH: disabling message, right? The way this works is that the Ethernet MAC in the device tree [1] has a phy-supply regulator attached [2]. In our regular BSP, this should then all be handled correctly. However, should you have any kind of modifications what could happen is that said regulator is no longer handled correctly, not sure. Anyway, an easy workaround may be to specify the regulator-always-on property for that regulator.

10

Using the minimal reference image without any modifications, we are able to connect through Ethernet.

Thank you for the suggestion to use regulator-always-on. That does succeed in keeping the power on because I can see the LEDs stay on and the V3.3_ETH: disabling message never appears. However, the system still does not recognize the Ethernet port. This might suggest that the message was a symptom of the Ethernet issues rather than a cause. We’ll test some different configurations to see if that impacts the behavior.