The Wandboard is a ultra low power complete computer with high performance multimedia capabilities based around the new upcoming Freescale i.MX6 Cortex-A9 processor and comes with a dazzling 1Ghz processor HDMI display interface and gigabit ethernet. The dualcore version of the Wandboard (The Wandboard DUAL) not only features 1GB of memory but also has onboard Wi-Fi and Bluetooth.     Wandboard Solo Wandboard Dual Processor Freescale i.MX6 Solo Freescale i.MX6 Duallite Cores Cortex-A9 Single core Cortex-A9 Dual core Memory 512 MB DDR3 1 GB DDR3 Audio • • Optical S/PDIF • • HDMI • • Camera interface • • micro SD cardslot 2 2 Serial port • • Expansion Header • • USB • • USB OTG • • SATA connector Not populated Not populated Gigabit LAN • • WIFI (802.11n) • Bluetooth • 69 USD 89 USD   www.wandboard.org Contact person : [email protected]

The DA9063 from Dialog Semiconductors is a powerful system PMIC for the next generation of single, dual and quad-core application processors based on the ARM Cortex™ A9 and A15 architecture. The PMIC follows a scalable approach of output currents and rails to supply the entire system and is capable of delivering a total of up to 12A from its six DC-DC converters. The DA9063 simultaneously powers the processor (the core at up to 5A), external memory, wireless communications (WLAN and Bluetooth), GPS and FM receivers, and data modems.  The DC-DC converters can be paralleled to provide 3A and 5A rails. Description: DA9063 is a high current system PMIC suitable for Single, Dual and Quad-core processors used in smartphones, tablets and other handhelds applications that require up to a 5A core processor supply. There are multiple operating modes, five consuming <20μA including a 1.5μA RTC mode with alarm & wake up. A system monitor watchdog is enabled in Active mode. DA9063 contains 6x DC-DC Buck converters designed to use small external 1µH inductors capable of supplying in total up to 12A continuous output (0.3-3.3V). 11x SmartMirror™ programmable LDO regulators rated up to 300mA. All support remote capacitor placement and operate from low 1.5/1.8V input supply; this allows the linear regulators to be cascaded with a suitable buck supply to improve overall system efficiency. A number of LDOs can be configured as current limited bypass-switches to support external peripherals such as external accessory or memory cards. The Buck converters do not require external Schottky diodes, they dynamically optimise their efficiency depending on the load current using an Automatic Sleep Mode (ASM). They incorporate pin and s/w controlled Dynamic Voltage Control (DVC) to support processor load adaptive adjustment of the supply voltage. Processor core leakage reduction can be achieved using external FET switches driven by the rail switch controllers for ultra-fast power domain switching. The DA9063 provides a startup sequencing engine that offers autonomous hardware and software controlled system start-up. Customisable power modes  can also be configured using “Power Commander,” Dialog’s powerful graphical user interface. The ON-key feature detects the button press time and offers configurable key-lock and application shut-down functions. Up to 16 free configurable GPIO pins are able to perform system functions including keypad supervision, application wake-up and timing controlled enable of external regulators/power switches or other ICs. A 10-bit ADC supports voltage and temperature supervision from general purpose inputs including automatic interrupt from comparators and resistor measurement.  Three RGB-LED driver pins are provided with PWM control. LDO8 may be configured as a 6-bit PWM controlled vibration motor driver with automatic battery voltage correction. Features Input supply voltage range up to 5.5v 6 DC-DC Buck Converters with Dynamic Voltage control 2.5A  Buck 2.5A  Buck 2.5A  Buck 1.5A  Buck 1.5A  Buck 1.5A  Buck 3MHz Switching Frequency Enables use of  1.0mm high inductors Integrated Power Switches 11 LDO Regulators with programmable Output 3 low noise LDOs 4 with Dynamic Voltage Control 5 with current limited Switch option Fast controller for 2 Rail Switches Ultra low power 1.5µA Real-Time Clock with alarm, oscillator circuitry with crystal frequency adjustment and controlled signal provision Power Manager with programmable Start-up of internal and external regulators/rail switches and configurable low power modes Support of multiple master applications via two independent Control Interfaces System Monitor including Watchdog Timer Up to 16 free configurable GPIO Pins enable system control from DA9063 while the application is in standby RGB-LED driver (PWM) with autonomous flashing PWM vibration motor driver 10-Bit ADC with 9 Channels and configurable alarm thresholds Regulator Supervision with automatic under and over voltage protection Coin Cell/Super-Capacitor Backup Charger      -40 to +85°C Temperature range 100VFBGA 8.0x8.0x1.0mm (0.8mm pitch) package Block Diagram DA9063: For more information: http://www.dialog-semiconductor.com/products/power-management/DA9063

This is a demo of the Nitrogen6X with BD_HDMI_MIPI daughter board. The Nitrogen6X is an i.MX6-based Single Board Computer (SBC) designed for both development and production use.  The BD_HDMI_MIPI daughter board utilizes the Toshiba TC358743XBG HDMI to MIPI CSI part to convert the HDMI signals to MIPI. The BD_HDMI_MIPI can be used with our Nitrogen6X, BD-SL-i.MX6, Nitrogen6_MAX boards as well as the Nitrogen6X_Carrier.  The daughter board can be used for evaluation as well as software development.  Please contact Boundary Devices for custom version. This demo shows the Nitrogen6X running Yocto based on 3.10.17 kernel and displaying the output of our Nitrogen6X_SOM on a 10.1" LG BD101LIC1 display.

The Wandboard is a ultra low power complete computer with high performance multimedia capabilities based around the new upcoming Freescale i.MX6 Cortex-A9 processor and comes with a dazzling 1Ghz processor HDMI display interface and gigabit ethernet. The dualcore version of the Wandboard (The Wandboard DUAL) not only features 1GB of memory but also has onboard Wi-Fi and Bluetooth. Wandboard Solo Wandboard Dual Processor Freescale i.MX6 Solo Freescale i.MX6 Duallite Cores Cortex-A9 Single core Cortex-A9 Dual core Memory 512 MB DDR3 1 GB DDR3 Audio • • Optical S/PDIF • • HDMI • • Camera interface • • micro SD cardslot 2 2 Serial port • • Expansion Header • • USB • • USB OTG • • SATA connector Not populated Not populated Gigabit LAN • • WIFI (802.11n) • Bluetooth • 69 USD 89 USD www.wandboard.org Contact person : [email protected]

iWave Systems Technologies Pvt. Ltd., a leading innovative Embedded Product Engineering Services company headquartered in Bangalore, launches “i.MX 6 SBC - Industry's latest Pico ITX Board around Freescale Semiconductor’s i.MX 6 Solo/Dual Lite processor which is iWave’s 4th i.MX 6 based design” on 26-02-2013 in Embedded World 2013 Nuremberg Germany. Measuring just 10cm x 7.2cm, iWave’s i.MX6 SBC is a highly integrated platform for increased performance in “Intelligent Industrial Control Systems, Industrial Human Machine Interface, Ultra Portable Devices, Home Energy Management Systems and Portable Medical Devices”. The i.MX 6 Solo/Dual Lite with ARM Cortex™-A9 single/dual cores running up to 1.0 GHz includes 2D and 3D graphics processors, 1080p video processing, and integrated power management. Each processor provides 32/64-bit DDR3/LVDDR3/LPDDR2-800 memory interface and a number of other interfaces for connecting peripherals, such as WLAN, Bluetooth™, GPS, hard drive, displays, and camera sensors. iWave’s new i.MX6 Solo/ Dual Lite based Pico ITX SBC integrates all standard interfaces into a single board with ultra-compact platform that can be utilized across multiple embedded PCs, systems and industrial designs. The i.MX6 SBC from iWave with its features like DDR3 RAM, Dual Display, Dual camera inputs, Gigabit Ethernet, Micro SD & SD slots, Dual USB 2.0 hosts, USB 2.0 OTG, Audio Out/In & serial interfaces, enables developers/users to quickly develop/implement their application needs around i.MX6 processor and optimize the “development effort and time to market” of their products. The i.MX6 SBC from iWave helps to reduce system cost, supports ultra-small form factor, wide operating temperature range from -20 0 C to +85 0 C and is backed with a minimum five years longevity support. Highlights of iWave’s i.MX6 SBC: ARM Cortex A9@ 1GHz Dual Lite/Solo core 10cm x 7.2cm Pico-ITX form factor Single Board Computer HD 1080p encode and decode,3D video playback in high definition Includes HDMI v1.4, MIPI and LVDS display ports, MIPI camera, Gigabit Ethernet, multiple USB 2.0 and PCI Express Comprehensive security features include cryptographic accelerators, high-assurance boot and tamper protection Technical &quick customization support with 5+ years, Long term support About iWave Systems: iWave has been an innovator in the development of “Highly integrated, high-performance, low-power and low-cost i.MX6/i.MX50/i.MX53/i.MX51/i.MX27 SOMs”. iWave helps its customers reduce their time-to-market and development effort with its products ranging from System-On-Module to complete systems. The i.MX6 Pico ITX SBC is brought out by iWave in a record time of just 5 weeks. Furthermore, iWave’s i.MX6/i.MX50/i.MX53/i.MX51/i.MX27 SOMs have been engineered to meet the industry demanding requirements like various Embedded Computing Applications in Industrial, Medical & Automotive verticals. iWave provides full product design engineering and manufacturing services around the i.MX SOMs to help customers quickly develop innovative products and solutions. For more details, please visit: http://www.iwavesystems.com/product/development-platform/i-mx6-pico-itx-sbc/i-mx6-pico-itx-sbc.html email: [email protected]

i.MX6 quad-core Cortex-A9 CPU, 1.2GHz Up to 4GB DDR3 and 32GB on-board SSD storage Integrated GPU and 1080p VPU, dual display support WiFi, BT 3.0, GbE, PCIe, SATA, 5x USB, 5x UART, 2x CAN Linux, Android ICS and Windows Embedded Compact 7 Miniature size - 75 x 65 x 6 mm CM-FX6-iMX6 is a tiny System-on-Module (SoM) / Computer-on-Module (CoM) designed to serve as a building block in embedded applications. CM-FX6 is based on the i.MX6 application processor featuring a highly scalable single/dual/quad core Cortex-A9 CPU at up to 1.2GHz coupled with powerful graphics and video processing units. The processor is supplemented with up-to 4GB DDR3 and 32GB of on-board SSD. In addition, CM-FX6 features a wide range of industry standard interfaces – Gigabit Ethernet, WiFi 802.11, Bluetooth, PCIe, SATA, USB, RS232 and CAN bus. CM-FX6 is provided with comprehensive documentation and full ready-to-run SW support for Linux, Android and Windows Embedded Compact 7 operating systems. CM-FX6-iMX6 Detailed Spec CM-FX6-iMX6 Block Diagram CM-FX6-iMX6 Development Kit CM-FX6-iMX6 Online Pricing

This FAQ is based on MYIR's i.MX6UL&6ULL products but also can be applied on products of other vendors. MYIR provides a series of i.MX 6UL/6ULL based products including SoM, SBC, development board and HMI display panel. MYD-Y6ULX-CHMI | 7-inch HMI Display Solution based on NXP i.MX 6UL/6ULL-Welcome to MYIR  MYS-6ULX | NXP i.MX 6UL / 6ULL SBC Board for IoT and Industry Applications-Welcome to MYIR  MYC-Y6ULX CPU Module | NXP i.MX 6UL, i.MX 6ULL SOM | ARM Cortex-A7 Processor-Welcome to MYIR   MYD-Y6ULX | NXP i.MX 6UL, i.MX 6ULL Development Board / SOM, ARM Cortex-A7 Processor-Welcome to MYIR  MYD-Y6ULX-HMI Development Board | NXP i.MX 6UL/6ULL Board for HMI Applications-Welcome to MYIR  MYIR is pleased to share the experience with more developers. 

These videos demonstrate an example application of a fully cloud-enabled and location-aware mass transport demo built on Freescale's i.MX5x platform with a HD passenger information display, PCAP touch enabled driver control display, and mobilde device (Android phone) integration. The demo showcases how Android provides the potential of significantly shortening the development cycle and accelerating your time-to-market. The demo is based on the Digi ConnectCore i.MX53 System-on-Module solution and was built using our Embedded Application Development Kit for Android (Gingerbread). Smart Tech for Passenger Buses by Digi International - Design West (ESC) 2012 - YouTube - The ARM video interview at Design West Android Bus Demo - YouTube  - The official Digi video overview Visit www.digiembedded.com for additional information, including a special i.MX53 Android Development Kit kit offer for $199. --- VDC Research Awards Digi Best of Show at Embedded World 2012 for Android Application Development Kit with iDigi Device

iWave released the official Yocto BSP for its i.MX6 Pico-ITX SBC board (iW-RainboW-G15S). The release is based on Linux 3.10.17 kernel and supports the following features: i.MX6 ARM Cortex A9 Quad, Dual, Dual Lite & Solo CPU 1GB DDR3 RAM (Quad, Dual, Dual Lite CPU version)/ 512MB DDR3 (Solo CPU version) Freescale PMIC SPI NOR Flash (default boot) eMMC Flash (default OS storage) Data UART uSD slot Standard SD slot USB 2.0 Host USB 2.0 device 10/100/1000 Ethernet Mini PCIex1 Port CAN Port LVDS display port 4 Wire Resistive touch PWM for backlight HDMI Port with Audio Hardware Codecs (Encode/Decode) 2D/3D Graphics CMOS CSI camera port MIPI CSI camera port AC97 Audio In/Out Console UART I2C Port DIP Switch, Status LEDs (GPIOs) This release supports single BSP, Binary image & MFG tool for all the four i.MX6 CPU version (Quad/Dual/Dual Lite/Solo) based SBC boards. Besides this Linux BSP support, Android Jelly Bean and WEC7 board support packages also supported for the i.MX6 Pico SBC boards by iWave systems. More details about the i.MX6 Pico SBC board hardware & software features can be found in the following i.MX6 Pico SBC product page:http://www.iwavesystems.com/product/single-board-computer/i-mx6-pico-itx-sbc/i-mx6-pico-itx-sbc.html

以下代码摘抄自：uboot 2009源码中board/Freescale/mx6q_sabreauto/flash_header.S #include <config.h> #include <asm/arch/mx6.h> #ifdef CONFIG_FLASH_HEADER #ifndef CONFIG_FLASH_HEADER_OFFSET # error "Must define the offset of flash header" #endif #define CPU_2_BE_32(l) \ ((((l) & 0x000000FF) << 24) | \ (((l) & 0x0000FF00) << 😎 | \ (((l) & 0x00FF0000) >> 😎 | \ (((l) & 0xFF000000) >> 24)) #define MXC_DCD_ITEM(i, addr, val) \ dcd_node_##i: \ .word CPU_2_BE_32(addr) ; \ .word CPU_2_BE_32(val) ; \ .section ".text.flasheader", "x" b _start .org CONFIG_FLASH_HEADER_OFFSET ivt_header: .word 0x402000D1 /* Tag=0xD1, Len=0x0020, Ver=0x40 */ app_code_jump_v: .word _start reserv1: .word 0x0 dcd_ptr: .word dcd_hdr boot_data_ptr: .word boot_data self_ptr: .word ivt_header app_code_csf: .word 0x0 reserv2: .word 0x0 boot_data: .word TEXT_BASE image_len: .word _end_of_copy - TEXT_BASE + CONFIG_FLASH_HEADER_OFFSET plugin: .word 0x0 dcd_hdr: .word 0x40D802D2 /* Tag=0xD2, Len=90*8 + 4 + 4, Ver=0x40 */ write_dcd_cmd: .word 0x04D402CC /* Tag=0xCC, Len=90*8 + 4, Param=0x04 */ #include <config.h> #include <asm/arch/mx6.h> #ifdef CONFIG_FLASH_HEADER #ifndef CONFIG_FLASH_HEADER_OFFSET # error "Must define the offset of flash header" #endif #define CPU_2_BE_32(l) \ ((((l) & 0x000000FF) << 24) | \ (((l) & 0x0000FF00) << 😎 | \ (((l) & 0x00FF0000) >> 😎 | \ (((l) & 0xFF000000) >> 24)) #define MXC_DCD_ITEM(i, addr, val) \ dcd_node_##i: \ .word CPU_2_BE_32(addr) ; \ .word CPU_2_BE_32(val) ; \ .section ".text.flasheader", "x" b _start .org CONFIG_FLASH_HEADER_OFFSET ivt_header: .word 0x402000D1 /* Tag=0xD1, Len=0x0020, Ver=0x40 */ app_code_jump_v: .word _start reserv1: .word 0x0 dcd_ptr: .word dcd_hdr boot_data_ptr: .word boot_data self_ptr: .word ivt_header app_code_csf: .word 0x0 reserv2: .word 0x0 boot_data: .word TEXT_BASE image_len: .word _end_of_copy - TEXT_BASE + CONFIG_FLASH_HEADER_OFFSET plugin: .word 0x0 dcd_hdr: .word 0x40D802D2 /* Tag=0xD2, Len=90*8 + 4 + 4, Ver=0x40 */ write_dcd_cmd: .word 0x04D402CC /* Tag=0xCC, Len=90*8 + 4, Param=0x04 */ 我的疑问是上面代码标红的部分的意义是什么？确切的说，IMX6Q既然规定了IVT在不同的boot devices中的偏移地址，比如我的应用场景是emmc，偏移地址是0x400(1K)，那么我的uboot镜像完全可以按照：IVT+uboot本体的格式来构建，这样一来当使用mfg工具烧写uboot镜像时就可以用以下的命令来执行： <CMD state="Updater" type="push" body="$ dd if=$FILE of=/dev/mmcblk0 bs=512 seek=2 ">write U-Boot to sd card</CMD> 而不是默认的命令（跳过uboot.bin前0x400的字节）： <CMD state="Updater" type="push" body="$ dd if=$FILE of=/dev/mmcblk0 bs=512 seek=2 skip=2">write U-Boot to sd card</CMD> 这样看，那么flash_header.S前面的0x400字节是不是多余的呢，还是有什么特别的用处，如果直接把这种uboot.bin烧写到emmc的0x400处（不跳过uboot.bin前0x400的字节，即b _start, .org CONFIG_FLASH_HEADER_OFFSET）,那是不是就直接会调整到_start函数开始执行，而不会进行DCD相关的配置？

Abstract: Browsers and mobile applications are using WebRTC for audio and video Real-Time Communications (RTC) via simple APIs. The WebRTC components have been optimized to best serve this purpose. WebRTC based web application provides rich, real-time multimedia features (think video chat) on the web, without any plugins, downloads or installs.It’s purpose is to help build a strong RTC platform that works across multiple web browsers, across multiple platforms. iWave has developed WebRTC based Peer to Peer audio and video communication on i.Mx6 Qseven development platform. iWave is using FireFox web browser and its in built webrtc  api’s for the communication. Architecture of WebRTC Detailed Description: iWave’s i.Mx6 Q7 platform has Quad core processor which can operate up to 1 GHz speed/core. i.MX6 CPU is NXP’s latest achievement in integrated multimedia application processors which is part of growing multimedia-focused products that offers high performance processing and are optimized for lowest power consumption. iWave’s i.Mx6 Q7 platform supports 1GB RAM in 64bit mode with eMMC memory of 4GB which can be used both as Mass storage and boot device. i.Mx6 Q7 also supports Ethernet port which is integrated i.Mx6 CPU and connected to the external Gigabit Ethernet PHY on SOM. iWave’s Application consist of two components – clients and server. Peer to Peer communication is done between two clients. Server is used for registering the clients and to keep the necessary set up for two clients to communicate. After setting up, the server is not having any role in the communication. Client Application: Client application is very simple web application using WebRTC to transport audio and video between two clients. The application will enable one client to "dial" the other client and make a video call (with audio).This application only works between two clients. It can be run using Firefox browser Server: The server brokers the initial connection between the two clients. Once a connection is established between the clients, their communication continues in a peer to peer mode: none of the video data is routed through the server. Working Process of WebRTC Peer to Peer communication Audio Codec: Audio codec supported by WebRTC is OPUS codec .OPUS codec Supports constant and variable bit rate encoding from 6 kbit/s to 510 kbit/s, frame sizes from 2.5 ms to 60 ms, and various sampling rates from 8 kHz (with 4 kHz bandwidth) to 48 kHz. The Acoustic Echo Canceler present in WebRTC removes the acoustic echo resulting from the voice being played out into the active microphone. Noise reduction component removes certain types of background noise usually associated with VoIP. Video Codec: Video codec supported by WebRTC is VP8. The VP8 video codec is well suited for RTC since it is designed for low latency. WebRTC has dynamic video jitter buffer for video which conceal the effects of jitter and packet loss on overall video quality. Image enhancement removes the video noise from image captured from camera. WebRTC call: A Screenshot of WebRTC peer to peer audio and video communication Benefits: WebRTC is In-built in Firefox browser. Improved video and audio streaming. VP8 video codec and OPUS audio codec provides much less data transmission without packet loss. WebRTC based Peer to Peer communication can be run from firefox  browser without any plugin or software installation. Audio and Video streaming can be done local networks. For more information please visit: WebRTC Peer to Peer Communication(Audio & Video) on i.MX6 board | iWave Systems or contact [email protected]

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.