root@colibri-imx7-07271340:/usr/bin# tdx-info
Software summary
Bootloader: U-Boot
Kernel version: 6.6.95-7.3.0-devel #1 SMP PREEMPT Fri Jun 27 10:09:04 UTC 2025
Kernel command line: ubi.mtd=ubi root=ubi0:rootfs rootfstype=ubifs ubi.fm_autoconvert=1 console=tty1 console=ttymxc0,115200n8 mtdparts=gpmi-nand:512k(mx7-bcb),1536k(u-boot1)ro,1536k(u-boot2)ro,512k(u-boot-env),-(ubi)
Distro name: NAME=“TDX Wayland with XWayland Upstream”
Distro version: VERSION_ID=7.3.0-devel-20250724151155-build.0
Distro variant: -
Hostname: colibri-imx7-07271340
Hardware info
HW model: Toradex Colibri iMX7S on Colibri Evaluation Board V3
Toradex version: 0032 V1.1D
Serial number: 07271340
Processor arch: armv7l
The EThernet interface eth0 almost takes 60 to 80 seconds, after the board is powered on, to respond(ARP Reply) to a PING request from host PC. The eth0 is configured to use static IP address settings using the ‘connman’ service app(not using systemd-networkd) to make sure DHCP Client is not active.
The board takes around 35 to 40 seconds to boot into the login prompt in the serial terminal as shown in the log below:
[2025-07-25 15:41:00.883] U-Boot 2024.07-7.3.0-devel+git.3f772959501c (Jul 01 2024 - 18:07:18 +0000)
[2025-07-25 15:41:00.892]
[2025-07-25 15:41:00.892] CPU: Freescale i.MX7S rev1.3 800 MHz (running at 792 MHz)
[2025-07-25 15:41:00.900] CPU: Extended Commercial temperature grade (-20C to 105C) at 33C
[2025-07-25 15:41:00.900] Reset cause: POR
[2025-07-25 15:41:00.900] DRAM: 256 MiB
[2025-07-25 15:41:00.979] Core: 90 devices, 20 uclasses, devicetree: separate
[2025-07-25 15:41:00.986] WDT: Started watchdog@30280000 with servicing every 1000ms (128s timeout)
[2025-07-25 15:41:00.995] PMIC: RN5T567 LSIVER=0x01 OTPVER=0x0d
[2025-07-25 15:41:00.995] NAND: 512 MiB
[2025-07-25 15:41:01.011] MMC: FSL_SDHC: 1
[2025-07-25 15:41:01.011] Loading Environment from MMC… MMC Device 0 not found
[2025-07-25 15:41:01.011] *** Warning - No MMC card found, using default environment
[2025-07-25 15:41:01.011]
[2025-07-25 15:41:01.028] Loading Environment from NAND… OK
[2025-07-25 15:41:01.043] In: serial
[2025-07-25 15:41:01.043] Out: serial
[2025-07-25 15:41:01.043] Err: serial
[2025-07-25 15:41:01.043] Model: Toradex 0032 Colibri iMX7S 256MB V1.1D
[2025-07-25 15:41:01.043] Serial#: 07271340
[2025-07-25 15:41:01.115] SEC0: RNG instantiated
[2025-07-25 15:41:01.123] Net: eth0: ethernet@30be0000
[2025-07-25 15:41:01.155] Hit any key to stop autoboot: 1 0
[2025-07-25 15:41:02.150] Booting from NAND…
…
[2025-07-25 15:41:32.488] [ 28.094972] fec 30be0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[2025-07-25 15:41:32.533] [ 28.146441] 8021q: 802.1Q VLAN Support v1.8
[2025-07-25 15:41:33.207]
[2025-07-25 15:41:33.207] TDX Wayland with XWayland Upstream 7.3.0-devel-20250724151155+build.0 (scarthgap) colibri-imx7-07271340 ttymxc0
[2025-07-25 15:41:33.223] Colibri-iMX7_Reference-Minimal-Image-upstream
[2025-07-25 15:41:33.223]
[2025-07-25 15:41:33.223] colibri-imx7-07271340 login:
The boot process is completed at 15:41:33.
The Ethernet traffic capture in Wireshark:
The ‘ARP Reply’ packet comes at 15:42:11, almost 70 seconds after power cycling.
My queries below:-
-
Is it possible to reduce the time taken by the Ethernet eth0 interface to do a quicker response to PING requests from other devices?
-
There seems to be neither ARP Announcement nor Gratuitous ARP from eth0. Does these needs to be specifically enabled? If yes, how do we go about it.
Thanks in advance for your answers.
BR,
Vijay.
Hi, I’m the Toradex AI Assistant.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer? 
Hello Vijay,
Thank you for your detailed description and analysis!
Let’s address your queries about Ethernet (eth0) response delay and ARP behavior on your Colibri iMX7S running TDX Wayland 7.3.0-devel with a static IP via ConnMan.
1. Reducing Ethernet eth0 Response Time
Observation:
- Your board boots to login at ~33 seconds after power-on.
- However, eth0 responds to a PING/ARP only after almost 70 seconds, indicating an additional ~35 second delay.
What’s happening:
When using ConnMan for static IP, the eth0 interface is not immediately available after boot—ConnMan takes additional time to bring up the interface and configure IPs, even for static settings. This is a known characteristic of ConnMan, especially on resource-constrained hardware.
What you can try:
-
Check AutoConnect and make the connection ‘Favorite’:
Ensures that ConnMan brings up eth0 as soon as possible:
connmanctl services
connmanctl services ethernet_XXXXXXXXXXXX_cable
Look for AutoConnect = True and Favorite = True. If not set, run:
connmanctl connect ethernet_XXXXXXXXXXXX_cable
connmanctl config ethernet_XXXXXXXXXXXX_cable --autoconnect yes
-
Switch to systemd-networkd (advanced, optional):
Users requiring faster/static and consistent network bring-up sometimes replace ConnMan with systemd-networkd. To do this:
- Disable ConnMan (this disables all ConnMan-managed configurations):
systemctl disable connman
systemctl stop connman
- Enable systemd-networkd:
systemctl enable systemd-networkd
systemctl start systemd-networkd
- Configure eth0 static IP by creating
/etc/systemd/network/20-wired.network:[Match]
Name=eth0
[Network]
Address=192.168.1.100/24
Gateway=192.168.1.1
Adjust IP and gateway for your setup.
More info:
Ethernet on Linux
-
Manual configuration for debugging:
Bring the interface up as soon as possible after login to see if the delay is only ConnMan-related (does not persist after reboot):
ip link set eth0 up
ip addr add 192.168.1.100/24 dev eth0
ip route add default via 192.168.1.1
2. ARP Announcements / Gratuitous ARP
Default Behavior:
- ConnMan does not proactively send ARP Announcements or Gratuitous ARP on static IP configuration. It will reply to incoming ARP requests only after the interface is fully configured and up.
If you want an ARP Announce/Gratuitous ARP:
-
Manual Trigger
You can send a Gratuitous ARP yourself if needed for applications like network switches learning the IP quickly.
-
Automate after network is up:
Add a script in /etc/network/if-up.d/ (if using systemd-networkd or classic networking) or use a systemd service that is triggered by ‘network online’ (After=network-online.target), to send arping as shown above.
Summary
- The extra eth0 ARP/PING delay is due to ConnMan needing more time to initialize—and is not a hardware limitation.
- For faster static IP/ARP response, switching to systemd-networkd or manual configuration is recommended.
- ConnMan does not send Gratuitous ARP by default; use
arping if required.
References:
Let me know if you’d like step-by-step guidance on switching to systemd-networkd or automating ARP Announcements!
Best regards,
Toradex AI Assistant.
As suggested by the Toradex AI Assistant we built a new Console image(Colibri-iMX7_Reference-Minimal-Image) with connman package(connman, connman-client etc.) removed.
So tested the Ethernet eth0 activation delay(ARP Reply) using only the systemd-networkd and a wired.network file with static IP address settings in the /etc/systemd/network .
But we still see the same problem. The board, after power cycling, takes around 35 seconds to boot completely and the PING reply from the eth0 network interface takes around 70 to 80 seconds.
Also, because there is no ARP Announcement other devices in the network are not able to update their respective ARP cache as soon as possible.
