How to Setup EC-Master on Qualcomm Dragonwing™ IQ-9075 Evaluation Kit
The Qualcomm Dragonwing IQ-9075 EVK is a high-performance edge AI platform based on the QCS9075 SoC. Combined with the acontis EC-Master and a real-time Linux kernel, it becomes a capable EtherCAT MainDevice controller suitable for robotics and industrial automation applications.
This guide covers the complete setup from building a real-time Yocto image to loading atemsys and tuning Linux for deterministic EtherCAT communication.
Install Linux and EC-Master
Step 1: Set Up the Host Computer
To prepare your Ubuntu build host, run the following commands:
sudo apt update
sudo apt install build-essential chrpath cpio debianutils diffstat \
file gawk gcc git iputils-ping libacl1 locales python3 python3-git \
python3-jinja2 python3-pexpect python3-pip python3-subunit socat \
texinfo unzip wget xz-utils zstd
sudo apt install pipx
# Restart your shell session after running this command to ensure path changes take effect
pipx ensurepath
# The kas version is expected to be 4.8 or higher
pipx install "kas>=4.8"
Step 2: Download the Qualcomm Yocto Project
Initialize the Yocto workspace with the real-time Linux manifest:
mkdir <WORKSPACE_DIR>
cd <WORKSPACE_DIR>
git clone https://github.com/qualcomm-linux/meta-qcom -b qli-2.0
kas shell meta-qcom/ci/iq-9075-evk.yml:meta-qcom/ci/linux-qcom-rt-6.18.yml:meta-qcom/ci/qcom-distro-kvm.yml
Step 3: Tune the Real-Time Kernel
Two key kernel boot parameters help eliminate unwanted latency introduced by power management:
- cpuidle.off=1 — Disables CPU idle state management entirely, preventing the CPU from entering sleep states between tasks. This eliminates the wake-up latency that can cause jitter in cyclic real-time tasks.
- cpufreq.off=1 — Disables dynamic CPU frequency scaling. The CPU runs at a fixed (typically maximum) frequency, removing the latency spikes associated with frequency transitions.
These parameters are essential for achieving consistent cycle times in EtherCAT applications.
On a multi-core system, you can reserve one or more CPU cores exclusively for real-time tasks such as the EtherCAT job task, preventing the Linux scheduler from placing general-purpose processes on those cores.
The relevant kernel parameters are:
- isolcpus=7 — Removes CPU 7 from the general-purpose scheduler's load balancing. The kernel will not place regular processes on this CPU unless explicitly instructed to do so.
- irqaffinity=0-6 — Restricts hardware interrupt handling to CPUs 0–6. CPU 7 is left free of interrupt load, further improving its real-time responsiveness.
The result: CPU 7 runs only your EtherCAT task with minimal interference from the rest of the system. The Qualcomm Yocto Real-time Linux recipe is isolating the CPU 7. Qualcomm provides a guide Get started with performance tuning and optimization which gives additional steps for tuning the kernel. To add general kernel parameters, edit the machine configuration file:
<WORKSPACE_DIR>/meta-qcom/conf/machine/iq-9075-evk.conf
To configure CPU core isolation, edit your Kas configuration file:
<WORKSPACE_DIR>/meta-qcom/ci/base.yml
Step 4: Add the atemsys and Network Driver Patches
To ensure the link layer runs correctly on the board, changes to the device tree and SMMU are required. A patch is needed so that Yocto builds the updated sources. Place the following patch file in the kernel recipe's configs directory:
<WORKSPACE_DIR>/meta-qcom/recipes-kernel/linux/linux-qcom-6.18
Required patch:
0002-arm64-dts-qcom-add-atemsys-support-for-lemans-and-SM.patch
Register the patches in the .inc file under SRC_URI:
<WORKSPACE_DIR>/meta-qcom/recipes-kernel/linux/linux-qcom_6.18.bb
file://0002-arm64-dts-qcom-add-atemsys-support-for-lemans-and-SM.patch \
Step 5: Build the Real-Time Linux Image
The Yocto project is now ready to build a real-time Linux image with the required changes. Run the following command to start the build:
kas build meta-qcom/ci/iq-9075-evk.yml:meta-qcom/ci/linux-qcom-rt-6.18.yml:meta-qcom/ci/qcom-distro-kvm.yml --target qcom-multimedia-image
After the build has finished, the image is inside:
build/tmp/deploy/iq-9075-evk/qcom-multimedia-image-iq-9075-evk.rootfs-xxx.qcomflash/
Step 6: Prepare the Board for Flashing
Connect a USB-C cable from the host computer to the board's flashing port. This cable carries the firmware images that QDL transfers to the device during flashing.
Set Switch Pin 3 to the ON position to enable QDL (Qualcomm Download) mode, so the board boots into the firehose loader instead of its normal Linux image.
Power-cycle the board so it restarts and comes up in QDL mode with the new switch setting active.
Verify QDL mode on host:
lsusb
# Expected: Qualcomm QDL mode
Step 7: Download the QDL Flashing Tool
Download the Qualcomm Device Loader (QDL) for Linux x64:
wget https://softwarecenter.qualcomm.com/api/download/software/tools/Qualcomm_Device_Loader/Linux/Debian/latest.zip -O qdl.zip
unzip qdl.zip
chmod +x QDL_2.7_Linux_x64/qdl
export PATH="$PATH:$PWD/QDL/QDL_2.7_Linux_x64"
Verify that the qdl Software is registered with:
qdl –version
Afterwards, also update the udev rules with the following command:
echo 'SUBSYSTEMS=="usb", ATTRS{idVendor}=="05c6", ATTRS{idProduct}=="9008", MODE="0666", GROUP="plugdev"' | sudo tee /etc/udev/rules.d/51-qcom-usb.rules
sudo systemctl restart udev
Step 8: Flash the Provisioning UFS
Flash the UFS provisioning data first, this only needs to be done once per board:
mkdir <provision_download_path>
cd <provision_download_path>
wget https://artifacts.codelinaro.org/artifactory/codelinaro-le/Qualcomm_Linux/QCS9100/provision.zip
unzip provision.zip -d provision
qdl --storage ufs prog_firehose_ddr.elf provision_1_2.xml
Step 9:Flash the SAIL (NOR)
cd build/tmp/deploy/iq-9075-evk/qcom-multimedia-image-iq-9075-evk.rootfs-xxx.qcomflash/sail_nor
qdl --storage spinor prog_firehose_ddr.elf rawprogram0.xml patch0.xml
Step 10: Flash the CDT
mkdir <cdt_download_path>
cd <cdt_download_path>
wget https://artifacts.codelinaro.org/ui/native/codelinaro-le/Qualcomm_Linux/QCS9100/cdt/qcs9075-iq-9075-evk.zip
unzip <downloaded_zip_file>
<qdl_download_path>/qdl --storage ufs prog_firehose_ddr.elf rawprogram3.xml patch3.xml
Step 11: Flash the Linux Image
cd build/tmp/deploy/iq-9075-evk/qcom-multimedia-image-iq-9075-evk.rootfs-xxx.qcomflash/
sudo systemctl stop ModemManager
qdl --storage ufs prog_firehose_ddr.elf rawprogram*.xml patch*.xml
Flashing is complete when the terminal prints: partition 1 is now bootable.
Set Switch Pin 3 back to the OFF position so the board boots normally instead of re-entering download mode. Attach a micro-USB cable for serial console access, this step is optional but it is the easiest way to watch the board boot, so we recommend it.
Power-cycle the board, and the boot sequence should now appear on the serial console.
Step 12: Build and Load atemsys
To allow direct hardware access between the Ethernet driver and the Ethernet MAC, the atemsys kernel module must be built and loaded. Download atemsys from GitHub: github.com/acontis/atemsys.
Cross compile it:
cd atemsys
export PATH=<WORKSPACE_DIR>/build/tmp/work/iq_9075_evk-qcom-linux/linux-qcom-rt/6.18.30/recipe-sysroot-native/usr/bin/aarch64-qcom-linux/:$PATH
make -C . ARCH=arm64 CC=aarch64-qcom-linux-gcc LD=aarch64-qcom-linux-ld.bfd AR=aarch64-qcom-linux-ar KERNELDIR=<WORKSPACE_DIR>/build/tmp/work/iq_9075_evk-qcom-linux/linux-qcom-rt/6.18.30/build modules
The module is loaded using the following command:
modprobe of_mdio
sudo insmod atemsys.ko
This setup enables direct hardware access for the acontis real-time Ethernet driver and eliminates unnecessary software layers. As a result, both real-time behavior and CPU efficiency are significantly improved.
Step 13: Running EtherCAT on the IQ-9075
Once the entire setup is complete, the board is ready to run EtherCAT at maximum performance. To start the demo, first load atemsys as described in Step 12. After that the Demo can be started with:
./EcMasterDemo -dw3504 1 1 iq-9075 -v 3 -perf -a 7 -sp -t 0 -f "eni64-DC_busshift_1000us_1000bytes_pdo.xml"
The following output will be printed:
0000000000: EcMasterDemo V3.3.2.01 for Linux_aarch64 Copyright acontis technologies GmbH @ 2026
0000000000: Full command line: -dw3504 1 1 iq-9075 -v 3 -perf -a 7 -sp -t 0 -f "eni64-DC_busshift_1000us_1000bytes_pdo.xml"
0000000001: EC-Master V3.3.2.01 (Unrestricted) (Jul 14 2026 19:09:33) for Linux_aarch64 Copyright acontis technologies GmbH @ 2026
0000000001: emllDW3504(0x00000001): V3.3.2.01 (Unrestricted) (Jul 14 2026 19:09:55) for Linux_aarch64 Copyright acontis technologies GmbH @ 2026
0000001796: Bus scan successful - 64 slaves found
0000004709: Master state changed from <UNKNOWN> to <INIT>
0000005613: Master state changed from <INIT> to <PREOP>
0000008610: DCM in sync (cur/avg/max) [ns]: -5665/ -2195/ -19452
0000008610: DC slaves "in-sync" - Deviation: 0x0
0000008651: Master state changed from <PREOP> to <SAFEOP>
0000008671: Master state changed from <SAFEOP> to <OP>
Performance Measurement
Test Network Setup
The test setup consists of an EtherCAT network with a total of 64 SubDevices. These SubDevices are manufactured by Beckhoff and Omron. The SubDevices are connected either via 100Base-TX (RJ45 connector) or LVDS (E-Bus). In the standard configuration, a total of 151 bytes of input data are read and 46 bytes of output data are written cyclically. In addition, precise synchronization is achieved using Distributed Clocks (DC). The cyclic frame has a total length of 329 bytes, including the EtherCAT protocol. The cycle time was set to one millisecond.
Network Timing
The network timing must be implemented at the application level, since the EC-Master library does not contain any internal tasks. The advantages of this approach are:
- No synchronization issues between application and EC-Master library.
- Consistent process data without using any locks.
- Various network timings driven by the application possible.
- Easy to integrate.
For most applications, the standard network timing is sufficient. The cycle begins with the processing of all received frames. The frames are stored in the network driver’s DMA memory. First, the data is checked for correctness, and then the input data is updated. In the application section, the output data is then calculated, and the transmission of the cyclic frame is initiated. In the EC-Master administration, numerous state machines are executed to initiate further actions as needed.
Standard network timing is implemented in the EcMasterDemo sample application. All sample programs can also determine the processing time required for each EC-Master function (job) and report it periodically. For the network outlined above, the average EC-Master processing time is only 15.1 us.
PerfMsmt 'Cycle Time ' (min/avg/max) [usec]: 991.9/1000.0/1009.0
PerfMsmt 'Task Duration (JOB_Total + App)' (min/avg/max) [usec]: 13.3/ 18.0/ 40.1
PerfMsmt 'JOB_Total ' (min/avg/max) [usec]: 10.7/ 15.1/ 30.1
PerfMsmt 'JOB_ProcessAllRxFrames Duration' (min/avg/max) [usec]: 5.2/ 7.3/ 18.9
PerfMsmt 'JOB_SendAllCycFrames Duration ' (min/avg/max) [usec]: 3.2/ 4.4/ 11.0
PerfMsmt 'JOB_MasterTimer Duration ' (min/avg/max) [usec]: 1.7/ 2.4/ 10.0
PerfMsmt 'JOB_SendAcycFrames Duration ' (min/avg/max) [usec]: 0.1/ 1.1/ 10.1
PerfMsmt 'myAppWorkPd ' (min/avg/max) [usec]: 0.1/ 0.1/ 0.9
Measuring EC-Master CPU Load and Round-trip
The flexible EC-Master job concept also allows for alternative network timing. The cycle begins with the transmission of the cyclic frame containing the process data. After the frame has passed through the network, processing takes place, which is typically triggered by an interrupt. This is followed by the application phase and EC-Master administration. This timing can also be used without an interrupt. In that case, the application simply polls until the cyclic frame is received.
The alternative network timing is implemented in the EcMasterDemoSyncSm sample application. In addition to the computation time required for the individual EC-Master functions (jobs), the round-trip time is also determined. This time is the sum of the transmission and reception processing times, as well as the time it takes for the frame to travel through the network. For the network outlined above, the average round-trip time is approximately 104.5 us.
PerfMsmt 'Cycle Time ' (min/avg/max) [us]: 997.2/1000.0/1002.9
PerfMsmt 'Task Duration (JOB_Total + App)' (min/avg/max) [us]: 109.5/ 113.2/ 119.7
PerfMsmt 'JOB_Total ' (min/avg/max) [us]: 8.2/ 10.7/ 16.4
PerfMsmt 'JOB_ProcessAllRxFrames Duration' (min/avg/max) [us]: 0.6/ 0.7/ 5.2
PerfMsmt 'JOB_SendAllCycFrames Duration ' (min/avg/max) [us]: 2.7/ 4.1/ 5.2
PerfMsmt 'JOB_MasterTimer Duration ' (min/avg/max) [us]: 1.7/ 2.2/ 4.9
PerfMsmt 'JOB_SendAcycFrames Duration ' (min/avg/max) [us]: 0.1/ 1.0/ 5.5
PerfMsmt 'myAppWorkPd ' (min/avg/max) [us]: 0.1/ 0.1/ 0.3
PerfMsmt 'RoundTrip (TX+RX) ' (min/avg/max) [us]: 102.8/ 104.5/ 106.8
Measuring Network Load
In addition to CPU load, you should also consider the network load. EtherCAT’s bandwidth is 100 Mbit, which corresponds to 12500 KByte/s or 12500 bytes/ms. This refers to the theoretically possible data rate. However, it is important to note that, in addition to the Ethernet data frame (IEEE 802.1), other data (start delimiter, preamble, start of frame, end delimiter) and the interpacket gap reduce the bandwidth somewhat. In practice, a maximum of 12000 bytes/ms can be achieved.
Calculating the minimum network load caused by cyclic process data is relatively simple. With a cycle time of one millisecond, the frame size displayed in EC-Engineer can be divided by 12000. For the configuration above, this results in 325/12000 = approximately 2.7 % as minimum load.
However, the actual load is higher, since in addition to the cyclic frames, further acyclic communication between the EC-Master and the SubDevices is also required. Since acyclic communication can become very extensive, it must be strictly limited. The maximum limit can be set using the EC-Master API function emInitMaster().
The average and maximum network load can also be conveniently viewed in the EC-Engineer Diagnostic Tool. The displayed data is continuously calculated by the EC-Master.
Increasing Network Load by adding more cyclic process data
The test setup with 64 SubDevices has a relatively small process image, with 151 bytes of input data and 46 bytes of output data. The goal is now to investigate how the size of the process data affects both, the network utilization and CPU utilization. To do this, additional variables are defined in the process image using EC-Engineer. These are also transmitted cyclically over the EtherCAT network. If necessary, multiple cyclic frames are automatically generated for this purpose, which are then included in the ENI file.
The number, size, and content of cyclic frames are clearly displayed in EC-Engineer:
Series of Measurements
Starting with the default configuration, the size of the process data is increased incrementally up to a maximum of 8064 bytes. EC-Master determines the average network load, and the sample applications measure the execution times of the EC-Master jobs as well as the round-trip time. The network load is calculated based on a maximum value of 12000 bytes/ms. The network cycle time is 1 ms.
|
Process data size [Bytes] |
Num of cyclic frames |
Cyclic frame size |
Avg |
Avg |
Avg |
Avg. EC-Master |
Avg. EC-Master |
|
197 |
1 |
329 |
329 |
2.8 |
105 |
12.3 |
1.2 |
|
1024 |
1 |
1170 |
1170 |
9.8 |
209 |
14.0 |
1.4 |
|
2048 |
2 |
2214 |
2214 |
18.5 |
288 |
18.1 |
1.8 |
|
4096 |
3 |
4306 |
4306 |
35.8 |
470 |
25.2 |
2.5 |
|
8064 |
6 |
8370 |
8370 |
68.9 |
795 |
47.4 |
4.7 |
Conclusion
EC-Master can be easily installed on the Qualcomm Dragonwing IQ-9075 Evaluation Kit in just a few hours. Isolating a CPU for the MainDevice application enables even better real-time performance. This results in a more stable cycle time and, consequently, less jitter in the EtherCAT network.
Operating an EtherCAT network with 64 SubDevices—some also use DC—places an extremely light load on the very powerful Dragonwing IQ-9075 CPU. Even with a significant increase in cyclic process data, the load caused by the EC-Master remains below 5%. Therefore, when designing a system, the primary focus should be on network load. However, you will rarely reach any limits here either, since with a typical cycle time of one millisecond, approximately 12,000 bytes can be transferred between the controller (MainDevice) and the peripherals (SubDevices).