Some customer need to run standalone application in i.MX side. This article describe how to run standalone application in uboot and kernel, how to improve application running performance. It takes i.MX8MP as example, which is also suitable for other i.MX platform.

This post walks through end-to-end steps to enable and verify TX PAUSE frame (IEEE 802.3x flow control) generation on the i.MX95 / i.MX9x series using DPDK 25.11 with the enetc4 VF driver and a Spirent traffic generator. I also share an optional debug patch that lowers the PAUSE trigger threshold for quick lab reproduction and adds register readback prints to dmesg. --- Overview -------- On i.MX95 the ENETC4 Ethernet controller uses a PF/VF split: - The kernel PF driver (fsl_enetc4, Linux 6.18+) owns the MAC, PHY negotiation, and PAUSE configuration. - The DPDK VF driver (net/enetc, DPDK 25.11) owns the receive rings in the DPDK application. When the link partner negotiates PAUSE, the kernel PF configures the MAC and notifies the DPDK VF via a mailbox message. The VF then enables congestion signaling on its Rx rings. When incoming traffic fills those rings past the configured threshold, the hardware automatically emits PAUSE frames toward the sender. The trigger chain looks like this: High-rate ingress traffic fills VF Rx rings --> ICM fill level crosses PPAUONTR threshold --> MAC emits IEEE 802.3x PAUSE frame to link partner --> link partner pauses its transmitter --- Hardware Setup -------------- - i.MX95 EVK (or any i.MX9x board with ENETC4) - 10G SFP+ DAC cable or fiber between i.MX95 ENETC4 port and Spirent TestCenter port - Spirent TestCenter (or equivalent traffic generator with flow control capture) Software versions used in this guide: - Kernel: Linux 6.18+ with fsl_enetc4 PF driver - DPDK: 25.11 (net/enetc VF PMD) - ethtool: 6.x --- Step 1 — Enable PAUSE on the Kernel PF Interface ------------------------------------------------- The kernel PF interface (typically eth1 for ENETC4 port 1) must have TX PAUSE enabled before the link comes up so that phylink can negotiate it with the link partner. # Identify the kernel PF interface ip link show | grep -E "eth[0-9]" # Enable TX and RX PAUSE (autoneg lets the link partner also advertise PAUSE, it is off since we are using spirent) ethtool -A eth1 tx on rx on autoneg off # Bring the link up ip link set eth1 up # After link is up, verify PAUSE was negotiated ethtool -a eth1 Expected output: Pause parameters for eth1: Autonegotiate: off RX: on TX: on If TX shows "off" after link up, the link partner may not have advertised PAUSE capability. Try forcing it: ethtool -A eth1 tx on rx on autoneg off --- Step 2 — Verify ethtool Statistics Are Available ------------------------------------------------- Confirm that the ethtool stats interface is working before starting traffic: ethtool -S eth1 | grep -E "txpf|rxpf|pause" You should see counters like txpf_frames and rxpf_frames (both 0 at this point). If you see "no stats available", verify your kernel build includes the ethtool ops for enetc4. --- Step 3 — Bind the DPDK VF to igb_uio ----------------------------------- note bootargs: must have iommu_passthrough=1 # Load the VFIO driver modprobe igb_uio echo 1 > /sys/bus/pci/devices/0002\:00\:10.0/sriov_numvfs echo igb_uio > /sys/bus/pci/devices/0002\:00\:12.0/driver_override echo 0002:00:12.0 > /sys/bus/pci/drivers/fsl_enetc_vf/unbind echo 0002:00:12.0 > /sys/bus/pci/drivers/igb_uio/bind ip link set eth1 vf 0 trust on --- Step 4 — Allocate Hugepages ----------------------------- # 4 x 1 GB hugepages (recommended for 10G line-rate testing) echo 4 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages mount -t hugetlbfs none /dev/hugepages # Verify allocation grep HugePages /proc/meminfo # HugePages_Total: 4 # HugePages_Free: 4 --- Step 5 — Start testpmd ------------------------ For PAUSE testing the goal is to build up backpressure in the VF Rx rings so the ICM congestion threshold is crossed. Use rxonly mode with a small Rx descriptor count so the ring fills up quickly under load. testpmd \ -l 0-3 -n 4 \ -a 0002:00:12.0 \ -- \ --rxd=256 \ --txd=512 \ --nb-cores=2 \ --rxq=1 --txq=1 \ --forward-mode=rxonly \ --stats-period=5 Inside the testpmd prompt: testpmd> set fwd rxonly testpmd> start testpmd is now receiving and the DPDK VF Rx rings will fill under high-rate ingress traffic, generating the congestion signal that drives PAUSE frame emission. --- check stats via: ethtool --include-statistics -a eth1   Step 6 — Configure Spirent TestCenter --------------------------------------- Spirent port sending TO i.MX95 (ingress traffic): - Frame size: 64 bytes or smaller (smaller frames fill rings faster) - Rate: 100% line rate (10 Gbps) - Frame type: Ethernet II / IPv4 - Destination MAC: MAC address of the i.MX95 ENETC4 VF interface - Destination IP: IP address assigned to the i.MX95 interface Spirent port receiving FROM i.MX95 (PAUSE capture): - Port Properties → Flow Control → Enable IEEE 802.3x PAUSE - Enable Capture → Filter EtherType: 0x8808 - Results → Port Results → watch "Flow Control Frames Received" This counter increments every time a PAUSE frame arrives from i.MX95. - Optional: Results → Flow Analysis → check "Pause Duration (quanta)" Expected value: ~32767 (0x7FFF) Alternative capture without Spirent license: # On any PC with a tap on the wire tcpdump -i eth0 'ether proto 0x8808' -v # PAUSE frame: dst 01:80:c2:00:00:01, EtherType 0x8808, opcode 0x0001 --- Step 7 — Verify PAUSE Frames Are Being Sent --------------------------------------------- Start Spirent at 100% line rate, then on the i.MX95 host run: watch -n 1 'ethtool -S eth1 | grep -E "txpf|rxpf"' Expected output when PAUSE is active: txpf_frames: <increasing> <-- TX PAUSE frames sent by i.MX95 On Spirent, "Flow Control Frames Received" should be incrementing at the same time. --- Optional — Debug Patch for Faster Lab Reproduction ---------------------------------------------------- I am attaching a patch file to this post. This useful for bring-up and debug — this is not required for production use.   Adds dev_info() prints to enetc4_set_tx_pause() and enetc_set_congestion_mode() in the kernel driver. After link-up you will see in dmesg: fsl_enetc4 0000:00:00.0: enetc4_set_tx_pause: tx_pause=1 fsl_enetc4 0000:00:00.0: PPAUONTR = 0x00001000 fsl_enetc4 0000:00:00.0: PPAUOFFTR = 0x00000400 fsl_enetc4 0000:00:00.0: PM_CMD_CFG(0) = 0x000000c3 TX_EN=1 RX_EN=1 TXP=0 fsl_enetc4 0000:00:00.0: set_congestion_mode: enable=1 num_rx_rings=1 fsl_enetc4 0000:00:00.0: ring[0] readback rbmr=0x00000010 This confirms the kernel PF configured the MAC and set the RBMR congestion mode bit on the PF rings. The DPDK VF should receive the same setting via mailbox. also Lowers the PAUSE trigger threshold to PPAUONTR=4096 bytes so that PAUSE frames are generated at much lower traffic rates — useful for quick lab tests without needing a full 10G line-rate traffic generator. Also adds ICM register definitions (PRXBCR, PRXBCHWMR) so you can observe the ICM fill level via ethtool -S. After applying this patch, check ICM fill level during traffic: ethtool -S eth1 | grep -E "prxbcr|prxbchwmr" # prxbcr_bytes: <live fill level> # prxbchwmr_bytes: <peak fill since boot> When prxbchwmr_bytes >= 4096, the threshold has been crossed and PAUSE should fire.   --- Key Register Reference (ENETC4) --------------------------------- Note: ENETC4 register offsets start at 0x5000 for MAC/PM registers. This is different from ENETC v1 which uses 0x8000. Use ethtool -S for PM counters since PF BAR0 is IOMMU-protected on i.MX95. Register Offset Description PM_CMD_CFG(0) 0x5008 MAC config register (TXP = BIT 15) PM_TXPF(0) 0x5218 TX PAUSE frames sent (64-bit) PM_RXPF(0) 0x5118 RX PAUSE frames received (64-bit) PPAUONTR 0x108 ICM fill level threshold to START PAUSE PPAUOFFTR 0x10C ICM fill level threshold to STOP PAUSE PRXBCR 0x128 Current ICM RX fill level (live, read-only) PRXBCHWMR 0x12C ICM RX peak fill since boot (read-only) For VF Rx ring registers, VF BAR0 is accessible via devmem2: # Check RBMR of VF ring 0 — BIT 4 = CM (congestion mode) # Replace VF_BAR0 with your actual address (find via /sys/bus/pci/devices/.../resource0) devmem2 <VF_BAR0 + 0x8100> w # Expected when PAUSE is active: 0x00000010 --- Environment ----------- SoC: i.MX95, i.MX943 (i.MX9x series with ENETC4) Kernel: Linux 6.18+ (fsl_enetc4 PF driver) DPDK: 25.11 (net/enetc VF PMD) Tool: testpmd, ethtool 6.x, Spirent TestCenter Hope this helps. Happy to answer questions on the setup.

Android HW-assisted Address Sanitizer for Memory Overflow checking       Hardware-assisted AddressSanitizer (HWASan) is a memory error detection tool.     HWASan is based on the memory tagging approach, where a small random tag value is associated both with pointers and with ranges of memory addresses. For a memory access to be valid, the pointer and memory tags have to match.     HWASan uses a lot less RAM compared to ASan, which makes it suitable for whole system sanitization.   Here show an example: Use HWAsan for WiFi-HAL Memory Overflow issue hunting in Android-13.0.0_2.3.0_auto BSP.     Test environment:         SW:   Android-13.0.0_2.3.0_auto_car2, pre-built image.         HW:  88W9098 WiFi/BT EVK (PCIe) + i.MX8QXP EVK.       Run 88W9098 WiFi/BT on i.MX8QXP EVK, after ~2 hours, got memory leakage.       To locate root cause, enabled HWASan, re-build Android-13.0.0_2.3.0_auto BSP, run again, Got HWAddressSanitizer report: “heap-buffer-overflow”.          --Reason>  "Empty or null ScanResult list"  ->           --Then>      "Attempt to retrieve OsuProviders with invalid scanResult List" ->          --Result>    "heap-buffer-overflow"         HWASan help to locate root cause of Memory Overflow issue, on WiFi AP Scan code.         Attach file:            "Android_HW-assisted-Address-Sanitizer_for_memory-overflow_checking.pdf"

Steps to add support for WPA3 R3 in supplicant and hostapd

Dynamic voltage and frequency scaling (DVFS) is a power management technique that allows dynamically reducing power consumption of a CPU by dynamically scaling down supply voltage and CPU frequency. Because the internal DCDC of the i.MX RT1170 cannot cover the needed maximum current requirement at the junction temperature of 125 °C, the DVFS technique can be used to reduce current drain for compatibility with the internal DCDC. Lowering the processor frequency dynamically can help reduce the chip input current demand and ensure that the chip can continue to work at the junction temperature of 125 °C. The demo is attached. Only IAR and armgcc versions are enabled. The corresponding Application Note can be downloaded in the below link. https://www.nxp.com/docs/en/application-note/AN13267.pdf

Hello guys, this is digi international i.MX53 connect core dev board , i took three years weekends and spent lot of money on it, it's based on Qt and GStreamer , top of the line, have fun with the i.mx monsters, cheers daniele

This video is an overview of the Altia user interface development software chain. We start with graphics in Adobe Photoshopand end running Altia-generated source code on the Freescale i.MX 6. Altia also supports Vybrid, MPC5645S (Rainbow), MPC5606S (Spectrum), i.MX53 and more.

This video shows NovTech implementation of the video in (CSI Port) and video out (HDMI Port) of the i.MX6 with real time image processing.  While playback of 1080p movie (stored in an SD Card) the IPU unit of the i.MX6 takes the real time images arrives on the CSI input, and combine both video stream to one using the 'green screen' concept.

Adeneo Embedded is among the only SI to provide a Windows Embedded Compact 2013 solution on i.MX6 and to have developed a fast boot implementation of WEC2013 on the i.MX6 SDP. Fast boot is a common request from customers but a complicated one to implement. Adeneo has implemented fast boot features on several operating systems on the i.MX6. Contact: [email protected]

Hi guys, here you can see Adeneo Embedded's demo Andrea's Tablet working on Android OS on Freescale's i.MX6 Sabre SDP platform The video features an Adeneo Embedded launcher with Open GL, a video player application, picture viewer application and an audio player application. Want more info ? Meet us on our website: www.adeneo-embedded.com

This full featured BSP comes with all the core improvements that were made on the SABRE Lite BSP along with support for most of the features available for the SABRE board platform. Please contact Adeneo Embedded for access to the BSP as binary OS images or evaluation source code version at [email protected]

Adeneo Embedded adds CSI camera support to their i.MX6 Windows Embedded Compact 7 (WEC7) BSP. Camera interface on the i.MX6 is one of highly requested features among customers and in order to cater to this demand Adeneo Embedded developed a camera driver for CSI interface on WEC7.

Hey guys! Here's Adeneo Embedded's Cube OpenGL demo of the WEC7 Congatec board!   Enjoy !

Boundary Devices has a variety of i.MX6 solutions. The SABRE Lite and Nitrogen6X boards are great tools for hardware and software evaluation. The Nitrogen6X_SOM is a low cost, highly integrated System-on-Module that is ideal for customers looking for rapid product development while maintaining the flexibility of a custom design. The Nitrogen6X_SOM is shown here running the QNX operating system with QT and Storyboard Suite from Crank Software on a 7" 800x480 display.

As part of a close collaboration with Freescale, Adeneo Embedded is releasing Freescale i.MX6 BSPs for Windows Embedded Compact 7 on a set of hardware devices :   i.MX6 Nitrogen6X i.MX6 SabreLite i.MX6 Sabre SDB i.MX6 Sabre SDP Share, subscribe and don't forget to comment !

This video is showing BCM PPC10W-6MXQ ARM Panel PC equipped with i.MX6 Cortex A9 Quad Core ARM motherboard supporting secondary display via HDMI output

The Opal Development Kit include 4 protected digital inputs and outputs. This video demonstrates these, including a simple Windows Embedded Compact 7 demo application. The source for this is available in the downloads section at devicesolutions.net/opaldevkit. Get more information about the Opal CPU module and development kit at devicesolutions.net/opal.

This is a reference design showcasing a secondary vehicle dashboard with on-board diagnostics information along with all entertainment and features: Wifi, Bluetooth, GPS, GSM, microSD, USB 2.0 Host, Ethernet, SATA 3.0 and HDMI 1080p Contact [email protected] for more information

This video shows Altia-generated graphics code running on Nitrogen 6X platform by Boundary Devices. There are three different types of GUIs included in the video -- home security / automation, automotive instrument cluster, and smart appliance.