Power Management

RM00293

NXP Semiconductors

i.MX Linux Reference Manual 26 June 2025

Manufacturer variants: 1

Selected specification: NXP Semiconductors

Documents: 1

Request Quote Download Datasheet Read online HTML view

Compare manufacturer specifications More from NXP Semiconductors Browse R parts

Manufacturer Specifications

Compare RM00293 variants.

Select a manufacturer to view its specifications, local PDF, and searchable HTML text.

1 manufacturers / 1 documents

Manufacturer	Series	Package	Documents	Available	Select specification
NXP Semiconductors	-	-	1	PDF HTML	Viewing

Online Datasheet

Read the NXP Semiconductors document online.

RM00293 NXP

Document overview

Manufacturer or author: Provided By www.digicamel.com(FREE DATASHEET DOWNLOAD SITE)
PDF pages: 301

Technical content

Datasheet sections

1 Introduction
1.1 Overview
1.1.1 Software Base
1.1.2 Features
1.2 Audience
1.2.1 Conventions
1.2.2 Definitions, Acronyms, and Abbreviations
1.3 References
2 System
2.1 Machine-Specific Layer (MSL)
2.1.1 Introduction
2.1.2 Interrupts (Operation)
2.1.2.1 Interrupt Hardware Operation
2.1.2.2 Interrupt Software Operation
2.1.2.3 Interrupt Features
2.1.2.4 Interrupt Source Code Structure
2.1.2.5 Interrupt Programming Interface
2.1.3 Timer
2.1.3.1 Timer Software Operation
2.1.3.2 Timer Features
2.1.3.3 Timer Source Code Structure
2.1.3.4 Timer Programming Interface
2.1.4 Memory Map
2.1.4.1 Memory Map Hardware Operation
2.1.4.2 Memory Map Features
2.1.5 IOMUX
2.1.5.1 IOMUX Hardware Operation
2.1.5.2 IOMUX Software Operation
2.1.5.3 IOMUX Features
2.1.5.4 IOMUX Source Code Structure
2.1.5.5 IOMUX Programming Interface
2.1.5.6 IOMUX Control Through GPIO Module
2.1.6 General Purpose Input/Output (GPIO)
2.1.6.1 GPIO Software Operation
2.1.6.2 GPIO Features
2.1.6.3 GPIO Module Source Code Structure
2.1.6.4 GPIO Programming Interface
2.1.7 Clock
2.1.7.1 Clock Software Operation
2.1.7.2 Clock Features
2.1.7.3 Source Code Structure
2.2 System Controller
2.2.1 Introduction
2.3 Boot Image
2.3.1 Introduction
2.4 Anatop Regulator Driver
2.4.1 Introduction
2.4.2 Hardware Operation
2.4.3 Software Operation
2.4.4 Driver Features
2.4.5 Driver Interface Details
2.4.6 Regulator APIs
2.4.7 Source Code Structure
2.4.8 Menu Configuration Options
2.5 Power Management
2.5.1 Low Level Power Management (PM)
2.5.1.1 Introduction
2.5.1.2 Software Operation
2.5.1.3 Source Code Structure
2.5.1.4 Menu Configuration Options
2.5.1.5 Programming Interface
2.5.2 PMIC PF Regulator
2.5.2.1 Introduction
2.5.2.2 Hardware Operation
2.5.2.3 Software Operation
2.5.2.4 Driver Features
2.5.2.5 Regulator APIs
2.5.2.6 Driver Architecture
2.5.2.7 Driver Interface Details
2.5.2.8 Source Code Structure
2.5.2.9 Menu Configuration Options
2.5.3 CPU Frequency Scaling (CPUFREQ)
2.5.3.1 Introduction
2.5.3.2 Software Operation
2.5.3.3 Source Code Structure
2.5.3.4 Menu Configuration Options
2.5.4 Dynamic Bus Frequency
2.5.4.1 Introduction
2.5.4.2 Operation
2.5.4.3 Software Operation
2.5.4.4 Source Code Structure
2.5.4.5 Menu Configuration Options
2.5.5 Battery Charging
2.5.5.1 Introduction
2.5.5.2 Software Operation
2.5.5.3 Source Code Structure
2.5.5.4 Menu Configuration Options
2.6 OProfile
2.6.1 Introduction
2.6.1.1 Overview
2.6.1.2 Features
2.6.1.3 Hardware Operation
2.6.1.4 Architecture-specific Components
2.6.1.6 Generic Kernel Driver
2.6.1.7 OProfile Daemon
2.6.1.8 Post Profiling Tools
2.6.1.9 Interrupt Requirements
2.6.2 Software Operation
2.6.2.1 Source Code Structure
2.6.2.2 Menu Configuration Options
2.6.2.3 Programming Interface
2.6.2.4 Example Software Configuration
2.7 Pulse-Width Modulator (PWM)
2.7.1 Introduction
2.7.2 Hardware Operation
2.7.3 Clocks
2.7.4 Software Operation
2.7.5 Driver Features
2.7.6 Source Code Structure
2.7.7 Menu Configuration Options

i.MX Linux Reference Manual Document information Information Content Abstract The i.MX family Linux Board Support Package (BSP) supports the Linux Operating System (OS) on the i.MX application processors.

1 Introduction

1.1 Overview

devices that use the Linux OS. open-source form as part of the base kernel. and the tests run on the BSP do not have sufficient coverage to replace traditional silicon verification test suites.

1.1.1 Software Base

(www.kernel.org). It is enhanced with the features provided by NXP.

1.1.2 Features

The table below describes the features supported by the BSP for specific platforms.

Interrupts GIC: The Linux kernel contains common Arm GIC interrupts handling code.
Timer (GPT): The General Purpose Timer (GPT) is set up to generate an interrupt as programmed to provide OS ticks. Linux OS facilitates timer use through various functions for timing delays, measurement, events, alarms, high-resolution timer features, and so on. Linux OS defines the MSL timer API required for the OS-tick timer and does not expose it beyond the kernel tick implementation.
GPIO/EDIO/IOMUX: The GPIO and EDIO components in the MSL provide an abstraction layer between the various drivers and the Machine-Specific Layer (MSL) All

SPBA: The Shared Peripheral Bus Arbiter (SPBA) provides an arbitration mechanism among multiple masters to allow access to the shared peripherals. The SPBA implementation under MSL defines the API to allow different masters to take or release ownership of a shared peripheral. General Drivers Thermal Driver The thermal driver will monitor the SoC's temperature in a certain frequency to protect the SoC. It defines three trip points: critical, hot, and active. Thermal Driver All OProfile OProfile is a system-wide profiler for Linux systems, capable of profiling all running code at low overhead. OProfile All Pulse Width Modulator The pulse-width modulator (PWM) has a 16-bit counter and is optimized to generate sound from stored sample audio images and generate tones. Pulse-Width Modulator (PWM) All Sensors Sensors cover accelerometer, ambient light and magnetometer sensors. Sensors All Watchdog The Watchdog Timer module protects against system failures by providing an escape from unexpected hang or infinite loop situations or programming errors. Watchdog All DMA Engine SDMA API The Smart Direct Memory Access (SDMA) API driver controls the SDMA hardware and provides an API to other drivers for transferring data between MCU, DSP and peripherals. Smart Direct Memory Access (SDMA) API All APBH-Bridge- DMA Both AHB-to-APBH and AHB-to-APBX DMA support configurable DMA descript chain. AHB-to-APBH Bridge with DMA (APBH-Bridge-DMA) All Power Management Drivers Low-level Power Management The low-level power management driver implements hardware-specific operations to meet power requirements and conserves power. Driver implementations are often different for different platforms. It is used by the DPM layer. Low-level Power Management (PM) Driver All Dynamic Bus Frequency The bus frequency driver dynamically manages the various system frequencies to improve power consumption. Dynamic Bus Frequency Driver i.MX 6 and i.MX 7

control of power supply regulators. (PTP) according to IEEE standard 1588. and channel interface functions. send and receive CAN messages. FlexCAN Driver i.MX 6Quad, i.MX 6Dual, i. MediaLB i.MX 6SoloX i.MX 6Quad i. required for IEEE 1588 and IEEE 802.1AS-2020. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

perform audio playback and recording functions. the asynchronous sample rate converter module. device for Tx and one capture device for Rx. the Atmel data Flash using the SPI interface. NAND GPMI Flash Driver i.MX 6Quad, i.MX 6Dual, i. the I2C bus to transfer data over the I2C bus. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

standard Linux driver interface to eSDHC. driver API to all UART ports.

1.2 Audience

1.2.1 Conventions

Courier monospaced type indicate commands, command parameters, code examples, and file and directory names.
Italic type indicates replaceable command or function parameters.
Bold type indicates function names.

1.2.2 Definitions, Acronyms, and Abbreviations

The following table defines the acronyms and abbreviations used in this document. Table 2. Definitions and Acronyms RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

stored in a lower address than the most significant byte. In big endian, the order of the bytes is reversed. Sensitive, but Unclassified (SBU) use. Table 2. Definitions and Acronyms...continued RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

for infrared wireless communication. and audio. It is also the name of the algorithms used to compress moving pictures and video.

MPEG-1 is optimized for CD-ROM and is the basis for MP3
MPEG-2 is defined for broadcast video in applications such as digital television set-top boxes and DVD
MPEG-3 was merged into MPEG-2
MPEG-4 is a standard for low-bandwidth video telephony and multimedia on the World-Wide Web MQSPI Multiple Queue Serial Peripheral Interface: used to perform serial programming operations necessary to configure radio subsystems and selected peripherals MSHC Memory Stick Host Controller NAND Flash Flash ROM technology: NAND Flash architecture is one of two flash technologies (the other being NOR) used in memory cards such as the Compact Flash cards. NAND is best suited to flash devices requiring high-capacity data storage. NAND flash devices offer storage space up to 512-Mbyte and offers faster erase, write, and read capabilities over NOR architecture NOR Flash See NAND Flash PCMCIA Personal Computer Memory Card International Association-a multicompany organization that has developed a standard for small, credit card-sized devices, called PC Cards. There are three types of PCMCIA cards that have the same rectangular size (85.6 by 54 millimeters), but different widths physical address The address by which the memory in the system is physically accessed

(a lock) on the frequency of an input, or reference, signal. numbers as part of the security module. USBOTG USB On The Go: an extension of the USB 2.0 specification for connecting peripheral devices to each other. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

1.3 References

SoCs might be buildable in the current release but not validated if they are at the previous validated level.

i.MX 6 Family: 6QuadPlus, 6Quad, 6DualLite, 6SoloX, 6SLL, 6UltraLite, 6ULL, 6ULZ
i.MX 7 Family: 7Dual, 7ULP
i.MX 8 Family: 8QuadMax, 8QuadPlus, 8ULP
i.MX 8M Family: 8M Plus, 8M Quad, 8M Mini, 8M Nano
i.MX 8X Family: 8QuadXPlus, 8DXL, 8DXL OrangeBox, 8DualX This release includes the following references and additional information.
i.MX Linux Release Notes (RN00210) - Provides the release information.
i.MX Linux User's Guide (UG10163) - Provides the information on installing U-Boot and Linux OS and using i.MX-specific features.
i.MX Yocto Project User's Guide (UG10164) - Describes the board support package for NXP development systems using Yocto Project to set up host, install tool chain, and build source code to create images.
i.MX Porting Guide (UG10165) - Provides the instructions on porting the BSP to a new board.
i.MX Machine Learning User's Guide (UG10166) - Provides the machine learning information.
i.MX DSP User's Guide (UG10167) - Provides the information on the DSP for i.MX 8.
i.MX 8M Plus Camera and Display Guide (UG10168) - Provides the information on the ISP Independent Sensor Interface API for the i.MX 8M Plus.
i.MX Digital Cockpit Hardware Partitioning Enablement for i.MX 8QuadMax (UG10169) - Provides the i.MX Digital Cockpit hardware solution for i.MX 8QuadMax.
i.MX Graphics User's Guide (UG10159) - Describes the graphics features.
Harpoon User's Guide (UG10170) - Presents the Harpoon release for i.MX 8M device family.
i.MX Linux Reference Manual (RM00293) - Provides the information on Linux drivers for i.MX.
i.MX VPU Application Programming Interface Linux Reference Manual (RM00294) - Provides the reference information on the VPU API on i.MX 6 VPU.
EdgeLock Enclave Hardware Security Module API (RM00284) - This document is a software reference description of the API provided by the i.MX 8ULP, i.MX 93, and i.MX 95 Hardware Security Module (HSM) solutions for the EdgeLock Enclave (ELE) Platform. The quick start guides contain basic information on the board and setting it up. They are on the NXP website.
SABRE Platform Quick Start Guide (IMX6QSDPQSG)
i.MX 6UltraLite EVK Quick Start Guide (IMX6ULTRALITEQSG)
i.MX 6ULL EVK Quick Start Guide (IMX6ULLQSG)
i.MX 7Dual SABRE-SD Quick Start Guide (SABRESDBIMX7DUALQSG)
i.MX 8M Quad Evaluation Kit Quick Start Guide (IMX8MQUADEVKQSG)
i.MX 8M Mini Evaluation Kit Quick Start Guide (8MMINIEVKQSG)
i.MX 8M Nano Evaluation Kit Quick Start Guide (8MNANOEVKQSG)
i.MX 8QuadXPlus Multisensory Enablement Kit Quick Start Guide (IMX8QUADXPLUSQSG)
i.MX 8QuadMax Multisensory Enablement Kit Quick Start Guide (IMX8QUADMAXQSG)
i.MX 8M Plus Evaluation Kit Quick Start Guide (IMX8MPLUSQSG) RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

i.MX 8ULP EVK Quick Start Guide (IMX8ULPQSG)
i.MX 8ULP EVK9 Quick Start Guide (IMX8ULPEVK9QSG)
i.MX 93 EVK Quick Start Guide (IMX93EVKQSG)
i.MX 93 9x9 QSB Quick Start Guide (93QSBQSG) Documentation is available online at nxp.com.
i.MX 6 information is at nxp.com/iMX6series.
i.MX SABRE information is at nxp.com/imxSABRE.
i.MX 6UltraLite information is at nxp.com/iMX6UL.
i.MX 6ULL information is at nxp.com/iMX6ULL.
i.MX 7Dual information is at nxp.com/iMX7D.
i.MX 7ULP information is at nxp.com/imx7ulp.
i.MX 8 information is at nxp.com/imx8.
i.MX 6ULZ information is at nxp.com/imx6ulz.
i.MX 91 information is at nxp.com/imx91.
i.MX 93 information is at nxp.com/imx93.
i.MX 95 information is at nxp.com/imx95.
i.MX 943 information is at nxp.com/imx94.

2 System

2.1 Machine-Specific Layer (MSL)

2.1.1 Introduction

The Machine-Specific Layer (MSL) provides the Linux kernel with the following machine-dependent components.

Interrupts including GPIO and EDIO (only on certain platforms)
Timer
Memory map
General Purpose Input/Output (GPIO) including IOMUX on certain platforms
Clock
Shared Peripheral Bus Arbiter (SPBA)
Smart Direct Memory Access (SDMA)

2.1.2 Interrupts (Operation)

This section describes the hardware and software operation of interrupts on the device.

2.1.2.1 Interrupt Hardware Operation

The Interrupt Controller controls and prioritizes all internal and external interrupt sources. By default, all interrupts have the same priority. Each interrupt source can be enabled or disabled by configuring the interrupt controller’s registers. There are three types of interrupts in GIC: PPI, SGI, and SPI.

PPI is private peripheral interrupts of each CPU. It can only be handled by each CPU.
SGI is software generated interrupts. It can be triggered by software operation, and it also can only be handled by each CPU. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

SPI is shared peripheral interrupts, which are normally external interrupt sources from SoC platform. It can be handled by all CPUs.

2.1.2.2 Interrupt Software Operation

running on the Arm architecture chooses the high-vector address model. defined as VBAR_ELn + offset. The offset depends on which exception level the interrupt exception is taken. The file Documentation/arm/Interrupts has a description of the Arm interrupt architecture. structure and exports one initialization function, which is called during system startup. Table 3. Interrupt Files

2.1.2.3 Interrupt Features

Interrupt Controller interrupt disable and enable
Functions required by the Linux interrupt architecture as defined in the standard Arm interrupt source code

2.1.2.4 Interrupt Source Code Structure

The interrupt module is located in drivers/irqchip. The table below lists the source files for interrupts. drivers/irqchip/irq-imx-gpcv2.c Interrupt functions with CONFIG_IMX_GPCV2 configuration. Table 4. Interrupt Files RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

2.1.2.5 Interrupt Programming Interface

the drivers through the request_irq() function to register device-specific interrupt handlers.

2.1.3 Timer

generates periodic interrupts) and the dynamic timers (to schedule events).

Updates the system uptime
Updates the time of day
Reschedules a new process if the current process has exhausted its time slice
Runs any dynamic timers that have expired
Updates resource usage and processor time statistics The following tables describes the different timers used. Timer Description General Purpose Timer (GPT) GPT is configured to generate a periodic interrupt at a certain interval (every 10 ms). Used by i.MX 6 to go into WFI mode. Used by i.MX 6 and i.MX 7. Enhanced Periodic Interrupt Timer (EPIT) Available on i.MX 6 and i.MX 7. Arm Arch Timer i.MX 8 and i.MX 9 usage instead of GPT System Counter Timer i.MX 8M, i.MX 8X, and i.MX 9 usage instead of GPT

Table 5. Timers

2.1.3.1 Timer Software Operation

clock source, interrupt mode and interrupt interval. time elapsed as the last timer interrupt.

2.1.3.2 Timer Features

Functions required by Linux OS to provide the system timer and dynamic timers. on CONFIG_HZ_XXX. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

2.1.3.3 Timer Source Code Structure

Table 6. Timer Files

2.1.3.4 Timer Programming Interface

The timer module utilizes four hardware timers, to implement clock source and clock event objects. with timer events for the purposes mentioned in the beginning of this chapter.

2.1.4 Memory Map

2.1.4.1 Memory Map Hardware Operation

The MMU, as part of the Arm core, provides the virtual to physical address mapping defined by the page table. For more information, see the Arm Technical Reference Manual (TRM) from Arm Limited.

2.1.4.2 Memory Map Features

map for all the I/O modules.

2.1.5 IOMUX

pin or as a GPIO pin. A functional pin can be subdivided into either a primary function or alternate functions.

TXD1-internal UART1 Transmit Data. This is the primary function of this pin.
UART2 DTR-alternate mode 3
LCDC_CLS-alternate mode 4 RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

GPIO4[22]-alternate mode 5
SLCDC_DATA[8]-alternate mode 6 If the hardware modes are chosen at the system integration level, this pin is dedicated only to that purpose and cannot be changed by software. Otherwise, the IOMUX module needs to be configured to serve a particular purpose that is dictated by the system (board) design. If the pin is connected to an external UART transceiver and therefore to be used as the UART data transmit signal, it should be configured as the primary function. If the pin is connected to an external Ethernet controller for interrupting the Arm core, then it should be configured as GPIO input pin with interrupt enabled. Again, be aware that the software does not have control over what function a pin should have. The software only configures pin usage according to the system design.

2.1.5.1 IOMUX Hardware Operation

SW_MUX_CTL-Selects the primary or alternate function of a pin. Also enables loopback mode when applicable.
SW_SELECT_INPUT-Controls pin input path. This register is only required when multiple pads drive the same internal port.
SW_PAD_CTL-Control pad slew rate, driver strength, pull-up/down resistance, and so on.

2.1.5.2 IOMUX Software Operation

The IOMUX software implementation provides an API to set up pin functionality and pad features.

2.1.5.3 IOMUX Features

2.1.5.4 IOMUX Source Code Structure

Table below lists the source files for the IOMUX module. The files are in the drivers/princtrl/freescale folder. Table 7. IOMUX Files RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

drivers/pinctrl/freescale/pinctrl-imx-scmi.c i.MX 943 and i.MX 95 pinctrl driver. Table 7. IOMUX Files...continued

2.1.5.5 IOMUX Programming Interface

See pinctrl binding documents Documentation/devicetree/bindings/pinctrl/fsl,imx*.

2.1.5.6 IOMUX Control Through GPIO Module

GPIO pin, the pin is controlled by the user through software with further configuration through the GPIO module. DATA register, but input based A_OUT or B_OUT). usage according to the system design.

2.1.5.6.1 GPIO Hardware Operation

The GPIO In Use Registers control a multiplexer in the GPIO module. control of IOMUX block of the GPIO. The GPIO module has a PULLUP control register (PUEN) for each GPIO port to control every pin of that port.

2.1.5.6.2 GPIO Software Operation (general)

The GPIO software implementation provides an API to setup pin functionality and pad features. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

2.1.5.6.3 GPIO Implementation

The GPIO implementation programs the GPIO module to configure the pins that are supported by the hardware.

2.1.6 General Purpose Input/Output (GPIO)

The GPIO module provides general-purpose pins that can be configured as either inputs or outputs. When configured as an output, the pin state (high or low) can be controlled by writing to an internal register. When configured as an input, the pin input state can be read from an internal register.

2.1.6.1 GPIO Software Operation

The general purpose input/output (GPIO) module provides an API to configure the i.MX processor external pins and a central place to control the GPIO interrupts. The GPIO utility functions should be called to configure a pin instead of directly accessing the GPIO registers. The GPIO interrupt implementation contains functions, such as the interrupt service routine (ISR) registration/ un-registration and ISR dispatching once an interrupt occurs. All driver-specific GPIO setup functions should be made during device initialization in the MSL layer to provide better portability and maintainability. This GPIO interrupt is initialized automatically during the system startup. If a pin is configured as GPIO by the IOMUX, the state of the pin should also be set since it is not initialized by a dedicated hardware module. Setting the pad pull-up, pull-down, slew rate and so on, with the pad control function may be required as well.

2.1.6.1.1 API for GPIO

API for GPIO lists the features supported by the GPIO implementation. The GPIO implementation supports the following features:

An API for registering an interrupt service routine to a GPIO interrupt. This is made possible as the number of interrupts defined by NR_IRQS is expanded to accommodate all the possible GPIO pins that are capable of generating interrupts.
Functions to request and free an IOMUX pin. If a pin is used as GPIO, another set of request/free function calls are provided. The user should check the return value of the request calls to see if the pin has already been reserved before modifying the pin state. The free function calls should be made when the pin is not needed. See the API document for more details.
Aligned parameter passing for both IOMUX and GPIO function calls. In this implementation the same enumeration for iomux_pins is used for both IOMUX and GPIO calls and the user does not have to figure out in which bit position a pin is located in the GPIO module.
Minimal changes required for the public drivers such as Ethernet and UART drivers as no special GPIO function call is needed for registering an interrupt.

2.1.6.2 GPIO Features

This GPIO implementation supports the following features:

Implements the functions for accessing the GPIO hardware modules
Provides a way to control GPIO signal direction and GPIO interrupts

2.1.6.3 GPIO Module Source Code Structure

All of the GPIO module source code is in the GPIO framework, in the following files, located in the directories indicated at the beginning of this chapter: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 8. GPIO Files

2.1.6.4 GPIO Programming Interface 2

2.1.7 Clock

The Linux clock framework relies on the underlying hardware to provide support for clock tree management. The following table describes different clock hardware used.

2.1.7.1 Clock Software Operation

2.1.7.2 Clock Features

Prepare/Unprepare a clock.
Enable/Disable a clock.
Get/Set the clock rate.
Get/Set the clock parent.

2.1.7.3 Source Code Structure

NXP Semiconductors RM00293 i.MX Linux Reference Manual File Description drivers/clk/imx/clk-imx7d.c i.MX 7Dual clock driver drivers/clk/imx/clk-imx7ulp.c i.MX 7ULP clock driver drivers/clk/imx/clk-imx8qm.c i.MX 8QuadMax clock driver drivers/clk/imx/clk-imx8qxp.c i.MX 8QuadXPlus clock driver drivers/clk/imx/clk-imx8mq.c i.MX 8M Quad clock driver drivers/clk/imx/clk-imx8mm.c i.MX 8M Mini clock driver drivers/clk/imx/clk-imx8mn.c i.MX 8M Nano clock driver drivers/clk/imx/clk-imx8ulp.c i.MX 8ULP clock driver drivers/clk/imx/clk-imx93.c i.MX 93 clock driver drivers/clk/clk-scmi.c i.MX 95 and i.MX 943 2.1.7.4 Different clock types provide different clock operation callbacks. Device drivers call standard clock APIs to clock framework and eventually call into platform clock driver, and the corresponding clock node’s operation callback is executed.

2.2 System Controller

2.2.1 Introduction

The System Controller is provided on i.MX 8 and i.MX 8X families and provides an abstraction to many underlying features of the hardware and runs on a Cortex-M processor which executes SC firmware (SCFW). This overview describes the features of the SCFW and APIs exposed to other software components. The System Controller features include:

System Intiialization and Boot - The SC firmware runs on the SCU immediately after the SCU Read-only- memory (ROM) finishes loading code/data images from the first container. It is responsible for initializing many aspects of the system. This includes additional power and clock configuration and resource isolation hardware configuration. By default, the SC firmware configures the primary boot core to own most of the resources and launches the boot core. Additional configuration can be done by boot code.
System Controller Communication - Other software components in the system communicate to the SC via an exposed API library. This library is implemented to make Remote Procedure Calls (RPC) via an underlying Inter-Processor Communication (IPC) mechanism. The IPC is facilitated by a hardware-based mailbox system. Software components (Linux, QNX, FreeRTOS, MCUXpresso SDK) delivered for i.MX8 already include ports of the client API. Other 3rd parties will need to first port the API to their environment before the API can be used. The porting kit release includes archives of the client API for existing SW. These can be used as reference for porting the client API. All that needs to be implemented is the IPC layer which will utilize messaging units (MU) to communicate with the SCFW.
Power Management - All aspects of power management including power control, bias control, clock control, reset control, and wake-up event monitoring are grouped within the SC Power Management service. – Power Control - The SC firmware is responsible for centralized management of power controls and external power management devices. It manages the power state and voltage of power domains as well as bias control. It also resets peripherals as required due to power-state transitions. This is immplemented with the API by communicating power state needs for individual resources. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual – Clock Control - The SC firmware is responsible for centralized management of clock controls. This includes clock sources such as oscillators and PLLs as well as clock dividers, muxes, and gates. This is implemented with the API by communicating clocking needs for individual resources. – Reset Control - The SC firmware is responsible for reset control. This includes booting/rebooting a partition, obtaining reset reasons, and starting/stopping of CPUs. Before any hardware in the SoC can be used, SW must first power up the resource and enable any clocks that it requires, otherwise access will generate a bus error.

Resource Management - SC firmware is responsible for managing ownership and access permissions to system resources. The features of the resource management service supported by SC firmware include: – Management of system resources such as SoC peripherals, memory regions, and pads – Allows resources to be partitioned into different ownership groupings that are associated with different execution environments including multiple operating systems executing on different cores, TrustZone, and hypervisor – Associates ownership with requests from messaging units within a resource partition – Allows memory to be divided into memory regions that are then managed like other resources – Allows owners to configure access permissions to resources – Configures hardware components to provide hardware enforced isolation – Configures hardware components to directly control secure/nonsecure attribute driven on bus fabric – Provides ownership and access permission information to other system controller functions (e.g., pad ownership information to the pad muxing functions) – Protection of resources is provided in two ways. First, the SCFW itself checks resource access rights when API calls are made that affect a specific resource. Depending on the API call, this may require that the caller be the owner, parent of the owner, or an ancestor of the owner. Second, any hardware available to enforce access controls is configured based on the RM state. This includes the configuration of IP such as XRDC2, XRDC, or RDC, as well as management pages of IP like CAAM.
Pad Configuration - Pad configuration is managed by SC firmware. The pad configuration features supported by the SC firmware include: – Configuring the mux, input/output connection, and low-power isolation mode. – Configuring the technology-specific pad setting such as drive strength, pullup/pulldown, etc. – Configuring compensation for pad groups with dual voltage capability.
Timers - Many timer oriented services are grouped within the SC Timer service. This includes watchdogs, RTC, and system counter. – Watchdog - The SC firmware provides "virtual" watchdogs for all execution environments. Features include update of the watchdog timeout, start/stop of the watchdog, refresh of the watchdog, return of the watchdog status such as maximum watchdog timeout that can be set, watchdog timeout interval, and watchdog timeout interval remaining. – Real-Time-Clock - The SC firmware is responsible for providing access to the RTC. Features include setting the time, getting the time, and setting alarms. – System Counter - The SC firmware is responsible for providing access to the SYSCTR. Features incude setting an absolute alarm or a relative, periodic alarm. Reading is done directly via local hardware interfaces available for each CPU.
Interrupts - The System Controller needs a method to inform users about asynchronous notification events. This is done via the Interrupt service. The service provides APIs to enable/disable interrupts to the user and to read the status of pending interrupts. Reading the status automatically clears any pending state.
Miscellaneous - On previous i.MX 6 and 7 devices, miscellaneous features were controlled using IOMUX GPR registers with signals connected to configurable hardware. This functionality is being replaced with DSC GPR signals. SC firmware is responsible for programming the GPR signals to configure these subsystem features. The SC firmware also responsible for monitoring various temperature, voltage, and clock sensors. – Controls - The SC firmware provides access to miscellaneous controls. Features include software request to set (write) miscellaneous controls and software request to get (read) miscellaneous controls. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual – Security - The SC firmware provides access to several security functions including image loading and authentication. – DMA - The SC firmware provides access to DMA channel grouping and priority functions. – Temp - The SC firmware provides access to temperature sensors. With this abstraction some hardware described in the SoC Reference Manual that is used by the SCFW is not directly accessible to other cores. This includes the following

All resources in the SCU subsystem (SCU M4, SCU LPUART, SCU LPI2C, etc.).
All resource accessed via MSI links from the SCU subsystem (inc. pads, DSC, XRDC2, eCSR)
OCRAM controller, CAAM MP, eDMA MP and LPCG
DB STC and LPCG, IMG GPR
GIC/IRQSTR LPCG, IRQSTR.SCU and IRQSTR.CTI
Any other resources reserved by the port of the SCFW to the board The System Controll firmware known as SCFW provided with each release works with associated i.MX reference boards and a porting kit is provided that provides a subset of source that can be customized for new boards. This porting kit is avaiable on nxp.com and includes a porting guide.

2.3 Boot Image

2.3.1 Introduction

series, the boot image is more complex and includes U-Boot as well various firmware required for a successful boot. This chapter describes the additional components for an i.MX 8 series boot loader. For i.MX 7ULP, the boot partition requires the Arm Cortex M-4 SDK flash since the Arm Cortex M-4 boots the U- Boot boot loader, but other i.MX 6 and i.MX 7 with Arm Cortex M-4 cores do not require this for succesful boot. The i.MX 8 and i.MX 9 bootloaders are created using imx-mkimage tool available on imx-mkimage on github.com/nxp-imx/ and all i.MX 8 Series require Arm trusted firmware available on imx-atf on github.com/nxp- imx/. For details on how to use the imx-mkimage tool to create an i.MX boot partition, refer to the i.MX Linux User's Guide. This tool for execution requires the following components. For i.MX 8M Quad, i.MX 8M Mini, and i.MX 8M Nano, the following firmware is needed:

Synopys DDR frimware
Signed HDMI firmware - that integrates with the DCSS driver. HDMI firmware is for i.MX 8M Quad only
Arm Trusted firmware - bl31-*soc* For i.MX 8QuadMax, the following firmware is needed:
System Controller Firmware (SCFW)
Arm Trusted firmware - bl31-*soc*
SECO firmware container image (ahab-container.img) for B0 For i.MX 8QuadXPlus, i.MX 8DualX, and i.M 8DualXLite, the following firmware is needed:
System Controller Firmware (SCFW)
Arm Trusted firmware - bl31-*soc*
SECO firmware container image (ahab-container.img) For i.MX 93 and i.MX 91, the following firmware is needed:
Synopsys DDR firmware RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

Arm Trusted firmware - bl31-*soc*
ELE firmware container For i.MX 95 and i.MX 943, the following firmware is needed:
Synopsys DDR firmware
Arm Trusted firmware
OEI firmware
ELE firmware container
System manager firmware All the i.MX series require Arm trusted firmware and U-boot. Also i.MX SoC supporting OP-TEE (all i.MX 6, 7 and 8M families) enabled with OP-TEE boot need the tee.bin created from building optee_ox. Type 2 hypervisors such as Jailhouse and kvm are not part of the boot loader. Type 1 hypervisors are part of the loader however xen and only support i.MX 95 19x19 EVK.

2.4 Anatop Regulator Driver

2.4.1 Introduction

The Anatop regulator driver provides the low-level control of the power supply regulators, and selection of voltage levels. This device driver makes use of the regulator core driver to access the Anatop hardware control registers and is only supported on i.MX 6 and i.MX 7.

2.4.2 Hardware Operation

The Power Management Unit on the die is built to simplify the external power interface and allow the die to be configured in a power appropriate manner. The power system consists of the input power sources and their characteristics, the integrated power transforming and controlling elements, and the final load interconnection and requirements. Utilizing 7 LDO regulators, the number of external supplies is greatly reduced. If the backup coin and USB inputs are neglected, then the number of external supplies is reduced to two. Missing from this external supply total are the necessary external supplies to power the desired memory interface. This will change depending on the type of external memory selected. Other supplies might also be necessary to supply the voltage to the different I/O power segments if their I/O voltage needs to be different than what is provided above. Some internal regulator can be bypassed, so that the external PMIC can supply power directly to decrease power number, such as VDD_SOC and VDD_ARM.

2.4.3 Software Operation

The Anatop regulator client driver performs operations by reconfiguring the Anatop hardware control registers. This is done by calling regulator core APIs with the required register settings.

2.4.4 Driver Features

The Anatop regulator driver is based on regulator core driver. A list of services provided for regulator control can be found here.

Switch ON/OFF all voltage regulators.
Set the value for all voltage regulators.
Get the current value for all voltage regulators. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

2.4.5 Driver Interface Details

Seven LDO regulators
All of the regulator functions are handled by setting the appropriate Anatop hardware register values. This is done by calling the regulator core APIs to access the Anatop hardware registers.

2.4.6 Regulator APIs

voltage regulators (where voltage output is controllable) and current sinks (where current output is controllable).

regulator_get used to lookup and obtain a reference to a regulator: – struct regulator *regulator_get(struct device *dev, const char *id);
regulator_put used to free the regulator source: – void regulator_put(struct regulator *regulator, struct device *dev);
regulator_enable used to enable regulator output: – int regulator_enable(struct regulator *regulator);
regulator_disable used to disable regulator output: – int regulator_disable(struct regulator *regulator);
regulator_is_enabled is the regulator output enabled: – int regulator_is_enabled(struct regulator *regulator);
regulator_set_voltage used to set regulator output voltage: – int regulator_set_voltage(struct regulator *regulator, int uV);
regulator_get_voltage used to get regulator output voltage: – int regulator_get_voltage(struct regulator *regulator); For more APIs and details in the regulator core source code inside the Linux kernel see: drivers/regulator/ core.c.

2.4.7 Source Code Structure

The Anatop regulators are registered in each SoC-specific dts file in arch/arm/boot/dts.

2.4.8 Menu Configuration Options

Device Drivers > Voltage and Current regulator support > Anatop Regulator Support.
System Type > Freescale i.MX on-chip ANATOP LDO regulators.

2.5 Power Management

2.5.1 Low Level Power Management (PM)

2.5.1.1 Introduction

Table 10. Power Management Modes not used in Linux OS, because no typical software power mode can be used to support them. Table below lists the detailed clock information for the different low power modes. Table 11. Low Power Modes RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

2.5.1.2 Software Operation

The i.MX 6 and i.MX 7 power management driver maps the low-power modes to the kernel power management states as listed below:

Standby-maps to STOP mode, which offers significant power saving, as all blocks in the system are put into a low-power state, except for Arm core, which is still powered on, and memory is placed in self-refresh mode to retain its contents.
Mem (suspend to RAM) maps to DORMANT mode, which offers most significant power saving, as all blocks in the system are put into a low-power state, except for memory, which is placed in self-refresh mode to retain its contents. If there is "fsl,enable-lpsr" defined in DTB ocrams node, mem is mapped to LPSR mode instead of DORMANT, and all the blocks in the system are put into power off state, except the LPSR, SNVS, and DRAM power domains.
System idle maps to WAIT mode.
If Arm Cortex-M4 processor is alive together with Arm Cortex-A processor before the kernel enters standby/ mem mode, and if Arm Cortex-M4 processor is not in its low-power idle mode, Arm Cortex-A processor triggers the SoC to enter WAIT mode instead of STOP mode to make sure that Arm Cortex-M4 processor can continue running. The i.MX 6 and i.MX 7 power management driver performs the following steps to enter and exit low power mode: 1. Allow the Cortex-A platform to issue a deep sleep mode request. 2. If STOP or DORMANT mode:
Program i.MX 6 CCM_CLPCR or i.MX 7 GPC_LPCR_A7_BSC and GPC_SLPCR registers to set low- power control register.
If DORMANT mode, request switching off CPU power when pdn_req is asserted.
Request switching off embedded memory peripheral power when pdn_req is asserted.
Program GPC mask register to unmask wakeup interrupts. 3. Call cpu_do_idle to execute WFI pending instructions for wait mode. 4. Execute imx6_suspend or imx7_suspend in IRAM. 5. In DORMANT mode, save Arm context, and change the drive strength of DDR PADs as "low" to minimize the power leakage in DDR PADs. Execute WFI pending instructions for stop mode. 6. Generate a wakeup interrupt and exit low-power mode. In DORMANT mode, restore Arm core and DDR drive strength. In DORMANT mode, the i.MX 6 and i.MX 7 can assert the PMIC_STBY_REQ pin to the PMIC and request a voltage change. The U-Boot or Machine-Specific Layer (MSL) usually sets the standby voltage in STOP mode according to i.MX 6 and i.MX 7 data sheet. On i.MX 8M Family the power management driver uses the following modes.
RUN Mode: In this mode, the Quad-A53 CPU core is active and running. Some portions can be shut off for power saving.
IDLE Mode: This mode is defined as a mode which CPU can automatically enter when there is no thread running and all high-speed devices are not active. The CPU can be put into power gated state but with L2 data retained, DRAM and bus clock are reduced, and most of the internal logics are clock gated but still remain powered.
SUSPEND Mode: This mode is defined as the most power saving mode where all the clocks are off and all the unnecessary power supplies are off. Cortex-A53 CPU platform is fully power gated. All the internal digital logics and analog circuits that can be powered down will be off.
SNVS Mode: This mode is also called RTC mode. In this mode, only the power for the SNVS domain remains on to keep RTC and SNVS logic alive. On i.MX 8 and i.MX 8X: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Low-power mode management is not controlled by a dedicated hardware block.
All low-power modes are implemented in system controller firware (SCFW) using software method.
SCFW powers off clusters/CPUs when the system is suspended. On i.MX 8ULP:
uPower is responsible for controlling the power mode transition, Power switch, and mem ON/OFF.
For detailed power mode description, see the Applications Processor Reference Manual associated with SoC. On i.MX 9 family:
RUN Mode: In this mode, the Cortex-A55 CPU core is active and running. Some portions can be shut off for power saving.
IDLE Mode: This mode is defined as a mode which CPU can automatically enter when there is no thread running and all high-speed devices are not active. The CPU can be put into power gated state but with L3 memory retained. DDR can be put into auto clock gating, power switchable MIX can be power off and most of the internal logics are clock gated but still remain powered.
SUSPEND Mode: This mode is defined as the most power saving mode where all the clocks are off and all the unnecessary power supplies are off. Cortex-A55 CPU platform is power gated. All the internal digital logics and analog circuits that can be powered down will be off.
BBSM Mode: This mode is also called RTC mode. In this mode, only the power for the BBSM domain remains on to keep RTC and BBSM logic alive.

2.5.1.3 Source Code Structure

Table below shows Power Management driver source files.

arch/arm/mach-imx/pm-imx6.c
arch/arm/mach-imx/suspend-imx6.S
arch/arm/mach-imx/cpuidle-imx6q.c Supports i.MX 6QuadPlus/Quad/Dual/Solo power management operation
arch/arm/mach-imx/pm-imx6.c
arch/arm/mach-imx/suspend-imx6.S
arch/arm/mach-imx/cpuidle-imx6sll.c
arch/arm/mach-imx/imx6sll_low_power_idle.S Supports i.MX 6SLL power management operation
arch/arm/mach-imx/pm-imx6.c
arch/arm/mach-imx/suspend-imx6.S
arch/arm/mach-imx/cpuidle-imx6ul.c
arch/arm/mach-imx/imx6ul_low_power_idle.S Supports i.MX 6UltraLite power management operation
arch/arm/mach-imx/pm-imx6.c
arch/arm/mach-imx/suspend-imx6.S
arch/arm/mach-imx/cpuidle-imx6ul.c
arch/arm/mach-imx/imx6ull_low_power_idle.S Supports i.MX 6ULL power management operation
arch/arm/mach-imx/pm-imx6.c
arch/arm/mach-imx/suspend-imx6.S
arch/arm/mach-imx/cpuidle-imx6sx.c
arch/arm/mach-imx/imx6sx_low_power_idle.S Supports i.MX 6SoloX power management operation
arch/arm/mach-imx/pm-imx7.c
arch/arm/mach-imx/suspend-imx7.S
arch/arm/mach-imx/cpuidle-imx7d.c Supports i.MX 7Dual power management operation

arch/arm/mach-imx/imx7d_low_power_idle.S
arch/arm/mach-imx/pm-imx7ulp.c
arch/arm/mach-imx/suspend-imx7ulp.S
arch/arm/mach-imx/cpuidle-imx7.c Supports i.MX 7ULP power management operation
drivers/soc/imx/imx8m_pm_domains.c Supports i.MX 8M power domains
driver/soc/imx/imx8ulp_lpm.c Supports i.MX 8ULP system level voltage and frequency scaling
driver/soc/imx/imx93_lpm.c Supports i.MX 93 and i.MX 91 system level voltage and frequency scaling, and DDR auto clock gating control Arm Trusted firmware exists in imx-atf on github.com/nxp- imx/. Supports i.MX 8, 8X, 8M, 8ULP, i.MX 93, i.MX 91, i.MX 95, and i.MX 943 to use Arm trusted firmware for power management operation

Table 12. Power Management Driver Files...continued

2.5.1.4 Menu Configuration Options

2.5.1.5 Programming Interface

2.5.2 PMIC PF Regulator

2.5.2.1 Introduction

2.5.2.2 Hardware Operation

PMIC PF regulator provides reference and supply voltages for the application processor and peripheral devices. Four buck (step down) converters (up to 6 independent output) and one boost (step up) converter are included. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual memory. Dynamic voltage scaling is provided to allow controlled supply rail adjustments for the processor cores and/or other circuitry. Linear regulators are directly supplied from the battery or from the switchers and include supplies for I/O and peripherals, audio, camera, BT, WLAN, and so on. Naming conventions are suggestive of typical or possible use case applications, but the switchers and regulators may be utilized for other system power requirements within the guidelines of specified capabilities. The only power on event of PF100 is PWRON is high, and the only power off event of PF100 is PWRON is low. PMIC_ON_REQ pin of i.MX 6, which is controlled by SNVS block of i.MX 6, will connect with PWRON pin of PF100 to control PF100 on/off, so that system can power off.

2.5.2.3 Software Operation

PMIC PF regulator client driver performs operations by reconfiguring the PMIC hardware control registers. Some of the PMIC power management operations depend on the system design and configuration. For example, if the system is powered by a power source other than the PMIC, then turning off or adjusting the PMIC voltage regulators has no effect. Conversely, if the system is powered by the PMIC, then any changes that use the power management driver and the regulator client driver can affect the operation or stability of the entire system.

2.5.2.4 Driver Features

PMIC PF regulator driver is based on regulator core driver. It provides the following services for regulator control of the PMIC component:

Switch ON/OFF all voltage regulators.
Set the value for all voltage regulators.
Get the current value for all voltage regulators.

2.5.2.5 Regulator APIs

The regulator power architecture is designed to provide a generic interface to voltage and current regulators within the Linux kernel. It is intended to provide voltage and current control to client or consumer drivers and to provide status information to user space applications through a sysfs interface. The intention is to allow systems to dynamically control regulator output to save power and prolong battery life. This applies to both voltage regulators (where voltage output is controllable) and current sinks (where current output is controllable). For more details, see opensource.wolfsonmicro.com/node/15 Under this framework, most power operations can be done by the following unified API calls:

regulator_get is an unified API call to lookup and obtain a reference to a regulator: struct regulator *regulator_get(struct device *dev, const char *id);
regulator_put is an unified API call to free the regulator source: void regulator_put(struct regulator *regulator, struct device *dev);
regulator_enable is an unified API call to enable regulator output: int regulator_enable(struct regulator *regulator);
regulator_disable is an unified API call to disable regulator output: int regulator_disable(struct regulator *regulator); RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

regulator_is_enabled is the regulator output enabled: int regulator_is_enabled(struct regulator *regulator);
regulator_set_voltage is an unified API call to set regulator output voltage: int regulator_set_voltage(struct regulator *regulator, int uV);
regulator_get_voltage is an unified API call to get regulator output voltage: int regulator_get_voltage(struct regulator *regulator); You can find more APIs and details in the regulator core source code inside the Linux kernel at: drivers/regulator/core.c

2.5.2.6 Driver Architecture

The following figure shows the basic architecture of the PMIC PF regulator driver. Figure 1. PMIC PF Regulator Driver Architecture

2.5.2.7 Driver Interface Details

Access to PFUZE100 regulator is provided through the API of the regulator core driver.

4 buck switch regulators on normal mode (up to 6 independent rails): SW1AB, SW1C, SW2, SW3A, SW3B, and SW4.
Buck switch can be programmed to a state of standby with specific register (PFUZE100_SWxSTANDBY) in advance.
6 Linear Regulators: VGEN1, VGEN2, VGEN3, VGEN4, VGEN5, and VGEN6.
1 LDO/Switch supply for VSNVS support on i.MX processors.
1 Low current, high accuracy, voltage reference for DDR Memory reference voltage.
1 Boost regulator with USB OTG support.
Most power rails from PFUZE100 have been programmed properly according to the hardware design. Therefore, you can't find the kernel using PFUZE100 regulators. PFUZE100 regulator driver has implemented these regulators so that customers can use it freely if default PFUZE100 value can't meet their hardware design.

2.5.2.8 Source Code Structure

drivers/regulator/pfuze100-regulator.c Implementation of the PFUZE100 regulator client driver. drivers/regulator/pf1550.c Implementation of the PFUZE1550 regulator client driver. drivers/regulator/pf1550-regulator-rpmsg.c Implementation of the PFUZE150 regulator RPMSG code. Table 13. PFUZE Driver Files device trees dtsi files in i.MX 6 and i.MX7 in arch/arm/boot/dts and for i.MX 8M in arch/arm64/boot/dts.

2.5.2.9 Menu Configuration Options

Device Drivers > Voltage and Current regulator support > Freescale PFUZE100/200/3000 regulator driver.

2.5.3 CPU Frequency Scaling (CPUFREQ)

2.5.3.1 Introduction

because the CPU uses less power as the clock speed is reduced.

2.5.3.2 Software Operation

The CPUFREQ device driver is designed to change the CPU frequency and voltage on the fly. userspace CPU frequency governor can be used. By default, the conservative CPU frequency governor is used. See the API document for more information on the functions implemented in the driver. The frequency 792000 is in KHz, which is 792 MHz. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

2.5.3.3 Source Code Structure

Table below shows the source files and headers available in the following directory. Table 14. CPUFREQ Driver Files

2.5.3.4 Menu Configuration Options

CONFIG_CPU_FREQ; In menuconfig, this option is located under: – CPU Power Management > CPU Frequency scaling
The following options can be selected: – CPU Frequency scaling – CPU frequency translation statistics – Default CPU frequency governor (conservative)(interactive) – Performance governor – Powersave governor – Userspace governor for userspace frequency scaling – Interactive CPU frequency policy governor – Conservative CPU frequency governor – Schedutil CPU frequency governor – CPU frequency driver for i.MX CPUs

2.5.4 Dynamic Bus Frequency

2.5.4.1 Introduction

between 24 MHz and its maximum frequency.

2.5.4.2 Operation

peripheral activity and CPU loading.

2.5.4.3 Software Operation

frequency to highest frequency setpoint based on the peripherals that are currently requesting. treats Arm Cortex-M4 processor as one of its high-speed devices.

High Frequency Setpoint mode is used when most peripherals that need higher frequency for good performance are active. For example, video playback and graphics processing.
Audio Playback setpoints mode is used in audio playback mode.
Low Frequency setpoint mode is used when the system is idle waiting for user input (display is off). For i.MX 8M, this mode is used when no peripheral device request high mode or audio mode. The following table explains the software setpoints for each Family. SoC Setpoints i.MX 6 • High Frequency Setpoint: AHB is at 132 MHz, AXI is at 264 MHz.
Audio Playback setpoints: On i.MX 6, AHB is at 25 MHz, AXI is at 50 MHz, and DDR is at 50 MHz for DDR3 and 100 MHz for LPDDR2..
Low Frequency setpoint: AHB is at 24 MHz, AXI is at 24 MHz, and DDR is at 24 MHz. i.MX 7Dual • High Frequency Setpoint: AHB is at 135 MHz, AXI is at 332 MHz, and DDR is at the maximum frequency.
Audio Playback setpoints: AHB is at 24 MHz, AXI is at 24 MHz, and DDR is at 100 MHz.
Low Frequency setpoint: AHB is at 24 MHz, AXI is at 24 MHz, and DDR is at 24 MHz. i.MX 8M • High bus frequency mode: The DDRC core clock is set to 800 MHz. The DDRC APB clock is set to 200 MHz. The NOC clock is set to 800 MHz. The main AXI cock is set to 333 MHz, and the AHB clock is set to 133 MHz.

Audio bus frequency mode: The DDRC core clock is set to 25 MHz, The DDRC APB clock is set to 20 MHz, the NOC clock is set to 100 MHz. Tthe main AXI clock is set to 25 MHz, and the AHB clock is set to 20 MHz. The DDR PLL is powered down for power saving.
Low bus frequency mode: The DDRC core clock is set to 25 MHz. The DDRC APB clock is set to 20 MHz. The NOC clock is set to 100 MHz. The main AXI clock is set to 25 MHz. The AHB clock is set to 20 MHz. The DDR PLL is powered down for power saving.

Table 15. BusFrequency Set Points...continued

2.5.4.4 Source Code Structure

The following table lists the source files and headers. Table 16. BusFrequency Driver Files arm64/boot/dts for i.MX 8M and i.MX 9. On i.MX 8ULP, there is a simple interface to change the APD-side voltage and frequency scaling. Note: Before enabling this mode, the FEC and the display must be off, and the system is idle. HW architecture. All these features can be used case by case to maximum dynamic power saving. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

OD/ND/LD mode Unlike the previous i.MX 8M family, there is no separate VDD_ARM power rail for Cortex-A platform. A single VDD_SOC power rail is used for the whole digital logic in the SoC. The VDD_SOC can be nominal (ND) or overdrive (OD) or a “low drive” (LD) voltage. Fine-grained DVFS is theoretically supported by the hardware (but not customer-exposed). In general, it is expected that many customers will choose to statically operate at either nominal or low drive voltage (for lowest power) or overdrive voltage (for highest performance). However, dynamic voltage scaling is supported on a system-level “mode change” (such as if the entire chip goes into a low power standby mode while the display is updating a clock, but the system is otherwise idle and waiting for input).
DDR frequency scaling On i.MX 93 and i.MX 91, the DDR subsystem has multiple frequency setpoints support. DDR can change the frequency dynamically to reduce the power consumption. There are two methods to change the DDR frequency dynamically: The HWFFC and SWFFC. The HWFFC switching flow is faster than the SWFFC. It has a very short latency. Normally, it can be used for DDR frequency scaling on the fly with display on. But it can only be used when switching the frequency to half of the highest frequency. SWFFC may need to be used to switch the target frequency to a setpoint that is lower than half of the highest frequency.
DDRC auto clock gating When the bus is idle after the number of cycles configured in the ‘ssi_idle_strap’ field in the DDR BLK_CTRL module, the DDRC will do auto clock gating to save power. This feature can be used to balance DDR subsystem performance and power significantly. The number of idle cycles before clock gating can be adjusted dynamically based on the actual use case to fine tuning the power saving.
Software implementation On i.MX 93 and i.MX 91, the whole digital logic is supplied by a single VDD_SOC power rails. It is not that good to support conventional cortex-A platform DVFS through Linux cpufreq framework. Too many clock constraints need to be considered when changing the VDD_SOC voltage. To simplify the case, the voltage scaling is supported by a system wide mode switching (OD/ND/LD) to force all the clocks and voltage constrains. This is supported by using an NXP specific linux kernel side module: drivers/soc/imx/ imx93_lpm.c. This driver will export two user space control nodes through /sys interface. The following figure shows the design details. User space /sys/devices/platform /imx93-lpm/mode Kernel space driver/soc/imx/imx93_lpm.c DDRMIX(DDRC, DDR_BLK_CTRL), CCM DDR HWFFC/SWFFC aaa-053529 ATF HW /sys/devices/platform /imx93-lpm/auto_clk_gating

and then be changed to the target frequency with HWFFC or SWFFC. See the following figure. Figure 3. Mode control node between the two modes freely even with the default DTB. High resolution display like 1080P 60fsp can not be supported when doing system wide mode switching. mode, the display should be off or with a lower resolution. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual echo 512 > /sys/devices/platform/imx93-lpm/auto_clk_gating // enable ddrc auto clock gating Limitation: When the auto clock gating is enabled, high resolution display like 1080P 60fps may flicker at lower DDR frequency.

2.5.4.5 Menu Configuration Options

There are no menu configuration options for this driver. The Bus Frequency drivers are included and enabled by default for the SoC that support bus frequency drivers.

2.5.5 Battery Charging

2.5.5.1 Introduction

Battery Charging is supported by the max8903-charger for the i.MX 6 SABRE SD boards.

2.5.5.2 Software Operation

None.

2.5.5.3 Source Code Structure

The battery charging source is based in drivers/power/supply/sabresd_battery.c

2.5.5.4 Menu Configuration Options

In menu configuration enable the following module: Device Drivers > Power supply class support > Sabresd Board Battery DC-DC Charger for USB and Adapter Power.

2.6 OProfile

2.6.1 Introduction

OProfile is a system-wide profiler capable of profiling all running code at low overhead. OProfile consists of a kernel driver, a daemon for collecting sample data, and several post-profiling tools for turning data into information.

2.6.1.1 Overview

OProfile leverages the hardware performance counters of the CPU to enable profiling of a wide variety of interesting statistics, which can also be used for basic time-spent profiling. All code is profiled: hardware and software interrupt handlers, kernel modules, the kernel, shared libraries, and applications. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

2.6.1.2 Features

OProfile has the following features.

Unobtrusive-No special recompilations or wrapper libraries are necessary. Even debug symbols (-g option to gcc) are not necessary unless users want to produce annotated source. No kernel patch is needed; just insert the module.
System-wide profiling-All code running on the system is profiled, enabling analysis of system performance.
Performance counter support-Enables collection of various low-level data and association for particular sections of code.
Call-graph support-OProfile can provide gprof-style call-graph profiling data.
Low overhead-OProfile has a typical overhead of 1-8% depending on the sampling frequency and workload.
Post-profile analysis-Profile data can be produced on the function-level or instruction-level detail. Source trees, annotated with profile information, can be created. A hit list of applications and functions that utilize the most CPU time across the whole system can be produced.
System support-Works with any i.MX supported kernel.

2.6.1.3 Hardware Operation

OProfile is a statistical continuous profiler. Profiles are generated by regularly sampling the current registers on each CPU (from an interrupt handler, the saved PC value at the time of interrupt is stored), and converting that runtime PC value into something meaningful to the programmer. OProfile achieves this by taking the stream of sampled PC values, along with the detail of which task was running at the time of the interrupt, and converting the values into a file offset against a particular binary file. Each PC value is thus converted into a tuple (group or set) of binary-image offset. The userspace tools can use this data to reconstruct where the code came from, including the particular assembly instructions, symbol, and source line (through the binary debug information if present). Regularly sampling the PC value like this approximates what actually was executed and how often and, more often than not, this statistical approximation is good enough to reflect reality. In common operation, the time between each sample interrupt is regulated by a fixed number of clock cycles. This implies that the results reflect where the CPU is spending the most time. This is a very useful information source for performance analysis. The Arm CPU provides hardware performance counters capable of measuring these events at the hardware level. Typically, these counters increment once per each event and generate an interrupt on reaching some pre- defined number of events. OProfile can use these interrupts to generate samples and the profile results are a statistical approximation of which code caused how many instances of the given event.

2.6.1.4 Architecture-specific Components

OProfile supports the hardware performance counters available on a particular architecture. Code for managing the details of setting up and managing these counters can be located in the kernel source tree in the relevant arch/arm/oprofile directory. The architecture-specific implementation operates through filling in the oprofile_operations structure at initialization. This provides a set of operations, such as setup(), start(), stop(), and so on, that manage the hardware-specific details the performance counter registers. The other important facility available to the architecture code is oprofile_add_sample(). This is where a particular sample taken at interrupt time is fed into the generic OProfile driver code. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

filesystem also contains a stats directory with a number of useful counters for various OProfile events.

2.6.1.6 Generic Kernel Driver

userspace daemon through the /dev/oprofile/buffer character device.

2.6.1.7 OProfile Daemon

(assuming the original binary files are still available and unchanged).

2.6.1.8 Post Profiling Tools

relevant binary file, and produce user readable information.

2.6.1.9 Interrupt Requirements

are not needed. The rate at which interrupts are generated depends on the event.

2.6.2 Software Operation

2.6.2.1 Source Code Structure

Oprofile platform-specific source files are available in arch/arm/oprofile. Table 17. OProfile Source Files RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

2.6.2.2 Menu Configuration Options

The following Linux kernel configurations are provided for this module. In menu configuration enable the following module:

CONFIG_OPROFILE-configuration option for the oprofile driver. In the menuconfig this option is available under
General Setup > Profiling support (EXPERIMENTAL) > OProfile system profiling (EXPERIMENTAL)

2.6.2.3 Programming Interface

This driver implements all the methods required to configure and control PMU and L2 cache EVTMON counters. More information, see the Linux document generated from build: make htmldocs.

2.6.2.4 Example Software Configuration

The following steps show and example of how to configure the OProfile: 1. Use the command bitbake linux-imx -c menuconfig. On the screen, first, go to Package list and select Oprofile. 2. Then, return to the first screen and select Configure Kernel, follow the instruction from Section 2.6.2.2, to enable Oprofile in the kernel space. 3. Save the configuration and start to build. 4. Copy Oprofile binaries to target rootfs. Copy vmlinux to /boot directory and run Oprofile root@ubuntu:/boot# opcontrol --separate=kernel --vmlinux=/boot/vmlinux root@ubuntu:/boot# opcontrol --reset Signalling daemon... done root@ubuntu:/boot# opcontrol --setup --event=CPU_CYCLES:100000 root@ubuntu:/boot# opcontrol --start Profiler running. root@ubuntu:/boot# opcontrol --dump root@ubuntu:/boot# opreport Overflow stats not available CPU: ARM V7 PMNC, speed 0 MHz (estimated) Counted CPU_CYCLES events (Number of CPU cycles) with a unit mask of 0x00 (No un it mask) count 100000 CPU_CYCLES:100000| samples| %| 4 22.2222 grep CPU_CYCLES:100000| samples| %| 4 100.000 libc-2.9.so 2 11.1111 cat CPU_CYCLES:100000| samples| %| 1 50.0000 ld-2.9.so 1 50.0000 libc-2.9.so ... root@ubuntu:/boot# opcontrol --stop Stopping profiling. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

2.7 Pulse-Width Modulator (PWM)

2.7.1 Introduction

audio images and generate tones. The PWM also provides control for the back light. the PWM Output (PWMO) signal.

2.7.2 Hardware Operation

The figure below shows the PWM block diagram. Figure 4. PWM Block Diagram interrupt signals to the processor interrupt handler. The PWM includes a single external output signal, PMWO.

Three clock inputs
Four interrupt lines
One hardware reset line
Four low power and debug mode signals
Four scan signals
Standard IP slave bus signals RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

2.7.3 Clocks

High frequency clock-provided by the CCM. The PWM can be run on this clock in low power mode.
Low reference clock - 32 KHz low reference clock provided by the CCM. The PWM can be run on this clock in the low power mode.
Global functional clock - for normal operations. In low power modes this clock can be switched off. The clock input source is determined by the CLKSRC field of the PWM control register. The CLKSRC value should only be changed when the PWM is disabled.

2.7.4 Software Operation

Table below provides a summary of the interface functions in source code. Table 18. PWM Driver Summary of the PWM module, rather than the local functional clock, as the local functional clock can change.

2.7.5 Driver Features

Duty cycle modulation
Varying output intervals
Two power management modes - full on and full off

2.7.6 Source Code Structure

Table 19. PWM Driver Files

2.7.7 Menu Configuration Options

Device Drivers > Pulse-Width Modulation (PWM) Support > i.MX PWM support RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Select the following option to enable the Backlight driver: Device Drivers > Graphics support > Backlight & LCD device support > Generic PWM based Backlight Driver

2.8 Remote Processor Messaging

2.8.1 Introduction

carbon footprint. This reduces power consumption without performance deterioration. a system is called Symmetric MultiProcessing (SMP). available on the system. In turn, drivers could then expose appropriate user space interfaces if needed. Figure 5. New multicore, multiOS architecture

2.8.2 Features

Designed for low-latency and low overhead operation, and compliant with the Linux RPMsg framework.
Optimized for embedded environments with constrained CPU and memory resources.
Implementation by using shared memory without data translation or message headers.
Application communication by using a client-server methodology. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Dynamic allocation of the RPMsg channels.

2.8.3 Source Code

Table 20. RPMSG Source

2.8.4 Menu Configuration Options

Device Drivers > IMX RPMSG pingpong driver -- loadable modules only
Device Drivers > IMX RPMSG tty driver -- loadable modules only 2.8.5 Running i.MX RPMsg Test Programs To run the i.MX RPMsg test program, perform the following operations: 1. Make sure that the proper Cortex-M4 processor RTOS and Linux images are used. For example on the i.MX 7Dual platforms:
rpmsg_pingpong_sdk_7dsdb.bin -> ping-pong test used on the i.MX 7Dual SDB board
rpmsg_str_echo_sdk_7dsdb.bin -> tty string echo test used on the i.MX 7Dual SDB board
rpmsg_pingpong_sdk_7dval.bin -> ping-pong test used on the i.MX 7Dual 12x12 LPDDR3 Arm2 board
rpmsg_str_echo_sdk_7dval.bin -> tty string echo test used on the i.MX 7Dual 12x12 LPDDR3 Arm2 board 2. Load the Cortex-M4 processor RTOS image, and kick it off in U-Boot. Load the Cortex-M4 processor RTOS image by the TFTP server or by the bootable SD card in U-Boot.
Load the Cortex-M4 processor RTOS image by the TFTP server. For example, a. Boot into U-Boot and stop. b. Use the following command to TFTP the responding Cortex-M4 processor RTOS image and boot it. dhcp 0x7e0000 10.192.242.53:rpmsg_pingpong_sdk_7dval.bin; bootaux 0x7e0000
Load the Cortex-M4 processor RTOS image by the SD card. For example, a. Created A bootable SD card by the MFGtools. Then, copy the Cortex-M4 processor RTOS files to the first partition formatted by the VFAT file system. b. Change the default Cortex-M4 processor RTOS name of the U-Boot. setenv m4image '<The name of the M4/RTOS image>';save c. Set up a boot args used by the Cortex-M4 processor. setenv run_m4_tcm 'if run loadm4image; then cp.b ${loadaddr} 0x7e0000 0x8000; bootaux 0x7e0000; fi'; save d. Modify the original bootcmd by adding run run_m4_tcm”. setenv bootcmd "run run_m4_tcm; <original contents of the bootcmd>"; save RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Note: “uart_from_osc” is mandatory required by i.MX 6SoloX when the Cortex-M4 processor RTOS image is running. Therefore, the mmcargs of U-Boot should be modified on i.MX 6SoloX. setenv mmcargs 'setenv bootargs console=${console},${baudrate} root= ${mmcroot}, uart_from_osc';save 3. Run the RPMsg test program. a. Make sure that imx_rpmsg_pingpong.ko and imx_rpmsg_tty.ko are built out. b. Use insmod imx_rpmsg_pingpong.ko or insmod imx_rpmsg_tty.ko to run the test program. Note: Do not run different test programs at the same time. c. Run the following command and ensure that the RPMsg TTY receiving program is running at backend when starting RPMsg TTY tests. /unit_tests/mxc_mcc_tty_test.out /dev/ttyRPMSG30 115200 R 100 1000 & Logs at the Linux OS side: insmod imx_rpmsg_tty.ko imx_rpmsg_tty rpmsg0: new channel: 0x400 -> 0x1! Install rpmsg tty driver! echo deadbeaf > /dev/ttyRPMSG30 imx_rpmsg_tty rpmsg0: msg(<- src 0x1) deadbeaf len 8

2.9 Thermal

2.9.1 Introduction

Thermal driver is a necessary driver for monitoring and protecting the SoC. The thermal driver monitors the SoC temperature in a certain frequency from an internal thermal sensor. It defines two trip points: critical and passive. Cooling device will take actions to protect the SoC according to the different trip points that SoC has reached:

When reaching critical point, cooling device will shut down the system.
When reaching passive point, cooling device will lower CPU frequency and notify GPU/VPU to run at a lower frequency.
When the temperature drops to 10 °C below passive point, cooling device will release all the cooling actions. Thermal driver has two parts:
Thermal zone defines trip points and monitors the SoC's temperature.
Cooling device takes the actions according to the different trip points. The critical and passive points threshold are confiugured in the following files.
i.MX 6 and i.MX 7 SoCs configure this in drivers/thermal/imx_thermal.c
i.MX 8M SoCs configure this in their dtsi file and specify CONFIG_IMX8M_THERMAL in defconfig.
i.MX 8 and i.MX 8X SoCsconfigure this in their dtsi file and specify CONFIG_IMX_SC_THERMAL in defconfig.

2.9.2 Software Operation

The thermal driver registers a thermal zone and a cooling device. A structure,thermal_zone_device_ops, describes the necessary interface that the thermal framework needs. The framework will call the related thermal zone interface to monitor the SoC temperature and do the cooling protection. The thermal driver can be accessed through the following interface: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

/sys/bus/platform/drivers/imx_thermal for i.MX 6 and i.MX 7.
/sys/class/thermal/thermal_zoneX for i.MX 8 and i.MX 8X.
/sys/bus/platform/drivers/qoriq_thermal for i.MX 8M Quad.
/sys/class/thermal/thermal_zone0/temp for i.MX 8M Mini.

2.9.3 Source Code Structure

imx91_thermal.c, device_cooling.c Thermal zone driver source files for i.MX 91. Table 21. Thermal Driver Files

2.9.4 Menu Configuration Options

For i.MX6 and i.MX7: Device Drivers > Generic Thermal sysfs driver > Temperature sensor driver for i.MX SoCs.
For i.MX 8QuadMax and i.MX 8QuadXPlus: Device Drivers > Generic Thermal sysfs driver > thermal sensor driver for NXP i.MX8 SoCs

2.10 Sensors

2.10.1 Introduction

Sensors include a group of drivers for Accelerometer, Pressure, Gyroscope, Ambient Light, and Magnetometer. Sensors are configured in the device trees for each board.

i.MX 6SABRE-SD, 6SABRE-AI, and 6SoloX use the MMA8451 sensor
i.MX 6UltraLite and 6ULL EVK use the FXLS8571Q sensor.
i.MX 7Dual SABRE-SD and i.MX 8QuadMax and i.MX 8QuadXPlus use the FX0S8700 sensor. i.MX Supports pressure sensor MPL3115 for the following SoC:
i.MX 7Dual SABRE-SD
i.MX 8QuadMax
i.MX 8QuadXPlus i.MX Supports gyroscope sensor FXAS2100 for the following SoC:
i.MX 7Dual SABRE-SD i.MX Supports ambient light sensor ISL29023 for the following SoC:
i.MX 6 SABRE-SD and 6 SABRE-AI
i.MX 6SoloX RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

i.MX 8QuadMax
i.MX 8QuadXPlus. i.MX supports magnetometer sensors MAG3110 for the following SoC:
i.MX 6 SABRE-SD
i.MX 6UL EVK
i.MX 6ULL EVK
i.MX 6SoloX i.MX supports accelerometer and gyroscope sensor LSM6DSO for the following SoC:
i.MX 93 i.MX supports temperature sensor P3T1085 for the following SoC:
i.MX 93
i.MX 95
i.MX 943

2.10.2 Sensor Driver Software Operation

2.10.3 Source Code Structure

Table below shows the driver source files available in the directory. Table 22. Sensor Driver Files

2.10.4 Menu Configuration Options

Drivers -> Industrial I/O -> Accelerometers -> Freescale/NXP MMA8452Q
Drivers -> Industrial I/O -> Inertial measurement units -> NXP FXOS8700 I2C driver
Drivers -> Industrial I/O -> Light sensors -> Intersil 29018 light and proximity sensor
Drivers -> Industrial I/O -> Digital gyroscope sensors -> NXP FXAS21002C Gyro Sensor
Drivers -> Industrial I/O -> Freescale MAG3110 3-Axis Magnetometer
Drivers -> Industrial I/O -> Inertial measurement units -> ST_LSM6DSx driver for STM 6-axis IMU MEMS sensors RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Drivers -> Industrial I/O support -> Temperature sensors -> NXP P3T1085 temprature sensor

2.11 Watchdog (WDOG)

2.11.1 Introduction

infinite loop situations or programming errors. share a virtual watchdog driver interface through system controller firmware.

2.11.2 Hardware Operation

After the WDOG timer is activated, it must be serviced by software on a periodic basis. module cannot be deactivated after it is activated.

2.11.3 Software Operation

The Linux OS has a standard WDOG interface that allows support of a WDOG driver for a specific platform. WDOG registers are only one-time programmable after booting, ensure these registers are written correctly.

2.11.4 Generic WDOG

The generic WGOD driver is implemented in the drivers/watchdog/imx2_wdt.c file. It provides functions for various IOCTLs and read/write calls from the user level program to control the WDOG.

2.11.5 Driver Features

Generates the reset signal if it is enabled but not serviced within a predefined timeout value (defined in milliseconds in one of the WDOG source files)
Does not generate the reset signal if it is serviced within a predefined timeout value
Provides IOCTL/read/write required by the standard WDOG subsystem

2.11.6 Source Code Structure

Table below shows the source files for watchdog WDOG drivers that are in drivers/watchdog. Table 23. Watchdog Driver Files RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 23. Watchdog Driver Files...continued

2.11.7 Menu Configuration Options

2.11.8 Programming Interface

WDIOC_GETSUPPORT
WDIOC_GETSTATUS
WDIOC_GETBOOTSTATUS
WDIOC_KEEPALIVE
WDIOC_SETTIMEOUT
WDIOC_GETTIMEOUT For detailed descriptions about these IOCTLs, see Documentation/watchdog.

3 Storage

3.1 AHB-to-APBH Bridge with DMA (APBH-Bridge-DMA)

3.1.1 Overview

AHB's HCLK. The H in APBH denotes that the APBH is synchronous to HCLK. as well as a central DMA facility for devices on this bus and a vectored interrupt controller for the Arm core. chapters elsewhere in this document. guaranteeing the Arm platform every fourth transfer on the APB.

3.1.1.1 Hardware Operation

Multichannel DMA supporting up to 32 time-division multiplexed DMA channels
Powered by a 16-bit Instruction-Set micro-RISC engine
Each channel executes a specific script
Very fast context-switching with two-level priority based preemptive multitasking
4 Kbytes ROM containing startup scripts (that is, boot code) and other common utilities that can be referenced by RAM-located scripts
8 Kbyte RAM area is divided into a processor context area and a code space area used to store channel scripts that are downloaded from the system memory.

3.1.1.2 Software Operation

up using the general structure.

0 GPMI0

1 GPMI1

2 GPMI2

3 GPMI3

4 GPMI4

5 GPMI5

6 GPMI6

7 GPMI7

8 EMPTY

9 EMPTY

10 EMPTY

11 EMPTY

12 EMPTY

13 EMPTY

14 EMPTY

15 EMPTY

Table 24. APBH DMA Channel Assignments

3.1.1.3 Source Code Structure

Table 25. APBH DMA Source Files

3.1.1.4 Menu Configuration Options

Device Drivers > DMA Engine support > MXS DMA support.

3.1.1.5 Programming Interface

3.2 EIM NOR

3.2.1 Introduction

The External Interface Module (EIM) NOR driver supports the Parallel NOR flash.

3.2.2 Hardware Operation

3.2.3 Software Operation

you may only use the jffs2 but cannot use the UBIFS for it.

3.2.4 Source Code

Table 26. WEIM-NOR Driver Files

3.2.5 Enabling the EIM NOR

3.3 MMC/SD/SDIO Host

3.3.1 Introduction

standard Linux driver interface to the ultra MMC/SD host controller (uSDHC). The host driver is part of the Linux kernel MMC framework.

1-bit or 4-bit operation for SD3.0 and SDIO 2.0 cards (so far we support SDIO v2.0 (AR6003 is verified)).
Supports card insertion and removal detections.
Supports the standard MMC commands.
PIO and DMA data transfers.
Supports power management.
Supports 1/4 8-bit operations for MMC cards. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

For i.MX 6, USDHC supports eMMC4.4 SDR and DDR modes.
For i.MX 7Dual, USDHC supports eMMC5.0, which includes HS400 and HS200.
Supports SD3.0 SDR50 and SDR104 modes.

3.3.2 Hardware Operation

The MMC communication is based on an advanced 11-pin serial bus designed to operate in a low voltage range. The uSDHC module supports MMC along with SD memory and I/O functions. The uSDHC controls the MMC, SD memory, and I/O cards by sending commands to cards and performing data accesses to and from the cards. The SD memory card system defines two alternative communication protocols: SD and SPI. The uSDHC only supports the SD bus protocol. The uSDHC command transfer type and uSDHC command argument registers allow a command to be issued to the card. The uSDHC command, system control, and protocol control registers allow the users to specify the format of the data and response and to control the read wait cycle. There are four 32-bit registers used to store the response from the card in the uSDHC. The uSDHC reads these four registers to get the command response directly. The uSDHC uses a fully configurable 128x32-bit FIFO for read and write. The buffer is used as temporary storage for data being transferred between the host system and the card, and vice versa. The uSDHC data buffer access register bits hold 32-bit data upon a read or write transfer. For receiving data, the steps are as follows: 1. The uSDHC controller generates a DMA request when there are more words received in the buffer than the amount set in the RD_WML register 2. Upon receiving this request, DMA engine starts transferring data from the uSDHC FIFO to system memory by reading the data buffer access register. For transmitting data, the steps are as follows: 1. The uSDHC controller generates a DMA request whenever the amount of the buffer space exceeds the value set in the WR_WML register. 2. Upon receiving this request, the DMA engine starts moving data from the system memory to the uSDHC FIFO by writing to the Data Buffer Access Register for a number of pre-defined bytes. The read-only uSDHC Present State and Interrupt Status Registers provide uSDHC operations status, application FIFO status, error conditions, and interrupt status. When certain events occur, the module has the ability to generate interrupts as well as set the corresponding Status Register bits. The uSDHC interrupt status enable and signal-enable registers allow the user to control if these interrupts occur.

3.3.3 Software Operation

The Linux OS contains an MMC bus driver which implements the MMC bus protocols. The MMC block driver handles the file system read/write calls and uses the low level MMC host controller interface driver to send the commands to the uSDHC. The MMC driver is responsible for implementing standard entry points for init, exit, request, and set_ios. The driver implements the following functions: For uSDHC:

The init function esdhc_pltfm_init() initializes the platform hardware and set platform dependant flags or values to sdhci_host structure.
The exit function esdhc_pltfm_exit() deinitializes the platform hardware and frees the memory allocated. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

The function esdhc_pltfm_get_max_clock() gets the maximum SD bus clock frequency supported by the platform.
The function esdhc_pltfm_get_min_clock() gets the minimum SD bus clock frequency supported by the platform.
esdhc_pltfm_get_ro() gets the card read only status.
esdhc_execute_tuning() handles the preparation for tuning. It's only used for SD3.0 UHS-I mode.
esdhc_set_clock() handles the clock change request. The figure below shows how the MMC-related drivers are layered. aaa-053521 File system (ext2fs/FAT driver) Application/server interface Host controller driver interface Client driver interfaceBlock client driver (storage) SDIO APP Etc sd, mmc, sdio, ce-ata and so on MMC/SD/SD IO/CE-ATA devices Local bus interface Kinds of bus protocol driverscore.c, sd.c, Host controller driversdhci.c/sdhci-pltfm.c sdhci-esdhc-imx.c block.c: block driver for peripheral media Host controller Slot electrical interface MMC/SD/SDIO/CE-ATA devices

Figure 6. MMC Drivers Layering

3.3.4 Driver Features

Supports multiple uSDHC modules.
Provides all the entry points to interface with the Linux MMC core driver.
MMC and SD cards.
SDIO cards.
SD3.0 cards.
Recognizes data transfer errors such as command time outs and CRC errors.
Power management.
It supports to be built as loadable or builtin module

3.3.5 Source Code Structure

Table below shows the uSDHC source files available in drivers/mmc/host. Table 27. uSDHC Driver Files MMC/SD Driver Files RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 27. uSDHC Driver Files MMC/SD Driver Files...continued

3.3.6 Menu Configuration Options

The following Linux kernel configuration options are provided for this module.

CONFIG_MMC builds support for the MMC bus protocol. In menuconfig, this option is available under: – Device Drivers > MMC/SD/SDIO Card support – By default, this option is Y.
CONFIG_MMC_BLOCK builds support for MMC block device driver which can be used to mount the file system. In menuconfig, this option is available under: – Device Drivers > MMC/SD Card Support > MMC block device driver – By default, this option is Y.
CONFIG_MMC_SDHCI_ESDHC_IMX is used for the i.MX USDHC ports. In menuconfig, this option is found under: – Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support > SDHCI support on the platform-specific bus > SDHCI platform support for the eSDHC i.MX controller To compile SDHCI driver as a loadable module, several options should be selected as indicated below: – CONFIG_MMC_SDHCI=m, it can be found at Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support – CONFIG_MMC_SDHCI_PLTFM=m, it can be found at Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support > SDHCI support on the platform-specific bus. – CONFIG_MMC_SDHCI_ESDHC_IMX=y, it can be found at Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support > SDHCI support on the platform-specific bus > SDHCI platform support for the Freescale eSDHC i.MX controller To compile SDHCI driver as a builttin module, several options should be selected as indicated below: – CONFIG_MMC_SDHCI=y, it can be found at Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support – CONFIG_MMC_SDHCI_PLTFM=y, it can be found at Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support > SDHCI support on the platform-specific bus. – CONFIG_MMC_SDHCI_ESDHC_IMX=y, it can be found at Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support > SDHCI support on the platform-specific bus > SDHCI platform support for the Freescale eSDHC i.MX controller
CONFIG_MMC_UNSAFE_RESUME is used for embedded systems which use a MMC/SD/SDIO card for rootfs. In menuconfig, this option is found under:

3.3.7 Device Tree Binding

compatible: Should be "fsl,<chip>-esdhc"
reg: Should contain eSDHC registers location
interrupts: Should contain eSDHC interrupt Optional properties:
non-removable: Indicate the card is wired to host permanently RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

fsl, wp-internal: Indicate to use controller internal write protection
cd-gpios: Specify GPIOs for card detection
wp-gpios: Specify GPIOs for write protection
fsl, delay-line: Specify delay line value for eMMC DDR mode Example:usdhc@02194000 { /* uSDHC2 */ compatible = "fsl,imx6q-usdhc"; reg = <0x02194000 0x4000>; interrupts = <0 23 0x04>; clocks = <&clks 164>, <&clks 164>, <&clks 164>; clock-names = "ipg", "ahb", "per"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usdhc2_1>; cd-gpios = <&gpio2 2 0>; wp-gpios = <&gpio2 3 0>; bus-width = <8>; no-1-8-v; keep-power-in-suspend; enable-sdio-wakeup; status = "okay"; Reference:
Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
arch/arm/boot/dts/imx6*.dtsi

3.3.8 Programming Interface

This driver implements the functions required by the MMC bus protocol to interface with the i.MX uSDHC module. See the Linux document generated from build: make htmldocs.

3.3.9 Loadable Module Operations

The SDHCI driver can be built as loadable or builtin module. 1. How to build SDHCI driver as loadable module.

CONFIG_MMC_SDHCI=m, it can be found at Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support
CONFIG_MMC_SDHCI_PLTFM=m, it can be found at Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support > SDHCI support on the platform-specific bus.
CONFIG_MMC_SDHCI_ESDHC_IMX=y, it can be found at Device Drivers > MMC/SD Card Support > Secure Digital Host Controller Interface support > SDHCI support on the platform-specific bus > SDHCI platform support for the i.MX eSDHC i.MX controller 2. How to load and unload SDHCI module. Due to dependency, load or unload the module following the module sequence shown below. run the following commands to load module:
load modules via insmod command, assuming the files of sdhci.ko and sdhci-platform.ko exist in current directory. $> insmod sdhci.ko $> insmod sdhci-platform.ko RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

load modules via modprobe command, make sure the files of sdhci.ko and sdhci-platform.ko exist in corresponding kernel module lib directory. $> modprobe sdhci.ko $> modprobe sdhci-platform.ko run the following commands to unload module.:
unload modules via insmod command. $> rmsmod sdhci-platform $> rmsmod sdhci
unload modules via modprobe command. $> modprobe -r sdhci-platform $> modprobe -r sdhci

3.4 NAND GPMI Flash

3.4.1 Introduction

The NAND Flash Memory Technology Devices (MTD) driver is used in the Generic-Purpose Media Interface (GPMI) controller on the i.MX 6 series and i.MX 7Dual. Only the hardware-specific layer has to be implemented for the NAND MTD driver to operate. The rest of the functionality such as Flash read/write/erase is automatically handled by the generic layer provided by the Linux MTD subsystem for NAND devices. The NAND MTD driver interfaces with the integrated NAND controller supporting file systems, such as UBIFS, CRAMFS and JFFS2UBI and UBIFSCRAMFS and JFFS2. The driver implementation supports the lowest level operations on the external NAND Flash chip, such as block read, block write and block erase as the NAND Flash technology only supports block access. Because blocks in a NAND Flash are not guaranteed to be good, the NAND MTD driver is also able to detect bad blocks and feed that information to the upper layer to handle bad block management.

3.4.2 Hardware Operation

NAND Flash is a nonvolatile storage device used for embedded systems. Driver does not support random accesses of memory as in the case of RAM or NOR Flash. Reading or writing to NAND Flash must be done through the GPMI. NAND Flash is a sequential access device appropriate for mass storage applications. Code stored on NAND Flash cannot be executed from there. Code must be loaded into RAM memory and executed from there. The i.MX 6 contains a hardware error-correcting block.

3.4.3 Software Operation

MTDs in Linux covers all memory devices such as RAM, ROM, and different kinds of NOR/NAND Flashes. The MTD subsystem provides uniform access to all such devices. Above the MTD devices there could be either MTD block device emulation with a Flash file system (JFFS2) or a UBI layer. The UBI layer in turn, can have either UBIFS above the volumes or a Flash Translation Layer (FTL) with a regular file system (FAT, Ext2/3) above it. The hardware-specific driver interfaces with the GPMI module on the i.MX 6. It implements the lowest level operations such as read, write and erase. If enabled, it also provides information about partitions on the NAND device-this information has to be provided by platform code. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual The NAND driver is the point where read/write errors can be recovered if possible. Hardware error correction is performed by BCH blocks and is driven by NAND drivers code. Detailed information about NAND driver interfaces can be found at www.linux-mtd.infradead.org.

3.4.4 Basic Operations: Read/Write

The NAND driver exports the following callbacks: gpmi_ecc_read_page (with ECC) gpmi_ecc_write_page (with ECC) gpmi_read_byte (without ECC) gpmi_read_buf (without ECC) gpmi_write_buf (without ECC) gpmi_ecc_read_oob (with ECC) gpmi_ecc_write_oob (with ECC) Since Kernel 4.1, the GPMI driver provides raw read/write modes, which exports these callbacks:

gpmi_ecc_read_page_raw (without ECC)
gpmi_ecc_write_page_raw (without ECC)
gpmi_ecc_read_oob_raw (without ECC)
gpmi_ecc_write_oob_raw (without ECC) These functions read the requested amount of data, with or without error correction. In the case of read, the gpmi_read_page() function is called, which creates the DMA chain, submits it to execute, and waits for completion. The write case is a bit more complex: the data to be written is mapped and flushed out by calling gpmi_send_page().

3.4.5 Error Correction

When reading or writing data to Flash, some bits can be flipped. This is normal behavior, and NAND drivers utilize various error correcting schemes to correct this. It could be resolved with software or hardware error correction. The GPMI driver uses only a hardware correction scheme with the help of an hardware accelerator- BCH. For BCH, the page laylout of 2K page is (2k + 64), the page layout of 4K page is (4k + 218) the page layout of 8K page is (8K + 448).

3.4.6 Boot Control Block Management

During startup, the NAND driver scans the first block for the presence of a NAND Control Block (NCB). Its presence is detected by magic signatures. When a signature is found, the boot block candidate is checked for errors using Hamming code. If errors are found, they are fixed, if possible. If the NCB is found, it is parsed to retrieve timings for the NAND chip. All boot control blocks are created when formatting the medium using the user space application kobs-ng .

3.4.7 Bad Block Handling

When the driver begins, by default, it builds the bad block table. It is possible to determine if a block is bad, dynamically, but to improve performance it is done at boot time. The badness of the erase block is determined by checking a pattern in the beginning of the spare area on each page of the block. However, if the chip uses hardware error correction, the bad marks falls into the ECC bytes area. Therefore, if hardware error correction is used, the bad block mark should be moved. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

3.4.8 Source Code Structure

The NAND driver is located in drivers/mtd/nand/gpmi-nand. Table below lists the source files for the NAND Driver.

drivers/mtd/nand/gpmi-nand/bch-regs.h
drivers/mtd/nand/gpmi-nand/gpmi-nand.h
drivers/mtd/nand/gpmi-nand/gpmi-regs.h Functions declaration
drivers/mtd/nand/gpmi-nand/gpmi-lib.c
drivers/mtd/nand/gpmi/nand/gpmi-nand.c GPMI NAND Functions

Table 28. NAND Driver Files

3.4.9 Menu Configuration Options

Device Drivers > Memory Technology Device (MTD) support > GPMI NAND Flash Controller driver In addition, these MTD options must be enabled:
CONFIG_MTD_NAND = [y | m]
CONFIG_MTD = y
CONFIG_MTD_BLOCK = y In addition, these UBI options must be enabled:
CONFIG_MTD_UBI=y
CONFIG_UBIFS_FS=y

3.5 Quad/Flexible/External Serial Peripheral Interface (QuardSPI/FlexSPI/XSPI)

3.5.1 Introduction

Flexible sequence engine to support various flash vendor devices.
Single, dual, quad, and octal modes of operation.
DDR/DTR mode wherein the data is generated on every edge of the serial flash clock.
Support for flash data strobe signal for data sampling in DDR and SDR mode.
DMA support to read RX Buffer data via AMBA AHB bus (64-bit width interface) or IP registers space (32-bit access). RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

3.5.2 Hardware Operation

equipped. Check the Quad SPI NOR type on the boards and then configure it properly.

3.5.3 Software Operation

system. The following figure illustrates the relationships between some of the standard components. Figure 7. Components of a Flash-Based File System provides the interfaces to read, write, and erase NOR Flash.

3.5.4 Driver Features

Provides necessary information for the upper-layer MTD driver. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

3.5.5 Source Code Structure

Table 29. Driver File

3.5.6 Menu Configuration Options

3.6 SATA

3.6.1 Introduction

The SATA AHCI driver is based on the LIBATA layer of the block device infrastructure of the Linux kernel. documentation, named SATA_Data_Book.pdf.

3.6.2 Board Configuration Options

With the power off, install the SATA cable and hard drive.

3.6.3 Software Operation

The details about the libata APIs, see the libATA Developer's Guide.

3.6.4 Source Code Structure

Table 30. SATA Driver Files

3.6.5 Menu Configuration Options

In busybox, enable "fdisk" under "Linux System Utilities".

3.6.6 Programming Interface

read, write, and ioctl) on /dev/sda*.

3.6.7 Usage Example

After building the kernel and the SATA AHCI driver and deploying, boot the target, and log in as root.
Make sure that the AHCI and AHCI platform drivers are built in the kernel or loaded into the kernel.

NXP Semiconductors RM00293 i.MX Linux Reference Manual sda: sda1 sd 0:0:0:0: [sda] Attached SCSI disk You may use standard Linux utilities to partition and create a file system on the drive (for example: fdisk and mke2fs) to be mounted and used by applications. The device nodes for the drive and its partitions appears under /dev/sda*. For example, to check basic kernel settings for the drive, execute hdparm /dev/sda.

3.6.8 Usage Example

The following command can be used to find out the capacities of the hard disk. If the hard disk is pre-formatted, this command shows the size of the hard disk, partitions, and filesystem type: $fdisk -l /dev/sda If the hard disk is not formatted, create the partitions on the hard disk using the following command: $fdisk /dev/sda After the partition, the created files resemble /dev/sda[1-4]. Block Read/Write Test: The command, dd, is used for for reading/writing blocks. Note this command can corrupt the partitions and filesystem on Hard disk. To clear the first 5 KB of the card, do the following: $dd if=/dev/zero of=/dev/sda1 bs=1024 count=5 The response should be as follows: 5+0 records in 5+0 records out To write a file content to the card enter the following text, substituting the name of the file to be written for file_name, do the following: $dd if=file_name of=/dev/sda1 To read 1KB of data from the card enter the following text, substituting the name of the file to be written for output_file, do the following: $dd if=/dev/sda1 of=output_file bs=1024 count=1 Files System Tests Format the hard disk partitons using mkfs.vfat or mkfs.ext2, depending on the filesystem: $mkfs.ext2 /dev/sda1 $mkfs.vfat /dev/sda1 Mount the file system as follows: $mkdir /mnt/sda1 RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

After mounting, file/directory, operations can be performed in /mnt/sda1 .

3.7 Smart Direct Memory Access (SDMA) API

3.7.1 Overview

Loading channel scripts from the MCU memory space into SDMA internal RAM
Loading context parameters of the scripts
Loading buffer descriptor parameters of the scripts
Controlling execution of the scripts
Callback mechanism at the end of script execution

3.7.2 Hardware Operation

Multichannel DMA supporting up to 32 time-division multiplexed DMA channels.
Powered by a 16-bit Instruction-Set micro-RISC engine.
Each channel executes specific script.
Very fast context-switching with two-level priority based preemptive multitasking.
4 Kbytes ROM containing startup scripts (that is, boot code) and other common utilities that can be referenced by RAM-located scripts.
8 Kbyte RAM area is divided into a processor context area and a code space area used to store channel scripts that are downloaded from the system memory.

3.7.3 Software Operation

SDMA memory, initializing the channel descriptors, and controlling the buffer descriptors and SDMA registers. channel is found, that channel is allocated for the requested DMA transfers. Table 31. SDMA Channel Usage RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 31. SDMA Channel Usage...continued

3.7.4 Source Code Structure

The following table shows the source files available in the directory drivers/dma. Table 32. SDMA API Source Files The following table shows the image files available in the directory firmware/imx/sdma for 4.1 and 4.9 kernels. For 4.14 kernel, the sdma firmware is provided with the firmware-imx package and not in the kernel source tree. Table 33. SDMA Script Files

3.7.5 Special peripheral with SDMA cases

In the current release, the I2C controller and SDMA script in i.MX 6/7Dual/8M either do not support SDMA. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

I2C uses DMA mode when the frame length is greater than 16 bytes, because I2C itself still needs to use the CPU to process the first few and last few bytes when sending and receiving a frame. Therefore, when the data being sent is not long, using DMA to send data does not improve efficiency.
The SDMA script is loaded in rootfs stage, so any use of I2C DMA transfer in kernel boot stage will fail. It is strongly recommended not to use I2C SDMA mode when sending small amounts of data. If there is a special case that needs to send a large amount of I2C data, contact NXP Pro-support to get the patchset.

3.8 SPI NOR Flash Memory Technology Device (MTD)

3.8.1 Introduction

The SPI NOR Flash Memory Technology Device (MTD) driver provides the support to the data Flash though the SPI interface. By default, the SPI NOR Flash MTD driver creates static MTD partitions to support data Flash.

3.8.2 Hardware Operation

On some boards, the SPI NOR - AT45DB321D is equipped, while on some boards M25P32 is equipped. Check the SPI NOR type on the boards and then configure it properly. The AT45DB321D is a 2.7 V, serial-interface sequential access Flash memory. The AT45DB321D serial interface is SPI compatible for frequencies up to 66 MHz. The memory is organized as 8,192 pages of 512 bytes or 528 bytes. The AT45DB321D also contains two SRAM buffers of 512/528 bytes each which allow receiving of data while a page in the main memory is being reprogrammed, as well as writing a continuous data stream. The M25P32 is a 32 Mbit (4M x 8) Serial Flash memory, with advanced write protection mechanisms, accessed by a high-speed SPI-compatible bus up to 75 MHz. The memory is organized as 64 sectors, each containing 256 pages. Each page is 256 bytes wide. Therefore, the whole memory can be viewed as consisting of 16384 pages, or 4,194,304 bytes. The memory can be programmed 1 to 256 bytes at a time using the Page Program instruction. The whole memory can be erased using the Bulk Erase instruction, or a sector at a time, using the Sector Erase instruction. Unlike conventional Flash memories that are accessed randomly, these two SPI NOR access data sequentially. They operate from a single 2.7-3.6 V power supply for program and read operations. They are enabled through a chip select pin and accessed through a three-wire interface: Serial Input, Serial Output, and Serial Clock.

3.8.3 Software Operation

In a Flash-based embedded Linux system, a number of Linux technologies work together to implement a file system. The figure below illustrates the relationships between some of the standard components. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Figure 8. Components of a Flash-Based File System provides the interfaces to read, write, and erase NOR Flash.

3.8.4 Source Code Structure

Table 34. SPI NOR MTD Driver Files

3.8.5 Menu Configuration Options

CONFIG_MTD_M25P80: This config enables access to most modern SPI flash chips, used for program and data storage.
Device Drivers > Memory Technology Device (MTD) support >Self-contained MTD device drivers > Support most SPI Flash chips (AT26DF, M25P, W25X, and so on)

4 Connectivity

4.1 ADC

4.1.1 ADC Introduction

Two 12-bit ADCs
Linear successive approximation algorithm with up to 12-bit resolution with 10/11 bit accuracy
Up to 1 MS/s sampling rate
Up to 8 single-ended external analog inputs RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Single or continuous conversion (automatic return to idle after single conversion)
Output Modes: (in right-justified unsigned format) – 12-bit – 10-bit – 8-bit
Configurable sample time and conversion speed/power
Conversion complete and hardware average complete flag and interrupt
Input clock selectable from up to four sources
Asynchronous clock source for lower noise operation with option to output the clock
Selectable asynchronous hardware conversion trigger with hardware channel select
Selectable voltage reference, Internal, External, or Alternate
Operation in low power modes for lower noise operation
Hardware average function
Self-calibration mode

4.1.2 ADC External Signals

ADC_VREFH: Voltage reference high
ADC_VREHL: Voltage reference low
ADC1_IN0: Analog channel 1 input 0
ADC1_IN1: Analog channel 1 input 1
ADC1_IN2: Analog channel 1 input 2
ADC1_IN3: Analog channel 1 input 3
ADC2_IN0: Analog channel 2 input 0
ADC2_IN1: Analog channel 2 input 1
ADC2_IN2: Analog channel 2 input 2
ADC2_IN3: Analog channel 2 input 3 The ADC pin settings should be done in the ADCx_PCTL register. No other extra IOMUX settings are required.

4.1.3 ADC Driver Overview

Four external inputs for each ADC controller channel
12 bit ADC
Single conversion
Hardware average
Low power mode of ADC
Sample rate changes in the available sample rate group

4.1.4 Source Code Structure

drivers/iio/adc/vf610_adc.c i.MX 6UltraLite and i.MX 6SoloX ADC functions. drivers/iio/adc/imx7d_adc.c i.MX 7Dual ADC functions. drivers/iio/adc/imx8qxp_adc.c i.MX 8QuadXPlus ADC functions. Table 35. ADC Driver Files RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

drivers/iio/adc/imx93_adc.c i.MX 93 ADC functions. Table 35. ADC Driver Files...continued

4.1.5 Menu Configuration Options

4.1.6 Programming Interface

The following table lists the software interfaces. Table 36. Software Interfaces

4.2 ENET IEEE-1588

4.2.1 Introduction

The driver requires a protocol stack to complete IEEE-1588 full protocol. It complies with the LinuxPTP stack. with a time-stamping module to support precise time stamping of incoming and outgoing frames. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Figure 9. IEEE 1588 Functions Overview

4.2.1.1 Transmit Timestamping

driver) should detect 1588 event frames and set the signal ff_tx_ts_frm together with the frame. application had the ff_tx_ts_frm signal asserted for the frame. TS_TIMESTAMP. The interrupt bit EIR (TS_AVAIL) is set to indicate that a new timestamp is available. other frames do not use the ff_tx_ts_frm indicator and hence do not interfere with the timestamp capture.

4.2.1.2 Receive Timestamping

provides the captured timestamp on ff_rx_ts(31:0). This is done for all received frames. field within the receive descriptor for software access.

4.2.2 Software Operation

Module initialization-Initializes the module with the device-specific structure, and registers a character driver.
Interrupt servicing routine-Supports events, such as TS_AVAIL, TS_TIMER. The driver shares interrupt servicing routine with FEC driver. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

4.2.2.1 Source Code Structure

Table below lists the source files in drivers/net/ethernet/freescale directory. Table 37. ENET 1588 File List

4.2.2.2 Menu Configuration Options

By default, ENET 1588 is enabled.

4.2.2.3 Programming Interface

The 1588 driver complies with the Linuxptp protocol stack interface. Stack-specific defines are added to the header file (fec.h).

Linuxptp stack This software is an implementation of the Precision Time Protocol (PTP) according to IEEE standard 1588 for Linux OS. The dual design goals are to provide a robust implementation of the standard and to use the most relevant and modern Application Programming Interfaces (API) offered by the Linux OS kernel. Supporting legacy APIs and other platforms is not a goal. The software is copyrighted by the authors and is licensed under the GNU General Public License. The software development is hosted at Source Forge: sourceforge.net/projects/linuxptp/

4.2.3.1 Linuxptp Stack Features

Ordinary/Boundary Clock
Best master clock algorithm
Transport over UDP/IPv4, UDP/IPv6, and IEEE 802.3
Transparent clock (E2E/P2P)
Slave only
Supporting IEEE 802.1AS-2011 in the role of end station

4.2.3.2 Using Linuxptp

NXP Semiconductors RM00293 i.MX Linux Reference Manual Transport on IEEE 802.3 with P2P delay mechanism: ptp4l -P -A -2 -H -m -i eth0

4.3 Enhanced Configurable Serial Peripheral Interface (ECSPI)

4.3.1 Introduction

The ECSPI driver implements a standard Linux driver interface to the ECSPI controllers. It supports the following features:

Interrupt-driven transmit/receive of bytes
Multiple master controller interface
Multiple slaves select
Multiclient requests ECSPI is used for fast data communication with fewer software interrupts than conventional serial communications. >Each ECSPI is equipped with a data FIFO and is a master/slave configurable serial peripheral interface module, allowing the processor to interface with external SPI master or slave devices. The primary features of the ECSPI includes:
Master/slave-configurable
Four chip select signals to support multiple peripherals
Up to 32-bit programmable data transfer
64 x 32-bit FIFO for both transmit and receive data
Configurable polarity and phase of the Chip Select (SS) and SPI Clock (SCLK) The ECSPI module supports the following features:
Implements each of the functions required by a ECSPI module to interface to Linux OS
Multiple SPI master controllers
Multiclient synchronous requests

4.3.2 Software Operation

The following sections describe the ECSPI software operation.

4.3.3 SPI Sub-System in Linux OS

The ECSPI driver layer is located between the client layer (SPI-NOR Flash are examples of clients) and the hardware access layer. The figure below shows the block diagram for SPI subsystem in Linux OS. The SPI requests go into I/O queues. Requests for a given SPI device are executed in FIFO order and they complete asynchronously through completion callbacks. There are also some simple synchronous wrappers for those calls including the ones for common transaction types such as writing a command and then reading its response. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

SPI-NOR Flash Client #2 Client #3.... Figure 10. SPI Subsystem below shows how the different SPI drivers are layered in the SPI subsystem. Figure 11. Layering of SPI Drivers in SPI Subsystem

4.3.4 Software Limitations

Does not currently have SPI slave logic implementation
Does not support a single client connected to multiple masters
Does not currently implement the user space interface with the help of the device node entry but supports sysfs interface

4.3.5 Standard Operations

The ECSPI driver is responsible for implementing standard entry points for init, exit, chip select, and transfer.

Init function spi_imx_init() registers the device_driver structure.
Probe function spi_imx_probe() performs initialization and registration of the SPI device-specific structure with SPI core driver. The driver probes for memory and IRQ resources. Configures the IOMUX to enable ECSPI I/ O pins, requests for IRQ and resets the hardware.
Chip select function spi_imx_chipselect() configures the hardware ECSPI for the current SPI device. Sets the word size, transfer mode, data rate for this device. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

SPI transfer function spi_imx_transfer() handles data transfers operations.
SPI setup function spi_imx_setup() initializes the current SPI device.
SPI driver ISR spi_imx_isr() is called when the data transfer operation is completed and an interrupt is generated.

4.3.6 ECSPI Synchronous Operation

The figure below shows how the ECSPI provides synchronous read/write operations. Figure 12. ECSPI Synchronous Operation

4.3.7 Source Code Structure

Table 38. ECSPI Driver Files

4.3.8 Menu Configuration Options

CONFIG_SPI build support for the SPI core. In menuconfig, this option is available under: – Device Drivers > SPI Support.
CONFIG_BITBANG is the Library code that is automatically selected by drivers that need it. SPI_IMX selects it. In menuconfig, this option is available under: – Device Drivers > SPI Support > Utilities for Bitbanging SPI masters.
CONFIG_SPI_IMX implements the SPI master mode for ECSPI. In menuconfig, this option is available under: – Device Drivers > SPI Support > Freescale i.MX SPI controllers.

4.3.9 Programming Interface

This driver implements all the functions that are required by the SPI core to interface with the ECSPI hardware. For more information, see the Linux document generated from build: make htmldocs. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

4.3.10 Interrupt Requirements

The SPI interface generates interrupts. ECSPI interrupt requirements are listed in table below. Table 39. ECSPI Interrupt Requirements

4.4 Fast Ethernet Controller (FEC)

4.4.1 Introduction

control and channel interface functions.

Full/Half duplex operation
Link status change detect
Auto-negotiation (determines the network speed and full or half-duplex operation)
Transmits features such as automatic retransmission on collision and CRC generation
Obtaining statistics from the device such as transmit collisions The network adapter can be accessed through the ifconfig command with interface name ethx. The driver auto- probes the external adaptor (PHY device).

4.4.2 Hardware Operation

The FEC is an Ethernet controller that interfaces the system to the LAN network. addition, the FEC supports 1000 Mbps RGMII, which uses 4-bit reduced GMII operating at 125 MHz. and RGMII modes uses a subset of the 18 signals. These signals are listed in table below. Table 40. Pin Usage in MII, RMII and RGMII Modes RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 40. Pin Usage in MII, RMII and RGMII Modes...continued can be divided in the parts listed below. For details, see the Applications Processor Reference Manuals.

Transmission-The Ethernet transmitter is designed to work with almost no intervention from software. Once ECR[ETHER_EN] is asserted and data appears in the transmit FIFO, the Ethernet MAC is able to transmit onto the network. When the transmit FIFO fills to the watermark (defined by the TFWR), the MAC transmit logic asserts FEC_TX_EN and starts transmitting the preamble (PA) sequence, the start frame delimiter (SFD), and then the frame information from the FIFO. However, the controller defers the transmission if the network is busy (FEC_CRS asserts).
Before transmitting, the controller waits for carrier sense to become inactive, then determines if carrier sense stays inactive for 60 bit times. If the transmission begins after waiting an additional 36 bit times (96 bit times after carrier sense originally became inactive), both buffer (TXB) and frame (TXF) interrupts may be generated as determined by the settings in the EIMR.
Reception-The FEC receiver is designed to work with almost no intervention from the host and can perform address recognition, CRC checking, short frame checking, and maximum frame length checking. When the driver enables the FEC receiver by asserting ECR[ETHER_EN], it immediately starts processing receive frames. When FEC_RX_DV asserts, the receiver checks for a valid PA/SFD header. If the PA/SFD is valid, it is stripped and the frame is processed by the receiver. If a valid PA/SFD is not found, the frame is ignored. In MII mode, the receiver checks for at least one byte matching the SFD. Zero or more PA bytes may occur, but if a 00 bit sequence is detected prior to the SFD byte, the frame is ignored.
After the first six bytes of the frame have been received, the FEC performs address recognition on the frame. During reception, the Ethernet controller checks for various error conditions and once the entire frame is written into the FIFO, a 32-bit frame status word is written into the FIFO. This status word contains the M, BC, MC, LG, NO, CR, OV, and TR status bits, and the frame length. Receive Buffer (RXB) and Frame Interrupts (RXF) may be generated if enabled by the EIMR register. When the receive frame is complete, the FEC sets RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

a frame has been received and is in memory. The Ethernet controller then waits for a new frame.

Interrupt management-When an event occurs that sets a bit in the EIR, an interrupt is generated if the corresponding bit in the interrupt mask register (EIMR) is also set. The bit in the EIR is cleared if a one is written to that bit position; writing zero has no effect. This register is cleared upon hardware reset. These interrupts can be divided into operational interrupts, transceiver/network error interrupts, and internal error interrupts. Interrupts which may occur in normal operation are GRA, TXF, TXB, RXF, RXB. Interrupts resulting from errors/problems detected in the network or transceiver are HBERR, BABR, BABT, LC, and RL. Interrupts resulting from internal errors are HBERR and UN. Some of the error interrupts are independently counted in the MIB block counters. Software may choose to mask off these interrupts as these errors are visible to network management through the MIB counters.
PHY management-phylib was used to manage all the FEC PHY-related operation such as PHY discovery, link status, and state machine.MDIO bus will be created in FEC driver and registered into the system. See Documentation/networking/phy.txt under the Linux OS source directory for more information.

4.4.3 Software Operation

Module initialization-Initializes the module with the device-specific structure
Rx/Tx transmition
Interrupt servicing routine
PHY management
FEC management such init/start/stop
i.MX 6 FEC module use little-endian format

4.4.4 Source Code Structure

Table 41. FEC Driver Files

4.4.5 Menu Configuration Options

CONFIG_FEC is provided for this module. This option is available under: – Device Drivers > Network device support > Ethernet (10, 100 or 1000 Mbit) > FEC Ethernet controller. – To mount NFS-rootfs through FEC, disable the other Network config in the menuconfig if need.

4.4.6 Programming Interface

NXP Semiconductors RM00293 i.MX Linux Reference Manual fec.h defines the struct for the register access and the struct for the buffer descriptor. For example, * Define the buffer descriptor structure. struct bufdesc { unsigned short cbd_datlen; /* Data length */ unsigned short cbd_sc; /* Control and status info unsigned long cbd_bufaddr; /* Buffer address */ struct bufdesc_ex { struct bufdesc desc; unsigned long cbd_esc; unsigned long cbd_prot; unsigned long cbd_bdu; unsigned long ts; unsigned short res0[4]; * Define the register access structure. #define FEC_IEVENT 0x004 /* Interrupt event reg */ #define FEC_IMASK 0x008 /* Interrupt mask reg */ #define FEC_R_DES_ACTIVE 0x010 /* Receive descriptor reg */ #define FEC_X_DES_ACTIVE 0x014 /* Transmit descriptor reg */ #define FEC_ECNTRL 0x024 /* Ethernet control reg */ #define FEC_MII_DATA 0x040 /* MII manage frame reg */ #define FEC_MII_SPEED 0x044 /* MII speed control reg */ #define FEC_MIB_CTRLSTAT 0x064 /* MIB control/status reg */ #define FEC_R_CNTRL 0x084 /* Receive control reg */ #define FEC_X_CNTRL 0x0c4 /* Transmit Control reg */ #define FEC_ADDR_LOW 0x0e4 /* Low 32bits MAC address */ #define FEC_ADDR_HIGH 0x0e8 /* High 16bits MAC address */ #define FEC_OPD 0x0ec /* Opcode + Pause duration */ #define FEC_HASH_TABLE_HIGH 0x118 /* High 32bits hash table */ #define FEC_HASH_TABLE_LOW 0x11c /* Low 32bits hash table */ #define FEC_GRP_HASH_TABLE_HIGH 0x120 /* High 32bits hash table */ #define FEC_GRP_HASH_TABLE_LOW 0x124 /* Low 32bits hash table */ #define FEC_X_WMRK 0x144 /* FIFO transmit water mark */ #define FEC_R_BOUND 0x14c /* FIFO receive bound reg */ #define FEC_R_FSTART 0x150 /* FIFO receive start reg */ #define FEC_R_DES_START 0x180 /* Receive descriptor ring */ #define FEC_X_DES_START 0x184 /* Transmit descriptor ring */ #define FEC_R_BUFF_SIZE 0x188 /* Maximum receive buff size */ #define FEC_MIIGSK_CFGR 0x300 /* MIIGSK config register */ #define FEC_MIIGSK_ENR 0x308 /* MIIGSK enable register */

4.4.6.1 Getting a MAC Address

The MAC address can be set through the kernel command line, kernel device tree DTS file, OCOTP, or MAC registers set by bootloader, such as U-Boot. The FEC driver uses it to configure the MAC address for the network device. In general, use kernel command line in a form of fec.macaddr=0x00,0x04,0x9f,0x01,0x30,0xe0 to set the MAC address. Due to certain pin conflicts (FEC RMII mode needs to use GPIO_16 or RGMII_TX_CTL pin as reference clock input/output channel), the one of the both pins cannot connect to branch lines for other modules use because the branch lines have serious influence on clock. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

4.5 FlexCAN

4.5.1 Introduction

maximum message buffer is 64. The driver is a network device driver of PF_CAN protocol family. The FlexCAN on the i.MX 8QuadMax/8QuadXPlus supports CAN FD protocol.

4.5.1.1 Software Operation

documents in the kernel source directory Documentation/networking/can.txt. netlink interface using the program "ip" from the "IPROUTE2" utility suite. Starting and stopping the CAN network device.

ip link set canX up type can bitrate 125000 The iproute2 tool also provides some other configuration capbilities for can bus such as bit-timing setting. For details, see kernel doc: Documentation/networking/can.txt

4.5.1.2 Source Code Structure

Table 42. FlexCAN Driver Files

4.5.1.3 Menu Configuration Options

The following kernel configuration options are provided for this module.

CONFIG_CAN - Build support for PF_CAN protocol family. In menuconfig, this option is available under Networking > CAN bus subsystem support.
CONFIG_CAN_RAW - Build support for Raw CAN protocol. In menuconfig, this option is available under Networking > CAN bus subsystem support > Raw CAN Protocol (raw access with CAN-ID filtering).
CONFIG_CAN_BCM - Build support for Broadcast Manager CAN protocol. In menuconfig, this option is available under Networking > CAN bus subsystem support > Broadcast Manager CAN Protocol (with content filtering). RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

CONFIG_CAN_VCAN - Build support for Virtual Local CAN interface (also in Ethernet interface). In menuconfig, this option is available under Networking > CAN bus subsystem support > CAN Device Driver > Virtual Local CAN Interface (vcan).
CONFIG_CAN_DEBUG_DEVICES - Build support to produce debug messages to the system log to the driver. In menuconfig, this option is available under Networking > CAN bus subsystem support > CAN Device Driver > CAN devices debugging messages.
CONFIG_CAN_FLEXCAN - Build support for FlexCAN device driver. In menuconfig, this option is available under Networking > CAN bus subsystem support > CAN Device Driver > Freescale FlexCAN.

4.6 Inter-IC (I2C)

4.6.1 Introduction

LPI2C is a bidirectional serial bus that provides a simple, efficient method of data exchange, minimizing the interconnection between devices. The LPI2C driver for Linux OS has two parts:

Bus driver-low level interface that is used to communicate with the LPI2C bus
Chip driver-interface between other device drivers and the LPI2C bus driver The I2C bus driver is a low-level interface that is used to interface with the I2C bus. This driver is invoked by the I2C chip driver and it is not exposed to the user space. The standard Linux kernel contains a core I2C module that is used by the chip driver to access the bus driver to transfer data over the I2C bus. This bus driver supports:
Compatibility with the I2C bus standard
Bit rates up to 1 Mbps
Standard I2C master mode and slave mode
Power management features by suspending and resuming I2C.

4.6.2 LPI2C Bus Driver Overview

The LPI2C bus driver is invoked only by the chip driver and is not exposed to the user space. The standard Linux kernel contains a core I2C module that is used by the chip driver to access the LPI2C bus driver to transfer data over the LPI2C bus. The chip driver uses a standard kernel space API that is provided in the Linux kernel to access the core I2C module. The standard I2C kernel functions are documented in the files available under Documentation/i2c in the kernel source tree. This bus driver supports the following features:

Compatible with the I2C bus standard
Interrupt-driven, byte-by-byte data transfer
Standard I2C master mode and slave mode

4.6.3 I2C Device Driver Overview

The I2C device driver implements all the Linux I2C data structures that are required to communicate with the LPI2C bus driver. It exposes a custom kernel space API to the other device drivers to transfer data to the device that is connected to the LPI2C bus. Internally, these API functions use the standard I2C kernel space API to call the I2C core module. The I2C core module looks up the LPI2C bus driver and calls the appropriate function in the LPI2C bus driver to transfer data. This driver provides the following functions to other device drivers:

Read function to read the device registers
Write function to write to the device registers RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

4.6.4 Software Operation

The I2C driver for Linux OS has two parts: an I2C bus driver and an I2C chip driver.

4.6.5 I2C Bus Driver Software Operation

I2C chip driver wants to communicate with an I2C device. each I2C module with the I2C core. These adapters are unregistered (removed) when the driver is unloaded. such as NACK is detected. When error condition occurs, I2C driver should stop current transfer.

4.6.6 I2C Device Driver Software Operation

can use the appropriate methods to transfer data.

4.6.7 Driver Features

I2C communication protocol
I2C master mode and slave mode of operation

4.6.8 Source Code Structure

Table 43. I2C Driver Files

4.6.9 Menu Configuration Options

4.6.10 Programming Interface

connected to the LPI2C bus. For more information, see include/linux/i2c.h.

4.7 Media Local Bus

4.7.1 Introduction

hardware interface and software API library. Media Local Bus Specification. the i.MX to the MediaLB controller. Figure 13. MLB Device Top-Level Block Diagram RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

channel type (synchronous, asynchronous, control, or isochronous) and direction (transmit or receive). device transmitting the data and the MediaLB device(s) receiving the data. The supported features are the following.

Synchronous, asynchronous, control, and isochronous channel.
Up to 64 logical channels and 64 physical channels running at a maximum speed of 1024Fs.
Transmission of commands and data and reception of receive status when functioning as the transmitting device associated with a logical channel address.
Reception of commands and data and transmission as receive status responses when functioning as the receiving device associated with a logical channel address.
MediaLB lock detection.
System channel command handling.
256Fs, 512Fs and 1024Fs frame rates.
Asynchronous, control, synchronous, and isochronous channel types.
The following configurations to MLB device module: – Frame rate – Device address – Channel address
MLB channel exception get interface. All the channel exceptions are sent and handled by the application.

4.7.2 MLB Driver Overview

to configure the MLB device module. The MLB driver architecture is shown in the figure below. Figure 14. MLB Driver Architecture Diagram RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual dev/async, /dev/sync, and /dev/isoc. Each minor device has the same interfaces, and handle both Tx and Rx operation. The following description is for both control and asynchronous device. The driver uses IRAM as MLB device module Tx/Rx buffer. All the data transmission and reception between module and IRAM is handled by the MLB module DMA. The driver is responsible for configuring the buffer start and end pointer for the MLB module. For reception, the driver uses a ring buffer to buffer the received packet for read. When a packet arrives, the MLB module puts the received packet into the IRAM Rx buffer, and notifies the driver by interrupt. The driver then copy the packet from the IRAM to one ring buffer node indicated by the write position, and updates the write position with the next empty node. Finally the packet reader application is notified, and it gets one packet from the node indicated by the read position of ring buffer. After the read is completed, it updates the read position with the next available buffer node. There is no received packet in the ring buffer when the read and write position is the same. For transmission, the driver writes the packet given by the writer application into the IRAM Tx buffer, updates the Tx status and sets MLB device module Tx buffer pointer to start transmission. After transmission completes, the driver is notified by interrupt and updates the Tx status to accept the next packet from the application. The driver supports NON BLOCK I/O. User applications can poll to check if there are packets or exception events to read, and also they can check if a packet can be sent or not. If there are exception events, the application can call ioctl to get the event. The ioctl also provides the interface to configure the frame rate, device address, and channel address.

4.7.3 Software Operation

The MLB driver provides a common interface to application.

Packet read/write-BLOCK and NONBLOCK Packet I/O modes are supported. Only one packet can be read or written at once. The minimum read length must be greater or equal to the received packet length, meanwhile the write length must be shorter than 1024 Bytes.
Polling-The MLB driver provide polling interface which polls for three status, application can use select to get current I/O status: – Packet available for read (ready to read) – Driver is ready to send next packet (ready to write) – Exception event comes (ready to read)
ioctl-MLB driver provides the following ioctl: MLB_SET_FPS Argument type: unsigned int Set frame rate, the argument must be 256, 512 or 1024. MLB_GET_VER Argument type: unsigned long Get MLB device module version, which is 0x02000202 by default on the i.MX35. MLB_SET_DEVADDR Argument type: unsigned char RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Set MLB device address, which is used by the system channel MlbScan command. argument format is: tx_ca[8:1] << 16 | rx_ca[8:1]. Startup the corresponding type of channel for transmit and reception. Shutdown the corresponding type of channel.

4.7.4 Source Code Structure

The table below lists the MLB Driver source files. Table 44. MLB Driver Source Files

4.7.5 Menu Configuration Options

Device Drivers > MXC support drivers > MXC Media Local Bus Driver > MLB support.

4.8 PCI Express Root Complex

4.8.1 Introduction

NXP Semiconductors RM00293 i.MX Linux Reference Manual PCI Express (PCIe) is Third Generation I/O Interconnect, targeting low cost, high volume, multiplatform interconnection usages. It has the concepts with earlier PCI and PCI-X and offers backwards compatibility for existing PCI software with following differences:

PCIe is a point-to-point interconnect
Serial link between devices
Packet based communication
Scalable performance via aggregated Lanes from X1 to X16
Need PCIe switch to have connection between more than two PCIe devices

4.8.2 Terminology and Conventions

The following terminologies and conventions are used in this document:

Bridge A Function that virtually or actually connects a PCI/PCI-X segment or PCI Express Port with an internal component interconnect or with another PCI/PCI-X bus segment or PCI Express Port.
Downstream – The relative position of an interconnect/System Element (Port/component) that is farther from the Root Complex. The Ports on a Switch that are not the Upstream Port are Downstream Ports. All Ports on a Root Complex are Downstream Ports. The Downstream component on a Link is the component farther from the Root Complex. – A direction of information flow where the information is flowing away from the Root Complex.
Endpoint One of several defined System Elements. A Function that has a Type 00h Configuration Space header.
Host The entity comprising of one (or more) Central Processing Unit(s) (CPU) and resources, such as Memory (RAM) that can be shared across multiple PCIe nodes connected through a Root Complex.
Lane A set of differential signal pairs, one pair for transmission and one pair for reception.
Link The collection of two Ports and their interconnecting Lanes. A Link is a dual simplex communications path between two components.
PCIe Fabric A topology comprised of various PCI Express nodes, also referred as devices. A device in the fabric can be Root Complex, Endpoint, PCIe-PCI/PCI-X Bridge or a Switch.
Port – Logically, an interface between a component and a PCI Express Link. – Physically, a group of Transmitters and Receivers located on the same chip that define a Link.
Root Complex RC A defined System Element that includes a Host Bridge, zero or more Root Complex Integrated Endpoints, zero or more Root Complex Event Collectors, and one or more Root Ports.
Root Port A PCI Express Port on a Root Complex that maps a portion of the Hierarchy through an associated virtual PCI-PCI Bridge.
Upstream – The relative position of an interconnect/System Element (Port/component) that is closer to the Root Complex. The Port on a Switch that is closest topologically to the Root Complex is the Upstream Port. The Port on a component that contains only Endpoint or Bridge Functions is an Upstream Port. The Upstream component on a Link is the component closer to the Root Complex. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

that device. An Upstream Flow is the communication moving towards RC. There is one PCIe port on the i.MX. Currently, only the RC mode is enabled in the Linux BSP. The following figure describes the diagram of the PCIe RC port on i.MX. Figure 15. diagram of the PCIe RC port on i.MX

Host Bridge: A bridge, integrated into RC to have PCI compatible connection to Host. The PCI side of this bridge is Bus #0 always. This means, the device on this bus will be the host itself.
Virtual PCI-PCI Bridge: Each PCI Express port which is part of RC or a Switch is treated as a virtual PCI-PCI bridge. This means each port has a primary and secondary PCI bus and the downstream is mapped into the remote configuration space.
Root port associated virtual bridge has Bus #0 on the primary side with secondary bus on the downstream.
Each PCIe Switch is viewed as collection of as many virtual PCI-PCI bridges as number of downstream ports, connected to a virtual PCI bus which is actually secondary bus of another PCI-PCI bridge forming the upstream port of the switch.
The upstream port of each EP can either be part of the secondary bus segment of virtual PCI-PCI Bridge representing downstream port of a switch or of the root port.

4.8.4 Features

The following are the various features supported by i.MX as a PCI Express Root Complex driver.

Express Base Specification Revision 2.0-compliant.
Gen2 operation with x1 link supporting 5 GT/s raw transfer rate in single direction.
Support Legacy Interrupts (INTx) and MSI.
Max_Payload_Size size (128 bytes).
It fits into Linux PCI Bus framework to provide PCI compatible software enumeration support.
In addition, it provides interface to Endpoint Drivers to access the respective devices detected downstream.
The same interface can be used by the PCI Express Port Bus Driver framework in Linux OS to handle AER, ASP, and so on.
Interrupt handling facility for EP drivers either as Legacy Interrupts (INTx). RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Access to EP I/O BARs through generic I/O accessories in Linux PCI subsystem.
Seamless handling of PCIe errors.
Supports the L0, L0s, L1, and L1.1 ASPM power management.

4.8.5 Linux OS PCI Subsystem and RC driver

architecture-specific Linux OS implementation, Host Controller (RC) Module, and Core.

PCI BIOS Architecture-specific Linux OS implementation to kick off PCI bus initialization. It interfaces with PCI Host Controller code as well as the PCI Core to perform bus enumeration and allocation of resources such as memory and interrupts. The successful completion of BIOS execution assures that all the PCI devices in the system are assigned parts of available PCI resources and their respective drivers (referred as Slave Drivers). PCI can take control of them using the facilities provided by PCI Core. It is possible to skip resource allocation (if they were assigned before Linux OS was booted, for example PC scenario).
Host Controller (RC) Module handles hardware (SoC + Board) specific initialization and configuration and it invokes PCI BIOS. It should provide callback functions for BIOS as well as PCI Core, which will be called during PCI system initialization and accessing PCI bus for configuration cycles. It provides resources information for available memory/IO space, INTx interrupt lines, MSI. It should also facilitate IO space access (as supported) through in _x_ () out _x_ () You may need to provide indirect memory access (if supported by h/w) through read _x_ () write _x_ ().
Core creates and initializes the data structure tree for bus devices as well as bridges in the system, handles bus/device numberings, creates device entries and proc/sysfs information, provides services for BIOS and slave drivers and provides hot plug support (optional/as supported by h/w). It targets (EP) driver interface query and initializes corresponding devices found during enumeration. It also provides MSI interrupt handling framework and PCI express port bus support. It provides Hot-Plug support (if supported), advanced error reporting support, power management event support, and virtual Channel support to run on PCI express ports (if supported).

4.8.6 PCIe Driver Source Files

Table 45. Source Files

4.8.7 System Resource: Memory Layout

NXP Semiconductors RM00293 i.MX Linux Reference Manual – PCIe device configuration space: 0x1ff0_0000 – 0x1ff7_ffff (512K bytes) – PCIe IO space: 0x1ff8_0000 – 0x1ff8_ffff (64K bytes) – PCIe memory space: 0x1800_0000 – 0x1fef_ffff (127M bytes)

PCIE1 – PCIe host configuration space: 0x33c0_0000 – 0x33ff_ffff (4Mbytes) – PCIe device configuration space: 0x27f0_0000 – 0x27f7_ffff (512K bytes) – PCIe IO space: 0x27f8_0000 – 0x27f8_ffff (64K bytes) – PCIe memory space: 0x2000_0000 – 0x27ef_ffff (127M bytes)

4.8.8 System Resource: Interrupt lines

i.MX Root Complex driver uses interrupt line 152 for MSI INT on i.MX 6 platforms, and 154 for MSI INT on i.MX 7Dual platforms.

4.9 USB

4.9.1 Introduction

The universal serial bus (USB) driver implements a standard Linux driver interface to the CHIPIDEA USB-HS OTG controller. The USB provides a universal link that can be used across a wide range of PC-to-peripheral interconnects. It supports plug-and-play, port expansion, and any new USB peripheral that uses the same type of port. The CHIPIDEA USB controller is Enhanced Host Controller Interface (EHCI)-compliant. This USB driver has the following features:

High-speed OTG core supported
High-speed Host Only core (Host1), high-speed, full speed, and low devices are supported
High-speed Inter-Chip core (Host2 & Host3)
High-speed Host Only core (OTG2), high-speed, full speed, and low devices are supported. A USB2Pci bridge is connected to OTG2 by default. Therefore, users may not be able to connect other USB devices on this port.
High-speed Inter-Chip core (Host2)
Host mode-Supports HID (Human Interface Devices), MSC (Mass Storage Class)
Peripheral mode-Supports MSC, and CDC (Communication Devices Class) drivers, which include Ethernet and serial support
Embedded DMA controller

4.9.2 Architectural Overview

The USB host system is composed of a number of hardware and software layers. The figure below shows a conceptual block diagram of the building block layers in a host system that support USB 2.0. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Figure 19. USB Block Diagram

4.9.3 Hardware Operation

For information on hardware operations, refer to the EHCI spec.ehci-r10.pdf.

4.9.4 Software Operation

4.9.5 Source Code Structure

The table below describes the USB source in drivers/usb. Table 46. Chipidea USB Driver Files RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 46. Chipidea USB Driver Files...continued

4.9.6 Menu Configuration Options

CONFIG_USB - Build support for Host-side USB
CONFIG_USB_EHCI_HCD EHCI HCD (USB 2.0) support
CONFIG_USB_CHIPIDEA - ChipIdea high-speed Dual Role Controller
CONFIG_USB_CHIPIDEA_UDC - ChipIdea device controller
CONFIG_USB_CHIPIDEA_HOST - ChipIdea host controller
CONFIG_USB_GADGET - USB Gadget Support
CONFIG_USB_MXS_PHY - Freescale MXS USB PHY support
CONFIG_NOP_USB_XCEIV - NOP USB Transceiver Driver

4.9.7 USB Wakeup Usage

The following example is for the OTG port and the first EHCI device. Controller wakeup setting, after the following settings, the VBUS and ID will be wakeup source. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual EHCI wakeup setting, after the following settings, the host will have wakeup ability, such as remote wakeup and connect/disconnect wakeup echo enabled > /sys/bus/usb/devices/usb1/power/wakeup echo enabled > /sys/bus/usb/devices/1-1/power/wakeup Note: When the OTG mode switches from the host to the device, it will delete the EHCI wakeup, and the user needs to set it again before the system suspending.

4.9.8 How to Close the USB Child Device Power

The following code string outlines how to close the USB child device power: echo auto > /sys/bus/usb/devices/1-1/power/control echo auto > /sys/bus/usb/devices/1-1.1/power/control (If there is a hub at USB device)

4.9.9 Changing the Controller Operation Mode

To change the default settings, the use can modify the DTS file as follows: dr_mode = "host" /* Set dr_mode = "host" /* Set controller as host only mode dr_mode = "peripheral" /* Set controller as peripheral only mode*/ dr_mode = "otg" /* Set controller as dual role mode */ as gadget-only mode */ dr_mode = "peripheral" /* Set controller as host-only mode */ dr_mode = "otg" /* Set controller as otg mode */

4.9.10 Loadable Module Support

The modprobe utility will automatically load the modules which have dependency among all modules. The loading command is as follows: modprobe phy-generic modprobe phy_mxs_usb modprobe ci_hdrc_imx The unloading command is as follows: modprobe -r ci_hdrc_imx modprobe -r phy_mxs_usb modprobe -r phy-generic

4.9.11 USB Charger Detection

i.MX SoC has USB charger detection ability, but it has no charging ability. The user can use the /sys entry to know the USB charger type, charging current, and whether the charger exists, as shown in the following three lines: cat /sys/class/power_supply/imx6_usb_charger/type cat /sys/class/power_supply/imx6_usb_charger/current_max RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual cat /sys/class/power_supply/imx6_usb_charger/present Currently, the i.MX 6 Sabre-SD board does not support the USB charger detection function. i.MX 6 Sabre-Auto supports the function.

4.9.12 Embeded Host Certification

4.9.12.1 Adding TPL-Support Property

To pass embeded host USB certification, "tpl-support" should be added in DTS to enable Targeted Peripheral List (TPL). For example, to enable TPL on the Host port of i.MX 6UltraLite EVK board (imx6ul-14x14-evk.dts): &usbotg2 { dr_mode = "host"; disable-over-current; tpl-support; status = "okay";

4.9.12.2 VBUS Control

The VBUS should be kept off until the Linux USB host function is ready. For example, on the i.MX 6UltraLite EVK board, because the pin is multiplexed with the touch function, you need to rework the board to make the GPIO (GPIO1_IO02) selected for VBUScontrol. Disable the touch function in its DTS file (imx6ul-14x14-evk.dts) as follows: &tsc { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_tsc>; xnur-gpio = <&gpio1 3 0>; measure_delay_time = <0xffff>; pre_charge_time = <0xfff>; status = "disabled"; Add VBUS GPIO pinctrl and its regulator node: pinctrl_usb_otg2: usbotg2grp { fsl,pins = < MX6UL_PAD_GPIO1_IO02__GPIO1_IO02 0xb0 reg_usb_otg2_vbus: regulator@2 { compatible = "regulator-fixed"; reg = <2>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usb_otg2>; regulator-name = "usb_otg2_vbus"; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; gpio = <&gpio1 2 GPIO_ACTIVE_HIGH>; enable-active-high; &usbotg2 { vbus-supply = <&reg_usb_otg2_vbus>; dr_mode = "host"; RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

4.10 USB3

4.10.1 Introduction

The supported features the following.

Host mode is implemented with a Linux OS standard XHCI driver with super-speed supported and tested.
For Device Mode only single queue is supported. Mass storage, ether, and serial are supported.

4.10.2 Source Code Structure

Table 47. CDNS3 USB3 Driver Source Files Table 48. DWC3 USB3 Driver Source Files RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 48. DWC3 USB3 Driver Source Files...continued

4.11 Low Power Universal Asynchronous Receiver/Transmitter (LPUART)

4.11.1 Introduction

The low-level UART driver interfaces the Linux serial driver API to all the UART ports.

Interrupt-driven and eDMA-driven transmit/receive of characters
Standard Linux baud rates up to 4 Mbps
Transmit and receive characters with 7-bit, 8-bit, 9-bit, or 10-bit character length
Transmits one or two stop bits
Supports TIOCMGET IOCTL to read the modem control lines. Only supports the constants TIOCM_CTS and TIOCM_CAR, plus TIOCM_RI in DTE mode only
Supports TIOCMSET IOCTL to set the modem control lines. Supports the constants TIOCM_RTS and TIOCM_DTR only
Odd and even parity
XON/XOFF software flow control. Serial communication using software flow control is reliable when communication speeds are not too high and the probability of buffer overruns is minimal
CTS/RTS hardware flow control-both interrupt-driven software-controlled hardware flow and hardware-driven hardware-controlled flow
Send and receive break characters through the standard Linux serial API
Recognizes frame and parity errors
Ability to ignore characters with break, parity and frame errors
Get and set UART port information through the TIOCGSSERIAL and TIOCSSERIAL TTY IOCTL. Some programs like setserial and dip use this feature to make sure that the baud rate was set properly and to get general information on the device. The UART type should be set to 52 as defined in the serial_core.h header file.
Power management feature by suspending and resuming the UART ports
Standard TTY layer IOCTL calls All the UART ports can be accessed from the device files /dev/ttyLP0 to /dev/ttyLP1.

4.11.2 Hardware Operation

Each UART hardware port is capable of standard RS-232 serial communication. programmed threshold level and when there is a change in state in the modem signals. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

4.11.3 Software Operation

UART drivers for various platforms. for handling the various interrupts for the UART ports, and providing console support if necessary. Each UART can be configured to use DMA for the data transfer by enabling the DMA channel in the DTS file. driver copies the data from the DMA receive buffer to the TTY Flip Buffer. serial driver in the kernel source tree.

4.11.4 Driver Features

Baud rates up to 4 Mbps
Recognizes frame and parity errors
Recognizes the modem control signals
Ignores characters with frame, parity, and break errors if requested to do so
Implements support for hardware flow control
Get and set the UART port information; certain flow control count information is not available in hardware- driven hardware flow control mode
Power management
Interrupt-driven and DMA-driven data transfer

4.11.5 Source Code Structure

Table below shows the UART driver source files. Table 49. UART Driver Files

4.11.6 Menu Configuration Options

NXP Semiconductors RM00293 i.MX Linux Reference Manual

4.11.7 Programming Interface

The UART driver implements all the methods required by the Linux serial API to interface with the UART port and provides a set of control methods to the Linux core UART driver. For more information about the methods implemented in the driver, see the API document.

4.11.8 Interrupt Requirements

The UART driver interface generates only one interrupt. The status is used to determine which kinds of interrupt occurs, such as RX or TX.

4.12 Bluetooth

4.12.1 Bluetooth Wireless Technology Introduction

Bluetooth technology is low-cost, low-power, short-range wireless technology. It was designed as a replacement for cables and other short-range technologies like IrDA. Bluetooth wireless technology operates in personal area range that typically extends up to 10 meters. For more information about Bluetooth wireless technology, see www.bluetooth.com/. For i.MX, Bluetooth is supported with multiple vendors. For details, see the Section "Connectivity for Bluetooth wireless technology and Wi-Fi" in the i.MX Linux User's Guide (UG10163).

4.12.2 Bluetooth Driver Overview

i.MX uses the open source NXP Bluetooth driver. The Bluetooth software is divided into four parts as follows:

4-wire UART and TTY driver: It is the communication interface with the Bluetooth module.
Bluetooth HCI device driver: NXP Bluetooth driver based on serdev driver for the NXP BT serial protocol based on running H:4. It is used for communication between Bluetooth device and host.
Bluetooth kernel stack: Bluetooth framework and protocols implementation.
Bluetooth user stack: Supplies several user-space utilities and integrate many profiles for use cases.

4.12.3 Bluetooth Driver Files

The Bluetooth driver source files are available in the kernel source directory.

Bluetooth HCI device driver: – drivers/bluetooth/btnxpuart.c
Bluetooth kernel stack: – net/bluetooth/*

4.12.4 Bluetooth Stack

BlueZ is the official Linux standard Bluetooth protocol stack, it is the latest version of 5.x and it is a Bluetooth stack for Linux kernel-based family of operating systems. Its goal is to program an implementation of the Bluetooth wireless standards specifications for Linux. To use Linux Bluetooth subsystem, you need several user-space utilities like hciconfig and bluetoothd. These utilities and updates to Bluetooth kernel modules are provided in the BlueZ packages. For more information, see www.bluez.org/. BlueZ source code are available in the git: git://git.kernel.org/pub/scm/bluetooth/bluez.git. The current BSP package tests pass with BlueZ 5.79. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

4.12.5 Menu Configuration Options

The following Linux kernel configuration option is provided for this module:

UART interface: – CONFIG_SERIAL_FSL_LPUART – CONFIG_SERIAL_IMX – CONFIG_TTY
HCI interface: – CONFIG_BT_HCIUART – CONFIG_BT_NXPUART
Bluetooth Stack: – CONFIG_BT – CONFIG_BT_RFCOMM – CONFIG_BT_RFCOMM_TTY – CONFIG_BT_BNEP – CONFIG_BT_BNEP_MC_FILTER – CONFIG_BT_BNEP_PROTO_FILTER – CONFIG_BT_HIDP

4.13 ENETC

4.13.1 Introduction

The NIC functionality in NETC is known as EtherNET Controller (ENETC). ENETC supports virtualization/ isolation based on PCIe Single Root IO Virtualization (SR-IOV), advanced QoS with 8 traffic classes and 4 drop resilience levels, and a full range of TSN standards and NIC offload capabilities. For more details, see Section "NET Controller (NETC) Domain" in the i.MX Applications Processor Reference Manual for i.MX 95 and i.MX 943.

4.13.2 Software Operation

The ENETC PF driver supports the following features:

10 Mbps, 100 Mbps, 1 Gbps, 2.5 Gbps, and 10 Gbps port speeds: Full range of standard 802.3 Ethernet speeds.
Half-duplex support at 10 Mbps and 100 Mbps speeds.
EEE support: Energy Efficient Ethernet.
Pause support: Recognizes and generates PAUSE frames with timing support for both receive and transmit.
One-step and two-step timestamping support for PTP/IEEE1588/IEEE802.1AS-2020.
Comprehensive statistics support enables system management and debugging.
MAC and VLAN filtering: Filtering for multiple MAC addresses and VLANs.
Virtualization: Hardware-supported isolation/virtualization through SR-IOV.
Transmits and receives buffer descriptor rings to transfer packets to and from the host.
XDP support (Both XDP copy mode and zero copy mode).
Receives Side Scaling (RSS): Load balancing across multiple receive descriptor rings (multiple cores) implemented within an SI.
Large Send Offload (LSO): Segmenting large TCP/UDP transmit units into multiple Ethernet frames.
Receive Segment Coalesce (RSC): Coalescing multiple receive TCP segments into a single frame.
VLAN tag extraction/insertion: Inserts predetermined tag on TX and removes expected tag on RX as seen by the SI. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

SI-Based VLAN: Removal and addition of SI-based VLAN.
Checksum offload: IP and TCP/UDP checksum offload for transmit.
Interrupt coalescing control: Interrupt coalescing can be set for each interrupt source.
Time Specific Departure (TSD): Enables to specify the time when a frame is to be transmitted.
TSN capabilities: Full range of TSN standards. – 802.1Qav: Credit-Based Shaper (CBS) support – 802.1Qci: Per Stream Filtering and Policing (PSFP) support – 802.1Qbv: Enhancements for Scheduled Traffic (EST) support – 802.1Qbu: Preemption support
Wake-on-LAN (WOL) support.
System suspend/resume support. The ENETC VF driver supports the following features:
Two-step timestamping support for PTP/IEEE1588/IEEE802.1AS-2020.
MAC and VLAN filtering: Filtering for multiple MAC addresses and VLANs.
Transmits and receives buffer descriptor rings to transfer packets to and from the host.
XDP support (Both XDP copy mode and zero copy mode).
Receive Side Scaling (RSS): Load balancing across multiple receive descriptor rings (multiple cores) implemented within an SI.
Large Send Offload (LSO): Segmenting large TCP/UDP transmit units into multiple Ethernet frames.
Receive Segment Coalesce (RSC): Coalescing multiple receive TCP segments into a single frame.
VLAN tag extraction/insertion: Inserts predetermined tag on TX and removes expected tag on RX as seen by the SI.
SI-Based VLAN: Removal and addition of SI-based VLAN.
Checksum offload: IP and TCP/UDP checksum offload for transmit.
Interrupt coalescing control: Interrupt coalescing can be set for each interrupt source.

4.13.3 Source Code Structure

The table below shows the source files. Table 50. ENETC source

4.13.4 Menu Configuration Options

CONFIG_ NXP_NETC_BLK_CTRL: Build support for NETCMIX, IERB, and PRB, which provides pre- configuration for ENETC. In menuconfig, this option is available under Device Drivers -> Network device support -> Ethernet driver support -> Freescale devices -> NETC blocks control driver.
CONFIG_ FSL_ENETC_MDIO: Build support for EMDIO driver, which provides MDIO bus to manage the external PHYs. In menuconfig, this option is available under Device Drivers -> Network device support -> Ethernet driver support -> Freescale devices -> ENETC MDIO driver. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

CONFIG_PTP_1588_CLOCK_NETC: Build support for NETC 1588 Timer driver. This module is needed if the ENETC driver wants to support PTP synchronization. In menuconfig, this option is available under Device Drivers -> PTP clock support -> NXP NETC Timer as PTP clock.
CONFIG_FSL_ENETC4: Build support for ENETC PF driver. In menuconfig, this option is available under Device Drivers -> Network device support -> Ethernet driver support -> Freescale devices -> ENETC4 PF driver.
CONFIG_FSL_ENETC_VF: Build support for ENETC VF driver. In menuconfig, this option is available under Device Drivers -> Network device support -> Ethernet driver support -> Freescale devices -> ENETC VF driver.

4.14 ENETC 1588 Timer

4.14.1 Introduction

Controller (NETC) Domain" in the i.MX Applications Processor Reference Manual for i.MX 95 and i.MX 943.

4.14.2 Software Operation

PTP synchronization supports for ENETC and NETC Switch.
PPS support.
Generates pulses at a specific future time.
External Trigger Timestamping support (EXTTS) support.

4.14.3 Source Code Structure

The table below shows the source files. Table 51. ENETC 1588 Timer source

4.14.4 Menu Configuration Options

available under Device Drivers -> PTP clock support -> NXP NETC Timer as PTP clock.

4.15 ENETC Switch

4.15.1 Introduction

(NETC) Domain" in the i.MX Applications Processor Reference Manual for i.MX 95 and i.MX 943.

4.15.2 Software Operation

Single port mode and bridge mode.
FDB and VLAN filtering support.
NXP switch tag support.
10 Mbps, 100 Mbps, 1 Gbps, and 2.5 Gbps port speeds: Full range of standard 802.3 Ethernet speeds.
Half-duplex support at 10 Mbps and 100 Mbps speeds: Enables use of various low power PHYs.
EEE support: Energy Efficient Ethernet.
Pause support: Recognizes and generates PAUSE frames with timing support for both receive and transmit.
One-step and two-step timestamping support for PTP/IEEE1588/IEEE802.1AS-2020 – One-step: Updates PTP Correction field based on the current time and passed in timestamp value. – Two-step: Captures and reports the time of SFD.
Comprehensive statistics support enables system management and debugging.
TSN capabilities: Full range of TSN standards. – 802.1Qav: Credit-Based Shaper (CBS) support. – 802.1Qci: Per Stream Filtering and Policing (PSFP) support. – 802.1Qbv: Enhancements for Scheduled Traffic (EST) support. – 802.1Qbu: Preemption support.
Flow actions support, such as TRAP, REDIRECT, and POLICE.

4.15.3 Source Code Structure

The table below shows the source files. Table 52. ENETC Switch source

4.15.4 Menu Configuration Options

CONFIG_ NXP_NETC_BLK_CTRL: Build support for NETCMIX, IERB, and PRB, which provides pre- configuration for switch. In menuconfig, this option is available under Device Drivers -> Network device support -> Ethernet driver support -> Freescale devices -> NETC blocks control driver.
CONFIG_ FSL_ENETC_MDIO: Build support for EMDIO driver, which provides MDIO bus to manage the external PHYs. In menuconfig, this option is available under Device Drivers -> Network device support -> Ethernet driver support -> Freescale devices -> ENETC MDIO driver. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

CONFIG_PTP_1588_CLOCK_NETC: Build support for NETC 1588 Timer driver. This module is needed if the ENETC driver wants to support PTP synchronization. In menuconfig, this option is available under Device Drivers -> PTP clock support -> NXP NETC Timer as PTP clock.
CONFIG_NET_DSA_TAG_NETC: Build support for NETC Switch tag driver. In menuconfig, this option is available under Networking support -> Networking options -> Distributed Switch Architecture -> Tag driver for NXP NETC switches.
CONFIG_ NET_DSA_NETC_SWITCH: Build support for NETC Switch driver. In menuconfig, this option is available under Device Drivers -> Network device support -> Distributed Switch Architecture drivers -> NXP NETC Ethernet switch support.

4.16 Ethernet Controller with TSN (ENET_QoS, EQoS)

4.16.1 Introduction

flexible receive parser, media clock recovery and generation, and safety. managing the transmit and receive functions, descriptor handling, and interrupt handling. Figure 20. EQoS-TSN module RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

4.16.2 Software Operation

RMII (10/100 Mbps), RGMII (10/100/1000 Mbps)
Time aware shaper (IEEE802.1Qbv), Time synchronization (IEEE1588-2008), and Frame pre-emption (IEEE802.1Qbu) for Time-Sensitive Networking (TSN)
Media clock recovery and generation for AVB
Full-duplex flow control operations (IEEE 802.3x pause packet and priority flow control)
Flexibility to control the Pulse per second (PPS) output signal
MDIO (clause 22 and Clause 45) interface for configuration and management of PHY device
VLAN insertion, replacement, and deletion in transmitted packets

4.16.3 Source Code Structure

The table below shows the source files. drivers/net/ethernet/stmicro/stmmac/stmmac_*.c The common logic part driven by different versions of EQoS. various versions of hardware for a shared API. Table 53. EQoS source

4.16.4 Menu Configuration Options

For the EQoS controller on the i.MX platform, it is controlled by CONFIG_STMMAC_ETH. upstream, this CONFIG is built as a module by default. This may affect the NFS boot.

4.17 Wi-Fi

4.17.1 Introduction

Fi" in the i.MX Linux User's Guide (UG10163).

4.17.2 Software Operation

The NXP Wi-Fi driver module is supported on all i.MX chipsets available in the Linux BSP, starting from BSP release.

4.17.3 Driver features

NXP Semiconductors RM00293 i.MX Linux Reference Manual The NXP Wi-Fi SoCs require a firmware image to be loaded on power-up/reset. The firmware images for the supported Wi-Fi SoCs are located in the following rootfs directory: /lib/firmware/nxp.

4.17.4 Source Code Structure

The NXP Onedriver source code files are available at github.com/nxp-imx.

4.17.5 Menu Configuration Options

The following Linux kernel configuration option is provided for this module:

CONFIG_MAC80211=y
COCONFIG_NL80211_TESTMODE=y
CONFIG_CFG80211_WEXT=y
CONFIG_HOSTAP=y
CONFIG_CFG80211_INTERNAL_REGDB=y

4.17.6 Configuring WLAN from User Space

4.17.6.1 Connecting AP in Station Mode

The following command group is used to connect WLAN to a given SSID. modprobe moal mod_para=nxp/wifi_mod_para.conf head -n 4 /etc/wpa_supplicant.conf > /etc/wpa_supplicant.conf.tmp wpa_passphrase ssid password >> /etc/wpa_supplicant.conf.tmp mv /etc/wpa_supplicant.conf /etc/wpa_supplicant.conf.bak mv /etc/wpa_supplicant.conf.tmp /etc/wpa_supplicant.conf wpa_supplicant -B -i mlan0 -c /etc/wpa_supplicant.conf -D nl80211 Here is an example of wpa_supplicant.conf: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 update_config=1 network={ ssid="NETGEAR73" #psk="freshbutter" psk=eb0376fc14ee5d1e6ce129ad54da038adab……

4.17.6.2 Obtaining an IP address

The following command is used to get an IP address for wlan0: udhcpc -i mlan0

4.18 Low Power Serial Peripheral Interface (LPSPI) Driver

4.18.1 Introduction

LPSPI provides an efficient interface (either as a controller or peripheral) to an SPI bus, which is a synchronous serial communication interface used in embedded systems. It is typically used to perform short distance RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

include interfacing with secure digital cards and LCD displays.

4.18.2 Driver Features

SPI communication protocol
SPI master mode and slave mode of operation

4.18.3 Source Code Structure

The table below shows the source files. Table 54. LPSPI source

4.18.4 Menu Configuration Options

5 Graphics

5.1 Graphics Processing Unit (GPU)

5.1.1 Introduction

module source is in the kernel source tree, but the libraries are delivered as binary only. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Graphics Processing Unit Hardware Applicable Platform 3D Vivante GC7000 Nano Ultra 7ULP and 8M Mini 3D Vivante GC7000 UltraLite 8M Plus 3D Vivante GC7000 Ultra Lite 8M Nano 3D Vivante GC2000 6Quad/6Dual 3D Vivante GC2000+ 6QuadPlus/6DualPlus 3D Vivante GC880 6DualLite/6Solo 3D/2D Vivante GC400T 6SoloX 2D Vivante GC320 6Quad/6Dual/6DualLite/6Solo Vector Vivante GC355 6Quad/6Dual 2D Vivante GC328 7ULP Note:

GC400T does not support OpenGL ES 3.0.
GC880/GC400T does not support OpenCL 1.1EP. GC2000 and GC2000+ support OpenCL 1.1 EP.

5.1.2 Driver Features

The GPU driver enables this board to provide the following software and hardware support:

EGL (EGL is an interface between Khronos rendering APIs such as OpenGL ES or OpenVG and the underlying native platform window system) 1.5 API defined by Khronos Group.
OpenGL ES (OpenGL ES is a royalty-free, cross-platform API for full-function 2D and 3D graphics on embedded systems) 1.1 API defined by Khronos Group.
OpenGL ES 2.0 API defined by Khronos Group.
OpenGL ES 3.0/3.1/3.2 API defined by Khronos Group.
OpenVG (OpenVG is a royalty-free, cross-platform API that provides a low-level hardware acceleration interface for vector graphics libraries such as Flash and SVG) 1.1 API defined by Khronos Group.
OpenCL (OpenCL is the first open, royalty-free standard for cross-platform, parallel programming of modern processors.) 1.1 EP API defined by Khronos Group.
OpenGL 2.1 API defined by Khronos Group.
Automatic 3D core slowing down, when hot notification from thermal driver is active, 3D core will run at 1/64 clock.
OpenCL1.1/1.2FP API defined by Khronos Group.
OpenVX 1.0.1 API defined by Khronos Group.
Vulkan 1.0 API defined by Khronos Group.

5.1.3 Hardware Operation

For detailed hardware operations, see the GPU chapters in the Applications Processor Reference Manual specific to SoC.

5.1.4 Software Operation

The GPU driver is divided into two layers. The first layer is running in kernel mode and acts as the base driver for the whole stack. This layer provides the essential hardware access, device management, memory RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

OpenGL ES 1.1, 2.0, and 3.0 API
EGL 1.5 API
OpenGL ES11/20/30/31/32
OpenCL 1.1/1.2 FP
OpenVX 1.0.1
Vulkan 1.0
OpenGL 4.0
WebGL 1.0.2
OpenVG 1.1 API
OpenCL 1.1 EP API

5.1.5 Source Code Structure

Table 55. GPU Driver Files If you replace the whole content in this directory, the GPU kernel driver can be upgraded.

5.1.6 Library Structure

libVDK.so VDK wrapper library. libVIVANTE.so Vivante user mode driver. xorg/modules/drivers/vivante_drv.so EXA library for X11 acceleration. Table 56. GPU Library Files ...continued

If no SOC limitation, for the x11 backend, libOpenVG.3d.so is linked by default.
If no SOC limitation, for framebuffer, directFB, and Wayland backends, the default openVG library is linked to libOpenVG.2d.so. This can be done by using the following sequence of commands: cd <ROOTFS>/usr/lib sudo ln -s libOpenVG_355.so libOpenVG.so

5.1.7 API References

OpenCL 1.1 EP www.khronos.org/opencl/
EGL 1.4 API: www.khronos.org/egl/
OpenVG 1.1 API: www.khronos.org/openvg/ RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

OpenGL ES API: www.khronos.org/opengles/
OpenCL API: www.khronos.org/opencl/
OpenVX API: www.khronos.org/openvx/
Vulkan API: www.khronos.org/vulkan/
OpenGL API: www.khronos.org/opengl/
WebGL API: www.khronos.org/webgl/

5.1.8 Menu Configuration Options

In menu configuration enable the following module for the GPU driver: CONFIG_MXC_GPU_VIV is a configuration option for GPU driver. In the menuconfig this option is available under Device Drivers > MXC support drivers > MXC Vivante GPU support > MXC Vivante GPU support. On the screen displayed, select Configure the kernel, select Device Drivers > MXC support drivers > MXC Vivante GPU support > MXC Vivante GPU support, and then exit. When the next screen appears, select the following options to enable the GPU driver:

Package list > imx-gpu-viv
This package provides proprietary binary libraries, and test code built from the GPU for framebuffer

5.2 Wayland

5.2.1 Introduction

Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a Wayland client itself. The clients can be traditional applications, X servers or other display servers. Part of the Wayland project is also the Weston reference implementation of a Wayland compositor. The Weston compositor is a minimal and fast compositor and is suitable for many embedded and mobile use cases. This chapter describes how to enable Wayland/Weston support on an i.MX series device.

5.2.2 Software Operation

and i.MX 7.

5.2.3 Yocto Build Instructions

The instructions for Yocto Project build are as follows: 1. Prepare a Yocto build directory and follow the setup instructions in the i.MX Yocto Project User's Guide (IMXLXYOCTOUG) for DISTRO Wayland. 2. Set up Yocto for Wayland in the build directory: $ MACHINE = <your-machine> DISTRO=fsl-imx-xwayland source imx-setup- release.sh -b build-wayland 3. Build an image. $ bitbake imx-image-full RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

5.2.4 Customizing Weston

The i.MX Weston includes two compositors. One is the EGL3D compositor, which is accelerated by the 3D core. The other is G2D compositor accelerated by the 2D BLT engines. Weston options can be updated in the file “/etc/init.d/weston”. use-gl EGL accelerated, defaults to be “1”. use-g2d G2D accelerated, defaults to be “0”. idle-time Idle time in seconds. Table 57. Common options for Weston

5.2.4.1 Multi display supported in Weston

5.2.4.2 Multi buffer supported in Weston

default, the Weston server starts with single buffering. flip, but the frame rate will be restricted to the display rate. A maximum of three buffers are supported. Before starting the Weston server, export FB_MULTI_BUFFER to control the number of buffers to be used.

5.2.5 Running Weston

To run clients, the second button in the top bar will run weston-terminal, from which you can run clients.

'weston-terminal' is a simple terminal emulator, not very compliant, but works well enough for bash.
'weston-flower' draws a flower on the screen, testing the frame protocol.
'weston-smoke' tests SHM buffer sharing. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

'weston-image' loads the image files passed on the command line and shows them.

6 Video

6.1 Capture Overview

6.1.1 Introduction

The i.MX capture driver support is through the V4L2 interface with camera sensor controllers and interfaces. starting the camera preview.

6.1.2 Capture Controllers and Interfaces

Camera Serial Interface - CSI
IPU-CSI
Video Interface Unit - VIU
Image Sensor Interface - ISI
Image Sensor Processing - ISP The list of capture interfaces for transfering image data are as follows:
Parallel-CSI
MIPI-CSI2
HDMI RX
TV Decoder This chapter describes the differences between the various controllers and interfaces. Note: The i.MX 6 with IPU uses internaldev for V4L2 interface while all others use subdev for V4L2 interface. The following table describes the different controllers and interfaces combinations. SoC Controller Interface 6SLL CSI Parallel CSI. 6SoloX VIU Parallel CSI and TV Decoder. 6UltraLite/6ULL CSI Parallel CSI. 6DualLite/Solo IPU-CSI Parallel CSI internaldev IPU. 6QuadPlus/Quad/Dual IPU-CSI Parallel CSI internaldev IPU. 7Dual/Solo CSI MIPI-CSI2 using Samsung and Parallel CSI. 8M Plus/8M Nano ISI MIPI-CSI2 using Samsung. 8M Plus ISP MIPI-CSI2 using Samsung. 8QuadMax ISI MIPI-CSI2 using Mixel and HDMI Receiver using Cadence. 8QuadXPlus ISI MIPI-CSI2 using Mixel and Parallel CSI using i.MX 8. 8M Quad CSI MIPI-CSI2 using Mixel.

8M Mini CSI MIPI-CSI2 using Samsung. 8ULP ISI MIPI-CSI2 using Mixel. i.MX 95 ISI and NEO ISP MIPI-CSI2 using Synopsys. Table 58. Camera Controllers and Interfaces...continued

The NEO ISP is a new controller used for the i.MX 95.
The ISP is a new controller used for the i.MX 8M Plus.
The ISI controller is a new controller used for some of the i.MX 8 series.
The i.MX 6 SoC without IPU, i.MX 7Dual and i.MX 8M use the same CSI controller driver.
The i.MX 8 and i.MX 8X families use a newer i.MX 8 CSI driver.
The i.MX 6 with IPU use a customized CSI that interfaces with IPU hardware.
Each SoC can support one or more interfaces as described in the previous table. The interfaces align with Video for Linux V4L2 APIs.
In some cases the capture controller is not interfacing to a camera but a video input unit. Some also connect to HDMI Receivers or TV Decoders.

6.1.2.1 IPUv3

Parallel CSI with 2 Ports, 20 bits+ 8 bits
Playback 1080i/p + D1@30fps @ 30fps
Record 1080p @ 30fps
2-way 720@30fps
De-interlacing high quality motion adaptive algorithm
Resizing - fully flexible
Rotation/inversion support
Color conversion - fully flexible
Memory interface - AXI split transaction 64-bit 266 MHz
Memory bus - selective read for combining
Control capabilities - display and DMA controller, internal synchronization
Synchronization - double/triple buffering, frame-by-frame or tight sub-frame with internal memory For i.MX 6 with IPU kernel configuration, use the following configurations:
Device Drivers -> Multimedia support (MEDIA_SUPPORT=y]) -> Media drivers -> Media platform devices (MEDIA_PLATFORM_DRIVERS [=y]) -> MXC Video For Linux Video Capture (VIDEO_MXC_CAPTURE [=m]) -> MXC Camera/V4L2 PRP Features support -> OmniVision OV5640 camera support (MXC_CAMERA_OV5640_V2 [=m])
Device Drivers -> Multimedia support (MEDIA_SUPPORT [=y]) -> Media drivers -> Media platform devices (MEDIA_PLATFORM_DRIVERS [=y]) -> MXC Video For Linux Video Capture (VIDEO_MXC_CAPTURE [=m]) -> MXC Camera/V4L2 PRP Features support -> OmniVision OV5640 camera support using MIPI (MXC_CAMERA_OV5640_MIPI_V2 [=m]) RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual These are driver files for the IPUv3:

drivers/media/platform/mxc/capture/ipu_bg_overlay_sdc.c
drivers/media/platform/mxc/capture/ipu_csi_enc.c
drivers/media/platform/mxc/capture/ipu_fg_overlay_sdc.c
drivers/media/platform/mxc/capture/ipu_prp_enc.c
drivers/media/platform/mxc/capture/ipu_prp_vf_sdc_bg.c
drivers/media/platform/mxc/capture/ipu_prp_vf_sdc.c
drivers/media/platform/mxc/capture/ipu_still.c
drivers/media/platform/mxc/capture/v4l2-int-device

6.1.2.2 CSI Controllers

MIPI-CSI-2 with 2 ports, 4 lanes x 1.5 Gbps (2.5 Gbps on i.MX 95)
Playback - two 1080p30
Record - 1080p30x2
2-way - 1080p30x2
Deinterlacing - simple bob and weave
Memory interface throughput - 64-bit
Controller capabilities - DMA
Synchronization - double buffer

6.1.2.3 ISI

The Image Sensor Interface (ISI) handles the DMA and image formatting operations for most the i.MX 8 and all of the i.MX 9 SoCs. The ISI uses a pixel link to attach to the capture interfaces. The number and type of capture interfaces depends on the SoC. The ISI has the following common features:

Deinterlacing-simple bob and weave
Resizing
Controller capabilities: DMA
Synchronization: double buffer SoC specific features are as follows: i.MX 8QuadXPlus:
Parallel CSI: one port 24 bits
MIPI-CSI-2 with 1 port, 4 lanes x 1.5 Gbps
Playback: 1080p30x2
Record: 1080p30x2
2-way: 1080p30x2
Memory interface throughput: 128-bit, 400 MHz i.MX 8QuadMax:
MIPI-CSI-2 with 2 ports, 4 lanes x 1.5 Gbps
HDMI Receiver: 1 port HDMI 1.4 4K30
Playback: 4K60x1, 4K30x1, or 1080px30x4
Record: 4K30x1 or 1080px30x4
2-way: 4K30x1 or 1080px30x4
Memory interface throughput - 128-bit, 400 MHz i.MX 8M Plus: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

MIPI-CSI-2 with 2 ports, 4 Lanes x 1.5 Gbps
Supports one source of 4K resolution at 30 fps (24 bpp)
Supports two sources up to 2K resolution at 60 fps (24 bpp) on each channel i.MX 8M Nano
MIPI-CSI-2 with 1 port, 4 Lanes x 1.5 Gbps
Supports one source up to 2K resolution at 60 fps (24 bpp) i.MX 93/91
MIPI-CSI-2 with 1 port, 2 lanes
Supports one source up to 2K resolution at 60 fps (24 bpp) i.MX MX 95
MIPI-CSI-2 with 2 ports, 4 Lanes x 2.5 Gbps
Supports one source of 4K resolution at 60 fps (24 bpp)
Supports two sources up to 2K resolution at 60 fps (24 bpp) on each channel
Supports eight sources up to 2K resolution at 30 fps (24 bpp) on each channel For i.MX 8M Nano, 8ULP, 8QuadXPlus, 8QuadMax, 8DualX, and i.MX 93/91/95, use the following kernel configurations and driver files:
Device Drivers -> Multimedia support (MEDIA_SUPPORT [=y]) -> Media drivers -> Media platform devices (MEDIA_PLATFORM_DRIVERS [=y]) -> i.MX 8 Image Sensor Interface (ISI) driver (VIDEO_IMX8_ISI [=y]) Select: MEDIA_CONTROLLER [=y] && V4L2_FWNODE [=y] && V4L2_MEM2MEM_DEV [=y] && VIDEO_V4L2_SUBDEV_API [=y] && VIDEOBUF2_DMA_CONTIG [=y] – imx8-isi-core.c – imx8-isi-crossbar.c – imx8-isi-gasket.c – imx8-isi-hw.c – imx8-isi-pipe.c – imx8-isi-video.c – imx8-isi-m2m.c
Device Drivers -> Multimedia support (MEDIA_SUPPORT [=y]) -> Media drivers -> Media platform devices (MEDIA_PLATFORM_DRIVERS [=y]) -> NXP i.MX 95 CSI Pixel Formatter Driver (VIDEO_IMX_CSI_FORMATTER [=y]) Select: MEDIA_CONTROLLER [=y] && V4L2_FWNODE [=y] && VIDEO_V4L2_SUBDEV_API [=y] – imx-csi-formatter.c For all the other platforms, use the following kernel configurations and driver files: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

Device Drivers -> Staging drivers (STAGING [=y]) -> Media staging drivers (STAGING_MEDIA [=y]) -> i.MX V4L2 media core driver (VIDEO_IMX_CAPTURE [=y]) -> i.MX 8QXP/QM Camera ISI/MIPI Features support -> i.MX 8 Image Sensor Interface hardware driver (IMX8_ISI_HW [=y]) – imx8-isi-hw.c
Device Drivers -> Staging drivers (STAGING [=y]) -> Media staging drivers (STAGING_MEDIA [=y]) -> i.MX V4L2 media core driver (VIDEO_IMX_CAPTURE [=y]) -> i.MX 8QXP/QM Camera ISI/MIPI Features support -> i.MX 8 Image Sensor Interface Core Driver (IMX8_ISI_CORE [=y]) – imx8-isi-core.c
Device Drivers -> Staging drivers (STAGING [=y]) -> Media staging drivers (STAGING_MEDIA [=y]) -> i.MX V4L2 media core driver (VIDEO_IMX_CAPTURE [=y]) -> i.MX 8QXP/QM Camera ISI/MIPI Features support -> i.MX 8 Image Sensor Interface Capture Device Driver (IMX8_ISI_CAPTURE [=y]) – imx8-isi-cap.c – imx8-isi-fmt.c
Device Drivers -> Staging drivers (STAGING [=y]) -> Media staging drivers (STAGING_MEDIA [=y]) -> i.MX V4L2 media core driver (VIDEO_IMX_CAPTURE [=y]) -> i.MX 8QXP/QM Camera ISI/MIPI Features support -> i.MX 8 Image Sensor Interface Memory to Memory Device Driver (IMX8_ISI_M2M [=y]) – imx8-isi-m2m.c – imx8-isi-fmt.c

6.1.2.4 Parallel CSI Interface

The Parallel CSI interface driver enables a direct connection to external CMOS sensors and CCIR656 video sources. The CSI and sensor drivers are implemented in the Video for Linux Two (V4L2) driver framework consisting of the image capture driver and the video output driver. The driver initializes the CSI interface and configures and operates with the hardware registers for the CSI module. The following features are supported:

Configurable interface logic to support most commonly available CMOS sensors.
Full control of 8-bit/pixel, 10-bit/pixel or 16-bit/pixel data format to 32-bit receive FIFO packing.
128x32 FIFO to store received image pixel data.
Receive FIFO overrun protection mechanism.
Embedded DMA controllers to transfer data from receive FIFO or statistic FIFO through AHB bus.
Support for double buffering two frames in the external memory.
Single interrupt source to interrupt controller from maskable interrupt sources: Start of Frame, End of Frame and so on.
Configurable master clock frequency output to sensor. The V4L2 CSI capture device includes two interfaces: the capture and overlay interfaces. The capture and overlay interface use the CSI embedded DMA controller to implement the function using V4L2 APIs. The following is the data flow of capture and overlay. 1. The camera sends the data to the CSI receive FIFO, through the 8-bit/10-bit data port. 2. The embedded DMA controllers transfer data from the receive FIFO to external memory through the AHB bus. 3. The data is save to user space memory or output to the frame buffer directly. i.MX 6 with IPU use a IPU-CSI driver that interfaces with the IPU directly. i.MX Quad Plus/Quad/Dual have support for two IPU-CSI senaros. i.MX 6 without IPU and i.MX 7Dual/Solo and i.MX 93 9x9 QSB use a separate CSI sensor driver that interfaces directly to the sensor. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

6.1.2.5 MIPI Camera Serial Interface (MIPI CSI)

There are four blocks in the MIPI CSI-2 D-PHY: PHY adaptation layer, packet analyzer, image data interface, and register bank. MIPI CSI-2 is a MIPI-Camera Serial Interface Host Controller with a high-performance serial interconnect bus for mobile applications, which connects camera sensors to the host system. The CSI-2 Host Controller is a digital core that implements all protocol functions defined in the MIPI CSI-2 Specification. In doing so, it provides an interface between the system and the MIPI D-PHY and allows communication with the MIPI CSI-2-compliant Camera Sensor. The MIPI CSI2 driver is used to manage the MIPI D-PHY and lets it work with both MIPI sensor and IPU CSI. MIPI CSI2 driver implements functions as follows:

MIPI CSI-2 low-level interface for managing the MIPI D-PHY register and clock
MIPI CSI-2 common API for communication between MIPI sensor and MIPI D-PHY By calling MIPI common APIs, the MIPI sensor can set certain information about sensor (such as datatype, lanes number, etc.) to MIPI CSI2 driver to configure D-PHY. For the IPU CSI module driver to have the correct configuration, receive appropriate data, and process it correctly, it is necessary for it to receive information about sensor (such as datatype, virtual channel, IPU ID, CSI ID, etc.) from the MIPI CSI2 driver. Functions and operations are listed as follows:
PHY Adaptation Layer handles managing the D-PHY interface including PHY error handling.
Packet Analyzer handles data lane merging if needed, together with header decoding, error detection and correction, frame size error detection and CRC error detection.
Image Date Interface separates CSI-2 packet header information and reorders data according to memory storage format. It also generates timing accurate video synchronization signals. Several error detections are also performed at frame-level and line-level.
Register Bank is accessible through a standard AMBA-APB slave interface and provides access to the CSI-2 Host Controller register for configuration and control. There is also a fully programmable interrupt generator to inform the system upon certain events. The MIPI CSI2 driver for Linux OS has two parts:
MIPI CSI2 driver initialization operation, which initializes mipi_csi2_info struct
MIPI CSI2 common APIs, which exports APIs for the CSI module driver and MIPI sensor driver

6.1.2.6 HDMI Receiver

The HDMI receiver allows capturing video with the Image Sensor Interface (ISI) from the HDMI RX. On i.MX 8QuadMax, the HDMI receiver video interface supports one port up to HDMI 1.4 4K30. i.MX 8 QuadMax uses the following kernel configurations and driver files:

Device Drivers -> Multimedia support (MEDIA_SUPPORT [=y]) -> Media drivers -> Media platform devices (MEDIA_PLATFORM_DRIVERS [=y]) -> Cadence MHDP HDMIRX Controller (VIDEO_MHDP_HDMIRX [=m]) – cdns-hdmirx.c – cdns-hdmirx-hdcp.c – cdns-hdmirx-hw.c – cdns-hdmirx-phy.c – cdns-mhdp-hdmirx.c Execute the following commands on U-Boot to enable the HDMI RX driver: U-Boot > setenv fdt_file imx8qm-mek-hdmi-rx.dtb U-Boot > setenv hdprx_enable yes U-Boot > saveenv RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Create a GStreamer pipline to display the captured video.

6.1.3 Cameras

CSI interfaces. When using MIPI mode, the camera connects to the i.MX chip through the MIPI CSI-2 interface. The following table lists the different i.MX Camera Accessories, supported interfaces, and pixel format. Table 59. i.MX Camera Accessories

6.1.3.1 YUV/RGB Cameras

6.1.3.1.1 OV5640

NXP Semiconductors RM00293 i.MX Linux Reference Manual The next level selections select the driver based on the different interfaces for each SoC. The source files for each driver are as follows.

For i.MX 6 with IPU, select both > MXC Camera/V4L2 PRP Features support and > OmniVision OV5640 camera support (MXC_CAMERA_OV5640). – drivers/media/platform/mxc/capture/ov5640.c
For i.MX 6 without IPU, select > OmniVision OV5640 camera support (MXC_CAMERA_OV5640_V2). – drivers/media/platform/mxc/capture/ov5640_v2.c
For i.MX 7, select > OmniVision OV5640 camera support using MIPI (MXC_CAMERA_OV5640_MIPI_V2). – drivers/media/platform/mxc/capture/ov5640_mipi_v2.c
For i.MX 8, i.MX 8X, and i.MX 8M, select Media ancillary drivers > Camera sensor devices > OmniVision OV5640 sensor support (VIDEO_OV5640). Note: This is the upstream driver version for OV5640. – drivers/media/i2c/ov5640.c The following are examples for creating pipeline manually.
On i.MX 8M Quad with dual OV5640, input size: 640x480, output size: 640x480, output format: YUYV media-ctl -d /dev/media0 -l "'ov5640 1-003c':0 -> 'imx8mq-mipi-csi2 media-ctl -d /dev/media0 -V "'ov5640 1-003c':0 [fmt:YUYV8_1X16/640x480 field:none]" media-ctl -d /dev/media0 -V "'imx8mq-mipi-csi2 30a70000.csi':0 [fmt:YUYV8_1X16/640x480 field:none]" media-ctl -d /dev/media0 -V "'csi':0 [fmt:YUYV8_1X16/640x480 field:none]"; media-ctl -d /dev/media1 -l "'ov5640 0-003c':0 -> 'imx8mq-mipi-csi2 media-ctl -d /dev/media1 -V "'ov5640 0-003c':0 [fmt:YUYV8_1X16/640x480 field:none]" media-ctl -d /dev/media1 -V "'imx8mq-mipi-csi2 30b60000.csi':0 [fmt:YUYV8_1X16/640x480 field:none]" media-ctl -d /dev/media1 -V "'csi':0 [fmt:YUYV8_1X16/640x480 field:none]";
On i.MX 8M Mini, input size: 1920x1080, output size: 1920x1080, output format: YUYV media-ctl -l "'ov5640 2-003c':0 -> 'csis-32e30000.mipi-csi':0 [1]" media-ctl -V "'ov5640 2-003c':0 [fmt:YUYV8_1X16/1920x1080 field:none]" media-ctl -V "'csis-32e30000.mipi-csi':0 [fmt:YUYV8_1X16/1920x1080 field:none]" media-ctl -V "'csi':0 [fmt:YUYV8_1X16/1920x1080 field:none]";
On i.MX 8M Nano, input size: 1920x1080, output size: 1920x1080, out format: UYVY media-ctl -l "'ov5640 2-003c':0 -> 'csis-32e30000.mipi-csi':0 [1]" media-ctl -V "'ov5640 2-003c':0 [fmt: UYVY8_1X16/1920x1080 field:none]" media-ctl -V "'csis-32e30000.mipi-csi':0 [fmt: UYVY8_1X16/1920x1080 field:none]" media-ctl -V "'crossbar':0 [fmt: UYVY8_1X16/1920x1080 field:none]" media-ctl -V "'mxc_isi.0':0 [fmt: UYVY8_1X16/1920x1080 field:none]"
On i.MX 8ULP, input size: 1920x1080, output size: 1920x1080, out format: UYVY media-ctl -l "'ov5640 0-003c':0 -> 'imx8mq-mipi-csi2 2daf0000.csi':0 [1]" media-ctl -V "'ov5640 0-003c':0 [fmt: UYVY8_1X16/1920x1080 field:none]" media-ctl -V "'imx8mq-mipi-csi2 2daf0000.csi':0 [fmt: UYVY8_1X16/1920x1080 field:none]" media-ctl -V "'crossbar':0 [fmt: UYVY8_1X16/1920x1080 field:none]" media-ctl -V "'mxc_isi.0':0 [fmt: UYVY8_1X16/1920x1080 field:none]" RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

6.1.3.1.2 OV10635

The Omnivison OV10635 camera is supported on i.MX 8QuadX/QuadXPlus. The camera is connected through a Maxim MAX9271 Serializer and a Maxim MAX9286 Deserializer. Up to four OV10635 cameras may be connected simultaneously per MIPI CSI2 port.

To select the kernel configuration, Device Drivers > Multimedia support > Media ancillary drivers > Video decoders > Maxim MAX9286 GMSL deserializer support (VIDEO_MAX9286) and Device Drivers > Multimedia support > Media ancillary drivers > Camera sensor devices > IMI RDACM20 camera support (VIDEO_RDACM20). – drivers/media/i2c/max9286.c – drivers/media/i2c/rdacm20.c

6.1.3.1.3 AP1302/AR0144

The Onsemi AR0144 camera is supported on the i.MX 9 family. The AR0144 is a raw camera, but it uses an external ISP, Onsemi AP1302, to process the raw image and provide an sRGB image.

For i.MX 93 and 95, select Media ancillary drivers > Camera sensor devices > ON Semiconductor's Advanced Image Coporcessor AP1302 support (VIDEO_AP1302). – drivers/media/i2c/ap1302.c Support V4L2 controls as follows:
V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE
V4L2_CID_GAMMA
V4L2_CID_CONTRAST
V4L2_CID_BRIGHTNESS
V4L2_CID_SATURATION
V4L2_CID_EXPOSURE
V4L2_CID_EXPOSURE_METERING
V4L2_CID_GAIN
V4L2_CID_ZOOM_ABSOLUTE
V4L2_CID_COLORFX
V4L2_CID_SCENE_MODE
V4L2_CID_POWER_LINE_FREQUENCY
V4L2_CID_LINK_FREQ A firmware named ap1302_ar0144_single_fw.bin is needed. Put it under the /lib/firmware folder. Configure the pipeline manually, for example: 1. YUV color space. a. Set up the link: $ media-ctl -l "'ap1302 2-003c':2->'csidev-4ad30000.csi':0 [1]" $ media-ctl -l "'csidev-4ad30000.csi':1 -> '4ac10000.syscon:formatter@20':0 [1]" b. Set up the formats. $ media-ctl -V "'ap1302 2-003c':2 [fmt: UYVY8_1X16/1920x1080 field:none]" $ media-ctl -V "'csidev-4ad30000.csi':0 [fmt: UYVY8_1X16/1920x1080 field:none]" $ media-ctl -V "'4ac10000.syscon:formatter@20':0 [fmt: UYVY8_1X16/1920x1080 field:none]" $ media-ctl -V "'crossbar':2 [fmt: UYVY8_1X16/1920x1080 field:none]" RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual $ media-ctl -V "'mxc_isi.0':0 [fmt: UYVY8_1X16/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.1':0 [fmt: UYVY8_1X16/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.2':0 [fmt: UYVY8_1X16/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.3':0 [fmt: UYVY8_1X16/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.4':0 [fmt: UYVY8_1X16/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.5':0 [fmt: UYVY8_1X16/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.6':0 [fmt: UYVY8_1X16/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.7':0 [fmt: UYVY8_1X16/1920x1080 field:none]" c. Set the YUV colorspace output (i.MX 93 only supports one). $ media-ctl -V "'mxc_isi.0':1 [fmt: YUV8_1X24/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.1':1 [fmt: YUV8_1X24/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.2':1 [fmt: YUV8_1X24/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.3':1 [fmt: YUV8_1X24/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.4':1 [fmt: YUV8_1X24/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.5':1 [fmt: YUV8_1X24/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.6':1 [fmt: YUV8_1X24/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.7':1 [fmt: YUV8_1X24/1920x1080 field:none]" 2. RGB color space (i.MX 93 only supports one). $ media-ctl -V "'mxc_isi.0':1 [fmt: RGB888_1X24/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.1':1 [fmt: RGB888_1X24/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.2':1 [fmt: RGB888_1X24/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.3':1 [fmt: RGB888_1X24/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.4':1 [fmt: RGB888_1X24/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.5':1 [fmt: RGB888_1X24/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.6':1 [fmt: RGB888_1X24/1920x1080 field:none]" $ media-ctl -V "'mxc_isi.7':1 [fmt: RGB888_1X24/1920x1080 field:none]" 3. Down scaling (resize), 1920x1080 -> 640x480 YUYV output (i.MX 93 only supports one). $ media-ctl -V "'mxc_isi.0':0 [fmt:UYVY8_1X16/1920x1080 field:none compose: (0,0)/640x480]" $ media-ctl -V "'mxc_isi.1':0 [fmt:UYVY8_1X16/1920x1080 field:none compose: (0,0)/640x480]" $ media-ctl -V "'mxc_isi.2':0 [fmt:UYVY8_1X16/1920x1080 field:none compose: (0,0)/640x480]" $ media-ctl -V "'mxc_isi.3':0 [fmt:UYVY8_1X16/1920x1080 field:none compose: (0,0)/640x480]" $ media-ctl -V "'mxc_isi.4':0 [fmt:UYVY8_1X16/1920x1080 field:none compose: (0,0)/640x480]" $ media-ctl -V "'mxc_isi.5':0 [fmt:UYVY8_1X16/1920x1080 field:none compose: (0,0)/640x480]" $ media-ctl -V "'mxc_isi.6':0 [fmt:UYVY8_1X16/1920x1080 field:none compose: (0,0)/640x480]" $ media-ctl -V "'mxc_isi.7':0 [fmt:UYVY8_1X16/1920x1080 field:none compose: (0,0)/640x480]" 4. Stream duplicated (only supported by i.MX 95), eight 1080P streams. If the user does not change the default route table, it does not need to configure the route table. $ gst-launch-1.0 v4l2src device=/dev/video0 ! video/x- raw,width=1920,height=1080,format=YUY2 ! waylandsink window-width=480 window- height=540 & $ gst-launch-1.0 v4l2src device=/dev/video1 ! video/x- raw,width=1920,height=1080,format=YUY2 ! waylandsink window-width=480 window- height=540 & $ gst-launch-1.0 v4l2src device=/dev/video2 ! video/x- raw,width=1920,height=1080,format=YUY2 ! waylandsink window-width=480 window- height=540 & RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual $ gst-launch-1.0 v4l2src device=/dev/video3 ! video/x- raw,width=1920,height=1080,format=YUY2 ! waylandsink window-width=480 window- height=540 & $ gst-launch-1.0 v4l2src device=/dev/video4 ! video/x- raw,width=1920,height=1080,format=YUY2 ! waylandsink window-width=480 window- height=540 & $ gst-launch-1.0 v4l2src device=/dev/video5 ! video/x- raw,width=1920,height=1080,format=YUY2 ! waylandsink window-width=480 window- height=540 & $ gst-launch-1.0 v4l2src device=/dev/video6 ! video/x- raw,width=1920,height=1080,format=YUY2 ! waylandsink window-width=480 window- height=540 & $ gst-launch-1.0 v4l2src device=/dev/video7 ! video/x- raw,width=1920,height=1080,format=YUY2 ! waylandsink window-width=480 window- height=540 & 5. Set the route table.

6.1.3.1.4 MT9M114

The Onsemi MT9M114 is supported on i.MX 91 and i.MX 93.

To select the kernel configuration, Device Drivers -> Multimedia support (MEDIA_SUPPORT [=y]) -> Media ancillary drivers -> Camera sensor devices (VIDEO_CAMERA_SENSOR [=y]) -> MT9M114x support (VIDEO_MT9M114X [=y]) – drivers/media/i2c/mt9m114x.c The following is an example for creating a pipeline manually. input size: 1280x720, Output size: 1280x720 out format: UYVY media-ctl -l "'mt9m114 7-0048':0 -> 'parallel-4ac10070.pcsi':0 [1]" media-ctl -V "'mt9m114 7-0048':0 [fmt: UYVY8_2X8/1280x720 field:none]" media-ctl -V "'parallel-4ac10070.pcsi':0 [fmt: UYVY8_2X8/1280x720 field:none]" media-ctl -V "'crossbar':0 [fmt: UYVY8_2X8/1280x720 field:none]" media-ctl -V "'mxc_isi.0':0 [fmt: UYVY8_2X8/1280x720 field:none]"

6.1.3.2 Raw Cameras

6.1.3.2.1 OX05B1S

The Omnivision OX05B1S is an 1/2.5-inch optical format, 2592x1944, stacked-chip, low power, CMOS, 2.2 µm, RGB-IR raw output sensor. It outputs data on the MIPI-CSI2 interface, up to 4 lanes, 10-bit, with a maximum image transfer rate of 1944 @ 60 fps. The Omnivision OX05B1S sensor is supported on i.MX 95 on the MIPI-CSI port using an NXP adapter board (SCH-89961 Rev. B). To activate the OX05B1S sensor, the following kernel modules need to be selected in the Linux kernel configuration:

Device Drivers > Multimedia support > Media ancillary drivers > Video decoders > OmniVision raw sensor support OX05B1S (CONFIG_VIDEO_OX05B1S) – drivers/media/i2c/ox05b1s/ox05b1s_mipi.c The formats supported for this sensor are: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

2592 x 1944, GRBG10 @ 30 fps The driver is V4L2 compliant, using common V4L2 controls:
V4L2_CID_VBLANK
V4L2_CID_HBLANK
V4L2_CID_PIXEL_RATE
V4L2_CID_ANALOGUE_GAIN
V4L2_CID_EXPOSURE The media controller graph for OX05B1S may look like as shown in the following figure. aaa-061278 mxc_isi.0 /dev/v41-subdev5 mxc_isi.0.capture /dev/video0 mxc_isi.1 /dev/v41-subdev6 mxc_isi.1.capture /dev/video1 mxc_isi.2 /dev/v41-subdev7 mxc_isi.2.capture /dev/video2 mxc_isi.3 /dev/v41-subdev8 mxc_isi.3.capture /dev/video3 mxc_isi.4 /dev/v41-subdev9 mxc_isi.4.capture /dev/video4 mxc_isi.4.output crossbar /dev/v41-subdev4 11 121098765 4ac10000.syscon:formatter@20 /dev/v41-subdev14 csidev-4ad30000.csi /dev/v41-subdev15 ox05b1s 2-0036 /dev/v41-subdev16 1 2 3210 mxc_isi.5 /dev/v41-subdev11 mxc_isi.5.capture /dev/video5 mxc_isi.6 /dev/v41-subdev12 mxc_isi.6.capture /dev/video6 mxc_isi.7 /dev/v41-subdev13 mxc_isi.7.capture /dev/video7

Figure 21. Media controller graph for OX05B1S

Set links: – media-ctl -d /dev/media1 -l "ox05b1s 2-0036":0 -> "csidev-4ad30000.csi":0[1] – media-ctl -d /dev/media1 -l "csidev-4ad30000.csi":1 -> "4ac10000.syscon:formatter@20":0[1] – media-ctl -d /dev/media1 -l "4ac10000.syscon:formatter@20":1 -> "crossbar":2[1] – media-ctl -d /dev/media1 -l "crossbar":5 -> "mxc_isi.0":0[1]
Set routes: – media-ctl -d /dev/media1 -R "crossbar" [2/0 -> 5/0 [1], 2/1 -> 6/0 [0], 2/2 -> – media-ctl -d /dev/media1 -R "csidev-4ad30000.csi" [0/0 -> 1/0 [1], 0/1 -> 1/1 RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual – media-ctl -d /dev/media1 -R "4ac10000.syscon:formatter@20" [0/0 -> 1/0 [1], 0/1

Set formats: – media-ctl -d /dev/media1 -V "ox05b1s 2-0036":0/0 [fmt:SGRBG10/2592x1944 field:none] – media-ctl -d /dev/media1 -V "csidev-4ad30000.csi":0/0 [fmt:SGRBG10/2592x1944 field:none] – media-ctl -d /dev/media1 -V "4ac10000.syscon:formatter@20":0/0 [fmt:SGRBG10/2592x1944 field:none] – media-ctl -d /dev/media1 -V "crossbar":2/0 [fmt:SGRBG10/2592x1944 field:none] – media-ctl -d /dev/media1 -V "mxc_isi.0":0/0 [fmt:SGRBG10/2592x1944 field:none]
Frames then may be captured from the /dev/video0 node: – v4l2-ctl --device /dev/video0 --set-fmt- video=width=2592,height=1944,pixelformat=BA10 --stream-mmap --stream-count=5

6.1.3.2.2 OS08A20

The Omnivision OS08A20 is an 1/1.8-inch optical format, 3840 x 2160, CMOS, 2.2 µm, raw RGB sensor. The OS08A20 has an 8-megapixel array image capable of operating at up to 60 fps in 10-bit resolution. It outputs data on the MIPI-CSI2 interface, up to 4 lanes, 10/12-bit. The Omnivision OS08A20 sensor is supported on i.MX 95 on the MIPI-CSI port using an NXP adapter board (SCH-89961 Rev. B), same as the OX05B1S. The kernel module is also the same as for OX05B1S, so follow the same steps to activate the OS08A20 sensor:

Device Drivers -> Multimedia support -> Media ancillary drivers -> Video decoders -> OmniVision raw sensor support OX05B1S (CONFIG_VIDEO_OX05B1S) – drivers/media/i2c/ox05b1s/ox05b1s_mipi.c The formats supported for this sensor are:
1920 x 1080, BGGR10, no HDR @ 60 fps
1920 x 1080, BGGR10, HDR @ 30 fps
3840 x 2160, BGGR12, no HDR @ 30 fps
3840 x 2160, BGGR10, HDR @ 15 fps
3840 x 2160, BGGR12, HDR @ 15 fps
3840 x 2160, BGGR10, no HDR @ 30 fps The driver is V4L2 compliant, using common V4L2 controls:
V4L2_CID_VBLANK
V4L2_CID_HBLANK
V4L2_CID_PIXEL_RATE
V4L2_CID_ANALOGUE_GAIN
V4L2_CID_EXPOSURE The HDR mode can be enabled or disabled by enabling the short exposure stream and route (on VC1). In this case, the the standard V4L2 control V4L2_CID_HDR_SENSOR_MODE will be automatically enabled and the sensor will operate in staggered HDR mode. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual ./media-ctl -d /dev/media0 -V "crossbar":2/0 [fmt:SBGGR10/3840x2160 field:none] ./media-ctl -d /dev/media0 -V "mxc_isi.0":0/0 [fmt:SBGGR10/3840x2160 field:none] Set formats for stream 1 (short exposure): ./media-ctl -d /dev/media0 -V "os08a20 2-0036":0/1 [fmt:SBGGR10/3840x2160 field:none] ./media-ctl -d /dev/media0 -V "csidev-4ad30000.csi":0/1 [fmt:SBGGR10/3840x2160 field:none] ./media-ctl -d /dev/media0 -V "4ac10000.syscon:formatter@20":0/1 [fmt:SBGGR10/3840x2160 field:none] ./media-ctl -d /dev/media0 -V "crossbar":2/1 [fmt:SBGGR10/3840x2160 field:none] ./media-ctl -d /dev/media0 -V "mxc_isi.2":0/0 [fmt:SBGGR10/3840x2160 field:none] The Omnivision OS08A20 sensor is supported on i.MX 95 (using the OX05B1S driver) in conjunction with the NEO ISP, but it is also supported on i.MX 8M Plus, in which case the VSI ISP is used, and there is another sensor driver, which is built outside the kernel. 6.1.3.2.3 0X03C10 The Omnivision OX03C10 sensor is supported on i.MX 95 using serializer/deserializer solutions from the following vendors:

Analog Devices: MAX96717/MAX96724
Texas Instruments: DS0UB953/DS0UV960 Up to 4 sensors are supported by each SerDes solution. The following subsections provide a brief overview of each solution. Both solutions share the same OX03C10 driver and custom controls. The Analog Devices SerDes solution is made up of one deserializer board having a MAX96724 chip and up to 4 sensor modules, each having an Omnivision OX03C10 sensor and one MAX96717 serializer chip. The modules are connected by Gigabit Multimedia Serial Links (GMSLs) over coax cables. To activate the Analog Devices solution, the following kernel modules need to be selected in the Linux kernel configuration:
max96724: Device Drivers -> Multimedia Support -> Media ancillary drivers -> Video decoders -> Maxim MAX96724 GMSL deserializer support – drivers/media/i2c/max96724.c
mx95mbcam: Device Drivers -> Multimedia Support -> Media ancillary drivers -> Video decoders -> NXP OX03C10 + MAX961717 combo GMSL2 camera support – drivers/media/i2c/mx95mbcam.c – drivers/media/i2c/max96717.c – drivers/media/i2c/ox03c10.c The drivers are V4L2 compliant, using common V4L2 controls (documented in Section 6.1.5), with a few custom controls added to the OX03C10 sensor driver to be able to set exposure, analog gain, digital gain, and white balance gain for each mode of operation in one single-system call. The custom controls UAPI (user-space API) is documented in the following header:
Include/uapi/linux/ox03c10.h The following is a list of the custom controls added. For the full description of the data structures needed to be passed to each control, see the UAPI header files: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

V4L2_CID_OX03C10_EXPOSURE – set exposure parameters for SPD, LCG, and VS modes.
V4L2_CID_OX03C10_ANALOGUE_GAIN – set analog gains for HCG, LCG, SPD, and VS modes.
V4L2_CID_OX03C10_DIGITAL_GAIN – set digital gains for HCG, LCG, SPD, and VS modes.
V4L2_CID_OX03C10_WB_GAIN – set white B, Gb, Gr and R gains for HCG, LCG, SPD, and VS modes.
V4L2_CID_OX03C10_PWL_EN – enable/disable PWL (piecewise linear) compression.
V4L2_CID_OX03C10_PWL_CTRL – change PWL mode.
V4L2_CID_OX03C10_PWL_KNEE_POINTS_LUT – set the PWL knee points.
V4L2_CID_OX03C10_OTP_CORRECTION – read OTP correction parameters. The Texas Instruments SerDes solution is made up of one deserializer board having a DSOUV960 chip and up to 4 sensor modules, each having an Omnivision OX03C10 sensor and one DSOU953 a serializer chip. The modules are connected by FPD-Link III (Flat Panel Display Link) over coax cables. To activate the Texas Instruments solution, the following kernel modules need to be selected in the Linux kernel configuration:
mx95mbcam: Device Drivers -> Multimedia support -> Media ancillary drivers -> Camera sensor devices -> OmniVision OX03C10 sensor support
ds90ub960-q1: Device Drivers -> Multimedia support -> Media ancillary drivers -> Video serializers and deserializers -> TI FPD-Link III/IV Deserializers

6.1.4 Software Operation

The V4L2 opteratons for capture support modes, picture formats and picture sizes varying for each capture interface. The imx-test repo has unit tests for these interfaces in the mxc_v4l2_test. See README for details on how to run tests.

6.1.4.1 Pipeline Operation

6.1.5 V4L2 Capture

Video for Linux Two (V4L2) is a Linux standard. The API specification is available at https://www.kernel.org/doc/ html/latest/userspace-api/media/v4l/v4l2.html. The V4L2 capture device includes two interfaces: the capture and overlay interfaces using the V4L2 API for capture and overlay devices. The following are some sample use cases for the V4L2 capture APIs: 1. Sets the capture pixel format and size using IOCTL VIDIOC_S_FMT. 2. Sets the control information using IOCTL VIDIOC_S_CTRL, for rotation. 3. Requests a buffer using IOCTL VIDIOC_REQBUFS. 4. Memory maps the buffer to its user space. 5. Executes the IOCTL VIDIOC_DQBUF. 6. Passes the data that requires post-processing to the buffer. 7. Queues the buffer using the IOCTL command VIDIOC_QBUF. 8. Starts the stream by executing IOCTL VIDIOC_STREAMON.

VIDIOC_STREAMON and VIDIOC_OVERLAY cannot be enabled simultaneously. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 60. V4L2 Capture API IOCTLs

6.1.6 Source Code Structure

imx8. For MIPI-CSI the source files are in drivers/mxc/mipi.

drivers/media/platform/nxp/dwc-mipi-csi2.c
drivers/phy/freescale/phy-fsl-imx9-dphy-rx.c i.MX 93/95 MIPI CSI Interface driver
drivers/media/platform/nxp/imx8mq-mipi-csi2.c
drivers/staging/media/imx/imx8-mipi-csi2-sam.c
drivers/media/platform/nxp/imx-mipi-csis.c i.MX 8 MIPI-CSI2 Capture Interface driver
drivers/media/platform/nxp/imx-parallel-csi.c i.MX 8 Parallel-CSI Interface driver
drivers/staging/media/imx/imx8-isi-core.c i.MX 8M Plus ISI Capture Controller driver

drivers/staging/media/imx/imx8-isi-cap.c
drivers/staging/media/imx/imx8-isi-hw.c
drivers/staging/media/imx/imx8-isi-m2m.c
drivers/staging/media/imx/imx8-isi-fmt.c
drivers/media/platform/nxp/imx8-isi/ i.MX 8, i.MX 8M (except for i.MX 8M Plus), and i.MX 8X ISI Capture Controller driver
drivers/media/platform/nxp/imx8- isi/imx8-isi-core.c
drivers/media/platform/nxp/imx8-isi/imx8-isi-video.c
drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
drivers/media/platform/nxp/imx8-isi/imx8-isi-m2m.c
drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c i.MX 8 ISI Capture Controller driver
drivers/media/i2c/ov5640.c
drivers/media/i2c/max9286.c
drivers/media/i2c/rdacm20.c i.MX 8 Omnivision Camera V3 Camera interface
drivers/media/platform/nxp/imx-jpeg/ i.MX 8 JPEG hardware interface
drivers/mxc/mipi/mxc_mipi_csi2.c
drivers/mxc/mipi/mxc_mipi_csi2.h i.MX 6 and i.MX 7 MIPI-CSI2 interface core driver
drivers/media/platform/mxc/capture/ipu_bg_overlay_sdc.c
drivers/media/platform/mxc/capture/ipu_csi_enc.c
drivers/media/platform/mxc/capture/ipu_fg_overlay_sdc.c
drivers/media/platform/mxc/capture/ipu_prp_enc.c
drivers/media/platform/mxc/capture/ipu_prp_vf_sdc_bg.c
drivers/media/platform/mxc/capture/ipu_prp_vf_sdc.c
drivers/media/platform/mxc/capture/ipu_still.c
drivers/media/platform/mxc/capture/v4l2-int-device.c i.MX 6 IPU V4L2 plugin
drivers/media/platform/mxc/capture/mx6s_capture.c
drivers/media/platform/mxc/capture/ov5640.c CSI Omnivision Camera V4L2 plugin
drivers/media/platform/mxc/capture/ov5640_v2.c Paralllel CSI Omnivision Camera V4L2 plugin
drivers/media/platform/mxc/capture/ov5640_mipi.c
drivers/media/platform/mxc/capture/ov5640_camera_mipi_int.c MIPI-CSI Omnivision Camera V4L2 plugin
drivers/media/platform/mxc/capture/ov5640_mipi_v2.c MIPI-CSI2 Omnivision Camera V4L2 plugin
drivers/media/platform/mxc/capture/adv7180.c TV Decoder ADV7180 V4L2
drivers/staging/media/imx/hdmirx/cdns-hdmirx-audio.c
drivers/staging/media/imx/hdmirx/cdns-hdmirx-hdcp.c
drivers/staging/media/imx/hdmirx/cdns-hdmirx-hw.c
drivers/staging/media/imx/hdmirx/cdns-hdmirx-phy.c
drivers/staging/media/imx/hdmirx/cdns-hdmirx-phy.h
drivers/staging/media/imx/hdmirx/cdns-hdmirx.c
drivers/staging/media/imx/hdmirx/cdns-mhdp-hdmirx.c
drivers/staging/media/imx/hdmirx/cdns-mhdp-hdmirx.h i.MX 8 HDMI RX

NXP Semiconductors RM00293 i.MX Linux Reference Manual

6.2 Display Overview

6.2.1 Introduction

The i.MX Display systems uses display controllers to optimize video data movement to display interfaces and graphics processing. Each display controller is implemented through a Linux driver and into a display framework either framebuffer or DRM. In some cases a display controller includes authentication ensuring a secure video pipeline. In others the display controller will include additional features for scaling, de-interlacing, tiling and color conversion during tranfers. For i.MX 8 supporting multiple displays is done with use of two controllers working together. This chapter provides a high level overview of i.MX display controllers and interfaces and the difference between framebuffer and DRM display drivers. The following display controllers are used.

IPU
PXP
eLCDIF
DPU
DCSS - on i.MX 8M only A display interface will interface to the display controller, display panel and in some cases encoders display bridges. The following display interfaces are supported.
EPDC - supporting EInk displays
Parallel - supporting LCD displays
LVDS - supporting LVDS displays
HDMI - supporting both on chip and external HDMI
Display Port - supporting eDP panels
MIPI-DSI - supporting MIPI displays Note: Analog display is no longer supported. Analog interface was used i.MX 37 and i.MX 5 families. The following HDMI display bridges/encoder are supported.
Parallel to HDMI - using Silicon Image si902x
LVDS to HDMI - using ITE it6263
MIPI-DSI to HDMI - using Analog Devices adv7535 Each SOC supports different display features. Some of these are configured in the device trees located at arch/ arm/boot/dts and arch/arm64/boot/dts. Go to the hardware reference manual for more details on the following.
Throughput – Number of outputs – Pixel clock rate – Max number of displays and corresponding resolution – Resolution at 60 Hz.
Interface – Parallel - number of ports and bit size – LVDS - number of lanes and channels. – MIPI-DSI - number of ports, lanes channels and speed
Processing – On the fly combining including high resolution displays – Off-line combining speed RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

6.2.2 Frame Buffer

Frame buffer drivers are supported for i.MX 6 and i.MX 7 but not for i.MX 8. The frame buffer drivers are supported using the the imxfb driver in drivers/video/fbdev. The frame buffer kernel fbdev structure is defined here or here on kernel.org. For more information on i.MX V4LS go the V4L2 chapter. The panels are supported with the framebuffer driver for the TRULY and EInk panels in the video/fbdev/mxc folder. See the panels supported by seaching for PANEL in the imx_v7_defconfig. The Trully panels are only supported with the MIPI DSI interface. The Eink panels are only supported with the EPDC interface.

6.2.3 Direct Rendering Model (DRM)

Direct Rendering Model (DRM) is the new display driver use for i.MX. The i.MX DRM driver is in drivers/ gpu/drm/imx. Other components have DRM interfaces such as GPU and DCSS. The DRM framework is documented here on kernel.org. The i.MX DRM drivers are implemented with the following drivers.

Hardware library support files
Core DRM drivers
Hardware dependent DRM drivers
HDMI DRM drivers supporting hdp HDMI/Display Port The DRM driver uses the DPU for the i.MX 8QuadMax and i.MX 8QuadXPlus, uses LCDIF for the i.MX 8M Quad and i.MX 8M Mini, uses DCNANO for the i.MX 8ULP, and uses LCDIFv3 for i.MX 8M Plus, i.MX 93, and i.MX 91. The i.MX DRM framework also includes panel drivers which exist in driver/gpu/panel. The supported DRM panels are Simple panel, Raydium RM67191, Raydium RM68200, and Raydium RM67199.

6.2.4 Display Resolution

The display resoluton calculation uses the following factors.

Frame Width
Frame Height
Frame rate (fps)
Blanking Interval - provided in the display's DS up to 35% (1.35) - use minn values The pixel clock [MHz] is calculated according to Frame Width x Frame Height x Frames Rate x Blanking Interval Things to consider are the following
Data format (pixel per clock)
Display's source clock (DI#_CLK_EXT bit
The load on the display controller (DC)

6.2.5 Authentication

Display authentication allows hardware processing to ensure display content is not compromised. This is done through a display authentication CRC using the authentication hardware This hardware is the DCIC integrated through the frame buffer display framework on i.MX 6 and the DPU implemented in the DRM display framework for i.MX 8. Display authentication CRC is supported on the following SoC.

i.MX 6 Solox supports authentication using DCIC for 1 display.
i.MX 6 QuadPlus/Quad/Dual support authentication using DCIC with 2 displays. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

i.MX 8QuadXPlus can authenticate 2 display using the DPU.
i.MX 8QuadMax can authenticate 4 displays using DPU.

6.2.6 Tiling

Tiling through hardware provides optimized video data display. This is implemented through different hardware blocks. The newest feature is the Display Prefetch Resolve (DPR) which increases performance on the i.MX 6 QuadPlus, i.MX 8QuadMax and i.MX 8QuadXPlus. Tile support is enabled on the following

i.MX 6Quad/Dual supports tiling using Video Data Order Adapter (VDOA).
i.MX 6QuadPlus supports both tiling VDOA and Display Prefetch Resolve (DPR) version 1
i.MX 8QuadXPlus and i.MX 8QuadMax supports tiling using Display Prefetch Resolve (DPR) version2

6.3 Display Controllers

6.3.1 Display Processing Unit (DPU)

6.3.1.1 Introduction

The display processing unit (DPU) is designed to support video and graphics processing functions and to interface with video and still display sensors and displays. The DPU driver provides internel kernel-level APIs to manipulate logical channels. A logical channel represents a complete DPU processing flow. For example, a complete DPU processing flow (logical channel) might consist of reading a YUV buffer from memory and displaying it to an external interface. The DPU API consists of a set of common functions for all channels. Its functions are to initialize channels, set up buffers, enable and disable channels and set up interrupts. Typical logical channels include:

CSI direct to memory
Memory to synchronous frame buffer background
Memory to synchronous frame buffer foreground The higher level drivers are responsible for memory allocation and providing user-level API. DPU interfaces are available for capture in the V4L2 framework and for display using the DRM display framework. DPU interfaces with LVDS, MIPI-DSI, HDMI and Parallel display interfaces. The DPU display controller supports a 32bit display composition engine that includes the following:
2 Display output streams on independent panels.
Two layer composition
Automatic safety stream panic plus detection using CRC matching using a Region CRC checker The DPU display controller supports a 2D composition engine which provides efficiency, performance and safety. The DPU 2D graphics engine support reduces the burden on the GPU so it only does 3D GPU. Video efficiency with overlay native video and graphics uses minimal access to system memory. Power efficiencies allow the 3D engine to be off for windowing GUI's like the Android Hardware Composer. The DPU also supports the following for authentication.
CRC checker with 8 stackable regions maskable, exclusive top-to-bottom priority
CRC check can be inserted after any stage in the post-processing pipe
CRC failure can generate SW interrupt, or switch the Frame Gen to either Safety Stream or Constant Plane The DPU display interfacce cache supports the following. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Each display plane has a multi line cache
This contains 8 lines of pixels for each plane
RGB, YUV etc formats supported
Supports Video and GPU tile formats
Contents are fetched from memory to fill cache ahead of time
Horizontal and vertical fetches supported
Warp fetches not supported, require bypass

6.3.1.2 DRM

The display processing unit (DPU) interfaces with the DRM driver supporting video display.

6.3.1.3 Source Code Structure

Table 62. DPU Driver source...continued

6.3.1.4 Menu Configuration Options

The following Linux kernel configuration options are provided for the DPU module.

6.3.2 Image Processing Unit (IPU)

6.3.2.1 Introduction

Parallel
LVDS
HDMI
MIPI-DSI Typical logical channels include:
CSI direct to memory
CSI to viewfinder pre-processing to memory
Memory to viewfinder pre-processing to memory
Memory to viewfinder rotation to memory
Previous field channel of memory to video deinterlacing and viewfinder pre-processing to memory
Current field channel of memory to video deinterlacing and viewfinder pre-processing to memory
Next field channel of memory to video deinterlacing and viewfinder pre-processing to memory
CSI to encoder pre-processing to memory
Memory to encoder pre-processing to memory
Memory to encoder rotation to memory
Memory to post-processing rotation to memory
Memory to synchronous frame buffer background
Memory to synchronous frame buffer foreground
Memory to synchronous frame buffer DC
Memory to synchronous frame buffer mask The IPU API has some additional functions that are not common across all channels, and are specific to an IPU sub-module. The types of functions for the IPU sub-modules are as follows: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Synchronous frame buffer functions
Panel interface initialization
Set foreground positions
Set local/global alpha and color key
Set gamma
CSI functions
Sensor interface initialization
Set sensor clock
Set capture size
Enable or disable prefetching linear frames by using PRE/PRG
Enable or disable resolving tiled frames by using PRE/PRG The higher level drivers are responsible for memory allocation, chaining of channels, and providing user-level API.

6.3.2.2 Hardware Operation

following figure shows the IPU hardware modules. Figure 23. IPUv3EX/IPUv3H IPU Module Overview

6.3.2.3 Software Operation

The IPU driver is a self-contained driver module in the Linux kernel.

Synchronous frame buffer driver
Display Interface (DI)
Display Processor (DP)
Image DMA Controller (IDMAC) RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

CMOS Sensor Interface (CSI)
Image Converter (IC)
Prefetch/Resolve Engine/Gasket (PRE/PRG) The figure below shows the interaction between the different graphics/video drivers and the IPU. aaa-053506 Camera app Video conf app Multimedia framework Media player app Other data flow Control calls Application (user mode) Middleware (user mode) Kernel mode Hardware V4L2 capure plugin I2C driver CSI IPU common API IPU display API DP/DC/DIPRPENC PRPVF PP MXC display driver VPUIPU I2C Camera Epson VGA mxc_ipu V4L2 video sink plugin VPU kernel driverOverlay frame buf Sync frame buf driver (DI0) Sync frame buf driver (DI1) V4L2 output driver V4L2 capture driver Ipu processing driver Camera sensor driver VPU library (userspace driver) VPU plugin

Figure 24. Graphics/Video Drivers Software Interaction for IPUv3

Device drivers-include the frame buffer driver for the synchronous frame buffer, the frame buffer driver for the displays, V4L2 capture drivers for IPU pre-processing, the V4L2 output driver for IPU post-processing, and the ipu processing driver which provide system interface to user space or V4L2 drivers. The frame buffer device drivers are available in drivers/video/mxc. The V4L2 device drivers are available in drivers/media/ platform/mxc.
The MXC display driver is introduced as a simple framework to manage interaction between IPU and display device drivers (e.g., LCD, LVDS, HDMI, MIPI, etc.)
Low-level library routines-interface to the IPU hardware registers. They take input from the high-level device drivers and communicate with the IPU hardware. The low-level libraries are available in the directory of the Linux kernel.

6.3.2.4 IPU Frame Buffer Drivers Overview

that the software is not required to know anything about the low-level hardware registers. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual a startup logo. This device depends on the virtual terminal (VT) console to switch from serial to graphics mode. The device is accessed through special device nodes, located in the /dev directory, as /dev/fb*. fb0 is generally the primary frame buffer. Other than the physical memory allocation and LCD panel configuration, the common kernel video API is utilized for setting colors, palette registration, image blitting, and memory mapping. The IPU reads the raw pixel data from the frame buffer memory and sends it to the panel for display.

6.3.2.5 IPU Frame Buffer Hardware Operation

The frame buffer interacts with the IPU hardware driver module.

6.3.2.6 IPU Frame Buffer Software Operation

A frame buffer device is a memory device, such as /dev/mem, and it has features similar to a memory device. Users can read it, write to it, seek to some location in it, and mmap() it (the main use). The difference is that the memory that appears in the special file is not the whole memory, but the frame buffer of some video hardware. /dev/fb* also interacts with several IOCTLs, which allows users to query and set information about the hardware. The color map is also handled through IOCTLs. For more information on what IOCTLs exist and which data structures they use, see include/uapi/linux/fb.h. The following are a few of the IOCTLs functions:

Request general information about the hardware, such as name, organization of the screen memory (planes, packed pixels, and so on), and address and length of the screen memory.
Request and change variable information about the hardware, such as visible and virtual geometry, depth, color map format, timing, and so on. The driver suggests values to meet the hardware capabilities (the hardware returns EINVAL if that is not possible) if this information is changed.
Get and set parts of the color map. Communication is 16 bits-per-pixel (values for red, green, blue, transparency) to support all existing hardware. The driver does all the calculations required to apply the options to the hardware (round to fewer bits, possibly discard transparency value). The hardware abstraction makes the implementation of application programs easier and more portable. The only thing that must be built into the application programs is the screen organization (bitplanes or chunky pixels, and so on), because it works on the frame buffer image data directly. The MXC frame buffer driver (drivers/video/mxc/mxc_ipuv3_fb.c) interacts closely with the generic Linux frame buffer driver (drivers/video/fbdev/core/fbmem.c).

6.3.2.7 Synchronous Frame Buffer Driver

The synchronous frame buffer screen driver implements a Linux standard frame buffer driver API for synchronous LCD panels or those without memory. The synchronous frame buffer screen driver is the top level kernel video driver that interacts with kernel and user level applications. This is enabled by selecting the Synchronous Panel Frame buffer option under the graphics support device drivers in the kernel configuration. To supplement the frame buffer driver, the kernel builder may also include support for fonts and a startup logo. This depends on the VT console for switching from serial to graphics mode. Except for physical memory allocation and LCD panel configuration, the common kernel video API is utilized for setting colors, palette registration, image blitting, and memory mapping. The IPU reads the raw pixel data from the frame buffer memory and sends it to the panel for display. The frame buffer driver supports different panels as a kernel configuration option. Support for new panels can be added by defining new values for a structure of panel settings. The frame buffer interacts with the IPU driver using custom APIs that allow: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

Initialization of panel interface settings
Initialization of IPU channel settings for LCD refresh
Changing the frame buffer address for double buffering support The following features are supported:
Configurable screen resolution
Configurable RGB 16, 24, or 32 bits per pixel frame buffer
Configurable panel interface signal timings and polarities
Palette/color conversion management
Power management
LCD power off/on
Enable/disable PRE/PRG features User applications utilize the generic video API (the standard Linux frame buffer driver API) to perform functions with the frame buffer. These include the following:
Obtaining screen information, such as the resolution or scan length
Allocating user space memory using mmap for performing direct blitting operations A second frame buffer driver supports a second video/graphics plane.

6.3.2.8 IPU Backlight Driver

IPU drivers also control the backlight. The IPU backlight driver implements IPU PWM backlight control for panels. It exports a sys control file under /sys/class/backlight/pwm-backlight.0/brightness to user space. The default backlight intensity value is 128.

6.3.2.9 IPU Device Driver

IPU (processing) device driver provide image processing features: resizing/rotation/CSC/combination/deinterlaci ng based on IC/IRT modules in IPUv3. The IPU device driver is task based, user just need prepare task setting, queue task, then block wait task finish. The driver now supports only blocking method, and the non-block method will be added in the future. The task structures are as follows: struct ipu_task { struct ipu_input input; struct ipu_output output; bool overlay_en; struct ipu_overlay overlay; #define IPU_TASK_PRIORITY_NORMAL 0 #define IPU_TASK_PRIORITY_HIGH 1 u8 priority; #define IPU_TASK_ID_ANY 0 #define IPU_TASK_ID_VF 1 #define IPU_TASK_ID_PP 2 #define IPU_TASK_ID_MAX 3 u8 task_id; int timeout; struct ipu_input { u32 width; u32 height; u32 format; RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

6.3.2.10 Source Code Structure

The source files associated with the IPU, Sensor, V4L2, and Panel drivers are available in the following folders.

drivers/mxc/ipu3
drivers/video/mxc
drivers/video/fbdev/mxc
drivers/video/backlight See the V4L2 chapter for more information on the IPU V4L2 driver files File Description driveers/mxc/ipu3/ipu_common.c IPU common library functions driveers/mxc/ipu3/ipu_common.c IPU common library functions drivers/mxc/ipu3/ipu_ic.c IPU IC base driver drivers/mxc/ipu3/ipu_device.c IPU driver device interface and fops functions. drivers/mxc/ipu3/ipu_capture.c IPU CSI capture base driver drivers/mxc/ipu3/ipu_disp.c IPU display functions drivers/mxc/ipu3/ipu_calc_stripes_sizes.c Multistripes method functions for ipu_device.c drivers/mxc/ipu3/pre.c i.MX 6 QuadPlus Prefetch/Resolve the engine driver drivers/mxc/ipu3/prg.c i.MX 6 QuadPlus Prefetch/Resolve the Gasket driver drivers/mxc/ipu3/mxc_ipuv3_fb.c Driver for synchronous frame buffer drivers/mxc/ipu3/vdoa.c VDOA post-processing driver, used by ipu_device.c

Table 63. IPU Driver Files...continued Table 64 lists the header files associated with the IPU and Panel drivers. Table 64. IPU Global Header Files

6.3.2.11 Menu Configuration Options

The following Linux kernel configuration options are provided for the IPU module.

CONFIG_MXC_IPU_V3 - Includes support for the Image Processing Unit. In menuconfig, this option is available under: Device Drivers > MXC support drivers > Image Processing Unit Driver By default, this option is Y for all architectures. If ARCH_MXC is true, CONFIG_MXC_IPU_V3 will be set.
CONFIG_MXC_IPU_V3_PRG - This enables support for the IPUv3 prefetch gasket engine to support double buffer handshake control between IPUv3 and prefetch engine (PRE), snoop the AXI interface for display refresh requests to memory, and modify the request address to fetch the double buffered row of blocks in OCRAM. Device Drivers > MXC support drivers > i.MX IPUv3 prefetch gasket engine This option depends on CONFIG_MXC_IPU_V3 and CONFIG_MXC_IPU_V3_PRE.
CONFIG_MXC_IPU_V3_PRE - This enables support for the IPUv3 prefetch engine to improve the system memory performance. The engine has the capability to resolve framebuffers in tile pixel format to linear. Device Drivers > MXC support drivers > i.MX IPUv3 prefetch engine This option depends on CONFIG_MXC_IPU_V3. Enabling this option selects CONFIG_MXC_IPU_V3_PRG.
CONFIG_MXC_CAMERA_OV5640_MIPI - Option for both the OV 5640 mipi sensor driver and the use case driver. This option is dependent on the VIDEO_MXC_CAPTURE option. In menuconfig, this option is available under: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Device Drivers > Multimedia support > V4L platform devices > MXC Video For Linux Video Capture > MXC Camera/V4L2 PRP Features support > OmniVision 5640 Camera support using mipi

CONFIG_MXC_CAMERA_OV5640 - Option for both the OV5640 sensor driver and the use case driver. This option is dependent on the VIDEO_MXC_CAPTURE option. In menuconfig, this option is available under: Device Drivers > Multimedia platform > V4L platform devices > MXC Video For Linux Video Capture > MXC Camera/V4L2 PRP Features support > OmniVision ov5640 camera support Only one sensor should be installed at a time.
CONFIG_MXC_IPU_PRP_VF_SDC - Option for the IPU (here the > symbols illustrates data flow direction between HW blocks): CSI > IC > MEM MEM > IC (PRP VF) > MEM Use case driver for dumb sensor or CSI > IC(PRP VF) > MEM for smart sensors. In menuconfig, this option is available under: Multimedia devices > Video capture adapters > MXC Video For Linux Camera > MXC Camera/V4L2 PRP Features support > Pre-Processor VF SDC library By default, this option is M for all.
CONFIG_MXC_IPU_PRP_ENC - Option for the IPU: Use case driver for dumb sensors CSI > IC > MEM MEM > IC (PRP ENC) > MEM or for smart sensors CSI > IC(PRP ENC) > MEM. In menuconfig, this option is available under: Device Drivers > Multimedia Devices > Video capture adapters > MXC Video For Linux Camera > MXC Camera/V4L2 PRP Features support > Pre-processor Encoder library By default, this option is set to M for all.
CONFIG_VIDEO_MXC_CAMERA - This is configuration option for V4L2 capture Driver. This option is dependent on the following expression: In menuconfig, this option is available under: Device Drivers > Multimedia devices > Video capture adapters > MXC Video For Linux Camera By default, this option is M for all.
CONFIG_VIDEO_MXC_OUTPUT - This is configuration option for V4L2 output Driver. This option is dependent on VIDEO_DEV && MXC_IPU option. In menuconfig, this option is available under: Device Drivers > Multimedia devices > Video capture adapters > MXC Video for Linux Video Output By default, this option is Y for all.
CONFIG_FB - This is the configuration option to include frame buffer support in the Linux kernel. In menuconfig, this option is available under: Device Drivers > Graphics support > Support for frame buffer devices By default, this option is Y for all architectures.
CONFIG_FB_MXC - This is the configuration option for the MXC Frame buffer driver. This option is dependent on the CONFIG_FB option. In menuconfig, this option is available under: Device Drivers > Graphics support > MXC Framebuffer support By default, this option is Y for all architectures.
CONFIG_FB_MXC_SYNC_PANEL - This is the configuration option that chooses the synchronous panel framebuffer. This option is dependent on the CONFIG_FB_MXC option. In menuconfig, this option is available under: Device Drivers > Graphics support > MXC Framebuffer support > Synchronous Panel Framebuffer By default this option is Y for all architectures.
CONFIG_FB_MXC_LDB - This configuration option selects the LVDS module on i.MX 6 chip. This option is dependent on CONFIG_FB_MXC_SYNC_PANEL and CONFIG_MXC_IPUV3 || FB_MXS options. In menuconfig, this option is available under: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Device Drivers > Graphics support > MXC Framebuffer support > Synchronous Panel Framebuffer > MXC LDB

CONFIG_FB_MXC_SII9022 - This configuration option selects the SII9022 HDMI chip. This option is dependent on CONFIG_FB_MXC_SYNC_PANEL option. In menuconfig, this option is available under: Device Drivers > Graphics support > MXC Framebuffer support > Synchronous Panel Framebuffer > Si Image SII9022 DVI/HDMI Interface Chip

6.3.3 Pixel Pipeline (PxP)

6.3.3.1 Introduction

The PxP is a display controller that works wtih the EPDC display interface. The Pixel Pipeline (PxP) DMA engine driver provides a unique API, which are implemented as a dmaengine client that smooths over the details of different hardware offload engine implementations. Typically, the users of PxP DMA-ENGINE driver include EPDC driver, V4L2 Output driver, and the PxP user-space library. The PxP driver uses PxP registers to interact with the hardware. For detailed hardware operations, see the Applications Processor Reference Manual document associated with SoC.

6.3.3.2 Software Operation

There are different versions of PxP IP. To ease the maintenance for the new version of PxP used on i.MX 7Dual, which has new features mainly for EPDC like hardware collision detection, E Ink Gen-II waveform algorithm (REAGL/-D) processing in hardware, and hardware dithering support, there are different drivers (drivers/dma/ pxp/pxp_dma_v3.c). However, each version uses the DMA Engine framework.

6.3.3.3 Key Data Structs

The PxP DMA Engine driver implementation depends on the DMA Engine Framework. There are three important structs in the DMA Engine Framework which are extended by the PxP driver: struct dma_device, struct dma_chan, struct dma_async_tx_descriptor. The PxP driver implements several callback functions which are called by the DMA Engine Framework (or DMA slave) when a DMA slave (client) interacts with the DMA Engine. The PxP driver implements the following callback functions in struct dma_device: device_alloc_chan_resources /* allocate resources and descriptors */ device_free_chan_resources /* release DMA channel's resources */ device_tx_status /* poll for transaction completion */ device_issue_pending /* push pending transactions to hardware */ and, device_prep_slave_sg /* prepares a slave DMA operation */ device_terminate_all/* manipulate all pending operations on a channel, returns zero or error code */ The first four functions are used by the DMA Engine Framework, the last two are used by the DMA slave (DMA client). Notably, device_issue_pending is used to trigger the start of a PxP operation. The PxP DMA driver also implements the interface tx_submit in struct dma_async_tx_descriptor, which is used to prepare the descriptor(s) which will be executed by the engine. When tasks are received in pxp_tx_submit, they are not configured and executed immediately. Rather, they are added to a task queue and the function call is allowed to return immediately. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

6.3.3.4 Channel Management

Although ePxP does not have multiple channels in hardware, the virtual channels are supported in the driver. This provides flexibility in the multiple instance/client design. At any time, a user can call dma_request_channel() to get a free channel, and then configure this channel with several descriptors. A descriptor is required for each input plane and for the output plane. When the PxP is no longer being used, the channel should be released by calling dma_release_channel(). Detailed elements of channel management are handled by the driver and are transparent to the client.

6.3.3.5 Descriptor Management

The DMA Engine processes the task based on the descriptor. One DMA channel is usually associated with several descriptors. Descriptors are recycled resources, under control of the offload engine driver, to be reused as operations complete. The extended TX descriptor packet (pxp_tx_desc), allows the user to pass PxP configuration information to the driver. This includes everything that the PxP needs to execute a processing task.

6.3.3.6 Completion Notification

There are two ways for an application to receive notification that a PxP operation has completed.

Call dma_wait_for_async_tx(). This call causes the CPU to spin while it polls for the completion of the operation.
Specify a completion callback. The latter method is recommended. After the PxP operation completes, the PxP output buffer data can be retrieved. For general information for DMA Engine Framework, seeDocumentation/dmaengine.txt in the Linux kernel source tree.

6.3.3.7 Limitations

The driver currently does not support scatterlist objects in the way they are traditionally used. Instead of using the scatterlist parameter object to provide a chain of memory sources and destinations, the driver currently uses it to provide the input and output buffers (and overlay buffers, if needed) for one transfer.
The PxP driver may not properly execute a series of transfers that is queued in rapid sequence. It is recommended to wait for each transfer to complete before submitting a new one.

6.3.3.8 Menu Configuration Options

The following Linux kernel configuration option is provided for this module:

For i.MX 7Dual, i.MX 8ULP, and i.MX93, select Device Drivers > DMA Engine support > [*] MXC PxP V3 support > [*] MXC PxP Client Device.
For i.MX 6, select Device Drivers > DMA Engine support > [*] MXC PxP V2 support > [*] MXC PxP Client Device.

6.3.3.9 Source Code Structure

Table 65. PxP source

6.3.4.1 Introduction

support another sync LCD panel, the user can write a sync LCD driver by referring to the existing ones.

6.3.4.2 Software Operation

/dev/mem. It can be read from, written to, or some location in it can be sought and mapped using mmap(). more information on which IOCTLs there are and which data structures are used. buffer video mode pattern and bits_per_pixel should be the frame buffer's color depth.

6.3.4.3 Menu Configuration Options

6.3.4.4 Source Code Structure

drivers/gpu/drm/imx/lcdifv3. Table 66. ELCIF source

6.3.5 Display Control Subsystem (DCSS)

6.3.5.1 Introduction

Supports up to 3 layers of graphics or video – Arbitrary offset – One plane can be graphics with 8 bit alpha support – Upscale 1920 x 1080p60 video or graphics to 3840 x 2160p60 – Downscale 3840 x 2160p30 video to 1920 x 1080p30 or 1280 x 720p30
HDR support: – HDR10 with 2084 and 2020 color spaces – Dolby Vision single and dual layer formats – HLG
HDMI 2.0a supporting one display: – Resolutions of: 640 x 480p60, 720 x 480p60, 1280 x 720p60, 1920 x 1080p60, 3840 x 2160p60 – HDCP 2.2 and HDCP 1.4
Pixel clock up to 596 MHz
Output can also go to MIPI DSI output
Frame Buffer Compression – Lossless compression of buffers RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

6.3.5.2 Source Code Structure

Table 67. DCSS Driver source

6.3.6 DCNANO

6.3.6.1 Introduction

Video Timing Generation – HSYNC, VSYNC, DE signals – Programmable timers
MIPI Display Protocols – Display Pixel Interface-2 (DPI-2) formats – DPI 24-bit, 18-bit (2 configs) and 16-bit support (3 configs) – (Optional) Display Bus Interface 2.0 (DBI-2)
Display Interface – Parallel Pixel Output with 24-bit Data, HSync, VSync, Data enable – Easily adaptable to external serialization logic, e.g., HDMI
Display – Display sizes to 1024x480 – Sync and blank signals RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Input Formats – ARGB2101010/ARGB8888/ARGB1555/RGB565/ARGB4444 – YUV422 packed & semi planar (YUY2, UYVY)
Format Conversion – Pixel inputs accepted from multiple RGB formats – Pixel output is 24 bit RGB in multiple formats
Output Formats – RGB888/DPI_D16CFG1/DPI_D16CFG2/DPI_D16CFG3/DPI_D18CFG1/ DPI_D18CFG2/ DPI_D24
Hardware Cursor – Supports ARGB888 and Mask cursor formats
Color – Overlay with coordinate generator – Alpha Blending: 8 Porter Duff Blending modes
Dither and Gamma Correction – A separate Look Up Table for Dither – A separate Look Up Table for Gamma Correction

6.3.6.2 Source Code Structure

The DCNANO drm driver is located in drivers/gpu/drm/imx/dcnano. Table 68. DCNANO driver source

6.4 Display Interfaces

6.4.1 Parallel LCD Interface

6.4.1.1 Introduction

IPU on i.MX with IPU
DPU on all i.MX8
ElCDIF on i.MX with PxP The Parallel interface supports at least one port on i.MX SoC that enable the parallel interface and supports two ports for i.MX with IPU. The enabled SoC have varying bitrates from 18bit to 24 bits per port. On i.MX 6 RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual with IPU the Parallel interface also supports a synchronous mode for display refresh and asynchronous mode to memory and is very flexible with a glue-less connection to RAM-less displays, display controllers and TV encoders.

6.4.2 MIPI DSI Interface

6.4.2.1 Introduction

The MIPI Display Interface (MIPI DSI) is a driver interface used to communicate with MIPI device controller on the display panel. MIPI DSI display panel driver provides an interface to configure the display panel through MIPI DSI. The MIPI DSI Interface is a digital core accompanied with a multi-lane D-PHY that implements all protocol functions defined in the MIPI DSI Specification, providing an interface between the System and MIPI DSI compliant Display The MIPI DSI overview can be found here however specifications are only available to MIPI members. The MIPI DSI module provides a high-speed serial interface between a host processor and a display module. It has higher performance, lower power, less EMI, and fewer pins compared with parallel bus. It is designed to be compatible with the standard MIPI DSI protocol and is built on the existing MIPI DPI-2, MIPI DBI-2 and MIPI DCS standards. The module sends pixels or commands to the peripheral and reads back status or pixel information from the peripheral. MIPI DSI serializes all pixels data, commands and events, and contains two basic modes: command mode and video mode. It uses command mode to write register and memory to the display controller while reading display module status information. It also uses video mode to transmit a real- time pixel streams from the host to peripheral in high-speed mode and generates an interrupt when an error occurs. For i.MX MIPI DSI is supported by a variety of drivers which are described in following chapters. The MIPI DSI drivers support the following features:

MIPI DSI communication protocol
MIPI DSI command mode and video mode
MIPI DCS command operation Both drivers support the following.
Drivers are not exposed to the user interface but through the drm or framebuffer interface.
MIPI DSI IP driver-low level interface used to communicate with MIPI device controller on the display panel
MIPI DSI display panel driver provides an interface to configure the display panel through MIPI DSI The driver enables the platform-related regulators and clock. It requests OS-related system resources and registers buffer event notifier for blank/unblank operation. The driver initializes MIPI D-PHY and configures the MIPI DSI IP according to the MIPI DSI display panel. The MIPI DSI driver supports the following features:
Compatibility with MIPI Alliance Specification for DSI, Version1.01.0r11
Compatibility with MIPI Alliance Specification for D-PHY, Version 1.00.00
Supports 1 to 4 D-PHY data lanes depending on SoC capabilities.
Bidirectional Communication and Escape Mode Support through Data Lane 0
Programmable display resolutions
Video Mode Pixel Formats, 16bpp (565 RGB),18bpp (666 RGB) packed, 18 bpp (666 RGB) loosely, 24bpp (888 RGB).
Supports the transmission of all generic commands
Supports ECC and checksum capabilities RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

End-of-Transmission Packet(EoTp) support
Supports ultra low power mode
Supports PMS control interface for PLL to configure byte clock frequency
Supports Prescaler to generate escape clock from byte clock The number of ports and lanes are specified in the device trees located in arch/arm/boot/dts and arch/arm64/ boot/dts.

6.4.2.2 Software Operation

The MIPI DSI driver has two parts: MIPI DSI IP driver and MIPI DSI display panel driver. attached is described in field int dev_id while the DI instance inside IPU is described in the field int disp_id. to configure the MIPI DSI hardware registers. IPU through DPI-2 interface and serializes pixel data and video event through high-speed data links for display. The MIPI DSI IP driver provides 3 APIs for MIPI DSI display panel driver to configure display module. to the manufacturer's specification.

6.4.2.3 Source Code Structure

Table below shows the MIPI DSI driver source files available in drivers/video/fbdev/mxc. Table 69. MIPI DSI Driver Files RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

6.4.2.4 Menu Configuration Options

In menu configuration, enable the following module: Device Drivers > Graphics support > MXC Framebuffer support > Synchronous Panel Framebuffer > MXC MIPI_DSI Device Drivers > Graphics support > MXC Framebuffer support > Synchronous Panel Framebuffer > MXC MIPI_DSI_SAMSUNG Device Drivers > Graphics support > DRM Support for Freescale i.MX > Support for Northwest Logic MIPI DSI displays Device Drivers > Graphics support > DRM Support for Freescale i.MX > Support for Samsung MIPI DSIM displays Device Drivers > Graphics support > DRM Support for Freescale i.MX > Freescale i.MX DRM Synopsys DesignWare MIPI DSI

6.4.3 LVDS Interface

6.4.3.1 Introduction

Low Voltage Differential Signalling (LVDS) supports high bandwidth and high definitiion graphics and fast frame rate with lower power consumption. The implentation uses paris of wires where each wire in the pair carries inverse signal of the other. This creates less interference and noise. The LVDS interferace uses four, six or eight paris of wirse with additional ones carrying clock and ground wires. The purpose of the LVDS interface is to support the flow of synchronous RGB data from the display controller to external display devices through the LVDS interface. This support covers all aspects of these activities: 1. Connectivity to relevant devices - Displays with LVDS receivers. 2. Data arrangement required by the external display receiver and by LVDS display standards. 3. Synchronization and control capabilities. The LVDS interface supports multiple controllers listed below.

LDB - double on i.MX 6 with IPU
Mixel on i.MX 8QuadMax
Mixel Combo on i.MX 8QuadXPlus The LVDS drivers works with the supported display framework, which is framebuffer for i.MX 6 and i.MX 7, and DRM for i.MX 8 and i.MX 93. The LVDS interface has the following structure of support
Channels - usually 2 channels
Each channel supports a number of data pairs
Data pixel rate which can vary on each data pair
Control signals for HSYNC,VSYNC, DE The LVDS interface supports the following displays.
IT6263 LVDS to HDMI bridge - implemented with our LDB driver
LVDS dual channel panel The relevant standards for LVDS are the following. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

PHY Standard: ANSI EIA-644A
Display Protocol Standards: – SPWG Standard Panel Working Group Specification 3.8 (May 2007) – VESA PSWG – Panel Standardization Working Group – set of standards for panels using LVDS. – JEIDA/JEITA DISM Standard JEIDA-59-1999 – OpenLDI (National) – Revision 0.95 13/May/1999. *Only* Unbalanced operating mode supported (aligned with vast majority of LCD vendors). The LVDS interface is supported through the framebuffer framework on i.MX 6 and i.MX 7, and the DRM framework on i.MX 8 and i.MX 93.

6.4.3.2 Software Operation

The LVDS driver is functional if the driver is built-in and the device tree status is set to "okay". set to use 30-bit JEIDA mode.

Enable the power to the LVDS.
Set ldb_di_clk's parent clk and the parent clk's rate.
Enable both ldb_di_clk and its parent clk.
Set the LVDS in a proper mode including display signals' polarities, channel mapping mode, and bit
Enable related i.MX LVDS channels.

6.4.3.3 Source Code Structure

Table 70. LVDS Source

6.4.3.4 Menu Configuration Options

6.4.4 LVDS Display Bridge (LDB)

6.4.4.1 Introduction

RGB data from IPU or LCDIF to external display devices through LVDS interface.

Connectivity to relevant devices - Displays with LVDS receivers.
Arranging data as required by the external display receiver and by LVDS display standards. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Synchronization and control capabilities.

6.4.4.2 Software Operation

The LDB driver is functional if the driver is built-in. display device with LVDS interface as the primary display device.

Set ldb_di_clk's parent clk and the parent clk's rate.
Enable both ldb_di_clk and its parent clk.
Set the LDB in a proper mode including display signals' polarities, LVDS channel mapping mode, bit

mapping mode, and reference resistor mode.

Enable related LVDS channels.

6.4.4.3 Source Code Structure

Table 71. LDB Source

6.4.4.4 Menu Configuration Options

The following Linux kernel configuration options are provided for this module.

6.4.5 Electrophoretic Display Controller (EPDC) Interface

6.4.5.1 Introduction

work with a range of E Ink panel types and specifications.

EPDC driver as a loadable or built-in module.
RGB565, RGB24, RGB32 and Y8 frame buffer formats.
Full and partial EPD screen updates.
Up to 256 panel-specific waveform modes.
Automatic optimal waveform selection for a given update. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

Synchronization by waiting for a specific update request to complete.
Screen updates from an alternate (overlay) buffer.
Automated collision handling.
64 simultaneous update regions.
Ppixel inversion in a Y8 frame buffer format.
90, 180, and 270 degree HW-accelerated frame buffer rotation.
Panning (y-direction only).
Automated full and partial screen updates through the Linux fb_deferred_io mechanism.
Three EPDC driver display update schemes: Snapshot, Queue, and Queue and Merge.
Setting the ambient temperature through either a one-time designated API call or on a per-update basis.
User control of the delay between completing all updates and powering down the EPDC.

6.4.5.2 EPDC Frame Buffer Driver Overview

The frame buffer device provides an abstraction for the graphics hardware. It represents the frame buffer video hardware and allows application software to access the graphics hardware through a well-defined interface, abstracting from software how to manage the low-level hardware registers. The EPDC driver supports this model with one key caveat: the contents of the frame buffer are not automatically updated to the E Ink display. Instead, a custom API function call is required to trigger an update to the E Ink display. The details of this process are explained in the Section 6.4.5.3. The frame buffer driver is enabled by selecting the frame buffer option under the graphics parameters in the kernel configuration. To supplement the frame buffer driver, the kernel builder may also includes support for fonts and a startup logo. The frame buffer device depends on the virtual terminal (VT) console to switch from serial to graphics mode. The device is accessed through special device nodes, located in the /dev directory, as / dev/fb*. fb0 is generally the primary frame buffer. A frame buffer device is a memory device, such as /dev/mem, and has features similar to a memory device. Users can read it, write to it, seek to some location in it, and mmap() it (the main use). The difference is that the memory that appears in the special file is not the whole memory, but the frame buffer of some video hardware. The EPDC frame buffer driver (drivers/video/fbdev/mxc/mxc_epdc_fb.c on i.MX 6DualLite or drivers/video/ fbdev/mxc/mxc_epdc_v2_fb.c for generation-II EPDC on i.MX 7Dual) interacts closely with the generic Linux frame buffer driver (drivers/video/fbmem.c). For additional details on the frame buffer device, see documentation in the Linux kernel found in Documentation/fb/framebuffer.txt.

6.4.5.3 EPDC Frame Buffer Driver Extensions

E Ink display technology, in conjunction with the EPDC, has several features that distinguish it from standard LCD-based frame buffer devices. These differences introduce the need for API extensions to the frame buffer interface. The EPDC refreshes the E Ink display asynchronously and supports partial screen updates. Therefore, the EPDC requires notification from the user when the frame buffer contents have been modified and which region needs updating. Another unique characteristic of EPDC updates to the E Ink display is the long screen update latencies (between 300-980 ms), which introduces the need for a mechanism to allow the user to wait for a given screen update to complete. The custom API extensions to the frame buffer device are accessible both from user space applications and from within kernel space. The standard device IOCTL interface provides access to the custom API for user space applications. The IOCTL extensions, along with relevant data structures and definitions, can be found in include/linux/mxcfb_epdc.h. A full description of these IOCTLs can be found in the Programming Interface section Section 6.4.5.11. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual For kernel mode access to the custom API extensions, the IOCTL interface should be bypassed in favor of direct access to the underlying functions.

6.4.5.4 EPDC Panel Configuration

The EPDC driver is designed to flexibly support E Ink panels with a variety of panel resolutions, timing parameters, and waveform modes. The EPDC driver is kept panel-agnostic through the use of an EPDC panel mode structure, imx_epdc_fb_mode, which can be found in include/linux/mxcfb_epdc.h. struct imx_epdc_fb_mode { struct fb_videomode *vmode; int vscan_holdoff; int sdoed_width; int sdoed_delay; int sdoez_width; int sdoez_delay; int gdclk_hp_offs; int gdsp_offs; int gdoe_offs; int gdclk_offs; int num_ce; The imx_epdc_fb_mode structure consists of an fb_videomode structure reference and a set of EPD timing parameters. The fb_videomode structure defines the panel resolution and the basic timing parameters (pixel clock frequency, hsync and vsync margins) and the additional timing parameters in imx_epdc_fb_mode define EPD-specific timing parameters, such as the source and gate driver timings. For details on how to configure E Ink panel timing parameters, see the EPDC programming model section in the i.MX 6DualLite Manual (IMX7DRM). In addition to the EPDC panel mode data, functions may be passed to the EPDC driver to define how to handle the EPDC pins when the EPDC driver is enabled or disabled. These functions should disable the EPDC pins for purposes of power savings.

6.4.5.5 Boot Command Line Parameters

Additional configuration for the EPDC driver is provided through boot command line parameters. The format of the command line option is epdc video=mxcepdcfb:[panel_name],bpp=16 The EPDC driver parses these options and tries to match panel_name to the name of video mode specified in the imx_epdc_fb_mode panel mode structure. If no match is found, then the first panel mode provided in the platform data is used by the EPDC driver. The bpp setting from this command line sets the initial bits per pixel setting for the frame buffer. A setting of 32 or 24 selects the RGB888 pixel format, one of 16 selects RGB565 pixel format, while a setting of 8 selects 8-bit grayscale (Y8) format.

6.4.5.6 EPDC Waveform Loading

The EPDC driver requires a waveform file for proper operation. This waveform file contains the waveform information needed to generate the waveforms that drive updates to the E Ink panel. A pointer to the waveform file data is programmed into the EPDC before the first update is performed. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual There are two options for selecting a waveform file: 1. Select one of the default waveform files included in this BSP release. 2. Use a new waveform file that is specific to the E Ink panel being used. The waveform file is loaded by the EPDC driver using the Linux firmware APIs.

6.4.5.7 Using a Default Waveform File

The quickest and easiest way to get started using an E Ink panel and the EPDC driver is to use one of the default waveform files provided in the Linux BSP. This should enable updates to several different types of E Ink panel without a panel-specific waveform file. The drawback is that optimal quality should not be expected. Typically, using a non-panel-specific waveform file for an E Ink panel results in more ghosting artifacts and overall poorer color quality. The following default waveform files included in the BSP reside in /lib/firmware/imx/epdc:

epdc_E60_V110.fw - Default waveform for the 6.0 inch V110 E Ink panel.
epdc_E60_V220.fw - Default waveform for the 6.0 inch V220 E Ink panel (supports animation mode updates).
epdc_E97_V110.fw - Default waveform for the 9.7 inch V110 E Ink panel.
epdc_E060SCM.fw - Default waveform for the 6.0 inch Pearl E Ink panel (supports animation mode updates).
epdc_ED060XH2C1.fw - Default waveform for the 6.0 inch E Ink panel (No Reagl/-D Support by default. For Reagl/-D support, contact NXP support.) The EPDC driver attempts to load a waveform file with the name "epdc_[panel_name].fw" under the directory / lib/firmware/imx/epdc in rootfs, where panel_name refers to the string specified in the fb_videomode name field. This panel_name information should be provided to the EPDC driver through the kernel command line parameters described in the preceding chapter. For example, to load the epdc_E060SCM.fw default firmware file for a Pearl panel, set the EPDC kernel command line paratmeter to the following: video=mxcepdcfb:E060SCM,bpp=16

6.4.5.8 Using a Custom Waveform File

To ensure the optimal E Ink display quality, use a waveform file specific to E Ink panel being used. The raw waveform file type (.wbf) requires conversion to a format that can be understood and read by the EPDC. This conversion script is not included as part of the BSP. Therefore, contact NXP to acquire this conversion script. Once the waveform conversion script has been run on the raw waveform file, the converted waveform file should be renamed so that the EPDC driver can find it and load it. The driver is going to search for a waveform file with the name "epdc_[panel_name].fw" under the directory /lib/firmware/imx/epdc in rootfs, where panel_name refers to the string specified in the fb_videomode name field. For example, if the panel is named "E60_ABCD", then the converted waveform file should be named epdc_E60_ABCD.fw. Note: If the EPDC driver searches for a firmware waveform file that matches the names of one of the default waveform files (see preceding chapter), it will choose the default firmware files that are built into the BSP over any firmware file that has been added in the firmware search path. Therefore, if you leave the BSP so that it uses the default firmware files, make sure to use a panel name other than those associated with the default firmware files, as those default waveform files will be preferred and selected over a new waveform file placed in the firmware search path.

6.4.5.9 EPDC Panel Initialization

The framebuffer driver will not typically (see note below for exceptions) go through any hardware initialization steps when the framebuffer driver module is loaded. Instead, a subsequent user mode call must be made to request that the driver initialize itself for a specific EPD panel. To initialize the EPDC hardware and E Ink panel, RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual an FBIOPUT_VSCREENINFO ioctl call must be made, with the xres and yres fields of the fb_var_screeninfo parameter set to match the X and Y resolution of a supported E Ink panel type. To ensure that the EPDC driver receives the initialization request, the activate field of the fb_var_screeninfo parameter should be set to FB_ACTIVATE_FORCE. Note: The exception is when the FB Console driver is included in the kernel. When the EPDC driver registers the framebuffer device, the FB Console driver will subsequently make an FBIOPUT_VSCREENINFO ioctl call. This will in turn initialize the EPDC panel.

6.4.5.10 Grayscale Framebuffer Selection

The EPDC framebuffer driver supports the use of 8-bit grayscale (Y8) and 8-bit inverted grayscale (Y8 inverted) pixel formats for the framebuffer (in addition to the more common RGB565 pixel format). In order to configure the framebuffer format as 8-bit grayscale, the application would call the FBIOPUT_VSCREENINFO framebuffer ioctl. This ioctl takes an fb_var_screeninfo pointer as a parameter. This parameter specifies the attributes of the framebuffer and allows the application to request changes to the framebuffer format. There are two key members of the fb_var_screeninfo parameter that must be set in order to request a change to 8-bit grayscale format: bits_per_pixel and grayscale. bits_per_pixel must be set to 8 and grayscale must be set to one of the 2 valid grayscale format values: GRAYSCALE_8BIT or GRAYSCALE_8BIT_INVERTED. The following code snippet demonstrates a request to change the framebuffer to use the Y8 pixel format: fb_screen_info screen_info; screen_info.bits_per_pixel = 8; screen_info.grayscale = GRAYSCALE_8BIT; retval = ioctl(fd_fb0, FBIOPUT_VSCREENINFO, &screen_info);

6.4.5.11 Software Operation

The EPDC Frame Buffer is accessible from user space and from kernel space. A single set of functions describes the EPDC Frame Buffer driver extension. There are two modes for accessing these functions with user space using the IOCTL interface and kernel space using funcions directly. Each IOCTL and function combination is described next. MXCFB_SET_WAVEFORM_MODES / mxc_epdc_fb_set_waveform_modes() Description: Defines a mapping for common waveform modes. Parameters: mxcfb_waveform_modes *modes Pointer to a structure containing the waveform mode values for common waveform modes. These values must be configured in order for automatic waveform mode selection to function properly. MXCFB_SET_TEMPERATURE / mxc_epdc_fb_set_temperature Description: Set the temperature to be used by the EPDC driver in subsequent panel updates. Parameters: int32_t temperature Temperature value, in degrees Celsius. Note that this temperature setting may be overridden by setting the temperature value parameter to anything other than TEMP_USE_AMBIENT when using the MXCFB_SEND_UPDATE ioctl. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual MXCFB_SET_AUTO_UPDATE_MODE / mxc_epdc_fb_set_auto_update Description: Select between automatic and region update mode. Parameters: __u32 mode In region update mode, updates must be submitted via the MXCFB_SEND_UPDATE IOCTL. In automatic mode, updates are generated automatically by the driver by detecting pages in frame buffer memory region that have been modified. MXCFB_SET_UPDATE_SCHEME / mxc_epdc_fb_set_upd_scheme Description: Select a scheme that dictates how the flow of updates within the driver. Parameters: __u32 scheme Select of the following updates schemes: UPDATE_SCHEME_SNAPSHOT - In the Snapshot update scheme, the contents of the framebuffer are immediately processed and stored in a driver-internal memory buffer. By the time the call to MXCFB_SEND_UPDATE has completed, the framebuffer region is free and can be modified without affecting the integrity of the last update. If the update frame submission is delayed due to other pending updates, the original buffer contents will be displayed when the update is finally submitted to the EPDC hardware. If the update results in a collision, the original update contents will be resubmitted when the collision has cleared. UPDATE_SCHEME_QUEUE - The Queue update scheme uses a work queue to asynchronously handle the processing and submission of all updates. When an update is submitted via MXCFB_SEND_UPDATE, the update is added to the queue and then processed in order as EPDC hardware resources become available. As a result, the framebuffer contents processed and updated are not guaranteed to reflect what was present in the framebuffer when the update was sent to the driver. UPDATE_SCHEME_QUEUE_AND_MERGE - The Queue and Merge scheme uses the queueing concept from the Queue scheme, but adds a merging step. This means that, before an update is processed in the work queue, it is first compared with other pending updates. If any update matches the mode and flags of the current update and also overlaps the update region of the current update, then that update will be merged with the current update. After attempting to merge all pending updates, the final merged update will be processed and submitted. MXCFB_SEND_UPDATE / mxc_epdc_fb_send_update Description: Request a region of the frame buffer be updated to the display. Parameters: mxcfb_update_data *upd_data Pointer to a structure defining the region of the frame buffer, waveform mode, and collision mode for the current update. This structure also includes a flags field to select from one of the following update options: EPDC_FLAG_ENABLE_INVERSION - Enables inversion of all pixels in the update region. EPDC_FLAG_FORCE_MONOCHROME - Enables full black/white posterization of all pixels in the update region. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual EPDC_FLAG_USE_ALT_BUFFER - Enables updating from an alternate (non-framebuffer) memory buffer. If enabled, the final upd_data parameter includes detailed configuration information for the alternate memory buffer. MXCFB_WAIT_FOR_UPDATE_COMPLETE / mxc_epdc_fb_wait_update_complete Description: Block and wait for a previous update request to complete. Parameters: mxfb_update_marker_data marker_data The update_marker value used to identify a particular update (passed as a parameter in MXCFB_SEND_UPDATE IOCTL call) should be re-used here to wait for the update to complete. If the update was a collision test update, the collision_test variable will return the result indicating whether a collision occurred. MXCFB_SET_PWRDOWN_DELAY / mxc_epdc_fb_set_pwrdown_delay Description: Set the delay between the completion of all updates in the driver and when the driver should power down the EPDC and the E Ink display power supplies. Parameters: int32_t delay Input delay value in milliseconds. To disable EPDC power down altogether, use FB_POWERDOWN_DISABLE (defined below). MXCFB_GET_PWRDOWN_DELAY / mxc_epdc_fb_get_pwrdown_delay Description: Retrieve the driver's current power down delay value. Parameters: int32_t delay Output delay value in milliseconds.

6.4.5.12 Structures and Defines

#define GRAYSCALE_8BIT 0x1 #define GRAYSCALE_8BIT_INVERTED 0x2 #define AUTO_UPDATE_MODE_REGION_MODE #define AUTO_UPDATE_MODE_AUTOMATIC_MODE #define UPDATE_SCHEME_SNAPSHOT #define UPDATE_SCHEME_QUEUE #define UPDATE_SCHEME_QUEUE_AND_MERGE #define UPDATE_MODE_PARTIAL 0x0 RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

6.4.5.13 Source Code Structure

The table below lists the source files associated with the EPDC driver and headers for programming access. Table 72. EPDC Source RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 72. EPDC Source...continued

6.4.5.14 Menu Configuration Options

CONFIG_FB_MXC_EINK_PANEL - support for the Electrophoretic Display Controller. In menuconfig, select Device Drivers > Graphics Support > E-Ink Panel Framebuffer
CONFIG_FB_MXC_EINK_V2_PANEL - support for v2 Electrophoretic Display Controller. In menuconfig, this option is available with Device Drivers > Graphics support > E-Ink Panel Framebuffer based on EPDC V2
CONFIG_FB - includes frame buffer support and is enabled by default. In menuconfig select Device Drivers > Graphics support > Support for frame buffer devices
CONFIG_MXC_PXP_V2 - support for the PxP and required by the EPDC driver for processing (color space conversion, rotation, auto-waveform selection) framebuffer update regions. In menuconfig select Device Drivers > DMA Engine support > MXC PxP support
CONFIG_MXC_PXP_V3 - support for next level PxP and required by Generation-II EPDC driver for processing framebuffer update regions. In menuconfig select Device Drivers > DMA Engine support > MXC PxP V3 support

6.4.6 High-Definition Multimedia Interface (HDMI) and Display Port (DP) Overview

6.4.6.1 Introduction

provides an embedded Display Port (eDP) Transmitter including HDMI Tranmit (TX) Controller and PHY. The following are compliance versions.

HDMI 1.4 and 2.0
DVI 1.0
DP 1.3
eDP 1.4
HDCP 1.4/2.2 Each SoC HDMI solution is presented in separate chapters. Display Port on i.MX uses the same IP block but has a different specification. The following table lists which SOC support HDMI and Display Port and its supported version. SoC Features i.MX 6QuadPlus/Quad/Dual HDMI 1.4 on chip i.MX 7ULP HDMI 1.4 external chip i.MX 8M Quad HDMI 2.0/Display Port 1.3 on chip

Table 73. HDMI Support...continued HDMI Audio data source comes from S/PDIF TX.

6.4.6.2 Software Operation

manage common HDMI resources, including the HDMI registers, clocks, and IRQ.

6.4.6.3 Core

Map the HDMI register region and provide APIs for reading and writing to HDMI registers.
Perform one-time initialization of key HDMI registers.
Initialize the HDMI IRQ and provide shared APIs for enabling and disabling the IRQ.
Provide a means for sharing information between the audio and video drivers (e.g., the HDMI pixel clock).
Provide a means for synchronization between HDMI video and HDMI audio while blank/unblank, plug in/plug out events happen. HDMI audio cannot start work while HDMI cable is in the state of plug out or HDMI is in state of blank. Every time HDMI audio starts a playback, HDMI audio driver should register its PCM into core driver and unregister PCM when the playback is finished. Once HDMI video blank or cable plug out event happens, core driver would pause HDMI audio DMA controller if its PCM is registered. When HDMI is unblanked or cable plug in event happens, core driver would firstly check if the cable is in the state of plug in, the video state is unblank and the PCM is registered. If items listed above are all yes, core driver would restart HDMI audio DMA.

6.4.6.4 Display Device Registration and Initialization

During the HDMI video driver initialization, mxc_dispdrv_register() is called to register the HDMI
When the i.MX Frame Buffer driver is initialized, mxc_dispdrv_init() is called. This results in an init call

to all registered display devices.

The mxc_hdmi_disp_init() callback is executed. The HDMI driver receives a structure from the i.MX

receive a hotplug interrupt. devices to be registered as MXC Display Driver devices. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

6.4.6.5 Hotplug Handling and Video Mode Changes

Once the connection between the i.MX frame buffer driver and the HDMI has been established through the MXC Display Driver interface, the HDMI video driver waits for a hotplug interrupt indicating that a valid HDMI sink device is connected and ready to receive HDMI video data. Subsequent communications between the HDMI and i.MX Frame Buffer Driver are conducted through the Linux Frame Buffer APIs. The following list demonstrates the software flow to recognize a HDMI sink device and configure the ELCDIF FB driver to drive video output: 1. The HDMI video driver receives a hotplug interrupt and reads the EDID from the HDMI sink device constructing a list of video modes from the retrieved EDID information. Using either the video mode string from the Linux kernel command line (for the initial connection) or the most recent video mode (for a later HDMI cable connection), the HDMI driver selects a video mode from the mode list that is the closest match. 2. The HDMI video driver calls fb_set_var() to change the video mode in the i.MX Frame Buffer driver. The i.MX Frame Buffer driver completes its reconfiguration for the new mode. 3. As a result of calling fb_set_var(), a Frame Buffer notification is sent back to the HDMI driver indicating that an FB_EVENT_MODE_CHANGE has occurred. The HDMI driver configures the HDMI hardware for the new video mode. 4. Finally, the HDMI module is enabled to generate output to the HDMI sink device. The i.MX Frame Buffer Driver will align to the display interface specific to each SoC as noted for each SoC HDMI chapter.

6.4.6.6 Audio

Since the HDMI Tx audio driver uses the ALSA SoC framework, it is broken into several files as listed in the source code structure sections of each hdmi chapter. Most of the code is in the platform DMA driver (sound/ soc/imx/imx-hdmi-dma.c) and the CODEC driver (sound/soc/codecs/mxc_hdmi.c). The machine driver (sound/ soc/imx/imx-hdmi.c) allocates the SoC audio device and links all the SoC components together. The DAI driver (sound/soc/imx/imx-hdmi-dai.c) is a SoC requirements. It is primarily used to get the platform data. The HDMI CODEC driver does most of the initialization of the HDMI audio sampler. Note that the HDMI Tx block only implements the AHB DMA audio and not the other audio interfaces (SSI, S/PDIF, etc). The other main function of the HDMI CODEC driver is to set up a struct of the IEC header information which needs to go into the audio stream. Since the struct is hooked into the ALSA layer, IEC settings will be accessible in userspace using the ‘iecset’ utility. The platform DMA driver handles the HDMI Tx block DMA engine. Note that HDMI audio uses the HDMI block DMA as well as SDMA. SDMA is used to implement the multi-buffer mechanism. Since the HDMI Tx block does not automatically merge the IEC audio header information into the audio stream, the platform DMA driver does the merging by using hdmi_dma_copy() (for no memory map use) or hdmi_dma_mmap_copy() (for memory map mode use) function before sending the buffers out. Note that, due to IEC audio header adding operation, it is possible that the user space application may not be able to get enough CPU periods to feed the data into HDMI audio driver in time, especially when system loading is high. In this case, some spark noise will be heard. In a different audio framework (ALSA LIB, or PULSE AUDIO), a different log about this noise may be printed. For example, in ALSA LIB, logs like "underrung!!! at least * ms is lost" are printed. HDMI audio playback depends on HDMI pixel clock. Therefore, while in the state of HDMI blank and cable plug out, HDMI audio is either stopped or can't be played. See detailed information in software_operation_core. Note that, because HDMI audio driver needs to add the IEC header, the driver needs to know the amount of data already written into the HDMI audio driver. If application is not able to decipher the amount of data written, for example DMIX plugin in ALSA LIB, the HDMI audio driver is not able to work properly. There will be no sound heard. The HDMI audio supports the features below: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

Playback sample rate – 32k, 44.1k, 48k, 88.2k, 96k, 176.4k, 192k – HDMI sink capability
Playback Channels: – 2, 4, 6, 8 – HDMI sink capability
Playback audio formats: – SNDRV_PCM_FMTBIT_S16_LE 6.4.6.7 i.MX 8 Display Port

6.4.6.7.1 Introduction

The High-Definition Multimedia Interface (HDMI) driver supports the on-chip Cadence HDTX IP module on the i.MX 8QuadMax and iMX 8MQuad providing capability to transfer uncompressed video, audio, and data using a single cable. The HDMI driver is divided into three sub-components: A video display device driver that integrates with the DPU/DCSS DRM driver, an audio driver that integrates with the ALSA/SoC sub-system, and a core API driver which manages the shared software and hardware resources of the HDMI driver. HDTX IP supports the following features:

Compliant with HDMI 2.0 Specification.
Supports up to 600 Mhz pixel CLK.
All video formats are supported, including dual-vide, stereo, and all colorimetry options (RGB, YCbCr444/422, and YCbCr420).
These audio formats are supported: PCM, HBR, DST, one-bit-audio, multi-stream, and 3D audio.
All info-frames are supported.
APB interface is used to control and read status information.
Embedded-CPU performs all protocol-specific tasks that simplify SoC integration: – HDCP 1.4/2.2 – Audio Return Channel (ARC) The HD Display TX Controller supports one or more of the protocols, such as HDMI, DisplayPort, or eDP. Each protocol requires a different firmware binaries. The figure below describes this. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Figure 25. HDMI HW Integration the data-path (video, audio, or info-frames).

Direct access to the HW registers for debugging purposes.
Direct access to I-MEM and D-MEM (during boot) for FW download.
Direct access to the HW registers of designated HW modules during operational mode (modules that are not controlled by the FW).
Indirect access to the HW registers of designated HW modules during operational mode, by communicating with FW over the command interface (using GENERAL_WRITE_REGISTER and GENERAL_READ_REGISTER commands).
Communication with different FW modules over a mailbox using the command interface.

6.4.6.7.2 Software Operation

The HDP DRM driver require a Core API driver component to the configurated HDMI FW. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

6.4.6.7.3 Source Code Structure

platform driver, and HDMI audio driver.

sound/soc/fsl/fsl_hdmi.c
sound/soc/fsl/imx-hdmi.c
sound/soc/fsl/hdmi_pcm.S
sound/soc/fsl/imx-hdmi-dma.c
sound/soc/fsl/imx-cdnhdmi.c HDMI Sound Driver

Table 74. HDP Core API Driver File List

6.4.6.7.4 Menu Configuration Options

6.4.6.8.1 Introduction

uncompressed video, audio, and data using a single cable.

Video display device driver that integrates with the Linux Frame Buffer API
Audio driver that integrates with the ALSA/SoC sub-system
CEC driver
Multifunction device (MFD) driver which manages the shared software and hardware resources of the HDMI driver. The HDMI driver supports the following features:
Integration with the MXC Display Device framework (for managing display device connections with the IPU(s))
HDMI video output up to 1080p60 resolution RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Support for reading EDID information from an HDMI sink device
Hotplug detection
Support CEC
Automated clock management to minimize power consumption
Support for system suspend/resume
HDMI audio playback (2, 4, 6, or 8 channels, 16-bit, for sample rates 32-KHz to 192-KHz)
IEC audio header information exposed through ALSA using ‘iecset’ utility The HDMI module receives video data from the Image Processing Unit (IPU), audio data from the external memory interface, and control data from the CPU, as shown in the figure below. Output data is transmitted via three Transition-Minimized Differential Signaling (TMDS) channels to an HDMI sink device external to the SoC. The HDMI also carries a VESA Data Display Channel (DDC). The DDC is an I2C interface which allows the HDMI source to query the HDMI sink for Extended Displa-y Identification Data (EDID). A CEC channel provides optional high-level control functions between the source and sink device. aaa-053509 Video I/F Audio DMA HDMI TX controller HDMI TX AHB master Parallel I/F Control regs HDMI TX PHY CEC DDC(I2C) HDCPRNDGenGasketClocks Interrupts HDCP keys storage Image processing unit External memory interface HDCP revocation RAM AHB slave TMDS_DATA 3 TMDS_CLK

NXP Semiconductors RM00293 i.MX Linux Reference Manual aaa-053513 Memory IPU #1 DI0 DI1 IPU #2 DI0 DI1 Parallel LCD, LVDS, MIPI DPI, etc HDMI HDMI out HDMI_MUX HDMI_MUX_CTRL Figure 27. IPU-HDMI Hardware Interconnection

6.4.6.8.2 Software Operation

HDMI video driver and the Linux Frame Buffer subsystem.

Applications

i.MX 6 framebuffer and display device software architecture HDMI audio driver HDMI MFD core MIPI DPI LDB Framebuffer core MXC display driver Parallel LCD drivers LDB driver (LVDS) MIPI DPI driver HDMI video driver Figure 28. HDMI Video SW Architecture correct video input from the IPU. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

6.4.6.8.3 CEC

Figure 29. HDMI CEC SW Architecture

6.4.6.8.4 Source Code Structure

The HDMI source code is provided in the HDMI core driver, the HDMI display driver, and the HDMI audio driver. are provided in imx-lib repo on codeaurraforum. are provided in imx-lib on Github nxp-imx project. Table 75. HDMI Source

6.4.6.8.5 Menu Configuration Options

6.4.6.9 External HDMI

6.4.6.9.1 Introduction

providing capability to transfer uncompressed video, audio, and data using a single cable.

HDMI video output supports 1080p60 and 720p60 resolutions.
Support for reading EDID information from an HDMI sink device for video.
Hotplug detection
HDMI audio playback (2 channels, 16/24 bit, 44.1 KHz sample rate) External HDMI is supported on i.MX 6 7ULP SoC. Output data is transmitted via three Transition-Minimized Differential Signaling (TMDS) channels to an HDMI sink device external to the SoC. Additionally, the HDMI carries a VESA Data Display Channel (DDC). DDC is an I2C interface which allows the HDMI source to query the HDMI sink for Extended Display Identification Data (EDID). A CEC channel provides optional high-level control functions between the source and sink devices.

6.4.6.9.2 Software Operation

The audio output depends on video display.

6.4.6.9.3 Source Code Structure

The source code for the HDMI driver is divided into the HDMI display driver and HDMI audio driver. drivers/video/fbdev/mxc/mxsfb_sii902x.c HDMI display driver implementation. sound/soc/fsl/imx-spdif.c S/PDIF Audio SoC Machine driver implementation. sound/soc/fsl/fsl_spdif.c S/PDIF Audio SoC DAI driver implementation. Table 76. HDMI Source RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

6.4.6.9.4 Menu Configuration Options

There are two main Linux kernel configuration options used to select and include HDMI driver functionality in the Linux OS image. The following configuration options are required to enable HDMI support. The CONFIG_FB_MXS_SII902X option provides support for the Sii902x HDMI video driver and can be selected with Device Drivers > Support for frame buffer devices > Si Image SII9022 DVI/HDMI Interface Chip. HDMI video on i.MX 6Sololite is dependent on MXC ELCDIF Framebuffer. The CONFIG_SND_SOC_IMX_SII902X option provides support for the HDMI Audio driver and can be selected with Device Drivers > Sound card support > ALSA for SoC audio support > ommon SoC Audio options for Freescale CPUs: > SoC Audio support for i.MX boards with sii902x

6.5 Video for Linux 2 (V4L2)

6.5.1 Introduction

The Video for Linux Two (V4L2) driver is plug-in for the V4L2 framework that enables support for camera capture and display. Some i.MX SoC support V4L2 based on the associated images processing units and capture hardware. For more information on V4L2 go to the API specification for Linux Video for Linux 2 available at Linux Media Subsystem Documentation. The V4L2 APIs enable camera and display controls but i.MX 8 only supports V4L2 capture and not display using the DPU instead for display control. i.MX 6 and i.MX 7 use both capture and display V4L2. 6.5.1.1 i.MX 8 DPU V4L2 The Video for Linux Two (V4L2) driver on i.MX 8 is plug-in for the V4L2 framework that enables support for camera capture only with the Display Processing Unit (DPU). The V4L2 DPU camera driver supports only basic capture. The V4l2 capture device takes incoming video images, either from a camera or a TV decoder, and captures the images to memory. The features supported by the V4L2 driver are as follows:

RGB 24-bit and YUV 4:2:2 interleaved formats for capture interface
Plug-in of different sensor drivers
Streaming (queued) input buffer
Programmable input and output pixel format and size
RGB 16, 24, and 32-bit, YUV 4:2:0, and 4:2:2 interleaved input formats The command modprobe mxc_v4l2_capture must be run before using V4L2 camera functions.

6.5.1.2 PxP V4L2

The Video for Linux Two (V4L2) drivers for PxP are used for dsiplay output only. 6.5.1.3 i.MX 6 with IPU V4L2 The Video for Linux Two (V4L2) drivers are plug-ins to the V4L2 framework that enable support for camera and preprocessing functions, as well as video and post-processing functions. The V4L2 camera driver implements support for all camera-related functions. The V4l2 capture device takes incoming video images, either from a RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual camera or a stream, and manipulates them. The output device takes video and manipulates it, then sends it to a display or similar device. The features supported by the IPU V4L2 driver are the follows:

Direct preview and output to SDC foreground overlay plane (with synchronized to LCD refresh)
Direct preview to graphics frame buffer (without synchronized to LCD refresh)
Color keying or alpha blending of frame buffer and overlay planes
Streaming (queued) capture from IPU encoding channel
Direct (raw Bayer) still capture (sensor dependent)
Programmable pixel format, size, frame rate for preview and capture
Programmable rotation and flipping using custom API
RGB 16-bit, 24-bit, and 32-bit preview formats
Raw Bayer (still only, sensor dependent), RGB 16, 24, and 32-bit, YUV 4:2:0 and 4:2:2 planar, YUV 4:2:2 interleaved, and JPEG formats for capture
Control of sensor properties including exposure, white-balance, brightness, contrast, and so on
Plug-in of different sensor drivers
Link post-processing resize and CSC, rotation, and display IPU channels
Streaming (queued) input buffer
Double buffering of overlay and intermediate (rotation) buffers
Configurable 3+ buffering of input buffers
Programmable input and output pixel format and size
Programmable scaling and frame rate
RGB 16, 24, and 32-bit, YUV 4:2:0 and 4:2:2 planar, and YUV 4:2:2 interleaved input formats
TV output The command modprobe mxc_v4l2_capture must be run before V4L2 functions.

6.5.1.4 IPU V4L2 Capture Device

The V4L2 capture device includes two interfaces:

Capture interface-uses IPU pre-processing ENC channels to record the YCrCb video stream
Overlay interface-uses the IPU device driver to display the preview video to the SDC foreground and background panel. V4L2 capture support can be selected during kernel configuration. The driver includes two layers. The top layer is the common Video for Linux driver, which contains chain buffer management, stream API and other ioctl interfaces. The files for this device are located in drivers/media/platform/mxc/capture/ The V4L2 capture device driver is in the mxc_v4l2_capture.c file. The low level overlay driver is in the ipu_fg_overlay_sdc.c, ipu_bg_overlay_sdc.c This code (ipu_prp_enc.c) interfaces with the IPU ENC hardware, and ipu_still.c interfaces with the IPU CSI hardware. Sensor frame rate control is handled by VIDIOC_S_PARM ioctl. Before the frame rate is set, the sensor turns on the AE and AWB turn on. The frame rate may change depending on light sensor samples. Drivers for specific cameras can be found in drivers/media/platform/mxc/capture/ RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

6.5.2 V4L2 Capture Device

The V4L2 capture device includes two interfaces:

Capture interface-uses i.MX processing engine to record the YCrCb video stream
Overlay interface-uses i.MX processing engine to display the preview video to the SDC foreground and background panel. The driver includes two layers. The top layer is the common Video for Linux driver, which contains chain buffer management, stream API and other ioctl interfaces. The low level layer is the i.MX SoC implementation for the display engine associated with the SoC detailed in each V4l2 SoC chapter.

6.5.2.1 V4L2 Capture IOCTLs

Currently, the memory map stream API is supported. Supported V4L2 IOCTLs include the following:

VIDIOC_QUERYCAP
VIDIOC_G_FMT
VIDIOC_S_FMT
VIDIOC_REQBUFS
VIDIOC_QUERYBUF
VIDIOC_QBUF
VIDIOC_DQBUF
VIDIOC_STREAMON
VIDIOC_STREAMOFF
VIDIOC_OVERLAY
VIDIOC_G_FBUF
VIDIOC_S_FBUF
VIDIOC_G_CTRL
VIDIOC_S_CTRL
VIDIOC_CROPCAP
VIDIOC_G_CROP
VIDIOC_S_CROP
VIDIOC_S_PARM
VIDIOC_G_PARM
VIDIOC_ENUMSTD
VIDIOC_G_STD
VIDIOC_S_STD
VIDIOC_ENUMOUTPUT
VIDIOC_G_OUTPUT
VIDIOC_S_OUTPUT V4L2 control code has been extended to provide support for rotation. The ID is V4L2_CID_PRIVATE_BASE. Supported values include:
0-Normal operation
1-Vertical flip
2-Horizontal flip
3-180° rotation
4-90° rotation clockwise RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

5-90° rotation clockwise and vertical flip
6-90° rotation clockwise and horizontal flip
7-90° rotation counter-clockwise The figure below shows a block diagram of V4L2 Capture API interaction. C om m o n video for linu x 2 d rive r a aa - 0 53 5 3 0 A pplicatio n m xc _v4l_ ca m era _ opsP oll w ait C hain of buffers S etup th e E B A of ID M A ch annels ac co rdin g to th e buffe r q ueue d S ingn al the polling functio n w hen fra m e ready S trea m on /off, op en /c lose U se r spa ce K erne l spac e Low er level M X C driver m xc _v4l_ ca m era _ opsIS R

Figure 30. Video4Linux2 Capture API Interaction

6.5.2.2 Use of the V4L2 Capture APIs

Sets the capture pixel format and size by IOCTL VIDIOC_S_FMT.
Sets the control information by IOCTL VIDIOC_S_CTRL for rotation usage.
Requests a buffer using IOCTL VIDIOC_REQBUFS. The common V4L2 driver creates a chain of buffers

(currently the maximum number of frames is 3).

Memory maps the buffer to its user space.
Queues buffers using the IOCTL command VIDIOC_QBUF.
Starts the stream using the IOCTL VIDIOC_STREAMON. This IOCTL enables the i.MX Processing Enginee
Takes the buffer from the queue using the IOCTL VIDIOC_DQBUF. This IOCTL blocks until it has been
Stores the buffer to a YCrCb file.
Replaces the buffer in the queue of the V4L2 driver by executing VIDIOC_QBUF again.
Sets the capture pixel format and size by executing the IOCTL VIDIOC_S_FMT.
Reads one frame still image with YUV422.

NXP Semiconductors RM00293 i.MX Linux Reference Manual 1. Sets the overlay window by IOCTL VIDIOC_S_FMT. 2. Turns on overlay task by IOCTL VIDIOC_OVERLAY. 3. Turns off overlay task by IOCTL VIDIOC_OVERLAY.

6.5.3 V4L2 Output Device

The driver implements the standard V4L2 API for output devices. V4L2 output device support can be selected during kernel configuration. The driver is available at drivers/media/platform/mxc/output/mxc_vout.c

6.5.3.1 V4L2 Output IOCTLs

Currently, the memory map stream API is supported. Supported V4L2 IOCTLs include the following:

VIDIOC_QUERYCAP
VIDIOC_REQBUFS
VIDIOC_G_FMT
VIDIOC_S_FMT
VIDIOC_QUERYBUF
VIDIOC_QBUF
VIDIOC_DQBUF
VIDIOC_STREAMON
VIDIOC_STREAMOFF
VIDIOC_G_CTRL
VIDIOC_S_CTRL
VIDIOC_CROPCAP
VIDIOC_G_CROP
VIDIOC_S_CROP
VIDIOC_ENUM_FMT The V4L2 control code has been extended to provide support for de-interlace motion. For this use, the ID is V4L2_CID_MXC_MOTION. Supported values include the following:
0-Medium motion
1-Low motion
2-High motion

6.5.3.2 Use of the V4L2 Output APIs

This section describes a sample V4L2 output process that uses the V4L2 output APIs. The application completes the following steps: 1. Sets the input pixel format and size using IOCTL VIDIOC_S_FMT. 2. Sets the control information using IOCTL VIDIOC_S_CTRL, for rotation, de-interlace motion(if needed). 3. Sets the output information using IOCTL VIDIOC_S_CROP. 4. Requests a buffer using IOCTL VIDIOC_REQBUFS. The common V4L2 driver creates a chain of buffers (not allocated yet). 5. Memory maps the buffer to its user space. 6. Executes the IOCTL VIDIOC_QUERYBUF to query buffers. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Passes the data that requires post-processing to the buffer.
Queues the buffer using the IOCTL command VIDIOC_QBUF.
Executes the IOCTL VIDIOC_DQBUF to dequeue buffers.
Starts the stream by executing IOCTL VIDIOC_STREAMON.
Stop the stream by excuting IOCTL VIDIOC_STREAMOFF.

6.5.4 Software Operatoins

6.5.4.1 Source Code Structure

The following table lists the source and header files associated with the V4L2 drivers. Table 77. V4L2 Driver Files Drivers for V4L2 cameras can be found in divers/media/platform/mxc/capture.

6.5.4.2 Menu Configuration Options

The kernel configuration options are provided below.

6.6 Video Analog-to-Digital Converter (VADC)

6.6.1 Introduction

decoder. The AFE accepts NTSC or PAL input from a device, such as an analog camera. The two parts are configured in the VADC driver. The video decoder outputs the YUV444-formatted data. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Internal voltage and current reference generator
10-bit resolution (9.5 bit ENOB at 66.5 Msps)
4 analog inputs, with all inputs available for CVBS
Programmable anti-aliasing filter, gain, and clamp The video decoder has the following features:
NTSC/PAL decoder
Direct data path (no complex resampling)
Automatic standards detection
2D adaptive comb filter
Datapath/clocking architecture encompasses a time base corrector for VCR signals
Luma passband is flat to > 6 MHz

6.6.2 Software Operation

The VADC driver is located under the Linux V4L2 architecture and it implements the V4L2 capture interfaces. and close the camera for image capture.

Capture stream mode The following picture format is supported:
YUV444 The following picture sizes are supported:
PAL
NTSC

6.6.3 Source Code Structure

Table below shows the VADC driver source files available in the drivers/media/platform/mxc/capture. Table 78. VADC Driver Files

6.6.4 Menu Configuration Options

6.6.5 DTS Configuration

The VADC input selected to vin1 and CSI2 is used to capture the VADC data.

6.7 Video Processing Unit (VPU)

6.7.1 Introduction

The VPU hardware performs all of the codec computation and most of the bitstream parsing/packeting. Table 79. VPU Malone is decoder while Windsor is encoder. Both comes from Amphion.

hantro/ (8mq/8mp decoder)
hantro_845/ (8mini decoder)
hantro_845_h1/ (8mini encoder)
hantro_vc8000e (8mp encoder)

6.7.2 Software Operation

Module initialization which initializes the module with the device-specific structure
Device initialization which initializes the VPU clock and hardware and request the IRQ
Interrupt servicing routine which supports events that one frame has been finished
File operation routine which provides the following interfaces to user space:
File open
File release
File IOCTL to provide interface for memory allocating and releasing
Memory map for register and memory accessing in user space RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Codec lib
Initializes codec system
Sets codec system configuration
Controls codec system by command
Reports codec status and result
System I/O operation
Requests and frees memory
Maps and unmaps memory/register to user space
Device management User space application for simple verification:
Read video raw data
YUV file dump
General options to configure the codec behavior The following figure shows a simple workflow shown in the H.264 example. H.264 Application aaa-053532 Receive H.264 stream start H264Declnit(&declnst, 0, 0, 0) H264DEC_OK Receive first H.264 coded data slice H.264 Decoder Initialize H.264 decoder Decode H.264 parameter sets Activate parameter sets based on information contained in first picture slice (IDR picture) H264DecDecode(declnst, &declnput, &decOutput) H264DecDecode(declnst, &declnput, &decOutput) H264DecGetInfo(declnst, &declnfo) H264DEC_STRM_PROCESSED H264DEC_HDRS_RDY Call H264DecGetInfo to obtain information about decoded stream; picture dimensions, cropping info etc. H264DEC_OK

NXP Semiconductors RM00293 i.MX Linux Reference Manual H.264 Application aaa-053533 H264DecNextPicture(declnst, &decPicture, 0) status H.264 Decoder Get next picture for display Decode H.264 decoding unit Get next picture from buffer Release resources Display picture Receive H.264 decoding unit Status == H264DEC_PIC_RDY NoYesNo No No H264DecDecode(declnst, &decInput, &decOutput) Display picture Yes Yes Stream buffer empty? Stream ended? No Yes Status == H264DEC_PIC_RDY status status H264DecRelease(declnst) H264DecNextPicture(decInst, &decPicture, 1) There is only a user-space programming interface for the VPU module. A user in the application layer cannot access the kernel driver interface directly. The VPU library accesses the kernel driver interface for users. There is one unified interface to wrap all different video formats. The following are the related APIs: CODEC_STATE decoder_decode_xxx(CODEC_PROTOTYPE * arg,STREAM_BUFFER * buf, OMX_U32 * consumed,FRAME * frame); CODEC_STATE decoder_getinfo_xxx(CODEC_PROTOTYPE * arg,STREAM_INFO * pkg); CODEC_STATE decoder_setppargs_xxx(CODEC_PROTOTYPE * codec,PP_ARGS * args); CODEC_STATE decoder_setframebuffer_xxx(CODEC_PROTOTYPE * arg, BUFFER *buff,OMX_U32 available_buffers); CODEC_STATE decoder_pictureconsumed_xxx(CODEC_PROTOTYPE * arg, BUFFER *buff); CODEC_STATE decoder_getframe_mpeg4(CODEC_PROTOTYPE * arg, FRAME * frame,OMX_BOOL eos); FRAME_BUFFER_INFO decoder_getframebufferinfo_xxx(CODEC_PROTOTYPE * arg); CODEC_STATE decoder_endofstream_xxx(CODEC_PROTOTYPE * arg) OMX_S32 decoder_scanframe_xxx(CODEC_PROTOTYPE * arg, STREAM_BUFFER * buf,OMX_U32 * first, OMX_U32 * last); CODEC_STATE decoder_abort_xxx(CODEC_PROTOTYPE * arg); CODEC_STATE decoder_abortafter_xxx(CODEC_PROTOTYPE * arg); RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

6.7.3 Source Code Structure

Table below lists the kernel space source files available drivers/mxc/vpu. Table 80. VPU Driver Files Table 81. MX6 VPU Library Files RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 82. VPU firmware Files

6.7.4 Menu Configuration Options

For i.MX 8M, select Device Drivers > MXC support drivers > MXC HANTRO (Video Processing Unit) support. V4L platform devices -> Amphion VPU (Video Processing Unit) Codec IP. For i.MX 95 WAVE6, select Device Drivers -> MXC support drivers -> WAVE6 VPU.

6.8 JPEG Encoder and Decoder

6.8.1 Introduction

JPEG is a part of the ISI domain, while for i.MX 9, it is a part of the VPU domain. JPEG Decoder consists of a JPEG decoder core (JPEG-D-X) and its corresponding wrapper. configuration mode and an encoding mode.

In configuration mode, it can fetch the configuration bitstream from the system memory and feed it to the encoder.
In encoding mode, it can fetch the image pixel data through the AXI bus interface and feed to the Encoder Core for encoding. Similarly, the JPEG Decoder Wrapper provides the interface for Cast JPEG Decoder core. The JPEG wrappers supports multiple image encoding through context switching, by the encoding descriptors. There are four bitstream slots. Each one can be enabled independently by chained descriptors. The JPEG encoder and decoder support a maximum horizontal resolution of 8K (0x2000) pixels. The horizontal resolution needs to be integer times of 8. It is the same for the vertical resolution. For YUV422 and YUV420, the resolution must be multiple of 16. The image size may be up to 64K x 64K. The JPEG encoder and decoder support 8-bit and 12-bit precision.

6.8.2 Overview of the JPEG Encoder and Decoder Driver

NXP Semiconductors RM00293 i.MX Linux Reference Manual The JPEG encoder and decoder driver implements a subset of the IOCTLs exposed by the V4L2 framework, namely the following v4l2_ioctl_ops:

VIDIOC_QUERYCAP
VIDIOC_ENUM_FMT_VID_CAP
VIDIOC_ENUM_FMT_VID_OUT
VIDIOC_QBUF
VIDIOC_DQBUF
VIDIOC_CREATE_BUFS
VIDIOC_PREPARE_BUF
VIDIOC_REQBUFS
VIDIOC_QUERYBUF
VIDIOC_STREAMON
VIDIOC_STREAMOFF User applications may interact with the driver through the supported V4L2 IOCTLs. The JPEG driver supports streaming I/O through memory mapping. This capability is exposed through the V4L2_CAP_STREAMING flag, when the VIDIOC_QUERYCAP is used. Streaming is an I/O method where only pointers to buffers are exchanged between the application and driver, but the data itself is not copied. Memory mapping is primarily intended to map buffers in the device memory into the application’s address space. The JPEG driver supports buffers memory-mapping through the multi-planar API. For more information on streaming I/O, see Streaming I/O (Memory Mapping).

6.8.3 Limitations of the JPEG Encoder/Decoder Driver

The hardware, namely the JPEG wrappers, supports multiple-image encoding through context switching. The driver does not use context switching, and only one of the available four slots is used. The hardware supports bitstream buffer half/full and returns features for bitstream buffer management, but the driver does not use them. The hardware supports the following formats: YUV444, YUV420, YUV422, RGB, ARGB, and Gray. The driver supports the same formats as the hardware. The driver supports JPEG images encoding and decoding through gstreamer, but it does not yet support MJPEG videos. The hardware has the limitation that the decoded image resolution should be larger than 64x64. The hardware has the limitation that the decoded image should have at least a default Huffman table (DHT marker section should be present in the JPEG input stream). If the decoded JPEG does not have a DHT, the driver provides a default one. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

7 Audio

7.1 Advanced Linux Sound Architecture (ALSA) System on a Chip (ASoC) Sound

7.1.1 ALSA Sound Driver Introduction

The Advanced Linux Sound Architecture (ALSA), now the most popular architecture in Linux system, provides audio and MIDI functionality to the Linux operating system. ALSA has the following significant features:

Efficient support for all types of audio interfaces, from consumer sound cards to professional multichannel audio interfaces.
Fully modularized sound drivers.
SMP and thread-safe design.
User space library (alsa-lib) to simplify application programming and provide higher level functionality.
Support for the older Open Sound System (OSS) API, providing binary compatibility for most OSS programs. ALSA System on Chip (ASoC) layer is designed for SoC audio. The overall project goal of the ASoC layer provides better ALSA support for embedded system on chip processors and portable audio CODECs. The ASoC layer also provides the following features:
CODEC independence. Allows reuse of CODEC drivers on other platforms and machines.
Easy I2S/PCM audio interface setup between CODEC and SoC. Each SoC interface and CODEC registers its audio interface capabilities with the core.
Dynamic Audio Power Management (DAPM). DAPM is an ASoC technology designed to minimize audio subsystem power consumption no matter what audio-use case is active. DAPM guarantees the lowest audio power state at all times and is completely transparent to user space audio components. DAPM is ideal for mobile devices or devices with complex audio requirements.
Pop and click reduction. Pops and clicks can be reduced by powering the CODEC up/down in the correct sequence (including using digital mute). ASoC signals the CODEC when to change power states.
Machine-specific controls. Allow machines to add controls to the sound card, for example, volume control for speaker amp. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Figure 32. ALSA SoC Software Architecture

Machine driver-handles any machine-specific controls and audio events, such as turning on an external amp at the beginning of playback.
Platform driver-contains the audio DMA engine and audio interface drivers (for example, I2S, AC97, PCM) for that platform.
CODEC driver-platform independent and contains audio controls, audio interface capabilities, the CODEC DAPM definition, and CODEC I/O functions. More detailed information about ASoC can be found in the Linux kernel documentation in the Linux OS source tree at linux/Documentation/sound/alsa/soc and at www.alsa-project.org/main/index.php/ASoC.

7.1.2 SoC Sound Card

FM CODEC (si4763) drivers are implemented using ASoC architecture. card only supports 2 or 6 channels audio playback. The AM/FM sound card supports radio PCM capture. The 7.1 CODEC is only supported on the i.MX 6Quad and i.MX 6Solo SABRE Auto platform. The AM/FM CODEC is only supported on the i.MX 6Quad and i.MX 6Solo SABRE Auto platform. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

7.1.2.1 Stereo CODEC Features

The stereo CODEC supports the following features:

Sample rates for playback and capture are 8 KHz, 32 KHz, 44.1 KHz, 48 KHz, and 96 KHz
Channels: – Playback: supports two channels. – Capture: supports two channels.
Audio formats: – Playback: – SNDRV_PCM_FMTBIT_S16_LE – SNDRV_PCM_FMTBIT_S20_3LE – SNDRV_PCM_FMTBIT_S24_LE – Capture: – SNDRV_PCM_FMTBIT_S16_LE – SNDRV_PCM_FMTBIT_S20_3LE – SNDRV_PCM_FMTBIT_S24_LE 7.1.2.2 7.1 Audio Codec Features
Sample rates for playback and record: – 48 KHz, 96 KHz, 192 KHz enabled)
Channels: – Playback: 2, 4, 6, 8 channels – Playback(ASRC enabled): 2, 6 channels – Capture: 2, 4 channels
Audio formats: – Playback: – SNDRV_PCM_FMTBIT_S16_LE – SNDRV_PCM_FMTBIT_S20_3LE – SNDRV_PCM_FMTBIT_S24_LE – Playback(ASRC enabled): – SNDRV_PCM_FMTBIT_S16_LE – SNDRV_PCM_FMTBIT_S24_LE – Capture: – SNDRV_PCM_FMTBIT_S16_LE – SNDRV_PCM_FMTBIT_S20_3LE – SNDRV_PCM_FMTBIT_S24_LE

7.1.2.3 AM/FM Codec Features

Supported sample rate for Capture: 48 KHz
Supported channels: – Capture: supports two channels.
Supported audio formats: – Capture: SNDRV_PCM_FMTBIT_S16_LE RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

7.1.2.4 Sound Card Information

The registered sound card information can be listed as follows using the commands aplay -l and arecord -l. For example, the stereo sound card is registered as card 0. root@ /$ aplay -l ** List of PLAYBACK Hardware Devices ** card 0: wm8962audio [wm8962-audio], device 0: HiFi wm8962-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0

7.1.3 Hardware Operation

The following sections describe the hardware operation of the ASoC driver.

7.1.3.1 Stereo Audio CODEC

The stereo audio CODEC is controlled by the I2C interface. The audio data is transferred from the user data buffer to/from the SSI FIFO through the DMA channel. The DMA channel is selected according to the audio sample bits. AUDMUX is used to set up the path between the SSI port and the output port which connects with the CODEC. The CODEC works in master mode and provides the BCLK and LRCLK. The BCLK and LRCLK can be configured according to the audio sample rate. The WM8958, WM8960, and WM8962 ASoC CODEC driver exports the audio record/ playback/mixer APIs according to the ASoC architecture. The CODEC driver is generic and hardware independent code that configures the CODEC to provide audio capture and playback. It does not contain code that is specific to the target platform or machine. The CODEC driver handles:

CODEC DAI and PCM configuration
CODEC control I/O-using I2C
Mixers and audio controls
CODEC audio operations
DAC Digital mute control The WM8958, WM8960, and WM8962 CODEC are registered as an I2C client when the module initializes. The APIs are exported to the upper layer by the structure snd_soc_dai_ops . Headphone insertion/removal can be detected through a GPIO interrupt signal. SSI dual FIFO features are enabled by default. 7.1.3.2 7.1 Audio Codec The 7.1 audio codec includes 8-channel DAC and 4-channel ADC, which are controlled by the I2C interface. The audio data is transferred from the user data buffer to the ESAI fifo, through a DMA channel. The DMA channel is selected according to audio sample bits. The codec works in slave mode as the ESAI provides the BCLK and LRCLK. The BCLK and LRCLK can be configured according to the audio sample rate. The ESAI supports up to eight audio output ports. While enabling ASRC, 7.1 audio codec supports 2 or 6 channel playback through ASRC. On the i.MX 6 Sabre ARD board, a CS42888 codec with 4 audio in port is used, each port receive two channels of data in the I2S format(network mode), providing 8-channel of playback functionality. This codec also has 2 audio output port connected with ESAI, providing 4-channel of recording functionality. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual The codec driver is generic and hardware independent code that configures the codec to provide audio capture and playback. It does not contain code that is specific to the target platform or machine. The codec driver handles:

Codec DAI and PCM configuration
Codec control I/O-using I2C
Mixers and audio controls
Codec audio operations
DAI Digital mute control The CS42888 codec is registered as an I2C client when the module initializes. The APIs are exported to the upper layer by the structure snd_soc_dai_ops.

7.1.3.3 AM/FM Codec

The AM/FM codec is a virtual codec, it only has a PCM interface connected to the Tuner device. The audio data is transferred from the user data buffer to or from the SSI FIFO through the DMA channel. The DMA channel is selected according to the audio sample bits. AUDMUX is used to set up the path between the SSI port and the output port which connects with the codec. The codec works in master mode as it provides the BCLK and LRCLK. The BCLK and LRCLK can be configured according to the audio sample rate.

7.1.4 Software Operation

The following sections describe the software operation of the ASoC driver.

7.1.4.1 ASoC Driver Source Architecture

File imx-pcm-dma.c is shared by the stereo ALSA SoC driver, the 7.1 ALSA SoC driver and other CODEC driver. This file is responsible for preallocating DMA buffers and managing DMA channels. The stereo CODEC is connected to the CPU through the SSI interface. fsl_ssi.c registers the CPU DAI driver for the stereo ALSA SoC and configures the on-chip SSI interface. wm8962.c registers the stereo CODEC and hifi imx-wm8958.c, imx-wm8960.c and imx-wm8962.c are the machine layer codes, which create the driver device and register the stereo sound card. The multichannel codec is connected to the CPU through the ESAI interface. fsl_esai.c registers the CPU DAI driver for the stereo ALSA SoC and configures the on-chip ESAI interface. cs42888.c registers the multichannel CODEC and hifi DAI drivers. The direct hardware operations on the multichannel CODEC are in cs42888.c. imx-cs42888.c is the machine layer code which creates the driver device and registers the stereo sound card. The AM/FM CODEC is connected to the CPU through the SSI interface. fsl_ssi.c registers the CPU DAI driver for the stereo ALSA SoC and configures the on-chip SSI interface. si476x.c registers the Tuner CODEC and Tuner DAI drivers. The direct hardware operations on the CODEC are in si476x.c. imx-si476x.c is the machine layer code which creates the driver device and registers the sound card.

7.1.4.2 Sound Card Registration

The codecs have the same registration sequence: 1. The codec driver registers the codec driver, DAI driver, and their operation functions. 2. The platform driver registers the PCM driver, CPU DAI driver and their operation functions, pre allocates buffers for PCM components and sets playback and capture operations as applicable. 3. The machine layer creates the DAI link between codec and CPU registers the sound card and PCM devices. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.1.4.3 Device Open

Allocates a free substream for the operation to be performed.
Opens the low level hardware device.
Assigns the hardware capabilities to ALSA runtime information (the runtime structure contains all the hardware, DMA, and software capabilities of an opened substream).
Configures DMA read or write channel for operation.
Configures CPU DAI and CODEC DAI interface.
Configures CODEC hardware.
Triggers the transfer. After triggering for the first time, the subsequent DMA read/write operations are configured by the DMA callback.

7.1.4.4 Device Tree Binding

Documentation/devicetree/bindings/sound/fsl,ssi.txt
Documentation/devicetree/bindings/sound/fsl-sai.txt
Documentation/devicetree/bindings/sound/fsl,esai.txt
Documentation/devicetree/bindings/sound/fsl,asrc.txt
Documentation/devicetree/bindings/sound/wm8962.txt
Documentation/devicetree/bindings/sound/wm8960.txt
Documentation/devicetree/bindings/sound/wm8994.txt
Documentation/devicetree/bindings/sound/cs42xx8.txt
Documentation/devicetree/bindings/sound/imx-audmux.txt
Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt
Documentation/devicetree/bindings/sound/imx-audio-cs42888.txt
Documentation/devicetree/bindings/sound/imx-audio-si476x.txt

7.1.4.5 Source Code Structure

The following table shows the stereo codec SoC driver source in sound/soc/fsl. Table 83. Stereo Codec SoC Driver Files RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 83. Stereo Codec SoC Driver Files...continued Table below lists the AM/FM codec SoC driver source files. These files are under sound/soc. Table 84. AM/FM Codec SoC Driver Source Files Table below shows the multiple-channel ADC SoC driver source files. Table 85. CS42888 ASoC Driver Source File

7.1.4.6 Menu Configuration Options

The following Linux kernel configuration options are provided for this module.

SoC Audio supports for WM8958, WM8960, and WM8962 CODEC. In menuconfig, this option is available: -> Device Drivers -> Sound card support RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual -> Advanced Linux Sound Architecture -> ALSA for SoC audio support -> SoC Audio for Freescale CPUs -> SoC Audio support for i.MX boards with wm8962 (or wm8958, wm8960)

SoC Audio supports for i.MX cs42888. In menuconfig, this option is available: -> Device Drivers -> Sound card support -> Advanced Linux Sound Architecture -> ALSA for SoC audio support -> SoC Audio for Freescale CPUs -> SoC Audio support for i.MX boards with cs42888
SoC Audio supports for AM/FM. In menuconfig, this option is available: -> Device Drivers -> Sound card support -> Advanced Linux Sound Architecture -> ALSA for SoC audio support -> SoC Audio for Freescale CPUs -> SoC Audio support for i.MX boards with si476x 7.2 Asynchronous Sample Rate Converter (ASRC) on i.MX 6/i.MX 8QuadMax/i.MX 8QuadXPlust

7.2.1 Introduction

The Asynchronous Sample Rate Converter (ASRC) converts the sampling rate of a signal to a signal of different sampling rate. The ASRC supports concurrent sample rate conversion of up to 10 channels. The sample rate conversion of each channel is associated to a pair of incoming and outgoing sampling rates. The ASRC supports up to three sampling rate pairs simultaneously.

7.2.1.1 Hardware Operation

ASRC includes the following features:

Supports ratio (Fsin/Fsout) range between 1/24 to 8.
Designed for rate conversion between 44.1 KHz, 32 KHz, 48 KHz, and 96 KHz.
Other input sampling rates in the range of 8 KHz to 100 KHz are also supported, but with less performance (see IC spec for more details).
Other output sampling rates in the range of 30 KHz to 100 KHz are also supported, but with less performance.
Automatic accommodation to slow variations in the incoming and outgoing sampling rates.
Tolerant to sample clock jitter.
Designed mainly for real-time streaming audio usage. Can be used for non-realtime streaming audio usage when the input sampling clocks are not available.
In any usage case, the output sampling clocks must be activated.
In case of real-time streaming audio, both input and output clocks need to be available and activated.
In case of non-realtime streaming audio, the input sampling rate clocks can be avoided by setting ideal-ratio values into ASRC interface registers. The ASRC supports polling, interrupt and DMA modes, but only DMA mode is used in the platform for better performance. The ASRC supports following DMA channels: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Peripheral to peripheral, for example: ASRC to ESAI
Memory to peripheral, for example: memory to ASRC
Peripheral to memory, for example: ASRC to memory For more information, see the ASRC chapter in the Applications Processor documentation associated with the SoC.

7.2.2 Software Operation

Currently, ASRC is used in two scenarios.

Memory > ASRC > Memory, ASRC is controlled by the user application or ALSA plug-in.
Memory > ASRC > peripheral, ASRC is controlled directly by other ALSA drivers. Application/middleware aaa-053499 ALSA lib/plugin ALSA driver for S/PDIF ALSA driver for stereo ALSA driver for 5.1 codec SPIDF/MLB driver Stereo codec driver 5.1 codec driver ASRC stream interface ASRC diver

Figure 33. Audio Driver Interactions ASRC registers itself under /dev/mxc_asrc and creates proc file /proc/driver/asrc when the module is inserted.

7.2.2.1 Sequence for Memory to ASRC to Memory

Open /dev/mxc_asrc device.
Request ASRC pair. - ASRC_REQ_PAIR
Configure ASRC pair. - ASRC_CONIFG_PAIR
Start ASRC. - ASRC_START_CONV
Write the raw audio data (to be converted) into the user maintained input buffer. Fill asrc_convert_buffer struct with input/output buffer length and address. Driver would copy output data to user maintained output buffer address according to the output buffer size. Repeat this step until all data is converted. -ASRC_CONVERT
Stop ASRC conversion. - ASRC_STOP_CONV
Release ASRC pair. - ASRC_RELEASE_PAIR
Close /dev/mxc_asrc device. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.2.2.2 Sequence for Memory to ASRC to Peripheral

The sound device(PCM) has been registered and start to enable the DMA channel in ALSA driver
Request ASRC pair - fsl_asrc_request_pair
Configure ASRC pair - fsl_asrc_config_pair
Enable the DMA channel from Memory to ASRC and from ASRC to Memory
Start DMA channel and start ASRC conversion - fsl_asrc_start_pair
When audio data playback complete, stop DMA channel and ASRC - fsl_asrc_stop_pair
Release ASRC pair - fsl_asrc_release_pair

7.2.2.3 Source Code Structure

The table below lists the source files available in sound/soc/fsl. Table 86. ASRC Source File List

7.2.2.4 Menu Configuration Options

Then the ASRC driver can only be configured with the build-in module.

7.2.2.5 Device Tree Binding

NXP Semiconductors RM00293 i.MX Linux Reference Manual

compatible: Compatible list, must contain "fsl,imx6q-asrc".
reg: Offset and length of the register set for the device.
interrupts: Contains the asrc interrupt.
clocks: Contains an entry for each entry in clock-names.
clock-names: Must contain "mem", "ipg", "asrck", and "dma". (Generally, "dma" is used for SPBA clock.)
dmas: Generic dma devicetree binding as described in Documentation/devicetree/bindings/dma/dma.txt.
dma-names: Six dmas have to be defined, "txa", "rxa", "txb", "rxb", "txc", "rxc".
fsl,clk-map-version: the mapping relationship in different SOC is different. This version number can be used to indicate clock map information.
fsl,clk-channel-bits: indicates the channel bit information. The functions of device tree bindings for ASRC P2P are as follows:
compatible: Compatible list, must contain "fsl,imx6q-asrc-p2p".
fsl,p2p-rate: A valid sample rate for Back-End (I2S) playback and record.
fsl,p2p-width: A valid sample width for Back-End (I2S) playback and record.
fsl,asrc-dma-rx-events: Contains three SDMA event numbers for ASRC Rx.
fsl,asrc-dma-tx-events: Contains three SDMA event numbers for ASRC Tx.

7.2.2.6 Programming Interface (Exported API and IOCTLs)

The ASRC Exported API allows the ALSA driver to use ASRC services. The ASRC IOCTLs below are used for user space applications: ASRC_REQ_PAIR: Apply a pair from ASRC driver. Once a pair is allocated, ASRC core clock is enabled. ASRC_CONFIG_PAIR: Configure ASRC pair allocated. User is responsible for providing parameters defined in struct asrc_config. Items in asrc_config are listed below:

pair: ASRC pair allocated by the IOCTL(ASRC_REQ_PAIR).
channel_num: channel number.
buffer_num: buffer number need for input and output buffer use.The input/output buffers are allocated inside ASRC driver. User is responsible for remap it into user space.
dma_buffer_size: buffer size for input and output buffers. The buffer size should be in the unit of page size. Usually, 4k bytes is used.
input_sample_rate: input sampling rate. Input sample rate should be in 5.512k, 8k, 11.025k, 16k, 22k, 32k, 44.1k, 48k, 64k, 88.2k 96k, 176.4k, 192k.
output_sample_rate: output sampling rate. Output sampling rate should be in 32k, 44.1k, 48k, 64k, 88.2k, 96k, 176.4k 192k.
input_word_width: word width of input audio data. The input data word width can be 16 bit or 24 bit.
output_word_width: word width of output audio data. The output data word width can be 16 bit or 24 bit.
inclk: the input clock source can be ESAI RX clock, SSI1 RX clock, SSI2 RX clock, SPDIF RX clock, MLB_clock, ESAI TX clock, SSI1 TX clock, SSI2 TX clock, SPDIF TX clock, ASRCLK1 clock, NONE. If using clock except NONE, user should make sure that the clock is available.
outclk: the output clock source is the same as the input clock source. ASRC_CONVERT: Convert the input data into output data according to the parameters set by ASRC_CONFIG_PAIR. Driver would copy input_buffer_length bytes data from the input_buffer_vaddr for conversion. After convertion, the driver fills the output_buffer_length according to data number generated by ASRC and copies the output_buffer_length RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual to output_buffer_vaddr. However, before calling ASRC_CONVERT, the user is responsible for filling the output_buffer_length according to the ratio of input sample rate and output sample rate. If the generated buffer size is larger than the user-filled output_buffer_size, the driver would only copy user-filled output_buffer_size to output_buffer_vaddr. If the generated buffer size is smaller than the user-filled output_buffer_size (the difference should be less than 64 bytes.), calling ASRC_CONVERT would fail.

input_buffer_vaddr: virtual address of input buffer.
output_buffer_vaddr: virtual address of output buffer.
input_buffer_length: length of input buffer (bytes).
output_buffer_length: length of output buffer (bytes). ASRC_START_CONV: Start ASRC pair convert. ASRC_STOP_CONV: Stop ASRC pair convert. ASRC_STATUS: Query ASRC pair status.

7.3 HDMI Audio

7.3.1 Introduction

HDMI Audio is covered in the HDMI overview chapter in video. See HDMI Audio for more details.

7.4 The Sony/Philips Digital Interface (S/PDIF)

7.4.1 Introduction

The Sony/Philips Digital Interface (S/PDIF) audio module is a stereo transceiver that allows the processor to receive and transmit digital audio. The S/PDIF transceiver allows the handling of both S/PDIF channel status (CS) and User (U) data. The frequency measurement block allows the S/PDIF RX section to derive the receive clock from the incoming S/PDIF stream.

7.4.1.1 S/PDIF Overview

Figure 34. S/PDIF Transceiver Data Interface Block Diagram

7.4.1.2 Hardware Overview

The S/PDIF receiver extracts the audio data from each S/PDIF frame and places the data in the S/PDIF Rx left and right FIFOs. The Channel Status and User Bits are also extracted from each frame and placed in the corresponding registers. The S/PDIF receiver provides a bypass option for direct transfer of the S/PDIF input signal to the S/PDIF transmitter.
For the S/PDIF transmitter, the audio data is provided by the processor through the SPDIFTxLeft and SPDIFTxRight registers. The Channel Status bits are provided through the corresponding registers. The S/ PDIF transmitter generates a S/PDIF output bitstream in the biphase mark format (IEC958), which consists of audio data, channel status and user bits. In the S/PDIF transmitter, the IEC958 biphase bit stream is generated on both edges of the S/PDIF Transmit clock. The S/PDIF Transmit clock is generated by the S/PDIF internal clock dividers and the sources are from outside of the S/PDIF block. The S/PDIF receiver can recover the S/PDIF Rx clock from the S/PDIF stream. Figure 34 shows the clock structure of the S/PDIF transceiver. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

7.4.1.3 Software Overview

The S/PDIF driver is designed under ALSA System on Chip (ASoC) layer. The ASoC driver for S/PDIF provides one playback device for Tx and one capture device for Rx. The playback output audio format can be linear PCM data or compressed data with 16-bit, 20-bit, and 24-bit audio. The allowed sampling bit rates are 44.1, 48 or 32 KHz. The capture input audio format can be linear PCM data or compressed 24-bit data and the allowed sampling bit rates are from 16 to 96 KHz. The driver provides the same interface for PCM and compressed data transmission.

7.4.1.4 ASoC Layer

The ASoC layer divides audio drivers for embedded platforms into separate layers that can be reused. ASoC divides an audio driver into a codec driver, a machine layer, a DAI (digital audio interface) layer, and a platform layer. The Linux kernel documentation has some concise description of these layers in linux/Documentation/ sound/alsa/soc. In the case of the S/PDIF driver, we are able to reuse the platform layer (imx-pcm-dma.c) that is used by the ssi stereo codec driver and also the generic dummy codec driver useful for DAI links creation without a real codec.

7.4.2 S/PDIF Tx Driver

The S/PDIF Tx driver supports the following features.

32, 44.1 and 48 KHz sample rates.
Signed 16 and 24-bit little Endian sample format. Due to S/PDIF SDMA feature, the 24-bit output sample file must have 32-bits in each channel per frame. Only the 24 LSBs are valid.
In the ALSA subsystem, the supported format is defined as S16_LE and S24_LE.
Stereo playback.
Information query through iecset or amixer.
The device ID can be determined by using the 'aplay -l' utility to list out the playback audio devices. For example: root@ ~$ aplay -l ** List of PLAYBACK Hardware Devices ** card 0: imxspdif [imx-spdif], device 0: S/PDIF PCM snd-soc-dummy-dai-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 Note: The number at the beginning of the IMX_SPDIF line is the card ID. The string in the square brackets is the card name.
The ALSA utility provides a common method for user spaces to operate and use ALSA drivers #aplay -Dplughw:0,0 audio.wav Note: The -D parameter of aplay indicates the PCM device with card ID and PCM device ID: hw:[card id], [pcm device id] The "iecset" utility provides a common method to set or dump the IEC958 status bits. #iecset -c 0 RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

7.4.2.1 Driver Design

Before S/PDIF playback, the configuration, interrupt, clock and channel registers are initialized. During S/ PDIF playback, the channel status bits are fixed. The DMA and interrupts are enabled. S/PDIF has 16 TX sample FIFOs on Left and Right channel respectively. When both FIFOs are empty, an empty interrupt is generated if the empty interrupt is enabled. If no data are refilled in the 20.8 μs (1/48000), an underrun interrupt is generated. Overrun is avoided if only 16 sample FIFOs are filled for each channel every time. If auto re- synchronization is enabled, the hardware checks if the left and right FIFO are in sync, and if not, it sets the filling pointer of the right FIFO to be equal to the filling pointer of the left FIFO and an interrupt is generated.

7.4.2.2 Provided User Interface

The S/PDIF transmitter driver provides one ALSA mixer sound control interface to the user besides the common PCM operations interface. It provides the interface for the user to write S/PDIF channel status codes into the driver so they can be sent in the S/PDIF stream. The input parameter of this interface is the IEC958 digital audio structure shown below, and only status member is used: struct snd_aes_iec958 { unsigned char status[24]; /* AES/IEC958 channel status bits */ unsigned char subcode[147]; /* AES/IEC958 subcode bits */ unsigned char pad; /* nothing */ unsigned char dig_subframe[4]; /* AES/IEC958 subframe bits */

7.4.3 S/PDIF Rx Driver

The S/PDIF Rx driver supports the following features:

16, 32, 44.1, 48, 64 and 96 KHz receiving sample rate
Signed 24-bit little endian sample format. Due to S/PDIF SDMA feature, each channel bit length in PCM recorded frame is 32 bits, and only the 24 LSBs are valid In ALSA subsystem, the supported format is defined as S24_LE.
Stereo record.
The device ID can be determined by using the 'arecord -l' to list out record devices. For example: root@ ~$ arecord -l ** List of CAPTURE Hardware Devices ** card 0: cs42888audio [cs42888-audio], device 0: HiFi CS42888-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: imxspdif [imx-spdif], device 0: S/PDIF PCM snd-soc-dummy-dai-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0
The ALSA utility provides a common method for user spaces to operate and use ALSA drivers. #arecord -Dplughw:1,0" -c 2 -r 44100 -f S24_LE record.wav RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

The "iecset" utility provides a common method to set or dump the IEC958 status bits.

7.4.3.1 Driver Design

status, user bits and valid bits concurrently. them out when a user application makes a request. set the mode (see Table 87), but no matter what the mode is, the driver handles the user bits in the same way. while S/PDIF driver is reading new U/Q bits. sound control interface is provided for the user to get the status of this valid bit.

7.4.3.2 Provided User Interface

The S/PDIF Rx driver provides interfaces for user application as shown in table below. An interrupt is associated with the valid flag. Table 87. S/PDIF Rx Driver Interfaces RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 87. S/PDIF Rx Driver Interfaces...continued Figure 35. S/PDIF Rx Application Program Flow

7.4.4 Source Code Structure

Table below lists the source files for the driver. Table 88. S/PDIF Driver Files RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 88. S/PDIF Driver Files...continued

7.4.4.1 Menu Configuration Options

CONFIG_SND_IMX_SPDIF - Configuration option for the S/PDIF driver:
Device Drivers -> Sound card support -> Advanced Linux Sound Architecture -> ALSA for SoC audio support -> SoC Audio for Freescale i.MX CPUs -> SoC Audio support for i.MX boards with S/PDIF

7.4.4.2 Device Tree Bindings

Documentation/devicetree/bindings/sound/fsl,spdif.txt
Documentation/devicetree/bindings/sound/imx-audio-spdif.txt

7.4.4.3 Interrupts and Exceptions

S/PDIF Tx/Rx hardware block has many interrupts to indicate the success, exception and event.

DPLL Lock and Loss Lock-Saves the DPLL lock status; this is used when getting the Rx sample rate
U/Q Channel Full and overrun/underrun-Puts the U/Q channel register data into queue buffer, and update the queue buffer write pointer
U/Q Channel Sync-Saves the ID of the buffer whose U/Q data is ready for read out
U/Q Channel Error-Resets the U/Q queue buffer

7.4.5 Unit Test Preparation

Setup M-Audio Transit USB sound card by installing M-Audio Transit driver on your PC.
Install WaveLab tools on your PC.

7.4.5.1 Tx test step

Plug optical line into [line|optical] port of M-Audio transit. Note: Make sure the [optical out] port of M-Audio transit has no output (red light off) after plugging the optical line.
Start up WaveLab, press the record button on the toolbar, set up the record file name, sample rate, and channel number, and then record.
Meanwhile, on board use following command to play one wave file: #aplay -D hw:[card id],[pcm id] audioXXkYYS.wav RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

After aplay finishes, stop recording in WaveLab.
Play the recorded WAV file in wavelab to check.

7.4.5.2 Rx test step

Plug optical line into [optical port] of M-Audio transit
Startup WaveLab, open a test WAV file: audioXXkYYS.wav to play in loop
Meanwhile, on board use the following command to record one WAV file. After finishing recording, you may playback the record WAV file on other audio card on the board or PC. #arecord -D hw:[card id],[pcm id] -c 2 -d 20 -r [sample rate in Hz] -f S24_LE record.wav Note: The sample rate argument in the arecord command must be consistent with the WAV file playing on WaveLab.

7.5 Audio Mixer (AUDMIX)

7.5.1 Introduction

Many applications require mixing of two or more audios to take different effects. Mixing of two audio streams into a single stream can be done with Audio Mixer. Audio Mixer has two input serial audio interfaces. These are driven by two Synchronous Audio Interface (SAI) modules. Each input serial interface carries 8 audio channels in its frame in TDM manner. Mixer mixes audio samples of corresponding channels from two interfaces into a single sample. Before mixing, audio samples of two inputs can be attenuated based on configuration. The output of the Audio Mixer is also a serial audio interface. Like input interfaces, it has the same TDM frame format. This output is used to drive the serial DAC TDM interface of audio codec and also sent to the external pins along with the receive path of normal audio SAI module for readback by the CPU. The output of Audio mixer can be selected from any of the three streams:

Serial audio input 1
Serial audio input 2
Mixed audio Mixing operation is independent of audio sample rate, but the two audio input streams must have the same audio sample rate with the same number of channels in TDM frame to be eligible for mixing.

7.5.2 Block diagram

Figure 36. Audio Mixer block diagram

7.5.3 Hardware Overview

audio and the other is for safety tone. The serial audio TDM frame can contain eight samples of 32 bit each. have the same number of channels and frame rate. The frame format is shown in the following figure. Figure 37. Audio TDM serial interface frame Input TDM frame is de-serialized as 32 bit samples starting from frame pulse in its own interface bit clock. configuration that defines the attenuation value at different time (called as attenuation profile). There are two independent attenuators for two audio streams. Output of two attenuators are used for mixing. transmitted in the same frame format like input interfaces with selected bit clock.

7.5.4 Software Overview

provides two playback devices for AudioMixer inputs and one capture device to capture the Audio Mixer output. PCM audio data, 16-bit, 18-bit, 20-bit, 24-bit, or 32-bit wide. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.5.4.1 User Interface

Audio Mixer interface is accessible from user space by using the amixer -c <audio mixer card> tool. The following Audio Mixer controls are exposed to user space.

1 Mixing Clock

2 Output Source enum r/w #0 'Disabled', #1

3 Output Width enum r/w #0 '16b', #1 '18b',

4 Output Clock

5 Frame Rate Diff

6 Clock Freq Diff

7 Sync Mode Config enum r/w #0 'Disabled', #1

8 Sync Mode Clk

9 TDM1 Attenuation enum r/w #0 'Disabled', #1

10 TDM1 Attenuation

11 TDM1 Attenuation

12 TDM1 Attenuation

13 TDM1 Attenuation

14 TDM1 Attenuation

15 TDM1 Attenuation

16 TDM2 Attenuation enum r/w #0 'Disabled', #1

17 TDM2 Attenuation

18 TDM2 Attenuation

19 TDM2 Attenuation

20 TDM2 Attenuation

21 TDM2 Attenuation

22 TDM2 Attenuation

Table 89. Audio Mixer controls...continued

7.5.4.2 Source Code Structure

The following table lists the source files for the driver. Table 90. Audio Mixer Driver Files

7.5.4.3 Menu Configuration Options

CONFIG_SND_IMX_AMIX - Configuration option for the Audio Mixer Driver
Device Drivers -> Sound card support -> Advanced Linux Sound Architecture -> ALSA for SoC audio support -> SoC Audio for Freescale i.MX CPUs -> SoC Audio support for i.MX boards with AMIX

7.6 PDM Microphone Interface (MICFIL)

7.6.1 Introduction

audio signal from a PDM microphone bitstream in a configurable output sampling rate.

7.6.2 Block diagram

The following figure shows the high-level view of the PDM Microphone Interface block. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Figure 38. PDM Microphone Interface block

7.6.3 Hardware Overview

configuration but each input channel could be turned on/off independently.

An input interface for each pair of PDM microphones
A decimation filter by channel
A FIFO by channel
A time generation unit
Shared interfaces to DMA, interrupts and SoC
One or more Hardware Voice Activity Detectors (HWVAD). The Decimation Filter implements a low-pass filter in the audio band (20Hz-22.5KHz @48KHz output sampling rate by default) with a configurable decimation rate. It is implemented using an arrange of a CIC, a Half Band, a FIR, and a DC remover filter. The Time Generator unit generates the PDM clock to the microphones. This clock is the same for all the PDM microphones and it is active for all the microphones, i.e. there is not possibility to turn off the PDM clock for one microphone only. It also generates the timing signals and controls for all the filter blocks. The decimation in the filters is also controlled by this block. It activates each block and channel and gives the start signal to FIR FSM and Half Band FSM. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

channels, the number of data stored surpasses a configured watermark.

7.6.4 Software Overview

format is 8-channels 32-bit wide linear PCM audio data @ 48kHz or 44.1kHz rate.

7.6.4.1 User Interface

PDM Microphone interface is accessible from user space by using the amixer -c <pdm mic card> tool. Controls are listed in the following table.

1 CH0 Gain int r/w min=0, max=15 15

2 CH1 Gain int r/w min=0, max=15 15

3 CH2 Gain int r/w min=0, max=15 15

4 CH3 Gain int r/w min=0, max=15 15

5 CH4 Gain int r/w min=0, max=15 15

6 CH5 Gain int r/w min=0, max=15 15

7 CH6 Gain int r/w min=0, max=15 15

8 CH7 Gain int r/w min=0, max=15 15

9 MICFIL Quality

10 HWVAD

11 HWVAD High-Pass

12 HWVAD Zero-

13 HWVAD Zero-

14 HWVAD Noise OR

15 HWVAD Sampling

16 Clock Source enum r/w #0 'Auto', #1 'Audio

17 HWVAD Input Gain int r/w min=0, max=15 0

18 HWVAD Sound

19 HWVAD Noise

20 HWVAD Detector

21 HWVAD Detector

22 HWVAD Noise

23 HWVAD Zero-

24 HWVAD Zero-

Table 91. PDM Microphone controls...continued

7.6.4.2 Source Code Structure

The following table lists the source files for the driver. Table 92. Audio Mixer Driver Files

7.6.4.3 Menu Configuration Options

CONFIG_SND_IMX_MICFIL - Configuration option for PDM Microphone Driver
Device Drivers -> Sound card support -> Advanced Linux Sound Architecture > ALSA for SoC audio support - > SoC Audio for Freescale i.MX CPUs -> SoC Audio support for i.MX boards with micfil 7.7 Asynchronous Sample Rate Converter (ASRC) on i.MX 8M Nano/i.MX 8M Plus

7.7.1 Introduction

NXP Semiconductors RM00293 i.MX Linux Reference Manual

7.7.2 Hardware Operation

The primary features for the ASRC are as follows:

4 Contexts - groups of channels with an independent time base
Fully independent and concurrent context control
Simultaneous processing of up to 32 audio channels
Programmable filter characteristics for each context
32, 24, 20, and 16-bit fixed point audio sample support
32-bit floating point audio sample support
8 kHz to 384 kHz sample rate
1/16 to 16x sample rate conversion ratio
Software control of fine conversion ratio The ASRC supports polling, interrupt and DMA modes, but only DMA mode is used in the platform for better performance. The ASRC supports the following DMA channels:
Peripheral to peripheral, for example: ASRC to SAI
Memory to peripheral, for example: memory to ASRC
Peripheral to memory, for example: ASRC to memory For more information, see the ASRC chapter in the Applications Processor documentation associated with the SoC.

7.7.3 Software Operation

As an assistant component in the audio system, the ASRC driver implementation depends on the use cases in the platform. Currently, ASRC is used in two scenarios:

Memory > ASRC > Memory: ASRC is controlled by the user application or ALSA plug-in.
Memory > ASRC > peripheral: ASRC is controlled directly by other ALSA drivers. Note: The audio driver interaction diagram is the same as Figure 33. The ASRC stream interface provides the interface for the user space. The ASRC registers itself under /dev/ mxc_asrc.

7.7.3.1 Sequence for Memory to ASRC to Memory

Open /dev/mxc_asrc device.
Request ASRC pair. - ASRC_REQ_PAIR
Configure ASRC pair. - ASRC_CONIFG_PAIR
Start ASRC. - ASRC_START_CONV
Write the raw audio data (to be converted) into the user maintained input buffer. Fill asrc_convert_buffer struct with input/output buffer length and address. Driver would copy output data to user maintained output buffer address according to the output buffer size. Repeat this step until all data is converted. -ASRC_CONVERT
Stop ASRC conversion. - ASRC_STOP_CONV
Release ASRC pair. - ASRC_RELEASE_PAIR
Close /dev/mxc_asrc device. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.7.3.2 Sequence for Memory to ASRC to Peripheral

The sound device (PCM) has been registered and starts to enable the DMA channel in the ALSA driver.
Request ASRC context. - fsl_easrc_request_context
Configure ASRC context. - fsl_easrc_config_context
Enable the DMA channel from Memory to ASRC and from ASRC to Memory.
Start DMA channel and start ASRC conversion. - fsl_easrc_start_context
When audio data playback complete, stop DMA channel and ASRC. - fsl_easrc_stop_context
Release ASRC pair. - fsl_easrc_release_context

7.7.3.3 Source Code Structure

The table below lists the source files available in sound/soc/fsl. Table 93. ASRC Source File List

7.7.3.4 Menu Configuration Options

Device Drivers
Sound card support
Advanced Linux Sound Architecture
ALSA for SoC audio support
SoC Audio for Freescale i.MX CPUs
Enhanced Asynchronous Sample Rate Converter (EASRC) module support. Then the ASRC driver can only be configured with the build-in module.

7.7.3.5 Device Tree Binding

compatible: Compatible list, must contain "fsl,imx8mn-easrc".
reg: Offset and length of the register set for the device.
interrupts: Contains the asrc interrupt.
clocks: Contains an entry for each entry in clock-names.
clock-names: Must contain "mem".
dmas: Generic dma devicetree binding as described in Documentation/devicetree/bindings/dma/dma.txt.
dma-names: Eight dmas have to be defined, " ctx0_rx", " ctx0_tx", " ctx1_rx", " ctx1_tx", " ctx2_rx", " ctx2_tx",
fsl,asrc-rate: A valid sample rate for Back-End (I2S) playback and record.
fsl,asrc-format: A valid sample width for Back-End (I2S) playback and record. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

7.7.3.6 Programming Interface (Exported API and IOCTLs)

pair: ASRC pair allocated by the IOCTL(ASRC_REQ_PAIR).
channel_num: channel number.
dma_buffer_size: buffer size for input and output buffers. The buffer size should be in the unit of page size. Usually, 4k bytes is used.
input_sample_rate: input sampling rate. Input sample rate should be in 5.512k, 8k, 11.025k, 16k, 22k, 32k, 44.1k, 48k, 64k, 88.2k 96k, 176.4k, 192k.
output_sample_rate: output sampling rate. Output sampling rate should be in 32k, 44.1k, 48k, 64k, 88.2k, 96k, 176.4k 192k.
input_format: word format of input audio data. The input data word width can be 16 bit or 24 bit.
output_format: word width of output audio data. The output data word width can be 16 bit or 24 bit.
inclk: none
outclk: none ASRC_CONVERT: Convert the input data into output data according to the parameters set by ASRC_CONFIG_PAIR. Driver would copy input_buffer_length bytes data from the input_buffer_vaddr for conversion. After convertion, the driver fills the output_buffer_length according to the data number generated by ASRC and copies output_buffer_length to output_buffer_vaddr. However, before calling ASRC_CONVERT, the user is responsible for filling the output_buffer_length according to the ratio of input sample rate and output sample rate. If the generated buffer size is larger than the user-filled output_buffer_size, the driver would only copy the user-filled output_buffer_size to output_buffer_vaddr. If the generated buffer size is smaller than user-filled output_buffer_size (the difference should be less than 64 bytes.), calling ASRC_CONVERT would fail.
input_buffer_vaddr: virtual address of input buffer.
output_buffer_vaddr: virtual address of output buffer.
input_buffer_length: length of input buffer (bytes).
output_buffer_length: length of output buffer (bytes). ASRC_START_CONV: Start ASRC pair convert. ASRC_STOP_CONV: Stop ASRC pair convert. ASRC_STATUS: Query ASRC pair status. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

8 Security

8.1 Cryptographic Acceleration and Assurance Module (CAAM)

8.1.1 CAAM Device Driver Overview

This section discusses implementation specifics of the kernel driver components supporting CAAM (Cryptographic Acceleration and Assurance Module) within the Linux kernel. CAAM's base driver packaging can be categorized on two distinct levels:

Configuration and Job Execution Level
API Interface Level Configuration and Job Execution Level consists of:
A control and configuration module which maps the main register page and writes global or system required configuration information.
A module that feeds jobs through job rings, and reports status. API Interface Level consists of:
An interface to the Sctterlist Crypto API supporting asynchronous single-pass authentication-encryption operations, and common blockciphers - caamalg.
An interface to the Scatterlist Crypto API supporting asynchronous hashes - caamhash.
An interface to the hwrng API supporting use of the Random Number Generator - caamrng.

8.1.2 Configuration and Job Execution Level

This section has two parts:

Control/Configuration Driver
Job Ring Driver

8.1.3 Control/Configuration Driver

The control and configuration driver is responsible for initializing and setting up the master register page, initializing early-on feature initialization, providing limited debug and monitoring capability, and generally ensuring that all other dependent driver subsystems can connect to a correctly-configured device. Step by step, it performs the following actions at startup:

Allocates a private storage block for this level.
Maps a virtual address to the full CAAM register page.
Maps a virtual address for the SNVS register page.
Maps a virtual (cache coherent) address for Secure Memory.
Registers the security violation interrupt.
Selects the correct DMA address size for the platform, and sets DMA address masks to match.
Identifies other pertinent interrupt connections.
Initializes all job ring instances.
If the system configuration includes a DPAA Queue Interface, that interface has frame-pop enabled. Note: i.MX 6 configurations do not contain this logic.
If the instance contains a TRNG, it's oscillator/entropy configuration is set and then "kickstarted".
Configuration information is sent to the system console to indicate that the driver is alive, and what configuration it has assumed. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

If CONFIG_DEBUG_FS is selected in the kernel configuration, then entries are added to enable debugfs views to useful registers in the performance monitor. Register views are accessible under the caam/ctl directory at the debugfs root entry.

8.1.4 Job Ring Driver

The Job Ring driver is responsible for providing job execution service to higher-level drivers. It takes care of overall management of both input and output rings and interrupt service driving the output ring. One driver call is available for higher layers to use for queueing jobs to a ring for execution: int caam_jr_enqueue(struct device *dev, u32 *desc, void (*cbk)(struct device *dev, u32 *desc, u32 status, void *areq), void *areq); Arguments: dev Pointer to the struct device associated with the job ring for use. In the current configuration, one or more struct device entries exist in the controller's private data block, one for each ring. desc Pointer to a CAAM job descriptor to be executed. The driver will map the descriptor prior to execution, and unmap it upon completion. However, since the driver can't reasonably know anything about the data referenced by the descriptor, it is the caller's responsibility to map/flush any of this data prior to submission, and to unmap/ invalidate data after the request completes. cbk Pointer to a callback function that will be called when the job has completed processing. areq Pointer to metadata or context data associated with this request. Often, this can contain referenced data mapping information that request postprocessing (via the callback) can use to clean up or release resources once complete. Callback Function Arguments: dev Pointer to the struct device associated with the job ring for use. desc Pointer to the original descriptor submitted for execution. status Completion status received back from the CAAM DECO that executed the request. Nonzero only if an error occurred. Strings describing each error are enumerated in error.c. areq Metadata/context pointer passed to the original request. Returns:

Zero on successful job submission
-EBUSY if the input ring was full
-EIO if driver could not map the job descriptor

8.1.5 API Interface Level

CAAM module provides a connection through the Scatterlist Crypto API both for common symmetric blockciphers, and for single-pass authentication-encryption services. This table lists all installed authentication- encryption algorithms by their common name, driver name, and purpose. Note that certain platforms, such as i.MX 6, contain a low-power MDHA accelerator, which cannot support SHA384 or SHA512. Name Driver Name Purpose authenc(hmac(md5),cbc(aes)) authenc-hmac-md5-cbc- aes-caam Single-pass authentication/ encryption using MD5 and AES-CBC RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Name Driver Name Purpose authenc(hmac(sha1),cbc(aes)) authenc-hmac-sha1-cbc- aes-caam Single-pass authentication/ encryption using SHA1 and AES- CBC authenc(hmac(sha224),cbc(aes)) authenc-hmac-sha224- cbc-aes-caam Single-pass authentication/ encryption using SHA224 and AES- CBC authenc(hmac(sha256),cbc(aes)) authenc-hmac-sha256- cbc-aes-caam Single-pass authentication/ encryptionusing SHA256 and AES- CBC authenc(hmac(sha384),cbc(aes)) authenc-hmac-sha384- cbc-aes-caam Single-pass authentication/ encryption using SHA384 and AES- CBC authenc(hmac(sha512),cbc(aes)) authenc-hmac-sha512- cbc-aes-caam Single-pass authentication/ encryption using SHA512 and AES- CBC authenc(hmac(md5),cbc(des3_ede)) authenc-hmac-md5- cbcdes3_ede-caam Single-pass authentication/ encryption using MD5 and Triple- DES-CBC authenc(hmac(sha1),cbc(des3_ede)) authenc-hmac-sha1-cbc- des3_ede-caam Single-pass authentication/ encryption using SHA1 and Triple- DES-CBC authenc(hmac(sha224),cbc(des3_ede)) authenc-hmac-sha224- cbc-des3_ede-caam Single-pass authentication/ encryption using SHA224 and Triple- DES-CBC authenc(hmac(sha256),cbc(des3_ede)) authenc-hmac-sha256- cbc-des3_ede-caam Single-pass authentication/ encryption using SHA256 and Triple- DES-CBC authenc(hmac(sha384),cbc(des3_ede)) authenc-hmac-sha384- cbc-des3_ede-caam Single-pass authentication/ encryption using SHA384 and Triple- DES-CBC authenc(hmac(sha512),cbc(des3_ede)) authenc-hmac-sha512- cbc-des3_ede-caam Single-pass authentication/ encryption using SHA512 and Triple- DES-CBC authenc(hmac(md5),cbc(des)) authenc-hmac-md5-cbc- des-caam Single-pass authentication/ encryption using MD5 and Single- DES-CBC authenc(hmac(sha1),cbc(des)) authenc-hmac-sha1-cbc- des-caam Single-pass authentication/ encryption using SHA1 and Single- DES-CBC authenc(hmac(sha224),cbc(des)) authenc-hmac-sha224- cbc-des-caam Single-pass authentication/ encryption using SHA224 and Single-DES-CBC authenc(hmac(sha256),cbc(des)) authenc-hmac-sha256- cbc-des-caam Single-pass authentication/ encryption using SHA256 and Single-DES-CBC authenc(hmac(sha384),cbc(des)) authenc-hmac-sha384- cbc-des-caam Single-pass authentication/ encryption using SHA384 and Single-DES-CBC RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Name Driver Name Purpose authenc(hmac(sha512),cbc(des)) authenc-hmac-sha512- cbc-des-caam Single-pass authentication/ encryption using SHA512 and Single-DES-CBC This table lists all installed symmetric key blockcipher algorithms by their common name, driver name, and purpose. Name Driver Name Purpose cbc(aes) cbc-aes-caam AES with a CBC mode wrapper cbc(des3_ede) cbc-3des-caam Triple DES with a CBC mode wrapper cbc(des) cbc-des-caam Single DES with a CBC mode wrapper ecb(aes) ecb-aes-caam AES with a ECB mode wrapper ecb(des3_ede) ecb-3des-caam Triples DES with a ECB mode wrapper ecb(des) ecb-des-caam Single DES with a ECB mode wrapper ecb(arc4) ecb-arc4-caam ARC4 with a ECB mode wrapper ctr(aes) ctr-aes-caam AES with a CTR mode wrapper Use of these services through the API is exemplified in the common conformance/performance testing module in the kernel's crypto subsystem, known as tcrypt, visible in the kernel source tree at crypto/tcrypt.c. The caamhashmodule provides a connection through the Scatterlist Crypto API both for common asynchronous hashes. This table lists all installed asynchronous hashes by their common name, driver name, and purpose. Note that certain platforms, such as i.MX 6, contain a low-power MDHA accelerator, which cannot support SHA384 or SHA512. Name Driver Name Purpose sha1 sha1-caam SHA1-160 Hash Computation sha224 sha224-caam SHA224 Hash Computation sha256 sha256-caam SHA256 Hash Computation sha384 sha384-caam SHA384 Hash Computation sha512 sha512-caam SHA512 Hash Computation md5 md5-caam MD5 Hash Computation hmac(sha1) hmac-sha1-caam SHA1-160 Hash-based Message Authentication Code hmac(sha224) hmac-sha224-caam SHA224 Hash-based Message Authentication Code hmac(sha256) hmac-sha256-caam SHA256 Hash-based Message Authentication Code hmac(sha384) hmac-sha384-caam SHA384 Hash-based Message Authentication Code hmac(sha512) hmac-sha512-caam SHA512 Hash-based Message Authentication Code hmac(md5) hmac-md5-caam MD5 Hash-based Message Authentication Code Use of these services through the API is exemplified in the common conformance/performance testing module in the kernel's crypto subsystem, known as tcrypt, visible in the kernel source tree at crypto/tcrypt.c. The caamrng module installs a mechanism to use CAAM's random number generator to feed random data into a pair of buffers that can be accessed through /dev/random. /dev/random is commonly used to feed the kernel's own entropy pool, which can be used internally, as an entropy source for other random data "devices". RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual For more information regarding support for this service, see rng-tools available in sourceforge.net/projects/ gkernel/files/rng-tools.

8.1.6 Driver Configuration

Configuration of the driver is controlled by the following kernel confguration parameters (found under Cryptographic API -> Hardware Crypto Devices): CRYPTO_DEV_FSL_CAAM Enables building the base controller driver and the job ring backend. CRYPTO_DEV_FSL_CAAM_RINGSIZE Selects the size (e.g., the maximum number of entries) of job rings. This is selectable as a power of 2 in the range of 2-9, allowing selection of a ring depth ranging from 4 to 512 entries. The default selection is 9, resulting in a ring depth of 512 job entries. CRYPTO_DEV_FSL_CAAM_INTC Enables the use of the hardware's interrupt coalescing feature, which can reduce the amount of interrupt overhead the system incurs during periods of high utilization. Leaving this disabled forces a single interrupt for each job completion, simplifying operation, but increasing overhead. CRYPTO_DEV_FSL_CAAM_INTC_COUNT_THLD If coalescing is enabled, selects the number of job completions allowed to queue before an interrupt is raised. This is selectable within the range of 1 to 255. Selecting 1 effectively defeats the coalescing feature. Any selection of a size greater than the job ring size forces a situation where the interrupt times out before ever raising an interrupt. The default selection is 255. CRYPTO_DEV_FSL_CAAM_INTC_TIME_THLD If coalescing is enabled, selects the count of bus clocks (divided by 64) before a coalescing timeout where, if the count threshold has not been met, an interrupt is raised at the end of the time period. The selection range is an integer from 1 to 65535. The default selection is 2048. CRYPTO_DEV_FSL_CAAM_CRYPTO_API Enables Scatterlist Crypto API support for asynchronous blockciphers and for single-pass autentication- encryption operations through the API using CAAM hardware for acceleration. CRYPTO_DEV_FSL_CAAM_AHASH_API RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Enables Scatterlist Crypto API support for asynchronous hashing through the API using CAAM hardware for acceleration. CRYPTO_DEV_FSL_CAAM_RNG_API Enables use of the CAAM Random Number generator through the hwrng API. This can be used to generate random data to feed an entropy pool for the kernels pseudo-random number generator. CRYPTO_DEV_FSL_CAAM_RNG_TEST Enables a captive test to ensure that the CAAM RNG driver is operating and buffering random data.

8.1.7 Limitations

Components of the driver do not currently build and run as modules. This may be rectified in a future version.
Interdependencies exist between the controller and job ring backends, therefore they all must run in the same system partition. Future versions of the driver may separate out the job ring back-end as a standalone module that can run independently (and support independent API and SM instances) in its own system partition.
The full CAAM register page is mapped by the controller driver, and derived pointers to selected subsystems are calculated and passed to higher-layer driver components. Partition-independent configurations will have to map their own subsystem pointers instead.
Upstream variants of this driver support only Power architecture. This Arm architecture-specific port is not upstreamed at this time, although portions may be upstreamed at some point.
TRNG kickstart may need to be moved to the bootloader in a future release, so that the RNG can be used earlier.
The Job Ring driver has a registration and de-registration functions that are not currently necessary (and may be rewritten in future editions to provide for shutdown notifications to higher layers.
The full CAAM function is exclusive with the Mega/Fast mix off feature in DSM. If CAAM is enabled, the Mega/Fast mix off feature needs to be disabled, and the user should "echo enabled > /sys/bus/platform/ devices/2100000.aips-bus/2100000.caam/2101000.jr0/power/wakeup" after the kernel boots up, and then Mega/Fast mix will keep the power on in DSM.

8.1.8 Limitations in the Existing Implementation Overview

This chapter describes a prototype of a Keystore Management Interface intended to provide access to CAAM Secure Memory. Secure memory provides a controlled and access-protected area where critical system security parameters can be stored and processed in a running system without bus-level exposure of clear secrets. Secrets can be imported into and exported from secure memory, but never exported from secure memory in their cleartext form. Instead, secrets may be exported from secure memory in a covered form, using keys never visible to the outside. This driver, with its kernel-level API, exposes a basic interface to allow kernel-level services access to secure memory functionality. It is split into two pieces:

Keystore Initialization and Maintenance Interfaces
Keystore Access Interface The initialization and maintenance services exist to initialize and define the instance of a keystore interface. Likewise, the access interface allows kernel-level services to use the API for management of security parameters. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

8.1.9 Initialize Keystore Management Interface

Installs a set of pointers to functions that implement an underlying physical interface to the keystore subsystem. In the present release, a default (and hidden) suite of functions implement this interface. Future implementations of this API may provide for the installation of an alternate interface. If this occurs, an alternate to this call can be provided. void sm_init_keystore(struct device *dev); Arguments: dev points to a struct device established to manage resources for the secure memory subsystem.

8.1.10 Detect Available Secure Memory Storage Units

Returns the number of available units ("pages") that can be accessed by the local instance of this driver. Intended for use as a resource probe. u32 sm_detect_keystore_units(struct device *dev); Arguments: dev Points to a struct device established to manage resources for the secure memory subsystem. Returns: Number of detected units available for use, 0 through n - 1 may be used with subsequent calls to all other API functions.

8.1.11 Establish Keystore in Detected Unit

Sets up an allocation table in a detected unit that can be used for the storage of keys (or other secrets). The unit will be divided into a series of fixed-size slots, each one of which is marked available in the allocation table. The size of each slot is a build-time selectable parameter. No calls to the keystore access interface can occur until sm_establish_keystore() has been called. sm_establish_keystore() should follow a call to sm_detect_keystore_units(). int sm_establish_keystore(struct device *dev, u32 unit); Arguments: dev Points to a struct device established to manage resources for the secure memory subsystem. unit One of the units detected with a call to sm_detect_keystore_units(). Returns:

Zero on successful return
-EINVAL if the keystore subsystem was not initialized
-ENOSPC if no memory was available for the allocation table and associated context data. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

8.1.12 Release Keystore

Releases all resources used by this keystore unit. No further calls to the keystore access interface can be made. void sm_release_keystore(struct device *dev, u32 unit); Arguments: dev Points to a struct device established to manage resources for the secure memory subsystem. unit One of the units detected with a call to sm_detect_keystore_units().

8.1.13 Allocate a Slot from the Keystore

Allocate a slot from the keystore for use in all other subsequent operations by the keystore access interface. int sm_keystore_slot_alloc(struct device *dev, u32 unit, u32 size, u32*slot); Arguments: dev Points to a struct device established to manage resources for the secure memory subsystem. unit One of the units detected with a call to sm_detect_keystore_units(). size Desired size of data for storage in the allocated slot. slot Pointer to the variable to receive the allocated slot number, once known. Returns:

Zero for successful completion.
-EKEYREJECTED if the requested size exceeds the selected slot size.

8.1.14 Load Data into a Keystore Slot

Load data into an allocated keystore slot so that other operations (such as encapsulation) can be carried out upon it. int sm_keystore_slot_load(struct device *dev, u32 unit, u32 slot, constu8 *key_data, u32 key_length); Arguments: dev Points to a struct device established to manage resources for the secure memory subsystem. unit One of the units detected with a call to sm_detect_keystore_units(). key_length Length (in bytes) of information to write to the slot. key_data Pointer to buffer with the data to be loaded. Must be a contiguous buffer. Returns:

Zero for successful completion.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

8.1.15 Demo Image Update

Encapsulate data written into a keystore slot as a Secure Memory Blob. int sm_keystore_slot_encapsulate(struct device *dev, u32 unit, u32 inslot, u32 outslot, u16 secretlen, u8 *keymod, u16 keymodlen); Arguments: dev Points to a struct device established to manage resources for the secure memory subsystem. unit One of the units detected with a call to sm_detect_keystore_units(). inslot Slot holding the input secret, loaded into that slot by sm_keystore_slot_load(). Note that the slot containing this secret should be overwritten or deallocated as soon as practical, since it contains cleartext at this point. outslot Allocated slot to hold the encapsulated output as a Secure Memory Blob. secretlen Length of the secret to be encapsulated, not including any blob storage overhead (blob key, MAC, etc.). keymod Key modifier component to be used for encapsulation. The key modifier allows an extra secret to be used in the encapsulation process. The same modifier will also be required for decapsulation. keymodlen Lenth of key modifier in bytes. Returns:

Zero on success
CAAM job status if a failure occurs

8.1.16 Decapsulate Data in the Keystore

Decapsulate data in the keystore into a Black Key Blob for use in other cryptographic operations. A Black Key Blob allows a key to be used "covered" in main memory without exposing it as cleartext. int sm_keystore_slot_decapsulate(struct device *dev, u32 unit, u32 inslot, u32 outslot, u16 secretlen, u8 *keymod, u16 keymodlen); Arguments: dev Points to a struct device established to manage resourcesfor the secure memory subsystem. unit One of the units detected with a call to sm_detect_keystore_units(). inslot Slot holding the input data, processed by a prior call to sm_keystore_slot_encapsulate(), and containing a Secure Memory Blob. outslot Allocated slot to hold the decapsulated output data in the form of a Black Key Blob. secretlen Length of the secret to be decapsulated, without any blob storage overhead. keymod Key modified component specified at the time of encapsulation. keymodlen Lenth of key modifier in bytes. Returns:

Zero on success

NXP Semiconductors RM00293 i.MX Linux Reference Manual

8.1.17 Read Data From a Keystore Slot

Extract data from a keystore slot back to a user buffer. Normally to be used after some other operation (e.g., decapsulation) occurs. int sm_keystore_slot_read(struct device *dev, u32 unit, u32 slot, u32 key_length, u8 *key_data); Arguments: dev Points to a struct device established to manage resources for the secure memory subsystem. unit One of the units detected with a call to sm_detect_keystore_units(). slot Allocated slot to read from. key_length Length (in bytes) of information to read from the slot. key_data Pointer to buffer to hold the extracted data. Must be a contiguous buffer. Returns:

Zero for successful completion.
-EFBIG if the requested size exceeds that which the slot can hold.

8.1.18 Release a Slot back to the Keystore

Release a keystore slot back to the available pool. Information in the store is wiped clean before the deallocation occurs. int sm_keystore_slot_dealloc(struct device *dev, u32 unit, u32 slot); Arguments: dev Points to a struct device established to manage resources for the secure memory subsystem. unit One of the units detected with a call to sm_detect_keystore_units(). slot Number of the allocated slot to be released back to the store. Returns:

Zero for successful completion.
-EINVAL if an unallocated slot is specified. Configuration of the Secure Memory Driver / Keystore API is dependent on the following kernel configuration parameters: CRYPTO_DEV_FSL_CAAM_SM Turns on the secure memory driver in the kernel build. CRYPTO_DEV_FSL_CAAM_SM_SLOTSIZE Configures the size of a secure memory "slot". RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Each secure memory unit is block of internal memory, the size of which is implementation dependent. This block can be subdivided into a number of logical "slots" of a size which can be selected by this value. The size of these slots needs to be set to a value that can hold the largest secret size intended, plus the overhead of blob parameters (blob key and MAC, typically no more than 48 bytes). The values are selectable as powers of 2, limited to a range of 32 to 512 bytes. The default value is 7, for a size of 128 bytes. CRYPTO_DEV_FSL_CAAM_SM_TEST Enables operation of a captive test / example module that shows how one might use the API, while verifying its functionality. The test module works along this flow:

Creates a number of known clear keys (3 sizes).
Allocated secure memory slots.
Inserts those keys into secure memory slots and encapsulates.
Decapsulates those keys into black keys.
Enrcrypts DES, AES128, and AES256 plaintext with black keys. Since this uses symmetric ciphers, same-key encryption/decryption results will be equivalent.
Decrypts enciphered buffers with equivalent clear keys.
Compares decrypted results with original ciphertext and compares. If they match, the test reports OK for each key case tested. Normal output is reported at the console as follows: platform caam_sm.0: caam_sm_test: 8-byte key test match OK platform caam_sm.0: caam_sm_test: 16-byte key test match OK platform caam_sm.0: caam_sm_test: 32-byte key test match OK
The secure memory driver is not implemented as a kernel module at this point in time.
Implementation is presently limited to kernel-mode operations.
One instance is possible at the present time. In the future, when job rings can run independently in different system partitions, a multiple instance secure memory driver should be considered.
All storage requests are limited to the storage size of a single slot (which is of a build-time configurable length). It may be possible to allow a secret to span multiple slots so long as those slots can be allocated contiguously.
Slot size is fixed across all pages/partitions.
Encapsulation/Decapsulation interfaces could allow for authentication to be specified; the underlying interface does not request it.
Encapsulation/Decapsulation interfaces return a job status; this status should be translated into a meaningful error from errno.h

8.1.19 CAAM/SNVS - Security Violation Handling Interface Overview

This chapter describes a prototype of a driver component and control interface for SNVS Security Violations. It provides a means of installing, managing, and executing application defined handlers meant to process security violation events as a response to their occurrence in a system. SNVS allows for the continuous monitoring of a number of possible attack vectors in a running system. If the occurrence of one of these attach vectors is sensed, (e.g., a Security Violation has been detected), SNVS can, along with erasing critical security parameters and transitioning to a failure state. generate an interrupt indicating that the violation has occurred. This interrupt can dispatch an application-defined routine to take RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual cleanup action as a consequence of the violation, such that an orderly shutdown of security services might occur. Therefore, the purpose of this interface is to allow system-level services to install handlers for these types of events. This allows the system designer to select how he wants to respond to specific security violation causes using a simple function call written to his system-specific requirements.

8.1.20 Operation

For existing platforms, 6 security violation interrupt causes are possible within SNVS. 5 of these violation causes are normally wired for use, and these causes are defined as:

SECVIO_CAUSE_CAAM_VIOLATION - Violation detected inside CAAM/SNVS
SECVIO_CAUSE JTAG_ALARM - JTAG activity detected
SECVIO_CAUSE_WATCHDOG - Watchdog expiration
SECVIO_CAUSE_EXTERNAL_BOOT - External bootload activity
SECVIO_CAUSE_TAMPER_DETECT - Tamper detection logic triggered Each of these causes can be associated with an application-defined handler through the API provided with this driver. If no handler is specified, then a default handler will be called. This handler does no more than to identify the interrupt cause to the system console.

8.1.21 Configuration Interface

The following interface can be used to define or remove application-defined violation handlers from the driver's dispatch table.

8.1.22 Install a Handler

int caam_secvio_install_handler(struct device *dev, enum secvio_cause cause, void (*handler)(struct device *dev, u32 cause, void *ext), u8 *cause_description, void *ext); Arguments: dev Points to SNVS-owning device. cause Interrupt source cause from the above list of enumerated causes. handler Application-defined handler, gets called with dev, source cause, and locally-defined handler argument cause_description Points to a string to override the default cause name, this can be used as an alternate for error messages and such. If left NULL, the default description string is used. ext pointer to any extra data needed by the handler. Returns:

Zero on success.
-EINVAL if an argument was invalid or unusable.

8.1.23 Remove an Installed Driver

dev Points to SNVS-owning device. cause Interrupt source cause.

Zero on success.
-EINVAL if an argument was invalid or unusable.

8.1.24 Driver Configuration CAAM/SNVS

driver is not buildable as a module in its present form.

8.2 Display Content Integrity Checker (DCIC)

8.2.1 Introduction

The goal of the DCIC is to verify that a safety-critical information sent to a display is not corrupted.

Pixel clock up to 148.5 MHz
Configurable polarity of Display Interface control signals
24-bit pixel data bus
Up to 16 rectangular ROIs with a configurable location and size
Independent CRC32 signature calculation for each ROI
External controller mismatch indication signal

8.2.2 Source Code Structure

Table 94. DCIC Driver Files

8.2.3 Menu Configuration Options

8.2.4 DTS Configuration

Table 95. DCIC Input Select

8.2.5 IOCTLs Functions

DCIC_IOC_CONFIG_DCIC: Configures the DCIC input CLK, VSYNC, HSYNC, and data signal polarity.
DCIC_IOC_CONFIG_ROI: Configures the ROI block size and reference signature.
DCIC_IOC_GET_RESULT: Gets the result of the ROI calculated signature.

8.2.6 Structures

8.2.7 DCIC CRC Calculation Functions

bytes per pixel (bpp), and the four functions above can cover different display bus widths and bpps.

8.3 Smart Card Interface - Subscriber Identification Module (SIM)

8.3.1 Introduction

8.3.2 Modes of Operation

The SIM module I/O interface can be operated in one of the three modes of operation summarized below.

Two-wire interface: Both the IC pin RX and TX are used to interface to the SmartCard.
External one-wire interface: The IC pins RX and TX are tied together externally to the IC and routed to the SmartCard.
Internal one-wire interface: The IC pin TX is routed to the SmartCard. The receive pin RX is connected to the TX pin internally to the IC.

8.3.3 External Signal Description

SIM_CLK: clock that the SIM module provides for the SmartCard. Typical frequencies are 1 MHz to 5 MHz. This clock is 372 times the data rate that is on pin SIM_TRXD.
SIM_RST_B: reset signal from the SIM to the SmartCard.
SIM_SVEN: SmartCard power supply enable control signal.
SIM_TRXD: transmitted/received date from SIM module to SmartCard.
SIM_PD: SmartCard insertion detect.

8.3.4 Source Code Structure

Table 96. SIM Source

8.3.5 Menu Configuration Options

8.3.6 Software Framework

Figure 40. SIM receiving flow

8.4 Secure Non-Volatile Storage (SNVS)

8.4.1 Introduction

SNVS is a block that interfaces with CAAM and SRTC. For SNVS services related to CAAM, see Section Driver Configuration CAAM/SNVS. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

8.5 SNVS Real Time Clock (SRTC)

8.5.1 Introduction

and can raise an alarm if tampering with counters is detected.

8.5.2 Hardware Operation

8.5.3 Software Operation

The following sections describe the software operation of the RTC driver.

8.5.4 Driver Features

Implements the functions required by Linux OS to provide the real time clock and alarm interrupt
Alarm wakes up the system from low power modes

8.5.5 Source Code Structure

The RTC module is implemented in drivers/rtc. Table 97. RTC Driver Files

8.5.6 Menu Configuration Options

9 NXP eIQ Machine Learning

9.1 Overview of NXP eIQ Machine Learning

9.1.1 Introduction (ML)

NXP Semiconductors RM00293 i.MX Linux Reference Manual of ML is to build algorithms that can receive input data and use statistical analysis to predict an output while updating outputs as new data becomes available. In 2010, a huge boom started called Deep Learning - it is a fast-growing subdomain of ML, based on Neural Networks (NN). Inspired by the human brain, Deep Learning has achieved state of the art results in various tasks (e.g., computer vision (CV), natural language processing (NLP). Neural Nets are capable of learning complex patterns from millions of examples. Huge adaptation in the embedded world is expected – an area where NXP is a leader. Continuing the effort of enabling its customers, NXP has created NXP eIQ for i.MX, a set of ML tools which allows developing and deploying ML applications on i.MX 8 QuadMax devices. This chapter contains an overview of specific areas of NXP eIQ machine learning technology. For detailed execution of machine learning commands, see the i.MX Machine Learning User's Guide (IMXMLUG).

9.1.2 OpenCV

OpenCV is an open source computer vision library and one of its modules, called ML, provides traditional machine learning algorithms. Another important module in OpenCV is DNN; it provides support for neural network algorithms. OpenCV offers a unified solution for both neural network inference (DNN module) and classic machine learning algorithms (ML module). By including many computer vision functions OpenCV makes it easier to build complex machine learning applications in a short amount of time and without having dependencies on other libraries. OpenCV has wide adoption in the Computer Vision field and is supported by a strong and very active community. Key algorithms are specifically optimized for various devices and instructions sets. For i.MX, OpenCV uses Arm NEON acceleration. Arm Neon technology is an advanced SIMD (single instruction multiple data) architecture extension for the Arm Cortex-A series. Neon technology is intended to improve the multimedia user experience by accelerating audio and video encoding/decoding, user interface, 2D/3D graphics or gaming. Neon can also accelerate signal processing algorithms and functions to speed up applications such as audio and video processing, voice and facial recognition, computer vision and deep learning. At its core, the OpenCV DNN module implements an inference engine and does not provide any functionalities for neural network training. For more details about supported models and supported layers, check the official OpenCV Deep Learning page. The OpenCV ML module contains classes and functions for solving machine learning problems e.g. classification, regression or clustering. It involves algorithms such as support vector machine (SVM), decision trees, random trees, expectation maximization, k-nearest neighbors, classic Bayes classifier, logistic regression, and boosted trees.

9.1.3 Arm Compute

The Arm Compute Library is a collection of low-level functions optimized for Arm CPU and GPU architectures targeted at image processing, computer vision, and machine learning. Arm computer is a convenient repository of optimized functions that developers can source individually or use as part of complex pipelines to accelerate algorithms and applications. Arm compute library also supports NEON acceleration. ARM computer can be shown with examples using DNN models with random weights and inputs and AlexNet using the graph API.

9.1.4 TensorFlow Lite

TensorFlow Lite is a light-weight version of and a next step from TensorFlow. TensorFlow Lite is an open-source software library focused on running machine learning models on mobile and embedded devices (available at www.tensorflow.org/lite). It enables on-device machine learning inference with low latency and small binary size. TensorFlow Lite also supports hardware acceleration using Android OS Neural Networks API. TensorFlow Lite supports a set of core operators (both quantized and floating point) tuned for mobile platforms. They incorporate pre-fused activations and biases to further enhance the performance and quantized accuracy. Additionally, TensorFlow Lite also supports the use of custom operations in models. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual TensorFlow Lite defines a new model file format, based on FlatBuffers. FlatBuffers is an open-source, efficient, cross-platform serialization library. It is similar to protocol buffers, but the primary difference is that FlatBuffers does not need a parsing/unpacking step for a secondary representation before you can access the data, often coupled with per-object memory allocation. Also, the code footprint of FlatBuffers is an order of magnitude smaller than protocol buffers. TensorFlow Lite has a new mobile-optimized interpreter, which has the key goal to keep apps lean and fast. The interpreter uses static graph ordering and a custom (less-dynamic) memory allocator to ensure minimal load, initialization, and execution latency.

9.1.5 ONNX Runtime

ONNX Runtime is an open source inference engine framework developed by Microsoft supporting ONNX model format. ONNX Runtime runs on CPU with NEON and it also supports GPU/NPU hardware accelerators using the execution providers. For more details about ONNX Runtime, check the official ONNX Runtime project webpage.

9.1.6 PyTorch

PyTorch is an open source machine learning library used for applications, such as computer vision and natural language processing. It is free and open-source software. PyTorch provides a Python package for high-level features like tensor computation. For more details about PyTorch, check the official webpage www.pytorch.org.

9.1.7 DeepViewRT

DeepViewRT is a proprietary neural network inference engine optimized for NXP microprocessors and microcontrollers, which not only implements its own compute engine, but is also able to leverage popular 3rd-party ones.

9.1.8 TVM

TVM is an open deep learning compiler stack for CPUs, GPUs, and specialized accelerators. It aims to close the gap between the productivity-focused deep learning frameworks, and the performance-oriented or efficiency-oriented hardware backends.

10 Data Plane Development Kit (DPDK)

10.1 Introduction

Data Plane Development Kit (DPDK) is a user space packet processing framework. The following section contains instructions for installing and configuring the user space DPDK v22.11 software. Besides highlighting the applicable platforms, this guide describes steps for compiling and executing sample DPDK applications in a Linux application (linuxapp) environment over i.MX boards.

10.1.1 Supported Platforms and Platform-Specific Details

Layerscape family of SoCs. This section describes the port layout of their Design Boards. Port layout information is especially relevant while executing DPDK applications to map DPDK port number to physical ports. The following provides the i.MX board-specific information. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Figure 46. i.MX 95 port layout

DPDK port names are the PCI addresses for the Ethernet ports and users might see a different name on the board.
Users need to use the lspci command to know the PCI addresses on the respective boards.
TJA1103 or TJA1120 daughter card is required for enablement of the ENET2 port. i.MX 943 refers to the NXP i.MX 943 EVK platform. For more information, see i.MX 9 Applications Processors and i.MX 94 Applications Processor. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

10.1.2 References

to test all PMD supported features. Table 98. DPDK Application References Table 99. Release References

10.2 DPDK Overview

underlying network infrastructure. provided to help understand various features and uses of DPDK framework. be performed in stages, resulting in more efficient use of code on cores. upon Fast-Path and Poll Mode Driver (PMD). performance penalties they introduce. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

dedicated and assigned to running PMD. More information on general working of DPDK can be found through DPDK website.

10.2.1 DPDK Platform Support

This section describes the NXP Data Path Acceleration Architecture. See the diagram below. Figure 47. DPDK architecture with NXP components

10.2.2 Supported DPDK Features

Basic statistics
Packet type parsing
Promiscuous mode
L3/L4 checksum offload
Linux
Arm v8 Applications:
dpdk-l2fwd
dpdk-l3fwd
dpdk-testpmd – RX only, TX only and forward modes
dpdk-fpr (only for i.MX 93)

NXP Semiconductors RM00293 i.MX Linux Reference Manual

dpdk-proc-info (only for i.MX 943) Limitations:
Multi-queue is not supported. 10.2.3 Supported DPDK Features on ENETC (i.MX 95) The following is the list of DPDK NIC features:
Basic stats
Packet type parsing
Promiscuous mode
Multicast Promiscuous mode
L3/L4 checksum offload
Link speed/ status support
Linux
Arm v8
MAC exact filter table filtering
VLAN exact filter table filtering
VLAN promiscuous
Multi-queue supported
Link status interrupt
MTCP stack supported
TSN QBV supported Applications:
dpdk-l2fwd
dpdk-l3fwd
dpdk-testpmd – RX only, TX only and forward modes
dpdk-pdump
dpdk-proc-info
dpdk-ip_fragmentation
dpdk-ip_reassembly
dpdk-fpr
dpdk-test
dpdk-ipsec-secgw
dpdk-test-crypto-perf Other Supported Network interfaces:
PCI 1g card
Tap and Virtio interfaces

10.3 Build DPDK

This section includes two subsections, which detail:

Building DPDK binaries (libraries and sample applications) using the Yocto build system.

10.3.1 Build DPDK Using Yocto

details of using the Yocto build system. binaries would be merged into it. bitbake dpdk: It is assumed setup-environment was run before running this command. environment by default compiles DPDK and place it in the rootfs. installed, binaries would be available in /usr/bin folder in the rootfs. /usr/bin contains the sample applications listed in DPDK Application References. or with absolute path to the binaries. The following table lists various DPDK example applications, which are available in the Yocto generated rootfs. dpdk-fpr for i.MX 93 and i.MX 95. Table 100. DPDK Example Applications

10.3.2 Standalone Build of DPDK Libraries and Applications

i.MX boards or directly on the Layerscape/i.MX target board. building DPDK on Layerscape/i.MX boards. For instructions on how to build DPDK using Yocto system, see Section 10.3.1. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual The DPDK source code contains all the necessary libraries for build example applications as well as test applications. The source code also includes various configuration and scripts for supporting build and execution. Obtain the DPDK source code using the link below: git clone https://github.com/NXPmicro/dpdk.git Once the above repository has been cloned, DPDK source code is available for compilation. This source is common for the Layerscape and i.MX platforms. Prerequisites before compiling DPDK Before compiling DPDK as a standalone build, following dependencies need to be resolved independently:

Platform compliant and compiled Linux Kernel source code so that KNI modules can be built. – This is optional and if KNI module support is not required, this can be ignored. – For details of compiling platform-compliant Linux kernel, see Download Yocto layers and Build Yocto images – For disabling KNI module, see notes below
OpenSSL libraries required for building software crypto driver (OpenSSL PMD). – This is optional and if the software crypto driver support is not required, this dependency can be ignored. – OpenSSL package needs to be separately compiled and libraries installed at a known path before DPDK build can be done. Follow the steps below to build OpenSSL as a standalone package: git clone https://github.com/nxp-qoriq/qoriq-components_openssl -b integration # Clone the OpenSSL source code cd openssl # Change into cloned directory git checkout LSDK-21.08 # Checkout the specific Tag supported by DPDK Export the Cross Compilation tool chain for building OpenSSL for target. The following step for exporting cross compilation toolchain is required only when compiling on Host. On a target board, it is assumed default build toolchain would be used. export CROSS_COMPILE=<path to uncompressed toolchain archive>/bin/aarch64-linux- gnu- Configure the OpenSSL build system with following command. The --prefix argument specifies a path where OpenSSL libraries would be deployed after build completes. This is also a path which would be provided to DPDK build system for accessing the compiled OpenSSL libraries. ./Configure linux-aarch64 --prefix=<OpenSSL library path> shared make depend make make install export OPENSSL_PATH=<OpenSSL library path> Note: When building DPDK on target board, it is possible that OpenSSL libraries required by DPDK are already available as part of the rootfs, in which case external compilation of OpenSSL package would not be required. To disable OpenSSL PMD support, see notes below. Compiling DPDK using meson RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Follow the steps below to compile DPDK once the above prerequisites are resolved. These steps are common for all platforms and are needed only when cross compiling on a host for all boards as target. In case of direct compilation on target boards, it is assumed that prerequisites would be satisfied using the root filesystem. 1. Set up the environment for compilation: a. This step is required only in the host environment where default toolchain is not for target boards. When compiling on a target board, this step can be skipped. export CROSS_PATH=<path to cross-compile toolchain> export PATH=$PATH:$CROSS_PATH b. Set up OpenSSL path for software crypto drivers (OpenSSL PMD). This is optional and can be skipped in case software crypto driver (OpenSSL PMD) support is not required. These external variables can also be used to pass other required libraries for example libpcap. 2. Use DPDK build system for compiling DPDK. Note: DPDK binaries generated using below steps are compatible for Layerscape and i.MX platforms. This is also valid when DPDK is build through Yocto build system. a. Execute the following command: meson arm64-build --cross-file config/arm/<config_file> -Dexamples = <list of example applications to be compiled separated by commas> - Dprefix=<location to install DPDK> ninja -C arm64-build Here, -Dprefix and -Dexamples are optional parameters. Dprefix parameter is used to deploy all the DPDK binaries (libraries and example applications) to a standard Linux package-specific layout within a directory represented by this parameter. Alternatively, a directory dpdk/arm64-build/ is also created and binaries and libraries are also available in it. install parameter is also not required in the ninja command, if installation is not required. Dexamples is used to compile required examples. In case you need to compile only drivers, this parameter is not needed. Note: The config_file here should be arm64_imx_linux_gnu_gcc for i.MX 93, i.MX 91, and i.MX 95 boards (Cortex-A55 platforms). For other platforms: arm64_dpaa_linux_gnu_gcc should be used. b. Once the example applications are compiled, the binaries are available in the DPDK build directory with prefix “dpdk”-: dpdk/arm64-build/examples/* Besides the example application above, DPDK also provides some sample test applications, which can be used for comprehensive verification of the DPDK driver (PMD) features for available and compatible devices. These sample test applications are compiled by default during the DPDK source compilation. These are available in the dpdk/arm64-build/app/ directory.

10.4 Flashing the Target board

The Universal Update Utility (UUU) runs on a Windows or Linux OS host and is used to download images to different devices on an i.MX board. For how to flash the target board, see the section “Universal update utility” in the i.MX Linux User's Guide (UG10163).

10.5 Running DPDK

10.5.1 Test environment setup

Various sample application execution steps are described in the following sections. The following figure shows the setup containing the DUT (Device Under Test) and the Packet Generator (Spirent packet generator). This is RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

and Packet generator unit. DPDK application running on the DUT is expected to forward the traffic. Figure 48. DPDK application setup

10.5.2 Prerequisites to boot the board

The following steps must be performed on the U-Boot for all the i.MX platforms.

10.5.2.1 Update bootargs

default_board_specific_args are the default boot arguments. For example, it can be like: mmcargs=setenv bootargs ${jh_clk} console=${console} root=${mmcroot}
hugepages can be used to add the hugepages: default_hugepagesz=2m hugepagesz=2m hugepages=256 Note: The number of hugepages can be increased/decreased, which depends on the system memory availablity and application requirements. Only 2MB size hugepages are supported on all i.MX SoCs except for i.MX 95. i.MX 95 also supports 1G size hugepages along with 2MB size pages. It is mandatory to have a few 2MB size hugepages even if the application needs only 1G size hugepages. This is because Ethernet RX/TX rings only use 2MB size hugepage memory. Therefore, it need to reserve the number of RX and TX rings + addtional a few (at least 4) 2MB size hugepages as well as along with 1G size hugepages. Addtional 2MB hugepages are required for DPDK eal library to reserve the memory from 2MB size hugepages. For example, if the application needs to use one 1G hugepage and 6 RX + 6 TX queues, at least one 1G and 16 2MB size pages must be reserved: default_hugepagesz=1024m hugepagesz=1024m hugepages=1 hugepagesz=2m hugepages=16 On the kernel console, to use both hugepages, mount the hugepages as follows: mkdir /mnt/huge_1G mkdir /mnt/huge_2M mount -t hugetlbfs -o pagesize=1G none /mnt/huge_1G mount -t hugetlbfs -o pagesize=2M none /mnt/huge_2M

NXP Semiconductors RM00293 i.MX Linux Reference Manual

imx-mem-params is used to reserve the initial DDR memory from U-Boot through the mem environment variable. It needs to be set on platforms with FEC/eQoS Ethernet interfaces as the BD ring of FEC/eQoS interfaces can only accept 32-bit addresses. mem=2096M For optimized performance on the i.MX platforms, perform the following steps: 1. Add isolcpus=<core_list> in mmcargs to add the CPUs planned to be used for DPDK applications. Where <core_list> is: For i.MX 8MM, 8MP: 1-3 For i.MX 8DXL: 1 For i.MX 93: 1 For i.MX 95: 1-5 Note:
i.MX 8DXL and i.MX 93 have only 2 cores, but to reserve the core 1 for DPDK, we can provide core_list=1 for both platforms.
i.MX 91 has only core 0, so the option isolcpus cannot be used. 2. Add the following parameters in mmcargs to set the CPU not to enter idle mode: \cpuidle.off=1 cpufreq.off=1\ 3. Set the system in performance mode (applicable only if the system does not support the option cpufreq.off=1 in bootargs): echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/ scaling_governor grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor Note: If the governor is not supported, check the lpm-mode. For example, for the i.MX 93 board: root@imx93evk:~# cat /sys/devices/platform/imx93-lpm/mode System is in OD mode with DDR 3733 MTS! You can set it as : root@:~# echo 0 > /sys/devices/platform/imx93-lpm/mode System switching to OD mode... root@:~# cat /sys/devices/platform/imx93-lpm/mode System is in OD mode with DDR 3733 MTS! For ENET-FEC and ENET-QOS on all i.MX platforms: Check the properties such as reset-gpios, reset-assert-us, and reset-deassert-us for the Ethernet node on U-Boot using the following command: fdt print For details of the fdt command, see Section 10.5.2.2. If these properties are present in the Ethernet node, remove it as it may cause issues in the forwarding. Use the following command on the U-Boot: => fdt rm /<soc>/<bus>/<ethernet>/mdio/<ethernet-phy>/ "property"; eg. fdt rm /soc@0/bus@42800000/ethernet@42890000/mdio/ethernet-phy@2 "reset-gpios"; RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

10.5.2.2 Device Tree file

For the i.MX platforms, DPDK-specific Device Tree file should be used to boot up the board. This Device Tree file is configured to provide user space applications with network interfaces. Once the Device Tree configuration mentioned above is used, all the Ethernet ports would be available in the user space only except the i.MX 95 platform. Changes to the Device Tree file would be required to assign some of the ports to Linux Kernel. Users can use the following method to replace the default dtb to support DPDK on the i.MX platforms. Execute these commands on U-Boot for i.MX 8M Mini: U-Boot > setenv fdtfile imx8mm-evk-dpdk.dtb U-Boot > saveenv U-boot > boot Execute these commands on U-Boot for i.MX 8M Plus: U-Boot > setenv fdtfile imx8mp-evk-dpdk.dtb U-Boot > saveenv U-boot > boot Execute these commands on U-Boot for i.MX 8DXL: U-Boot > setenv fdtfile imx8dxl-evk.dtb; setenv loadkernel 'fatload mmc U-Boot > setenv loadfdt 'fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}'; U-Boot > run loadkernel; run loadfdt; fdt addr ${fdt_addr}; U-Boot > fdt set /bus@5b000000/ethernet@5b050000 compatible "fsl,imx-enet-qos" "snps,dwmac-5.10a"; U-Boot > setenv bootcmd 'mmc dev ${mmcdev};run mmcargs; booti ${loadaddr} - ${fdt_addr};' Execute these commands on U-Boot for i.MX 91: U-Boot > setenv fdtfile imx91-11x11-evk.dtb U-Boot > setenv loadkernel 'fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} Image' U-Boot > setenv loadfdt 'fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdtfile}'; U-Boot > run loadkernel; run loadfdt; fdt addr ${fdt_addr}; U-Boot > fdt set /soc@0/bus@42800000/ethernet@42890000 compatible "fsl,imx8mm- fec-uio"; U-Boot > fdt set /soc@0/bus@42800000/ethernet@428a0000 compatible "fsl,imx-enet- qos" "snps,dwmac-5.10a"; U-Boot > fdt resize 4096; U-Boot > fdt set /aliases "ethernet1" "/soc@0/bus@42800000/ethernet@428a0000"; U-Boot > setenv bootcmd 'mmc dev ${mmcdev}; run mmcargs; booti ${loadaddr} - ${fdt_addr};' Execute these commands on U-Boot for i.MX 93: U-Boot > setenv fdtfile imx93-11x11-evk.dtb U-Boot > setenv loadkernel fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} Image; U-Boot > setenv loadfdt 'fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr_r} ${fdtfile}'; U-Boot > run loadkernel; run loadfdt; fdt addr ${fdt_addr_r}; U-Boot > fdt set /soc@0/bus@42800000/ethernet@42890000 compatible "fsl,imx8mm- fec-uio"; RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual U-Boot > fdt rm /soc@0/bus@42800000/ethernet@42890000/mdio/ethernet-phy@2 "reset-gpios"; U-Boot > fdt rm /soc@0/bus@42800000/ethernet@42890000/mdio/ethernet-phy@2 "reset-assert-us"; U-Boot > fdt rm /soc@0/bus@42800000/ethernet@42890000/mdio/ethernet-phy@2 "reset-deassert-us"; U-Boot > fdt set /soc@0/bus@42800000/ethernet@428a0000 compatible "fsl,imx-enet- qos" "snps,dwmac-5.10a"; U-Boot > fdt resize 4096; U-Boot > fdt set /aliases "ethernet1" "/soc@0/bus@42800000/ethernet@428a0000"; U-Boot > fdt rm /soc@0/bus@42800000/ethernet@428a0000/mdio/ethernet-phy@1 "reset-gpios"; U-Boot > fdt rm /soc@0/bus@42800000/ethernet@428a0000/mdio/ethernet-phy@1 "reset-assert-us"; U-Boot > fdt rm /soc@0/bus@42800000/ethernet@428a0000/mdio/ethernet-phy@1 "reset-deassert-us"; U-Boot > run mmcargs; sleep 1; booti ${loadaddr} - ${fdt_addr}; Execute these commands on U-Boot for i.MX 95 (Cortex-A core): U-Boot > setenv fdtfile imx95-19x19-evk.dtb U-Boot > saveenv U-boot > boot Execute these commands on U-Boot for i.MX 95 (Cortex-M7 core): U-Boot > setenv fdtfile imx95-19x19-evk-netc-rpmsg.dtb U-Boot > saveenv U-boot > boot Execute these commands on U-Boot for i.MX 943 (SGMII ports): U-Boot > setenv fdtfile imx943-evk-sgmii.dtb U-Boot > saveenv U-Boot > boot

10.5.3 Prerequisites for running DPDK applications on Linux OS

When the Linux OS is up, perform the following steps before running the DPDK applications: 1. Load the non-cacheable module. modprobe kpage_ncache.ko 2. Manually allocate hugepages if required. echo 448 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages Note: Users may not be required to allocate hugepages if they are already added from the kernel bootargs. It can be checked using: cat /proc/cmdline

10.5.4 Executing DPDK applications

This section describes how to execute DPDK sample applications on i.MX platforms. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual i.MX 93 platforms Note:

The following command snippets assume that the commands are executed while being present in /usr/bin or appropriate PATH variable has been set.
i.MX 8M Mini supports ENETFEC Ethernet interface.
i.MX 8DXL supports ENETQOS Ethernet interface.
i.MX 8M Plus, i.MX 93, and i.MX 91 support ENETFEC and ENETQOS Ethernet interfaces.
User must provide the --vdev argument with the value net_enetfec to enable ENETFEC Ethernet device and/or --vdev argument with the value net_enetqos to enable ENETQOS Ethernet device for DPDK applications. l2fwd– Layer 2 forwarding application Sample application to show forwarding between multiple ports based on the Layer 2 information: dpdk-l2fwd -c 0x1 -n 1 --vdev 'net_enetfec' -- -p 0x1 dpdk-l2fwd -c 0x1 -n 1 --vdev 'net_enetqos' -- -p 0x1 dpdk-l2fwd -c 0x3 -n 1 --vdev 'net_enetqos' --vdev 'net_enetfec' -- -p 0x3 -T 0 In the command above: -c refers to the core mask for the cores to be assigned to DPDK. -p is the port mask for the ports to be used by the application. Other command line parameters may also be provided. For a complete list, see L2Forwarding Sample Application (in Real and Virtualized Environments). Note: DPDK L2fwd application periodically prints the I/O stats. To avoid CPU core to be interrupted because of these scheduled prints, the -T 0 option can be appended atthe end of the command line. l3fwd– Layer 3 forwarding application Sample application to show forwarding between multiple ports based on the Layer 3 information: dpdk-l3fwd -c 0x1 --vdev='net_enetfec' -n 1 -- -p 0x1 --config="(0,0,0)" -P -- parse-ptype dpdk-l3fwd -c 0x1 --vdev='net_enetqos' -n 1 -- -p 0x1 --config="(0,0,0)" -P -- parse-ptype dpdk-l3fwd -c 0x3 -n 1 --vdev 'net_enetqos' --vdev 'net_enetfec' -- -p 0x3 -P -- config="(0,0,1)(1,0,1)" --parse-ptype In the command above: -c refers to the core mask for the cores to be assigned to DPDK. -p is the port mask for the ports to be used by application. --config is the (Port, Queue, Core) configuration used by the application for attaching cores to queues on each port. Other command line parameters may also be provided. For a complete list, see L3Forwarding Sample Application. dpdk-testpmd Sample application used for the functionality test. It ensures that the traffic generator to board connectivity is proper. You may run dpdk-testpmd in tx_only mode to validate, if the packets are going out on specific interfaces. For the information about the testpmd application and its supported arguments, see webdocumentation.
For TX only: dpdk-testpmd -c 0x1 -n 1 --vdev='net_enetfec' -- -i --portmask=0x1 --nb-ports=1 --forward-mode=rxonly RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual dpdk-testpmd -c 0x3 -n 1 --vdev 'net_enetqos' -- -i --portmask=0x2 --nb-ports=1 --forward-mode=txonly

For RX only: dpdk-testpmd -c 0x1 -n 1 --vdev='net_enetfec' -- -i --portmask=0x1 --nb-ports=1 --forward-mode=txonly dpdk-testpmd -c 0x1 -n 1 --vdev 'net_enetqos' -- -i --portmask=0x2 --nb-ports=1 --forward-mode=rxonly
For IO: dpdk-testpmd -c 0x1 -n 1 --vdev=’net_enetfec’ -- -i --portmask=0x1 --nb-ports=1 --forward-mode=io dpdk-testpmd -c 0x1 -n 1 --vdev 'net_enetqos' -- -i --portmask=0x2 --nb-ports=1 --forward-mode=io dpdk-testpmd -c 0x3 -n 1 --vdev 'net_enetqos' --vdev 'net_enetfec' -- -i -- portmask=0x3 --nb-ports=2 --forward-mode=io 10.5.4.2 Executing DPDK applications on i.MX 95 platform On i.MX 95, DPDK supports VF for both enetc-1g and enetc-10g interfaces. Note: Users must provide the --vdev argument with the value net_tap0 for tap interface and virtio_user0 for the i.MX 95 platform in TAP/Virtio-ENETC use-case.

10.5.4.2.1 Setting up the ENETC Ethernet interfaces

Note: In the following steps, we are creating VF0 and running DPDK on it. Perform the following steps to set up each ENETC interface: 1. Configure multiple queues (if required as per usecase). Devlink utilty in Linux OS can be used to configure multiple queues in the initialization process of PF. The number of rings allocated to each SI is at least 1. a. Example to set the number of rings of PF to 1, VF0 to 6, and VF1 to 1: devlink dev param set pci/0002:00:10.0 name si_num_rings cmode driverinit value 0106 Note: Here, 0002:00:10.0 is the PF PCI address. The value is a string type value. Numerically higher VFs have lower bytes of the string. For example, if one ENETC supports 2 VFs, and the string is set to "304" or "0304", then the ring allocation for each VF is shown below: VF0 = 0x04 VF1 = 0x03 The number of rings of PFs is not explicitly presented in the string, because the remaining number of rings is reserved for PF. b. Run the devlink reload command to apply the new configuration. devlink dev reload pci/0002:00:10.0 c. Verify the value of si_num_rings. devlink dev param show pci/0002:00:10.0 name si_num_rings RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Example output: pci/0002:00:10.0: name si_num_rings type driver-specific values: cmode driverinit value 0106 Note: For Arm Cortex-M7, VF0 is configured to support 3 queues and VF1 is configured to support 4 queues and it is not user configurable. 2. Bind VFs to the DPDK. echo 1 > /sys/bus/pci/devices/0002\\:00\\:00.0/sriov_numvfs Note: Use dpdk-devbind.py -s to identify the PCI address of the 1g and 10g ports, like 0002:00:00.0 in the example above. Check dmesg logs to identify the PCI address of the VF created. Example kernel logs for VF: [ 2002.156985] fsl_enetc_vf 0002:00:12.0: enabling device (0000 -> 0002) [ 2002.517997] uio_pci_generic 0002:00:12.0: enabling device (0000 -> 0002) [ 2002.543684] uio_pci_generic 0002:00:12.0: No IRQ assigned to device: no support for interrupts? Use dpdk-devbind.py to bind VF to DPDK: dpdk-devbind.py -b uio_pci_generic <vf-pci-addr> Note: Users must use the igb_uio module instead of uio_pci_genric for link status interrupts. According to the logs above, 0002:00:12.0 is the <vf-pci-addr>. 3. Enable trust for the specified VF user by specifying the PF eth interface. (Not required on the Cortex- M7.) ip link set <eth-interface> vf 0 trust on Check the eth interface using: eg. ./dpdk-devbind.py -s [In below o/p eth0 is the PF eth interface] 0002:00:00.0 'Device e101' if=eth0 drv=fsl_enetc4 unused=vfio- pci,uio_pci_generic Execute the following command to run the DPDK application on i.MX 95: ./dpdk-l2fwd -c 0x3 -n 1 -- -p 0x1 ./dpdk-l3fwd -c 0x2 -n 1 -- -p 0x1 -P --config="(0,0,1)" ./dpdk-testpmd -c 0x3 -n 1 -- -i --portmask=0x1 ./dpdk-ip_fragmentation -c 0x2 -n 1 -- -p 0x1 ./dpdk-ip_reassembly -c 0x2 -n 1 -- -p 0x1 Examples to run DPDK with multi-queues: ./dpdk-l3fwd -c 0x3f -n 1 -- -p 0x1 -P --config="(0,0,1) (0,1,2) (0,2,3) (0,3,4) (0,4,5) (0,5,0)" ./dpdk-testpmd -c 0x3f -n 1 -- -i --portmask=0x1 --rxq=5 --txq=5 RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

10.5.4.2.3 OpenSSL-based applications

OpenSSL-based applications include the following:

dpdk-test application: The dpdk-test application is a command-line interface that facilitates running various tests or test suites. It can be used to do functional testing of the drivers and libraries. The binary is tested for various algos and protocols in Crypto PMDs. dpdk-test --vdev 'crypto_openssl' --log-level=6 RTE>> cryptodev_openssl_asym_autotest For more details, see dpdk-test.
dpdk-test-crypto-perf application: The dpdk-test-crypto-perf tool is a DPDK utility that allow to measure the performance parameters of PMDs available in the Crypto tree. There are two measurement types available: throughput and latency. This application is tested using the crypto_perf_test.sh script. crypto_perf_test.sh openssl For more details, see dpdk-test-crypto-perf.
IPsec Gateway dpdk-ipsec-secgw application: General setup: – For IPsec application, two DUTs need to be configured as endpoint 0 (ep0) and endpoint 1 (ep1). – Connect Port 1 and Port 1 of the ep0 and ep1 to each other (back-to-back). – Connect Port 0 and Port 0 of the ep0 and ep1 to packet generator (for example, Spirent). The sample configurations for both ep0 and ep1 are available at /etc/dpdk/. Custom port mappings, SA/SP and the routes can be configured in the corresponding configuration file named ep0.cfg and ep1.cfg for respective endpoint. – Endpoint 0 command: dpdk-ipsec-secgw -c 0x8 --vdev 'crypto_openssl' -- -p 0x2 -P -- config="(1,0,3)" -f /etc/dpdk/ep0_64X64.cfg – Endpoint 1 command: dpdk-ipsec-secgw -c 0x8 --vdev 'crypto_openssl' -- -p 0x2 -P -- config="(1,0,3)" -f /etc/dpdk/ep1_64X64.cfg For more details, see dpdk-ipsec-secgw.

10.5.4.2.4 PSI-VSI MBOX messaging

DPDK supports VF to send messages to PF by the VSI-TO-PSI messaging mechanism. It can be used for supporting features not under VF's control. Currently, the following features have been supported using this mechanism:

VF primary MAC based filtering
Enable/Disable Promiscuous mode
Enable/Disable Allmulti MAC mode
Get link status
Get link speed
MAC Exact Match filtering
VLAN Exact Match filtering
Enable/Disable VLAN promiscous mode

NXP Semiconductors RM00293 i.MX Linux Reference Manual 2. (Optional) Control the timeout and delay time counters with env. variables. export ENETC4_VSI_WAIT_DELAY_UPDATE=<val> export ENETC4_VSI_WAIT_TIMEOUT_UPDATE=<val> Note: Using these parameters, users have control over the waiting time for PSI to process message sent by VSI. 3. Enable trust for the specified VF user by specifying the PF eth interface. (Not required on the Cortex- M7.) ip link set <eth-interface> vf 0 trust on Check the eth interface using: eg. ./dpdk-devbind.py -s [In below o/p eth0 will be the PF eth interface] 0002:00:00.0 'Device e101' if=eth0 drv=fsl_enetc4 unused=vfio- pci,uio_pci_generic 4. Run the dpdk-testpmd application: ./dpdk-testpmd -c 0x3 -n 1 -- -i --portmask=0x1 5. These features can be tested using dpdk-testpmd using its runtime functions below: mac_addr set <port_id> <valid_mac_address> /* Set Primary MAC */ set promisc <port_id> off/on /* Enable/Disable promiscuous mode set allmulti <port_id> off/on /* Enable/Disable allmulti MAC mode */ show port info <port_id> /* Get link status/speed */ See webdocumentation for the information on the dpdk-testpmd application runtime functions. To add the MAC adddress exact match entry: 1. Disable the promiscuous mode to test the MAC entries filtering. set promisc <port_id> off 2. Run the following command to add the exact match MAC address entry: mac_addr add <port_id> <valid_mac_address> To add/remove the VLAN exact match entry: Run the following commands on the dpdk-testpmd the command line interface to disable the VLAN promisc mode and set the VLAN filter mode for the port: vlan set filter on <port_id> Note: By default, the VLAN promisc mode is enabled. Once the VLAN promisc is off, add the exact match VLAN entries: If required, the entry can be removed using the following command: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual To enable promisc mode and unset VLAN filter mode for the port: vlan set filter off <port_id> Note: Currently, the maximum MAC and VLAN address exact match filter table entries that can be added are 4 per ENETC. To register link status interrupts: DPDK is dependant on the igb_uio module instead of uio_pci_genric for interrupts. Run the following commands to bind the device to igb_uio: insmod igb_uio.ko or modprobe igb_uio 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 Run dpdk-testpmd to check the status interrupts: ./dpdk-testpmd -c 0xc --log-level=*:debug -n 1 -- -i --portmask 0x1 Open a new terminal and try to change the link status using either the following commands or attach and de- attach the cable: $ ifconfig eth1 down $ ifconfig eth1 up Note: Here, eth1 is the PF interface. Then users can observe the link change notifications on the console. It may take a few seconds to get the notification of link up.

10.5.4.2.5 Running DPDK on VF1

i.MX 95 supports maximum two VFs. To test DPDK with second VF, perform the following steps. In this use- case, two VFs are created, VF0 is owned by the kernel and VF1 is owned by DPDK. 1. Run the devbind.py script for the device ID. ./dpdk-devbind.py -s 2. Create two VFs, one for DPDK and one for the kernel. echo 2 > /sys/bus/pci/devices/0002\\:00\\:10.0/sriov_numvfs 3. Check dmesg logs to identify the PCI address of the VF1 created. Example kernel logs for VF: [107.122861] pci 0002:00:12.0: [1131:ef00] type 00 class 0x020001 [107.230531] fsl_enetc_vf 0002:00:12.0: enabling device (0000 -> 0002) [ 107.232173] pci 0002:00:14.0: [1131:ef00] type 00 class 0x020001 [ 107.342547] fsl_enetc_vf 0002:00:14.0: enabling device (0000 -> 0002) 4. Use dpdk-devbind.py to bind VF1 to DPDK: dpdk-devbind.py -b uio_pci_generic <vf1-pci-addr> As per the logs above, 0002:00:14.0 is the <vf1-pci-addr>. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual 5. Enable trust for the specified VF user by specifying the PF eth interface. ip link set <eth-interface> vf 1 trust on Check eth interface using: eg. ./dpdk-devbind.py -s [In below o/p eth0 is the PF eth interface] 0002:00:00.0 'Device e101' if=eth0 drv=fsl_enetc4 unused=vfio- pci,uio_pci_generic 6. Run the following commands: ./dpdk-l2fwd -c 0x3 -n 1 -- -p 0x1 ./dpdk-l3fwd -c 0x2 -n 1 -- -p 0x1 -P --config="(0,0,1)" Note:

i.MX 95 supports the maximum frame size to 2000 Bytes.
Availability of Multiple queues is dependent on the ENETC PF driver (Arm core kernel driver or Cotex-M7 core driver).
RSS is enabled on using multiple queues. – The RSS secret key is a random key. – Enabled RSS hash functions are IP source address, IP destination address, UDP/TCP source port, and UDP/TCP destination port.
Receive queues are equally configured in the RSS indirection table to receive flows.
Hardware Packet type parsing for supported packets is enabled by default.
Checksum validation offload is enabled by default.
Only 1G Intel Gigabit PCI-E Network Adapter EXPI9301CTBLK is supported.
Only ENETC 10G interface is supported with the Cortex-M7 image.
ip_fragmentation and ip_reassembly can receive only up to 2000 bytes.
Link status change notifications are supported with the igb_uio framework only. It may take a few seconds to get the link status UP notification. 10.6 Executing DPDK applications on i.MX 943 platform Note: Only the internal ENETC port supports VF, which is connected to the switch CPU port. External ENETC ports do not support VF. 1. Create and configure the bridge with two switch ports: ip link add name br0 type bridge ip link set dev swp0 master br0 ip link set dev swp1 master br0 ip link set dev br0 up ip link set dev swp0 up ip link set dev swp1 up 2. Create 2 Virtual Functions (VFs): echo 2 > /sys/bus/pci/devices/0000:00:00.0/sriov_numvfs 3. Bind the VFs to the DPDK-compatible driver: dpdk-devbind.py -b uio_pci_generic 0000:00:08.0 dpdk-devbind.py -b uio_pci_generic 0000:00:10.0 4. Enable trusted mode for both VFs: ip link set eth0 vf 0 trust on RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual ip link set eth0 vf 1 trust on 5. Add static forwarding entries to the bridge's forwarding database (FDB): bridge fdb add 02:00:00:00:00:00 dev swp0 master static bridge fdb add 02:00:00:00:00:01 dev swp1 master static Note: This means that if a packet has destination MAC 02:00:00:00:00:00, the bridge forwards it out swp0. If the destination is 02:00:00:00:00:01, it goes out through swp1. For dpdk-l2fwd, the destination MAC address is replaced by 02:00:00:00:00:TX_PORT_ID, hence this is set here. For dpdk-l3fwd, add the static MAC address through the command line. dpdk-testpmd sets the same MAC when running in MAC mode. 6. Run the DPDK application: $ dpdk-l2fwd -c 0x3 -n 1 -- -p 0x3 -T 0 $ dpdk-l3fwd -c 0x2 -n 1 -- -p 0x3 --config="(0,0,1), (1,0,1)" $ dpdk-testpmd -c 0x3 -n 1 -- -i --portmask=0x3 --forward-mode=mac testpmd> set promisc all off testpmd> start Note: Currently, the following test cases are not supported on i.MX 943:

All multi-promisc mode
Get Link status of VF
MAC address exact match filter
Multi-queue
Link status interrupts
Jumbo frame
DPDK IP fragmentation
DPDK reassembly 10.7 IEEE 802.1Qbv

10.7.1 Overview

IEEE 802.1Qbv allows time-based scheduling of network traffic.
The Gate Control List (GCL) is a fundamental component of the IEEE 802.1Qbv protocol.
The GCL (Gate C Logic) entries decide the gate open/close timings.
The queues are allowed to transmit only when the gate is open.
The GCL operates in a cyclic manner, repeating its sequence of entries periodically.

10.7.2 Steps to test the QBV test case scenario for ENETC

To test the TSN-QBV scenario for ENETC, perform the following steps: 1. Configure multiple queues for VF0. Use the following commands to configure 5 queues for VF0. devlink dev param set pci/0002:00:10.0 name si_num_rings cmode driverinit value 0105 devlink dev reload pci/0002:00:10.0 devlink dev param show pci/0002:00:10.0 name si_num_rings Note: Maximum queues for VF0 can be 5 because the minimum 2 is required for PF by using the tc command to configure gate scheduling and 1 is reserved for VF1. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual 2. Bind VFs to the DPDK. echo 1 > /sys/bus/pci/devices/0002\\:00\\:10.0/sriov_numvfs dpdk-devbind.py -b uio_pci_generic 0002:00:12.0 ip link set eth1 vf 0 trust on 3. Configure the QBV rule using the tc command. Use the following commands to configure the gate scheduling: tc qdisc replace dev eth1 parent root handle 200 taprio num_tc 2 map 0 1 queues 1@0 1@1 base-time 10000 sched-entry S 1 100000 sched-entry S 0 50000 sched-entry S 2 100000 sched-entry S 0 50000 sched-entry S 4 100000 sched- entry S 0 50000 sched-entry S 8 100000 sched-entry S 0 50000 sched-entry S 10 100000 sched-entry S 0 50000 sched-entry S 20 100000 sched-entry S 0 50000 sched-entry S 40 100000 sched-entry S 0 50000 sched-entry S 80 100000 flags 0x2

Each queue is configured to a particular TC.
In this command, gate is configured to open for a particular queue for 100 microsec and then all queue gates are closed for 50 microsec between every gate scheduling.
Configuring all gates closed for some time can be beneficial when analyzing the captured data packets.
The priority for each queue is configured by users in DPDK using the devargs argument.
Although num_tc and map define only two PF queues, the GCL includes entries for multiple queues, including VF queues (for example, VF0). This is intentional so that the GCL can be effective for DPDK applications.
In the tc command, queue IDs are referenced using the mask values (for example, S 1, S 2, etc.). These map directly to TX queues in DPDK when the GCL is applied. For example, S 1 corresponds to the txq0 in DPDK, S 2 maps to txq1, and so on. Note: For more details on tc qdisc and its usage, see the tc qdisc main page: Run man tc on your terminal for details. 4. Check if the rule is properly implemented. tc -d -s qdisc show dev eth1 root 5. Run the test-pmd command. ./dpdk-testpmd -c 0xf -n 1 -a 0002:00:12.0,enetc4_txq_prior="1|2|3|4|5" -- -i --nb-ports=1 --nb-cores=3 --forward-mode=txonly --txq=3 --txonly_vlan_multiq_enable --txpkts=1500
The priority for each queue is configured by users in DPDK using the devargs argument as shown in the command above.
The priorities for each queue are separated by '|' in devargs. In tc qdisc GCL: Queue IDs (S 1, S 2, etc.) are scheduled for specific time slices. In DPDK: These queue IDs map to transmit queues as follows:
S 1 -> txq0
S 2 -> txq1
S 4 -> txq2, and so on 6. Capture the packets on Spirent and analyze the Wireshark output. The output should be observed in the way the rule is configured using the tc command. According to the tc command above, the expected results should be: VLAN priority 0 packets are displayed for 100 microsec, and then a break of 50 microsec should be observed. Then again for 100 microsec VLAN priority 1 packets are displayed, and then a break of 50 microsec, and so on. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

10.8 DPDK-FPR application

10.8.1 Overview

DPDK-FPR is a DPDK-based Fast Path Routing application supported on i.MX 95 and i.MX 93. The DPDK-FPR application provides the following capabilities:

Routing between DPDK interfaces using Longest Prefix Match (LPM).
Supports both IPv4 and IPv6 traffic.
Learns Routes and Neighbors from the Linux kernel using Netlink, with automatic updates managed by kernel.
Forwards non-IPv4 and non-IPv6 packets to kernel.
Provides IP forwarding and rate limiting to kernel traffic.
Support 5 tuples ACL based packets drop.
Provides core-based statistics.
Includes a Command Line Interface (CLI) based on Unix sockets.
Configurable through a configuration file. When running the DPDK-FPR application with an Ethernet interface, an equivalent tap interface (named dtap*) is created in the kernel. This tap interface allows the application to send traffic to the kernel in scenarios where DPDK relies on the kernel or dependencies like routing and neighbor table information. The MAC address of the dtap interface matches that of the Ethernet interface used by DPDK. Configuration of the dtap interface is managed through a callback script provided by the user.

10.8.2 DPDK compilation

Perform the following steps: 1. See Section 10.3.2 for Compiling DPDK using meson. 2. To install the DPDK in a particular directory, export the following env. variable for compiling the DPDK. export DESTDIR=<path to install> 3. Compile and install the DPDK: meson <params> ninja -C <build> install

10.8.3 Application compilation

Execute the following commands: export ARCH=aarch64 export PATH=$PATH:<toolchain path> export CC=aarch64-linux-gnu-gcc export AR=aarch64-linux-gnu-ar export PKG_CONFIG_LIBDIR=$PKG_CONFIG_LIBDIR:<DESTDIR>/usr/local/lib/pkgconfig/ make Note: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual 1. Update CC according to the toolchain GCC binary name. 2. Modify the libdpdk.pc file for correct installation path. Perform the following steps: a. Edit the libdpdk.pc file at the location: <DESTDIR>/usr/local/lib/pkgconfig/libdpdk.pc. b. Update the first line prefix path to: prefix=<DESTDIR>/usr/local.

10.8.4 Running the application

Perform the following steps to run dpdk-fpr. Note: For the i.MX 93 platform:

Use the /etc/dpdk-fpr/fpr_imx93.conf file to run dpdk-fpr on this platform.
ENET-FEC limitation: Enable promiscuous to resolve arp of IPv6 traffic. Note: All the configuration files are available in the /etc/dpdk-fpr folder in rootfs, and the dpdk-fpr binary is in the /usr/bin folder in rootfs. 3. Run the dpdk-fpr application. cd /etc/dpdk-fpr ./dpdk-fpr --configfile ./fpr.conf 4. Open a new shell. 5. Connect to FPR using socat: - socat - UNIX-CONNECT:/tmp/fpr.sock - help 6. Resolve the ARP and run traffic.

10.8.5 CLI commands help accessible through socat

Perform the following steps: 1. Show help: help 2. Show the neighbour table (similar with the ARP table in the Linux kernel, only valid rules): neigh ipv4/ipv6 3. To look up a route entry in the LPM table: lpm_lkp <IP> 4. Show the LPM status (Added/Deleted routes): lpm_stats ipv4/ipv6 5. Show the status: # Detailed cores stats stats # Detailed cores stats in JSON format stats -j # Display cores stats after every <sec> stats -c <sec> RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual 6. Dump the full neighbour table: dump_neigh ipv4 <filepath e.g. /home/root/temp.txt> cat /home/root/temp.txt 7. Dump the current log levels and log type IDs: dumploglevel <filepath e.g. /home/root/level.txt> cat /home/root/level.txt 8. Set the global log level: # Value can be 0 to 8: 0 is no logs and 8 is debug level loglevel <level> 9. Enable/Disable the log type levels: logtype <type_id> <enable/disable> For type_id: Use "dumploglevel" to see type id of a DPDK component. For all log types, type_id is 255. enable/disable: 0 for log disable and 1 for log enable. Level of enabled log will be global log level which can be set by "loglevel" 10. IP rate limit: rlimit <IP> <PPS> 0 PPS indicates rate limit is disabled. Note: FPR limits the rate to approximate PPS value. 11. Add IPv4/IPv6 ACL rules to drop packets: acl_add ipv4/ipv6 <file_path> 12. Show/Clear the port: # Display port information show port info <portid> # Display port specific statistics show port stats <portid> # Display port specific extended statistics show port xstats <portid> Note:

Replace show with clear to clear the statistics.
These features are available only if the underlying driver supports these features.

10.8.6 Configuration file options

The configuration file options include the following:

Options defined under the section [EAL]: arg = <list of EAL arguments> Note: – Refer to DPDK-EAL for DPDK official EAL document arguments. – Pass the tap interfaces as vdev in the EAL argument list. – The number of vdev must be equal to the actual number of the Ethernet devices.
Options defined under the section [fpr]: - callback-setup = <script> Give shell script path to config kernel interfaces. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Script can have commands for IP address, routes and ARPs - promiscuous = <0/1> 1 to enable and 0 to disable promiscuous - multicast = <0/1> 1 to enable and 0 to disable multicast - kni_rate_limit = <PPS> Rate limit the packets in PPS sent to the kernel interface. 0 value disables rate limit. - unixsock = <PATH> Override cmdline unixsock path (default: "/tmp/fpr.sock) - rule_ipv4 = <file path> File path for IPv4 ACL rules. Only packet drop action is supported. Use "/dev/ null" as value to not to configure any ACL rule. Refer: L3FWD-ACL - rule_ipv6 = <file path> File path for IPv6 ACL rules. Only packet drop action is supported. Use "/dev/ null" as value to not to configure any ACL rule. Refer: L3FWD-ACL - max-pkt-len = <len> Increase or decrease the maximum RX length. max-pkt-len = MTU(Maximum Transmission Unit) + 14(src mac + dst mac) + 4(CRC) MTU will also be driven from this value. - rate_limit = <file path> Define rate limite for various IP range. FPR will limit the rate to approximate PPS value. - aclneon = 1 To enable Neon algorithm for ACL

Options defined under the section [port <portid>]: Note: <portid> is the ID of the port to be used. - eal queues = <queue id> <lcore id> Only single queue is supported so queue id must be 0 - kni = <lcore id> Configuration of equivalent kernel interface. User will have to create the interface via EAL arguments. Note: To comment a line in the configuration file, put ";" before the line.

10.8.7 Limitations

The DPDK-FPR application has the following limitations:

The default gateway for routes is not supported.
No IPv6 extension headers are supported.

10.9 MTCP

10.9.1 i.MX 95 Setup

Connect two i.MX 95 boards in back-to-back setup. 10.9.2 "client" Application Application measures read and write throughput for given number of seconds. 1. Rename the sample files sample_route.conf and sample_arp.conf under /usr/bin/mtcp to route.conf and arp.conf respectively. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual 3. Update the route and arp entries according to the IP addresses and MAC addresses of the interfaces. Note: The port MAC address and IP address (if not given in the configuration file) are shown on the application initialization. Therefore, execute the application, get the IP addresses and MAC addresses, fill the route and arp configuration, and re-run the application. 4. Update client.conf with the required details and correct port names to be used for traffic. The port names must be separated by commas (,). Note: For i.MX 95, the PCI address format, for example, 0000.00.10.0, for the port is used instead of the port name. For details, see Section 10.9.4. 5. On the first board, run the following command: ./client send <destination IP> <port> <time in seconds> 6. On the second board, run the following command: ./client wait <destination IP> <port> <time in seconds> Where,

<port>: Any TCP port number
client send <destination IP>: IP address of the neighbor
client wait <destination IP>: Destination IP address of the client interface Take two boards i.MX95_1 and i.MX95_2 as an example. Update the arp entries in the config/arp.conf file: Update the route entries in the config/route.conf file: Run the client application: Note: The application can run on only 1 core.

10.9.3 Webserver

Epserver is the server application. ewget reads the file we write at the server side. It is similar to wget. 1. Rename the sample files sample_route.conf and sample_arp.conf under /usr/bin/mtcp to route.conf and arp.conf respectively. 3. Update the route and arp entries according to the IP addresses and MAC addresses of the interfaces. Note: The port MAC address and IP address (if not given in the configuration file) are shown on the application initialization. Therefore, execute the application, get the IP addresses and MAC addresses, fill the route and arp configuration, and re-run the application. 4. Update epserver.conf and epwget.conf with the required details and correct port names to be used for traffic. The port names must be separated by commas (,). Note: For i.MX 95, the PCI address format, for example, 0000.00.10.0, for the port is used instead of the port name. For details, see Section 10.9.4. 5. Create a random txt file (for example, a.txt) on the server board in the /home/www directory. Create a directory www if it does not exist. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual 6. On the first board, run the following command: ./epserver -p /home/www -f epserver.conf -N 8 7. On the second board, run the following command: ./epwget <Server IP/file name> <number of requests> -N 1 -c 8000 -f epwget.conf -o <file name> Where,

-p is the path of the server home directory where all the files are present.
-f is the configuration file name.
-N is the number of cores.
-c is the number of concurrent connections.
-o (optional) is the output file in which the content of a.txt receives. Note: epwget can work on only 1 core.

10.9.4 MTCP Configuration

The following is the description for the Port, eal_args, and stat_print parameters:

Port: List of the port names to be used for traffic. Port names must be separated by commas (,). Note: For i.MX 95, the PCI address format, for example, 0000.00.10.0, for the port is used instead of the port name. – Example for multiple-port configuration: To use ENETC-1G and ENETC-10G ports, the port configuration is like: port = 0002:00:02.0,0002:00:12.0 – Example for port configuration with IP addresses: Note: – The IP value must be immediate after the port name and (@) separated. – The port configuration parameter accepts user's given IP address for each port. If the IP address is not given for the port, the MTCP stack generates random IP addresses.
eal_args: List of DPDK EAL library configuration. See EAL for the detailed list of supported parameters. eal_args = --log-level=8 -b The parameters must be separated by a space character. Note: Do not use eal_args for core-mask. num_cores can be used for the number of cores.
stat_print: List of the port names to be used for statistics. Port names must be separated by space characters. – Example to enable statistics for a single DPDK port: To use only ENETC-1G, stat_print configuration is like: stat_print = 0002:00:02.0 – Example to enable statistics for multiple DPDK ports: To use ENETC-1G and ENETC-10G ports, stat_print configuration is like: stat_print = 0002:00:02.0, 0002:00:12.0 RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

configuration files client.conf, epserver.conf, and epwget.conf.

10.10 XDP

Figure 49. NAT Flow Setup and Testing Guide

10.10.1 Hardware Requirements

Device: i.MX 95 board
Ethernet interfaces: 2 (eth0, eth1)
Spirent ports: 2

10.10.2 Network Setup

Spirent Port1 1. Connection: Connect Sprint Port 1 to eth0 on the i.MX 95 board. 2. Configure the connected device: – IPv4 Address: 1.1.1.2 – IPv4 Gateway: 1.1.1.1
Spirent Port2 1. Connection: Connect Sprint Port 2 to eth1 on the i.MX 95 board. 2. Configure the connected device: – IPv4 Address: 4.4.4.1 – IPv4 Gateway: 4.4.4.4 10.10.3 i.MX 95 Board Configuration 1. Assign the IP addresses to Ethernet interfaces: ifconfig eth0 1.1.1.1 up ifconfig eth1 4.4.4.4 up RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual 2. Add a static route: 3. Enable IP forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward

10.10.4 Verification

Verify the network connectivity: ping 1.1.1.2 ping 4.4.4.1

10.10.5 NAT Flow Rule Setup

Edit the input.txt file available at /opt/xdp/, and add the following NAT flow rule: nat_saddr=4.4.4.2 nat_daddr=8.8.8.8 nat_sport=1036 nat_dport=1024 mtu=1500 saddr=1.1.1.2 daddr=8.8.8.8 sport=1024 dport=1024 protocol=17 interface=eth1

10.10.6 Loading XDP

Load the XDP program on both eth0 and eth1. $ cd /opt/xdp/ $ xdp_fp -D eth0 eth1 Note: xdp_fp, xdp_fp_kern.o, and input.txt must be present in the same directory. Use xdp_fp -h for help.

10.10.7 Traffic Generation and Packet Capture

Capture the packets at Sprint Port 2. The following is the expected traffic pattern in Wireshark: Time Source Destination Protocol Length Info

1024 Len=82

NXP Semiconductors RM00293 i.MX Linux Reference Manual

10.11 Troubleshooting

If DPDK example applications are not found in rootfs, ensure you are using the correct rootfs (rootfs.wic.zst), which integrates the DPDK.
If applications are not initialized properly, ensure HugePages are added as mentioned in the sections above.
If Ethernet port is not found, ensure that you are using the correct DTB.

11 Unit Tests

11.1 System

11.1.1 OProfile

11.1.1.1 Test Name

autorun-oprofile.sh

11.1.1.1.1 Location

/unit_tests/OProfile/

11.1.1.1.2 Functionality

11.1.1.1.3 Configuration

11.1.1.1.4 Use Case and Expected Output

./autorun-oprofile.sh

11.1.2 Owire

11.1.2.1 Test Name

autorun-owire.sh

11.1.2.1.1 Location

NXP Semiconductors RM00293 i.MX Linux Reference Manual

11.1.2.1.2 Functionality

Test EEPROM functionality.

11.1.2.1.3 Configuration

11.1.2.1.4 Use Case and Expected Output

./autorun-owire.sh

11.1.3 Power Management

11.1.3.1 Test Name

/unit_tests/Power_Management/suspend_random_auto.sh
/unit_tests/Power_Management/suspend_quick_auto.sh

11.1.3.1.1 Location

/unit_tests/Power_Management/

11.1.3.1.2 Functionality

Enables low power mode on and wakes up the different cores on all i.MX boards..

11.1.3.1.3 Configuration

11.1.3.1.4 Use Case and Expected Output

$ /unit_tests/Power_Management/suspend_random_auto.sh or $ /unit_tests/Power_Management/suspend_quick_auto.sh Expected output on i.MX 7D Sabre SD board: # /unit_tests/Power_Management/suspend_random_auto.sh rtcwakeup.out: wakeup from "mem" using rtc0 at Wed Feb 22 22:55:29 2017 PM: Syncing filesystems ... done. Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 632.862 msecs PM: suspend devices took 0.640 seconds PM: late suspend of devices complete after 1.258 msecs PM: noirq suspend of devices complete after 1.198 msecs Disabling non-boot CPUs ... CPU1: shutdown RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Turn off Mega/Fast mix in DSM Enabling non-boot CPUs ... CPU1 is up PM: noirq resume of devices complete after 0.832 msecs imx-sdma 30bd0000.sdma: loaded firmware 4.2 PM: early resume of devices complete after 0.930 msecs PM: resume of devices complete after 483.310 msecs PM: resume devices took 0.480 seconds Restarting tasks ... done. suspend 0 times wakeup 7 seconds, sleep 16 seconds rtcwakeup.out: wakeup from "mem" using rtc0 at Wed Feb 22 22:55:42 2017 PM: Syncing filesystems ... done. Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 630.328 msecs PM: suspend devices took 0.640 seconds PM: late suspend of devices complete after 1.252 msecs PM: noirq suspend of devices complete after 1.203 msecs Disabling non-boot CPUs ... CPU1: shutdown Turn off Mega/Fast mix in DSM Enabling non-boot CPUs ... CPU1 is up PM: noirq resume of devices complete after 0.777 msecs imx-sdma 30bd0000.sdma: loaded firmware 4.2 PM: early resume of devices complete after 0.873 msecs PM: resume of devices complete after 483.406 msecs PM: resume devices took 0.480 seconds Restarting tasks ... done. suspend 1 times wakeup 11 seconds, sleep 20 seconds rtcwakeup.out: wakeup from "mem" using rtc0 at Wed Feb 22 22:56:10 2017 37PM: Syncing filesystems ... done. Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 651.761 msecs PM: suspend devices took 0.660 seconds PM: late suspend of devices complete after 1.245 msecs PM: noirq suspend of devices complete after 1.193 msecs Disabling non-boot CPUs ... CPU1: shutdown Turn off Mega/Fast mix in DSM Enabling non-boot CPUs ... CPU1 is up PM: noirq resume of devices complete after 0.728 msecs imx-sdma 30bd0000.sdma: loaded firmware 4.2 PM: early resume of devices complete after 0.859 msecs PM: resume of devices complete after 483.441 msecs PM: resume devices took 0.480 seconds Restarting tasks ... done. suspend 2 times RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual wakeup 3 seconds, sleep 12 seconds rtcwakeup.out: wakeup from "mem" using rtc0 at Wed Feb 22 22:56:34 2017 PM: Syncing filesystems ... done. Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 641.321 msecs PM: suspend devices took 0.650 seconds PM: late suspend of devices complete after 1.258 msecs PM: noirq suspend of devices complete after 1.195 msecs Disabling non-boot CPUs ... CPU1: shutdown Turn off Mega/Fast mix in DSM Enabling non-boot CPUs ... CPU1 is up PM: noirq resume of devices complete after 0.730 msecs imx-sdma 30bd0000.sdma: loaded firmware 4.2 PM: early resume of devices complete after 0.857 msecs PM: resume of devices complete after 483.451 msecs PM: resume devices took 0.480 seconds Restarting tasks ... done. suspend 3 times wakeup 9 seconds, sleep 8 seconds rtcwakeup.out: wakeup from "mem" using rtc0 at Wed Feb 22 22:56:56 2017 PM: Syncing filesystems ... done. 38Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 641.492 msecs PM: suspend devices took 0.650 seconds PM: late suspend of devices complete after 1.255 msecs PM: noirq suspend of devices complete after 1.201 msecs Disabling non-boot CPUs ... CPU1: shutdown Turn off Mega/Fast mix in DSM Enabling non-boot CPUs ... CPU1 is up PM: noirq resume of devices complete after 0.731 msecs imx-sdma 30bd0000.sdma: loaded firmware 4.2 PM: early resume of devices complete after 0.861 msecs PM: resume of devices complete after 483.476 msecs PM: resume devices took 0.480 seconds Restarting tasks ... done. # /unit_tests/Power_Management/suspend_quick_auto.sh rtcwakeup.out: wakeup from "mem" using rtc0 at Wed Feb 22 23:01:16 2017 PM: Syncing filesystems ... done. Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 632.891 msecs PM: suspend devices took 0.640 seconds PM: late suspend of devices complete after 1.254 msecs PM: noirq suspend of devices complete after 1.200 msecs Disabling non-boot CPUs ... RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual CPU1: shutdown Turn off Mega/Fast mix in DSM Enabling non-boot CPUs ... CPU1 is up PM: noirq resume of devices complete after 0.734 msecs imx-sdma 30bd0000.sdma: loaded firmware 4.2 PM: early resume of devices complete after 0.862 msecs PM: resume of devices complete after 483.417 msecs PM: resume devices took 0.480 seconds Restarting tasks ... done. suspend 1 times rtcwakeup.out: wakeup from "mem" using rtc0 at Wed Feb 22 23:01:19 2017 PM: Syncing filesystems ... done. Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 631.833 msecs 39PM: suspend devices took 0.640 seconds PM: late suspend of devices complete after 1.253 msecs PM: noirq suspend of devices complete after 1.242 msecs Disabling non-boot CPUs ... CPU1: shutdown Turn off Mega/Fast mix in DSM Enabling non-boot CPUs ... CPU1 is up PM: noirq resume of devices complete after 0.729 msecs imx-sdma 30bd0000.sdma: loaded firmware 4.2 PM: early resume of devices complete after 0.862 msecs PM: resume of devices complete after 483.416 msecs PM: resume devices took 0.480 seconds Restarting tasks ... done. suspend 2 times rtcwakeup.out: wakeup from "mem" using rtc0 at Wed Feb 22 23:01:22 2017 PM: Syncing filesystems ... done. Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 633.624 msecs PM: suspend devices took 0.640 seconds PM: late suspend of devices complete after 1.252 msecs PM: noirq suspend of devices complete after 1.204 msecs Disabling non-boot CPUs ... CPU1: shutdown Turn off Mega/Fast mix in DSM Enabling non-boot CPUs ... CPU1 is up PM: noirq resume of devices complete after 0.733 msecs imx-sdma 30bd0000.sdma: loaded firmware 4.2 PM: early resume of devices complete after 0.853 msecs PM: resume of devices complete after 483.450 msecs PM: resume devices took 0.480 seconds Restarting tasks ... done. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

11.1.4 Remote Processor Messaging

11.1.4.1 Test Name

mxc_mcc_tty_test.out

11.1.4.1.1 Location

/unit_tests/Remote_Processor_Messaging

11.1.4.1.2 Functionality

Test communication between Cortex-A and Cortex-M cores.

11.1.4.1.3 Configuration

To run the i.MX RPMsg test program, perform the following operations: Make sure that the proper Cortex-M4 processor RTOS and Linux images are used. The following are examples for the i.MX7Dual board:

rpmsg_pingpong_sdk_7dsdb.bin → ping-pong test used on the i.MX7Dual SDB board
rpmsg_str_echo_sdk_7dsdb.bin → tty string echo test used on the i.MX7Dual SDB board
rpmsg_pingpong_sdk_7dval.bin → ping-pong test used on the i.MX7Dual 12x12 LPDDR3 ARM2 board
rpmsg_str_echo_sdk_7dval.bin → tty string echo test used on the i.MX7Dual 12x12 LPDDR3 ARM2 board Load the Cortex-M4 processor RTOS image, and kick it off in U-Boot. Load the Cortex-M4 processor RTOS image by the TFTP server or by the bootable SD card in U-Boot.
Load the Cortex-M4 processor RTOS image by the TFTP server: – Boot into U-Boot and stop. – Use the following command to TFTP the responding Cortex-M4 processor RTOS image and boot it. => dhcp 0x7f8000 10.192.242.53:rpmsg_pingpong_sdk_7dval.bin; bootaux 0x7f8000
Load the Cortex-M4 processor RTOS image by the SD card: – Create a bootable SD card by using MFGtools. – Copy the Cortex-M4 processor RTOS files to the first partition formatted with the VFAT file system.
Change the default Cortex-M4 processor RTOS name of the U-Boot. => setenv m4image '<The name of the M4/RTOS image>';save Set up a bootargs used by the Cortex-M4 processor. => setenv run_m4_tcm 'if run loadm4image; then cp.b ${loadaddr} 0x7f8000 0x8000; => bootaux 0x7f8000; fi'; save Modify the original bootcmd by adding run run_m4_tcm. => setenv bootcmd "run run_m4_tcm; <original contents of the bootcmd>"; save RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Note: NOTE “uart_from_osc” is required by i.MX 6SoloX when the Cortex-M4 processor RTOS image is running. Therefore, the mmcargs of U-Boot should be modified on i.MX 6SoloX. => setenv mmcargs 'setenv bootargs console=${console},${baudrate} root= ${mmcroot}, uart_from_osc';save Run the RPMsg test program. * Make sure that imx_rpmsg_pingpong.ko and imx_rpmsg_tty.ko are built out. * Use insmod imx_rpmsg_pingpong.ko or insmod imx_rpmsg_tty.ko to run the test program. Note: NOTE Do not run different test programs at the same time.

11.1.4.1.4 Use Case and Expected Output

Run the following command and ensure that the RPMsg TTY receiving program is running at the backend when starting RPMsg TTY tests. # ./mxc_mcc_tty_test.out /dev/ttyRPMSG30 115200 R 100 1000 & Expected output: mxc_mcc_tty_test.out: $ insmod imx_rpmsg_tty.ko $ imx_rpmsg_tty rpmsg0: new channel: 0x400 -> 0x1! $ Install rpmsg tty driver! $ echo deadbeaf > /dev/ttyRPMSG30 $ imx_rpmsg_tty rpmsg0: msg(<- src 0x1) deadbeaf len 8

11.1.5 Watchdog (WDOG)

11.1.5.1 Test Name

autorun-wdog.sh
wdt_driver_test.out

11.1.5.1.1 Location

/unit_tests/Watchdog/

11.1.5.1.2 Functionality

Tests the Watchdog Timer module which protects against system failures by providing an escape from unexpected hang, infinite loop situations or programming errors.

11.1.5.1.3 Configuration

11.1.5.1.4 Use Case and Expected Output

NXP Semiconductors RM00293 i.MX Linux Reference Manual Expected output This should generate a reset after 3 seconds (a 1 second time-out and a 2 second sleep). or ./wdt_driver_test.out 2 1 0 The system should keep running without being reset. This test requires the kernel to be executed with the "jtag=on" on some platforms. Press "Ctrl+C" to terminate this test program.

11.2 Storage

11.2.1 Media Local Bus

11.2.1.1 Test Name

mxc_mlb150_test

11.2.1.1.1 Location

/unit_tests/Media_Local_Bus/

11.2.1.1.2 Functionality

MediaLB is an on-PCB or inter-chip communication bus specifically designed to standardize a common hardware interface and software API library.

11.2.1.1.3 Configuration

In menu configuration enable the following module: Device Drivers > MXC support drivers > MXC Media Local Bus Driver > MLB support Test only supported on i.MX6SX, i.MX6QP, i.MX6Q, i.MX6DL

11.2.1.1.4 Use Case and Expected Output

./mxc_mlb150_test [-v] [-h] [-b] [-f fps] [-t casetype] [-q sync quadlets] [-p isoc packet length]\\n" -v verbose -h help -b block io test -f FPS, 256/512/1024/2048/3072/4096/6144 -t CASE, CASE can be 'sync', 'ctrl', 'async', 'isoc' -q SYNC QUADLETS, quadlets per frame in sync mode, can be 1, 2, or 3 -p Packet length, package length in isoc mode, can be 188 or 196 RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

11.2.2 MMC/SD/SDIO Host

11.2.2.1 Test Name

autorun-mmc-blockrw.sh
autorun-mmc-fdisk.sh
autorun-mmc-fs.sh
autorun-mmc-mkfs.sh
autorun-mmc.sh

11.2.2.1.1 Location

/unit_tests/MMC_SD_SDIO/

11.2.2.1.2 Functionality

The conjunction of MMC SD SDIO tests exercise the following instructions:

MMC/SD read write test.
MMC/SD block read write test.
MMC/SD fdisk test.
MMC/SD file system test.
MMC/SD mkfs test.

11.2.2.1.3 Configuration

11.2.2.1.4 Use Case and Expected Output

All test return "Pass" if successful. ./autorun-mmc-blockrw.sh ./autorun-mmc-fdisk.sh ./autorun-mmc-fs.sh ./autorun-mmc-mkfs.sh ./autorun-mmc.sh

11.2.3 MMDC

11.2.3.1 Test Name

mmdc2

11.2.3.1.1 Location

/unit_tests/MMDC/

11.2.3.1.2 Functionality

NXP Semiconductors RM00293 i.MX Linux Reference Manual

11.2.3.1.3 Configuration

The following parameters allow to customize the mmcd2 test:

export MMDC_SLEEPTIME - define profiling duration (500ms by default)
export MMDC_LOOPCOUNT - define profiling times (1 by default, -1 means infinite loop)
export MMDC_CUST_MADPCR1 - customize madpcr1

11.2.3.1.4 Use Case and Expected Output

The expected output will print the profiling results ./mmdc2 [ARM:DSP1:DSP2:GPU2D:GPU2D1:GPU2D2:GPU3D:GPU3D2:GPUVG:VPU:M4:PXP:USB:SUM]

11.2.4 SATA

11.2.4.1 Test Name

autorun-ata.sh

11.2.4.1.1 Location

/unit_tests/SATA/

11.2.4.1.2 Functionality

This test writes data to the SATA drive connected to the SATA connector on the i.MX board. The data is then read back and compared to what was written.

11.2.4.1.3 Configuration

Module required: pata_fsl.ko. Hardware required: SATA drive. Only i.MX 6 Quad and QuadPlus have SATA support.

11.2.4.1.4 Use Case and Expected Output

./autorun-ata.sh Expected output Test should return "HDD test passes" if successful.

11.3 Connectivity

11.3.1 Enhanced Configurable Serial Peripheral Interface (ECSPI)

11.3.1.1 Test Name

mxc_spi_test1.out

11.3.1.1.1 Location

NXP Semiconductors RM00293 i.MX Linux Reference Manual

11.3.1.1.2 Functionality

This test sends bytes of the last parameter to a specific SPI device. The maximum transfer bytes are 4096 bytes for bits per word less than 8(including 8), 2048 bytes for bits per word between 9 and 16, 1024 bytes for bits per word larger than 17(including 17). SPI writes data received data from the user into Tx FIFO and waits for the data in the Rx FIFO. Once the data is ready in the Rx FIFO, it is read and sent to user.

11.3.1.1.3 Configuration

For the i.MX 6QuadPlus/Quad/Dual auto boards this requires the ecspi device tree. This feature is disabled with default device tree.

11.3.1.1.4 Use Case and Expected Output

./mxc_spi_test1.out -D 0 -s 1000000 -b 8 E6E0 ./mxc_spi_test1.out -D 1 -s 1000000 -b 8 -H -O -C E6E0E6E00001E6E00000 Usage: ./mxc_spi_test1.out [-D spi_no] [-s speed] [-b bits_per_word] [-H] [-O] [-C] $lt;value> <spi_no> - CSPI Module number in [0, 1, 2] <speed> - Max transfer speed <bits_per_word> - bits per word -H - Phase 1 operation of clock -O - Active low polarity of clock -C - Active high for chip select <value> - Actual values to be sent

11.3.2 ETM

11.3.2.1 Test Name

11.3.2.1.1 Location

/unit_tests/ETM/

11.3.2.1.2 Functionality

Embedded Trace Macrocell, The ETM is an optional debug component that enables reconstruction of program execution. The ETM is designed as a high-speed, low-power debug tool that only supports instruction trace. This ensures that area is minimized, and that gate count is reduced.

11.3.2.1.3 Configuration

11.3.2.1.4 Use Case and Expected Output

NXP Semiconductors RM00293 i.MX Linux Reference Manual --etm-3.4-alt-branch ETM v3.4 trace data with alternative branch encoding --pft-1.1 PFT v1.1 trace data --cycle-accurate Cycle-accurate tracing was enabled (Default 1) --contextid-bytes Number of Context ID bytes (Default 4) --formatter Enable Formatter Unpacking --sourceid-match Enable Source ID from formatter. Also enables formatter --print-long-waits Highlight long waits --print-input Print input data --print-config Print configuration data --help Print usage information

11.3.3 Inter-IC (I2C)

11.3.3.1 Test Name

mxc_i2c_slave_test.out

11.3.3.1.1 Location

/unit_tests/I2C/

11.3.3.1.2 Functionality

11.3.3.1.3 Configuration

11.3.3.1.4 Use Case and Expected Output

11.3.4 Keyboard

11.3.4.1 Test Name

autorun-keypad.sh
mxc_keyb_test.sh

11.3.4.1.1 Location

/unit_tests/Keyboard/

11.3.4.1.2 Functionality

Tests keyboard input via USB.

11.3.4.1.3 Configuration

Connect Keyboard to USB OTG port.

11.3.4.1.4 Use Case and Expected Output

NXP Semiconductors RM00293 i.MX Linux Reference Manual Outputs: Print "PASS" status ./mxc_keyb_test.sh Output: An event will occur when a key is pressed

11.3.5 Low Power Universal Asynchronous Receiver/Transmitter (LPUART)

11.3.5.1 Test Name

autorun-mxc_uart.sh
mxc_uart_stress_test.out
mxc_uart_test.out
mxc_uart_xmit_test.out

11.3.5.1.1 Location

/unit_tests/UART/

11.3.5.1.2 Functionality

These tests excercise the low-level UART driver whihc is responsible for supplying information such as the UART port information and a set of control functions to the core UART driver.

11.3.5.1.3 Configuration

11.3.5.1.4 Use Case and Expected Output

./autorun-mxc_uart.sh ./mxc_uart_stress_test.out /dev/ttymxc# ./mxc_uart_test.out /dev/ttymxc# ./mxc_uart_xmit_test.out /dev/ttymxc#

11.3.6 USB

11.3.6.1 Test Name

autorun-usb-gadget.sh
autorun-usb-host.sh

11.3.6.1.1 Location

/unit_tests/USB/

11.3.6.1.2 Functionality

This tests excerise the universal serial bus (USB) driver which implements a standard Linux driver interface to the CHIPIDEA USB-HS OTG controller. The USB provides a universal link that can be used across a wide RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual range of PC-to-peripheral interconnects. It supports plug-and-play, port expansion, and any new USB peripheral that uses the same type of port.

11.3.6.1.3 Configuration

Modules required:

/lib/modules/$(kernel_version)/kernel/drivers/usb/gadget/g_ether.ko
/lib/modules/$(kernel_version)/kernel/drivers/usb/gadget/arcotg_udc.ko
/lib/modules/$(kernel_version)/kernel/drivers/usb/host/ehci-hcd.ko

11.3.6.1.4 Use Case and Expected Output

./autorun-usb-gadget.sh or ./autorun-usb-host.sh

11.4 Graphics

11.4.1 Graphics Processing Unit (GPU)

11.4.1.1 Test Name

gpu.sh
gpuinfo.sh

11.4.1.1.1 Location

/unit_tests/GPU

11.4.1.1.2 Functionality

tutorial3: test OpenGL ES 1.1 basic function
tutorial4_es20: test OpenGL ES 2.0 basic function
tiger: test OpenVG 1.1 basic function
tvui: test Raster 2D and LibVivanteDK API

11.4.1.1.3 Configuration

For gpu.sh and gpuinfo.sh to work add the following line to the target board defconfig file:

CONFIG_MXC_GPU_VIV=y Hardware required: LVDS Display Panel and i.MX SoC with a GPU

11.4.1.1.4 Use Case and Expected Output

NXP Semiconductors RM00293 i.MX Linux Reference Manual

tutorial3: a cube with texture rotating in the middle of the screen
tutorial4_es20: draws a glass sphere inside a big sphere (enviroment mapping). The glass sphere shows both reflection and refraction effects.
tiger: a tiger spinning on the screen.
tvui: draws several movie clips and a tv control panel. Example output is: # ./gpu.sh ---- Running < gpu.sh > test ---- /unit_tests/GPU /unit_tests/GPU Rendered 100 frames in 624 milliseconds: 160.26 fps id=43, a,b,g,r=0,8,8,8, d,s=16,0, AA=0,openvgbit=71 frames:100 -- fps:58.997051 press ESC to escape... ./gpu.sh: line 28: cd: /opt/viv_samples/hal/: No such file or directory /unit_tests/GPU ---- Test < gpu.sh > ended ---- ./gpuinfo.sh - Information about GPU is printed on console. # ./gpuinfo.sh ---- Running < gpuinfo.sh > test ---- GPU Info gpu : 0 model : 2000 revision : 5108 product : 0 eco : 0 gpu : 8 model : 320 revision : 5007 product : 0 eco : 0 gpu : 9 model : 355 revision : 1215 product : 0 eco : 0 VIDEO MEMORY: gcvPOOL_SYSTEM: Free : 134217728 B Used : 0 B Total : 134217728 B gcvPOOL_CONTIGUOUS: Used : 0 B gcvPOOL_VIRTUAL: Used : 0 B NON PAGED MEMORY: Used : 0 B Paged memory Info lowMem: 0 bytes highMem: 0 bytes CMA memory info RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual cma: 138485760 bytes ---- Test < gpuinfo.sh > ended ----

11.5 Video

11.5.1 Display

11.5.1.1 Test Name

autorun-fb.sh
mxc_tve_test.sh
mxc_fb_test.out
mxc_epdc_fb_test.out
mxc_epdc_v2_fb_test.out
mxc_spdc_fb_test.out
mxc_fb_vsync_test.out

11.5.1.1.1 Location

/unit_tests/Display/

11.5.1.1.2 Functionality

The tests under the display directory test some of the display options that are available with the i.MX family of boards. Some of the devices that can be tested include LVDS, HDMI and EPDC panels. Specifically the 'mxc_fb_test.out' tests the following features:

Basic fb operation
Set background/foreground to 16 bpp fb
Global alpha blending
Color key test
Framebuffer Panning
Gamma test Aditionally, the EPDC tests 'mxc_epdc_fb_test.out' and 'mxc_epdc_v2_fb_test.out' test the following features:
Basic Updates
Rotation Updates
Grayscale Framebuffer Updates
Auto-waveform Selection Updates
Panning Updates
Overlay Updates
Auto-Updates
Animation Mode Updates
Fast Updates
Partial to Full Update Transitions
Test Pixel Shifting Effect

NXP Semiconductors RM00293 i.MX Linux Reference Manual

Collision Test Mode
Stress Test
RGB565, Y8 framebuffer format
0, 90, 180, 270 degree framebuffer rotation
Framebuffer panning
Use of the alternate framebuffer
Auto-waveform mode selection
Automatic update mode
The force-monochrome update feature and animation mode updates
Support for using a grayscale colormap
Snapshot, Queue, and Queue and Merge update schemes
The EPDC Collision Test mode

11.5.1.1.3 Configuration

In order to run some tests, changes to the defconfig file for the target board are required. These changes will add functionality in which the following tests depend upon. For autorun-fb.sh, 'mxc_fb_test.out' and 'mxc_fb_vsync_test.out' add the following to the target board defconfig file: CONFIG_FB=y CONFIG_FB_MXC=y CONFIG_FB_MXC_EDID=y CONFIG_FB_MXC_SYNC_PANEL=y CONFIG_FB_MXC_LDB=y CONFIG_FB_MXC_HDMI=y For 'mxc_epdc_fb_test.out' and 'mxc_epdc_v2_fb_test.out' add the following to the target board defconfig file: CONFIG_FB=y CONFIG_FB_MXC=y CONFIG_FB_MXC_EINK_PANEL=y CONFIG_MFD_MAX17135=y CONFIG_REGULATOR_MAX17135=y CONFIG_MXC_PXP=y CONFIG_DMA_ENGINE=y

11.5.1.1.4 Use Case and Expected Output

# ./autorun-fb.sh Expected output is: ---- Running < autorun-fb.sh > test ---- Checking for devnode: /dev/fb0 autorun-fb.sh: PASS devnode found: /dev/fb0 FB Blank test Screen should be off FB Color test RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Setting FB to 16-bpp Setting FB to 24-bpp Setting FB to 32-bpp FB panning test autorun-fb.sh: Exiting PASS Exiting PASS. # ./mxc_tve_test.sh Expected output is: ---- Running < mxc_tve_test.sh > test ---- Setting TV to NTSC mode /unit_tests/Display/mxc_tve_test.sh: line 9: echo: write error: Invalid argument /unit_tests/Display/mxc_tve_test.sh: line 11: /unit_tests/mxc_v4l2_output.out: No such file or directory Blank the display Unblank the display Setting TV to PAL mode /unit_tests/Display/mxc_tve_test.sh: line 22: echo: write error: Invalid argument /unit_tests/Display/mxc_tve_test.sh: line 23: /unit_tests/mxc_v4l2_output.out: No such file or directory Blank the display Unblank the display # ./mxc_fb_test.out Expected Output is shown below. The test should pass without any failure messages, and the display on panel should be correct. For each test, a sequence of updates should be reflected on the screen. For almost all tests, the text printed out in the debug console describes the image that should be observed on the screen. For i.MX6Quad fb0 and fb1 are used for tests, fb0 is background framebuffer, and fb1 is foreground overlay framebuffer. Opened fb: /dev/fb0 (DISP4 BG - DI1) DISP4 BG - DI1: screen info: 1024x768 (virtual: 1024x1536) @ 32-bpp Opened fb: /dev/fb1 (DISP4 FG) DISP4 FG: screen info: 240x320 (virtual: 240x960) @ 16-bpp @DISP4 BG - DI1: Set colorspace to 16-bpp @DISP4 FG: Set colorspace to 16-bpp Prepared DISP4 BG - DI1 (black) and DISP4 FG (white). Verify the screen and press any key to continue! @DISP4 BG - DI1: Succesfully changed screen to 1024x768 (virtual: 1024x768) @16- bpp @DISP4 FG: Succesfully changed screen to 240x320 (virtual: 240x320) @16-bpp Testing global alpha blending... Fill the FG in black (screen is 240x320 @ 16-bpp) Fill the BG in white (screen is 1024x768 @ 16-bpp) Alpha is 0, FG is opaque Alpha is 255, BG is opaque RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Color key enabled Color key disabled Global alpha disabled Pan test start. @DISP4 FG: Set the colorspace to 16-bpp Pan test done. @DISP4 BG - DI1: Set colorspace to 16-bpp Pan test start. @DISP4 BG - DI1: Set the colorspace to 16-bpp Pan test done. Gamma test start. Gamma 0.800000 Gamma 1.000000 Gamma 1.500000 Gamma 2.200000 Gamma 2.400000 Gamma test end. Test bpp start @DISP4 BG - DI1: Set colorspace to 32-bpp @DISP4 BG - DI1: Fill the screen in red @DISP4 BG - DI1: Set colorspace to 24-bpp @DISP4 BG - DI1: Fill the screen in blue @DISP4 BG - DI1: Set colorspace to 16-bpp @DISP4 BG - DI1: Fill the screen in green Test bpp end # ./mxc_epdc_fb_test.out [-h] [-a] [-n] EPDC framebuffer driver test program. Usage: mxc_epdc_fb_test [-h] [-a] [-p delay] [-u s/q/m] [-n <expression>] -h Print this message -a Enabled animation waveforms for fast updates (tests 8-9) -p Provide a power down delay (in ms) for the EPDC driver 0 - Immediate (default) -1 - Never <ms> - After <ms> milliseconds -u Select an update scheme s - Snapshot update scheme q - Queue update scheme m - Queue and merge update scheme (default) -n Execute the tests specified in expression Expression is a set of comma-separated numeric ranges If not specified, all tests except Stress are run Example: ./mxc_epdc_fb_test.out -n 1-3,5,7 EPDC tests: 1 - Basic Updates 2 - Rotation Updates 3 - Grayscale Framebuffer Updates 4 - Auto-waveform Selection Updates 5 - Panning Updates 6 - Overlay Updates 7 - Auto-Updates 8 - Animation Mode Updates 9 - Fast Updates 10 - Partial to Full Update Transitions 11 - Test Pixel Shifting Effect 12 - Colormap Updates 13 - Collision Test Mode RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual 14 - Stress Test 15 - Dithering Y8->Y1 Test 16 - Dithering Y8->Y4 Test 17 - Hardware Dithering Test 18 - Advanced Algorithm Test The full set of tests should pass without any failure messages. For each test, a sequence of updates should be reflected on the screen. For almost all tests, the text printed out in the debug console describes the image that should be observed on the screen. mxc_epdc_v2_fb_test.out: The full set of tests should pass without any failure messages. For each test, a sequence of updates should be reflected on the screen. For almost all tests, the text printed out in the debug console describes the image that should be observed on the screen. # ./mxc_spdc_fb_test.out ---- Running < ./mxc_spdc_fb_test.out > test ---- Unable to open /dev/fb5 # ./mxc_fb_vsync_test.out Usage: /unit_tests/Display# ./mxc_fb_vsync_test.out <fb #> <count> <fb #> the framebuffer number <count> the frames to be rendered Example: /unit_tests/Display# echo 0 > /sys/class/graphics/fb0/blank /unit_tests/Display# ./mxc_fb_vsync_test.out 0 100 Expected output is the following when using 100 for the < count > argument total time for 100 frames = 1655674 us = 60 fps

11.5.2 High-Definition Multimedia Interface (HDMI) and Display Port (DP) Overview

11.5.2.1 Test Name

mxc_cec_test.out

11.5.2.1.1 Location

/unit_tests/HDMI/

11.5.2.1.2 Functionality

Verify HDMI CEC function and send poweroff command to HDMI sink.

11.5.2.1.3 Configuration

For mxc_cec_test.out to work add the following line to the target board defconfig file: CONFIG_MXC_HDMI_CEC=y The hardware should support HDMI and TV should support HDMI CEC RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

11.5.2.1.4 Use Case and Expected Output

./mxc_cec_test.out

11.5.3 Video Processing Unit (VPU)

11.5.3.1 Test for i.MX 6

autorun-vpu.sh
mxc_vpu_test.out

11.5.3.1.1 Location

/unit_tests/VPU/

11.5.3.1.2 Functionality

The VPU test exercises the following options on the Video Processing Unit (VPU):

Decode one stream and display on the LCD.
Decode a stream and save to a file.
Decode a stream using a config file.
Encode a YUV stream and save to a file.
Encode an image from the camera and decode it to display on the LCD.
Decode multiple streams with different formats simultaneously.
Decode and encode simultaneously.
Output to TV out.
Test VPU with VDI (HW deinterlace via IPU).

11.5.3.1.3 Configuration

This tests require libvpu.so under /usr/lib/ and LCD display. This test requires i.MX 6QuadPlus/Quad/Dual SoC.

11.5.3.1.4 Use Case and Expected Output

./autorun-vpu.sh Decode one stream and display on the LCD. To test MPEG-4 decode and display to screen: ./mxc_vpu_test.out -D "-i /usr/vectors/file.m4v -f 0" To test H.263 decode and display to screen: ./mxc_vpu_test.out -D "-i /usr/vectors/file.263 -f 1" To test H.264 decode and display to screen: ./mxc_vpu_test.out -D "-i /usr/vectors/file.264 -f 2" You can get the mp4 test file from the imx-test.git server. It is located under test/mxc_vpu_test/configs/akiyo.mp4. Decode a stream and save to a file. To test MPEG-4 decode and save to file: ./mxc_vpu_test.out -D "-i /usr/vectors/file.m4v -f 0 -o out.yuv" To test H.263 decode and save to file: ./mxc_vpu_test.out -D "-i /usr/vectors/file.263 -f 1 -o out.yuv" To test H.264 decode and save to file: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual ./mxc_vpu_test.out -D "-i /usr/vectors/file.264 -f 2 -o out.yuv" Decode a stream using a config file. Change options in config file, e.g, config_dec. Input correct input filename, output filename, format, ./mxc_vpu_test.out -C config_dec Encode a YUV stream and save to a file. To test MPEG-4 encode and save to a file: ./mxc_vpu_test.out -E "-i file.yuv -w 240 -h 320 -f 0 -o file.mpeg4" To test H.263 encode and save to a file: ./mxc_vpu_test.out -E "-i file.yuv -w 240 -h 320 -f 1 -o file.263" To test H.264 encode and save to a file: ./mxc_vpu_test.out -E "-i file.yuv -w 240 -h 320 -f 2 -o file.264" Encode an image from the camera and decode it to display on the LCD. To encode an MPEG4 image from the camera and display on the LCD: that ./mxc_vpu_test.out -L "-f 0 -w 1280 -h 720" To encode an H263 image from the camera and display on the LCD: ./mxc_vpu_test.out -L "-f 1 -w 1280 -h 720" To encode an H264 image from the camera and display on the LCD: ./mxc_vpu_test.out -L "-f 2 -w 1280 -h 720" Decode multiple streams with different formats simultaneously. Decoder one H264 and one MPEG4 streams. akiyo.yuv" Decode and encode simultaneously. Encode one MPEG-4 stream and decode one H.264 stream simultaneously. ./mxc_vpu_test.out -E "-w 176 -h 144 -f 0 -o enc.m4v" -D "-i/vectors/file.264 -f Test VPU with TV out. Decoder one stream as normal VPU test. For example, H264 video stream: ./mxc_vpu_test.out -D "-i filename -f 2" Test VPU with VDI (HW deinterlace via IPU). Select one stream with top and bottom fields are interlaced. av_stress2_dsmcc4m_1_C1_V11_A6.mp4_track1.h264 To decode the stream and display on LCD: ./mxc_vpu_test.out -D "-i av_stress2_dsmcc4m_1_C1_V11_A6.mp4_track1.h264 -f2" To decode the stream and display on LCD using high motion stream video De Interlacing algorithm: ./mxc_vpu_test.out -D "-i av_stress2_dsmcc4m_1_C1_V11_A6.mp4_track1.h264 -v h - f2" To decode the stream and display on LCD using low motion stream video De Interlacing algorithm: ./mxc_vpu_test.out -D "-i av_stress2_dsmcc4m_1_C1_V11_A6.mp4_track1.h264 -v l - f2" To decode the stream and display on LCD having input in NV12 pixel format: ./mxc_vpu_test.out -D "-i av_stress2_dsmcc4m_1_C1_V11_A6.mp4_track1.h264 -v 11.5.3.2 Test for i.MX 8M Quad

11.5.3.2.1 Location

/unit_tests/VPU/hantro

11.5.3.2.2 Functionality

The VPU test exercises the following option on the VPU:

NXP Semiconductors RM00293 i.MX Linux Reference Manual

11.5.3.2.3 Use Case and Expected Output

Example for decoding different codecs: /unit_tests/VPU/hantro/g2dec -P -b -ibs -Oout.yuv test.hevc /unit_tests/VPU/hantro/g2dec -P -b -iivf -Oout.yuv test.vp9 /unit_tests/VPU/hantro/hx170dec -P -Oout.yuv test.h264 /unit_tests/VPU/hantro/mx170dec -P -Oout.yuv test.mpeg4 /unit_tests/VPU/hantro/m2x170dec -P -Oout.yuv test.mpeg2 /unit_tests/VPU/hantro/vx170dec -P -Oout.yuv test.vc1 /unit_tests/VPU/hantro/vp8x170dec -P -Oout.yuv test.vp8 /unit_tests/VPU/hantro/vp6dec -P -Oout.yuv test.vp6 /unit_tests/VPU/hantro/rvx170dec -P -Oout.yuv test.rv /unit_tests/VPU/hantro/jx170dec -P -Oout.yuv test.jpg /unit_tests/VPU/hantro/ax170dec -P -Oout.yuv test.avs 11.5.3.3 Test for i.MX 8M Mini

11.5.3.3.1 Location

/unit_tests/VPU/hantro

11.5.3.3.2 Functionality

The VPU test exercises the following option on the VPU:

Decode a stream and save to a file.
Encode a YUV stream and save to a file.

11.5.3.3.3 Use Case and Expected Output

Example for decoder: /unit_tests/VPU/hantro/g2dec -P -b -ibs -Oout.yuv test.hevc /unit_tests/VPU/hantro/g2dec -P -b -iivf -Oout.yuv test.vp9 /unit_tests/VPU/hantro/hx170dec -P -Oout.yuv test.h264 /unit_tests/VPU/hantro/vp8x170dec -P -Oout.yuv test.vp8 Example for encoder: /unit_tests/VPU/hantro/h264_testenc -w176 -h144 -o temp.h264 -i test.yuv /unit_tests/VPU/hantro/vp8_testenc -w176 -h144 -o temp.h264 -i test.yuv

11.5.3.4.1 Location

/unit_tests/V4L2_VPU/

11.5.3.4.2 Functionality

The VPU test exercises the following option on the VPU:

NXP Semiconductors RM00293 i.MX Linux Reference Manual

Encode a YUV stream and save to a file.

11.5.3.4.3 Use Case and Expected Output

Example for decoder, which helps to list the 'ifmt' value for different codecs: /unit_tests/V4L2_VPU/mxc_v4l2_vpu_test.out parser --key 0 --name input.h264 --fmt h264 decoder --key 1 --source 0 convert --key 2 --source 1 --fmt i420 ofile --key 3 --source 2 --name output.yuv Example for encoder (H.264 only): /unit_tests/V4L2_VPU/mxc_v4l2_vpu_test.out ifile --key 0 --name input_1920_1080.yuv --fmt i420 --size 1920 1080 convert --key 1 --source 0 -- fmt nv12 encoder --key 2 --source 1 --size 1920 1080 --gop 60 --fmt h264 --qp 25 --bitrate 5000000 --framerate 30 --profile 0 ofile --key 3 --source 2 --name output.h264 Execute /unit_tests/V4L2_VPU/mxc_v4l2_vpu_test.out help for more details.

11.5.4 JPEG Encoder and Decoder

11.5.4.1 Test Name

encoder_test
decoder_test

11.5.4.1.1 Location

/unit_tests/JPEG

11.5.4.1.2 Functionality

The encoder_test receives a raw file in one of the supported formats as input and produces a JPEG file as output, with the same resolution and pixel format as the input, unless cropping is performed. The application fills the raw file in one V4L2 output buffer, enqueues it into the driver, and expects to dequeue the JPEG image in one capture buffer. The decoder_test receives a JPEG file in one of the supported formats as input and produces a raw file as output, with the same resolution and pixel format as the input. The application fills the jpeg file in one V4L2 output buffer, enqueues it into the driver, and expects to dequeue the raw image in one capture buffer.

11.5.4.1.3 Configuration

No special configuration.

11.5.4.1.4 Use Case and Expected Output

NXP Semiconductors RM00293 i.MX Linux Reference Manual Usage: ./decoder_test.out -d </dev/videoX> -f <FILENAME> -w <width> -h <height> -p <pixel_format> [-n <iterations>] [-x] Supported pixel formats: yuv420: 2-planes, Y and UV-interleaved, same as NV12M yuv420s: 2-planes, Y and UV-interleaved, contiguous, same as NV12 yuv420-12: 2-planes, Y and UV-interleaved, non-contiguous, 12-bit precision yuv420s-12: 2-planes, Y and UV-interleaved, contiguous, 12-bit precision yuv422: packed YUYV yuv422-12: packed YUYV, 12-bit precision rgb24: packed RGB (obsolete) bgr24: packed BGR bgr24-12: packed BGR, 12-bit precision yuv444: packed YUV yuv444-12: packed YUV, 12-bit precision gray: Y8 Single Component gray-12: Y12 Single Component argb: packed ARGB (obsolete) abgr: packed ABGR abgr-12: packed ABGR, 12-bit precision Optional arguments: -x: print a hexdump of the result -n: number of iterations for enqueue/dequeue loop -q: quality factor 1..100, for encoder only -W <crop width> -H <crop height> (optional, supported only for encoder) Supported formats: yuv420: 2-planes, Y and UV-interleaved, same as NV12 yuv422: packed YUYV rgb24: packed RGB yuv444: packed YUV gray: Y8 or Y12 or Single Component argb: packed ARGB The input file has to be a JPEG file that matches the specified width, height, and pixel format. The output is a raw file called "outfile" in the current folder, with the same width, height, and pixel format as the input. ./encoder_test.out Usage: ./encoder_test.out -d </dev/videoX> -f <FILENAME> -w <width> -h <height> -p <pixel_format> [-n <iterations>] [-x] Supported pixel formats: yuv420: 2-planes, Y and UV-interleaved, same as NV12M yuv420s: 2-planes, Y and UV-interleaved, contiguous, same as NV12 yuv420-12: 2-planes, Y and UV-interleaved, non-contiguous, 12-bit precision yuv420s-12: 2-planes, Y and UV-interleaved, contiguous, 12-bit precision yuv422: packed YUYV yuv422-12: packed YUYV, 12-bit precision rgb24: packed RGB (obsolete) bgr24: packed BGR RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual bgr24-12: packed BGR, 12-bit precision yuv444: packed YUV yuv444-12: packed YUV, 12-bit precision gray: Y8 Single Component gray-12: Y12 Single Component argb: packed ARGB (obsolete) abgr: packed ABGR abgr-12: packed ABGR, 12-bit precision Optional arguments: -x: print a hexdump of the result -n: number of iterations for enqueue/dequeue loop -q: quality factor 1..100, for encoder only -W <crop width> -H <crop height> (optional, supported only for encoder) Supported formats: yuv420: 2-planes, Y and UV-interleaved, same as NV12 yuv422: packed YUYV rgb24: packed RGB yuv444: packed YUV gray: Y8 or Y12 or Single Component argb: packed ARGB The input file has to be a raw file that matches the specified width, height, and pixel format. The output is a JPEG file called "outfile.jpeg" in the current folder, with the same width, height, and pixel format as the input, unless cropping is performed.

11.6 Audio

11.6.1 Advanced Linux Sound Architecture (ALSA) System on a Chip (ASoC) Sound

11.6.1.1 Test Name

mxc_tuner_test.out

11.6.1.1.1 Location

/unit_tests/ALSA/

11.6.1.1.2 Functionality

Test audio capabilities using ALSA.

11.6.1.1.3 Configuration

ALSA is supported on all i.MX for test aplay, arecord and speaker-test. To use this tuner test it requires tuner hardware available only on the i.MX 6 auto reference boards RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

11.6.1.1.4 Use Case and Expected Output

11.6.2.1 Test Name

mxc_asrc_test.out

11.6.2.1.1 Location

/unit_tests/ASRC

11.6.2.1.2 Functionality

Converts WAV to different sample rates.

11.6.2.1.3 Configuration

11.6.2.1.4 Use Case and Expected Output

#/unit_tests/ASRC/mxc_asrc_test.out -to 48000 /unit_tests/ASRC/audio8k16S.wav audio48k16S.wav ---- Running < /unit_tests/ASRC/mxc_asrc_test.out > test ---- Pair A requested All tests passed with success More usages for mxc_asrc_test.out can be obtained by the following command: #/unit_tests/ASRC/mxc_asrc_test.out -h ---- Running < /unit_tests/ASRC/mxc_asrc_test.out > test ---- * Test aplication for ASRC * Options : -to <output sample rate> <origin.wav$gt; <converted.wav> <input clock source> <output clock source> input clock source types are: 0 -- INCLK_NONE 1 -- INCLK_ESAI_RX 2 -- INCLK_SSI1_RX 3 -- INCLK_SSI2_RX 4 -- INCLK_SPDIF_RX 5 -- INCLK_MLB_CLK 6 -- INCLK_ESAI_TX 7 -- INCLK_SSI1_TX 8 -- INCLK_SSI2_TX 9 -- INCLK_SPDIF_TX 10 -- INCLK_ASRCK1_CLK default option for output clock source is 0 output clock source types are: 0 -- OUTCLK_NONE 1 -- OUTCLK_ESAI_TX RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual 2 -- OUTCLK_SSI1_TX 3 -- OUTCLK_SSI2_TX 4 -- OUTCLK_SPDIF_TX 5 -- OUTCLK_MLB_CLK 6 -- OUTCLK_ESAI_RX 7 -- OUTCLK_SSI1_RX 8 -- OUTCLK_SSI2_RX 9 -- OUTCLK_SPDIF_RX 10 -- OUTCLK_ASRCK1_CLK default option for output clock source is 10

11.7 Security

11.7.1 Display Content Integrity Checker (DCIC)

11.7.1.1 Test Name

mxc_dcic_test.out

11.7.1.1.1 Location

/unit_tests/DCIC/

11.7.1.1.2 Functionality

The goal of the DCIC is to verify that a safety-critical information sent to a display is not corrupted.

11.7.1.1.3 Configuration

11.7.1.1.4 Use Case and Expected Output

# ./mxc_dcic_test.out -bw 18 -dev 1 Expected output for mxc_dcic_test.out: Opened fb0 open /dev/dcic1 bpp=16, bus_width=18 Config ROI=1 Config ROI=3 Config ROI=5 ROI=0,crcRS=0x0, crcCS=0x0 ROI=1,crcRS=0x6cd6b18d, crcCS=0x6cd6b18d ROI=2,crcRS=0x0, crcCS=0x0 ROI=3,crcRS=0xc9da7ae6, crcCS=0xc9da7ae6 ROI=4,crcRS=0x0, crcCS=0x0 ROI=5,crcRS=0xb5ba1453, crcCS=0xb5ba1453 ROI=6,crcRS=0x0, crcCS=0x0 ROI=7,crcRS=0x0, crcCS=0x0 ROI=8,crcRS=0x0, crcCS=0x0 RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual ROI=9,crcRS=0x0, crcCS=0x0 ROI=10,crcRS=0x0, crcCS=0x0 ROI=11,crcRS=0x0, crcCS=0x0 ROI=12,crcRS=0x0, crcCS=0x0 ROI=13,crcRS=0x0, crcCS=0x0 ROI=14,crcRS=0x0, crcCS=0x0 ROI=15,crcRS=0x0, crcCS=0x0 All ROI CRC check success!

11.7.2 SIM

11.7.2.1 Test Name

mxc_sim_test.out

11.7.2.1.1 Location

/unit_tests/SIM/

11.7.2.1.2 Functionality

Basic testing of SIM card interface.

11.7.2.1.3 Configuration

11.7.2.1.4 Use Case and Expected Output

/unit_tests/mxc_sim_test.out Expected output atr[0]= 0x3b atr[1]= 0x68 atr[2]= 0x0 atr[3]= 0x0 atr[4]= 0x0 atr[5]= 0x73 atr[6]= 0xc8 atr[7]= 0x40 atr[8]= 0x0 atr[9]= 0x0 atr[10]= 0x90 atr[11]= 0x0 rx[0] = 0x6e rx[1] = 0x0 rx[0] = 0x6d rx[1] = 0x0 rx[0] = 0x6e rx[1] = 0x0

11.7.3 SNVS Real Time Clock (SRTC)

11.7.3.1 Test Name

autorun-rtc.sh
rtctest.out
rtcwakeup.out

11.7.3.1.1 Location

NXP Semiconductors RM00293 i.MX Linux Reference Manual

11.7.3.1.2 Functionality

These tests check the Real Time Clock (RTC) module which is used to keep the time and date. It provides a certifiable time to the user and can raise an alarm if tampering with counters is detected.

11.7.3.1.3 Configuration

For autorun-rtc.sh, rtctest.out and rtcwakeup.out to work add the following line to the target board defconfig file: CONFIG_RTC_DRV_SNVS=y

11.7.3.1.4 Use Case and Expected Output

./autorun-rtc.sh or ./rtctest.out $lt;arg> --full run all tests --no-periodic don't run periodic interrupt tests or ./rtcwakeup.out -d rtc0 -m mem -s 10 Expected output autorun-rtc.sh: Exit with PASS results. rtctest.out: The program ends with "Test complete" status. rtcwakeup.out: System is wakeup after 10s. Expected output for i.MX 7D Sabre SD

autorun-rtc.sh autorun-rtc.sh i.MX7D Checking for devnode: /dev/rtc0 autorun-rtc.sh: PASS devnode found: /dev/rtc0 Running test case: ./rtctest.out --no-periodic RTC Driver Test Example. Counting 5 update (1/sec) interrupts from reading /dev/rtc0: 1 2 3 4 5 Again, from using select(2) on /dev/rtc0: 1 2 3 4 5 Current RTC date/time is 21-2-2017, 23:13:07. Alarm time now set to 23:13:12. Typing "cat /proc/interrupts" will show 1 more events on IRQ rtc. autorun-rtc.sh: PASS test case: ./rtctest.out --no-periodic rtc irqs before running unit test: 303 rtc irqs after running unit test: 314 so rtc irqs during test was: checking rtc interrupts PASS autorun-rtc.sh: Exiting PASS

NXP Semiconductors RM00293 i.MX Linux Reference Manual Counting 5 update (1/sec) interrupts from reading /dev/rtc0: 1 2 3 4 5 Again, from using select(2) on /dev/rtc0: 1 2 3 4 5 Current RTC date/time is 21-2-2017, 23:14:48. Alarm time now set to 23:14:53. Periodic IRQ rate was 1Hz. Counting 20 interrupts at: 2Hz: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 4Hz: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 8Hz: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 16Hz: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 32Hz: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 64Hz: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Typing "cat /proc/interrupts" will show 131 more events on IRQ rtc.

rtctest.out --no-periodic /rtctest.out --no-periodic RTC Driver Test Example. Counting 5 update (1/sec) interrupts from reading /dev/rtc0: 1 2 3 4 5 Again, from using select(2) on /dev/rtc0: 1 2 3 4 5 Current RTC date/time is 21-2-2017, 23:16:24. Alarm time now set to 23:16:29. Typing "cat /proc/interrupts" will show 1 more events on IRQ rtc.
rtcwakeup.out -d rtc0 -m mem -s 10 ./rtcwakeup.out -d rtc0 -m mem -s 10 rtcwakeup.out: wakeup from "mem" using rtc0 at Wed Feb 22 23:17:29 2017 PM: Syncing filesystems ... done. Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 639.100 msecs PM: suspend devices took 0.640 seconds PM: late suspend of devices complete after 1.236 msecs PM: noirq suspend of devices complete after 1.202 msecs Disabling non-boot CPUs ... CPU1: shutdown Turn off Mega/Fast mix in DSM Enabling non-boot CPUs ... CPU1 is up PM: noirq resume of devices complete after 0.756 msecs imx-sdma 30bd0000.sdma: loaded firmware 4.2 PM: early resume of devices complete after 0.972 msecs PM: resume of devices complete after 483.302 msecs PM: resume devices took 0.480 seconds Restarting tasks ... done.

12 Note About the Source Code in the Document

Example code shown in this document has the following copyright and BSD-3-Clause license: RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Copyright 2025 NXP Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

13.1 Revision History

This table provides the revision history. Document ID Release date Description 2.11, OP-TEE 4.6.0, Yocto 5.2 Walnascar, and added the i.MX 943 as Alpha quality. 2024 Upgraded to the 6.6.36 kernel. v2.10, OP-TEE 4.2.0, Yocto 5.0 Scarthgap, and added the i.MX 91 as Alpha quality, i.MX 95 as Beta quality. added the i.MX 95 as Alpha Quality.

Revision history

NXP Semiconductors RM00293 i.MX Linux Reference Manual Document ID Release date Description Kirkstone Yocto. 5.10.52. Cortex-M4 image". MX 8M Plus and i.MX 8DXL. consolidated GA for released i.MX boards. and consolidated GA for released i.MX boards. boards. IMXLXRM v.L4.9.51_8qm-beta2/8qxp- beta 02/2018 Added i.MX 8QuadMax Beta2 and i.MX 8QuadXPlus Beta. IMXLXRM v.L4.9.51_imx8qxp-alpha 11/2017 Initial release. Revision history...continued RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual Legal information Definitions Draft — A draft status on a document indicates that the content is still under internal review and subject to formal approval, which may result in modifications or additions. NXP Semiconductors does not give any representations or warranties as to the accuracy or completeness of information included in a draft version of a document and shall have no liability for the consequences of use of such information. Disclaimers Limited warranty and liability — Information in this document is believed to be accurate and reliable. However, NXP Semiconductors does not give any representations or warranties, expressed or implied, as to the accuracy or completeness of such information and shall have no liability for the consequences of use of such information. NXP Semiconductors takes no responsibility for the content in this document if provided by an information source outside of NXP Semiconductors. In no event shall NXP Semiconductors be liable for any indirect, incidental, punitive, special or consequential damages (including - without limitation - lost profits, lost savings, business interruption, costs related to the removal or replacement of any products or rework charges) whether or not such damages are based on tort (including negligence), warranty, breach of contract or any other legal theory. Notwithstanding any damages that customer might incur for any reason whatsoever, NXP Semiconductors’ aggregate and cumulative liability towards customer for the products described herein shall be limited in accordance with the Terms and conditions of commercial sale of NXP Semiconductors. Right to make changes — NXP Semiconductors reserves the right to make changes to information published in this document, including without limitation specifications and product descriptions, at any time and without notice. This document supersedes and replaces all information supplied prior to the publication hereof. Suitability for use — NXP Semiconductors products are not designed, authorized or warranted to be suitable for use in life support, life-critical or safety-critical systems or equipment, nor in applications where failure or malfunction of an NXP Semiconductors product can reasonably be expected to result in personal injury, death or severe property or environmental damage. NXP Semiconductors and its suppliers accept no liability for inclusion and/or use of NXP Semiconductors products in such equipment or applications and therefore such inclusion and/or use is at the customer’s own risk. Applications — Applications that are described herein for any of these products are for illustrative purposes only. NXP Semiconductors makes no representation or warranty that such applications will be suitable for the specified use without further testing or modification. Customers are responsible for the design and operation of their applications and products using NXP Semiconductors products, and NXP Semiconductors accepts no liability for any assistance with applications or customer product design. It is customer’s sole responsibility to determine whether the NXP Semiconductors product is suitable and fit for the customer’s applications and products planned, as well as for the planned application and use of customer’s third party customer(s). Customers should provide appropriate design and operating safeguards to minimize the risks associated with their applications and products. NXP Semiconductors does not accept any liability related to any default, damage, costs or problem which is based on any weakness or default in the customer’s applications or products, or the application or use by customer’s third party customer(s). Customer is responsible for doing all necessary testing for the customer’s applications and products using NXP Semiconductors products in order to avoid a default of the applications and the products or of the application or use by customer’s third party customer(s). NXP does not accept any liability in this respect. Terms and conditions of commercial sale — NXP Semiconductors products are sold subject to the general terms and conditions of commercial sale, as published at https://www.nxp.com/profile/terms, unless otherwise agreed in a valid written individual agreement. In case an individual agreement is concluded only the terms and conditions of the respective agreement shall apply. NXP Semiconductors hereby expressly objects to applying the customer’s general terms and conditions with regard to the purchase of NXP Semiconductors products by customer. Export control — This document as well as the item(s) described herein may be subject to export control regulations. Export might require a prior authorization from competent authorities. Suitability for use in non-automotive qualified products — Unless this document expressly states that this specific NXP Semiconductors product is automotive qualified, the product is not suitable for automotive use. It is neither qualified nor tested in accordance with automotive testing or application requirements. NXP Semiconductors accepts no liability for inclusion and/or use of non-automotive qualified products in automotive equipment or applications. In the event that customer uses the product for design-in and use in automotive applications to automotive specifications and standards, customer (a) shall use the product without NXP Semiconductors’ warranty of the product for such automotive applications, use and specifications, and (b) whenever customer uses the product for automotive applications beyond NXP Semiconductors’ specifications such use shall be solely at customer’s own risk, and (c) customer fully indemnifies NXP Semiconductors for any liability, damages or failed product claims resulting from customer design and use of the product for automotive applications beyond NXP Semiconductors’ standard warranty and NXP Semiconductors’ product specifications. HTML publications — An HTML version, if available, of this document is provided as a courtesy. Definitive information is contained in the applicable document in PDF format. If there is a discrepancy between the HTML document and the PDF document, the PDF document has priority. Translations — A non-English (translated) version of a document, including the legal information in that document, is for reference only. The English version shall prevail in case of any discrepancy between the translated and English versions. Security — Customer understands that all NXP products may be subject to unidentified vulnerabilities or may support established security standards or specifications with known limitations. Customer is responsible for the design and operation of its applications and products throughout their lifecycles to reduce the effect of these vulnerabilities on customer’s applications and products. Customer’s responsibility also extends to other open and/or proprietary technologies supported by NXP products for use in customer’s applications. NXP accepts no liability for any vulnerability. Customer should regularly check security updates from NXP and follow up appropriately. Customer shall select products with security features that best meet rules, regulations, and standards of the intended application and make the ultimate design decisions regarding its products and is solely responsible for compliance with all legal, regulatory, and security related requirements concerning its products, regardless of any information or support that may be provided by NXP. NXP has a Product Security Incident Response Team (PSIRT) (reachable at PSIRT@nxp.com) that manages the investigation, reporting, and solution release to security vulnerabilities of NXP products. NXP B.V. — NXP B.V. is not an operating company and it does not distribute or sell products. Trademarks Notice: All referenced brands, product names, service names, and trademarks are the property of their respective owners. NXP — wordmark and logo are trademarks of NXP B.V. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual AMBA, Arm, Arm7, Arm7TDMI, Arm9, Arm11, Artisan, big.LITTLE, Cordio, CoreLink, CoreSight, Cortex, DesignStart, DynamIQ, Jazelle, Keil, Mali, Mbed, Mbed Enabled, NEON, POP, RealView, SecurCore, Socrates, Thumb, TrustZone, ULINK, ULINK2, ULINK-ME, ULINK- PLUS, ULINKpro, μVision, Versatile — are trademarks and/or registered trademarks of Arm Limited (or its subsidiaries or affiliates) in the US and/or elsewhere. The related technology may be protected by any or all of patents, copyrights, designs and trade secrets. All rights reserved. Bluetooth — the Bluetooth wordmark and logos are registered trademarks owned by Bluetooth SIG, Inc. and any use of such marks by NXP Semiconductors is under license. EdgeLock — is a trademark of NXP B.V. eIQ — is a trademark of NXP B.V. RM00293 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NXP Semiconductors RM00293 i.MX Linux Reference Manual

3.1 AHB-to-APBH Bridge with DMA (APBH-

3.5 Quad/Flexible/External Serial Peripheral

3.8 SPI NOR Flash Memory Technology Device

4.3 Enhanced Configurable Serial Peripheral

NXP Semiconductors RM00293 i.MX Linux Reference Manual

4.11 Low Power Universal Asynchronous

4.16 Ethernet Controller with TSN (ENET_QoS,

4.18 Low Power Serial Peripheral Interface

NXP Semiconductors RM00293 i.MX Linux Reference Manual

6.4.5 Electrophoretic Display Controller (EPDC)

6.4.6 High-Definition Multimedia Interface (HDMI)

6.4.6.4 Display Device Registration and

NXP Semiconductors RM00293 i.MX Linux Reference Manual

6.4.6.5 Hotplug Handling and Video Mode

6.4.6.8 i.MX 6 On Chip High-Definition Multimedia

6.8.2 Overview of the JPEG Encoder and

6.8.3 Limitations of the JPEG Encoder/Decoder

7.1 Advanced Linux Sound Architecture (ALSA)

7.2 Asynchronous Sample Rate Converter

(ASRC) on i.MX 6/i.MX 8QuadMax/i.MX

7.2.2.2 Sequence for Memory to ASRC to

7.2.2.6 Programming Interface (Exported API and

7.4 The Sony/Philips Digital Interface (S/PDIF) ... 192

7.7 Asynchronous Sample Rate Converter

7.7.3.2 Sequence for Memory to ASRC to

NXP Semiconductors RM00293 i.MX Linux Reference Manual

7.7.3.6 Programming Interface (Exported API and

8.1 Cryptographic Acceleration and Assurance

8.1.8 Limitations in the Existing Implementation

8.1.10 Detect Available Secure Memory Storage

8.1.19 CAAM/SNVS - Security Violation Handling

8.3 Smart Card Interface - Subscriber

10.1.1 Supported Platforms and Platform-Specific

10.2.3 Supported DPDK Features on ENETC

10.3.2 Standalone Build of DPDK Libraries and

10.5.3 Prerequisites for running DPDK

10.5.4.1 Executing DPDK applications on i.MX 8M Mini, i.MX 8M Plus, i.MX 8DXL, i.MX 91, 10.5.4.2 Executing DPDK applications on i.MX 95 10.6 Executing DPDK applications on i.MX 943

10.7.2 Steps to test the QBV test case scenario for

10.8.5 CLI commands help accessible through

NXP Semiconductors RM00293 i.MX Linux Reference Manual

11.3.1 Enhanced Configurable Serial Peripheral

11.3.5 Low Power Universal Asynchronous

11.5.2 High-Definition Multimedia Interface (HDMI)

11.5.3.4 Test for i.MX 8QuadXPlus, 8QuadMax, and

11.6.1 Advanced Linux Sound Architecture (ALSA)

11.6.2 Asynchronous Sample Rate Converter

(ASRC) on i.MX 6/i.MX 8QuadMax/i.MX

12 Note About the Source Code in the

Please be aware that important notices concerning this document and the product(s) described herein, have been included in section 'Legal information'. © 2025 NXP B.V. All rights reserved. For more information, please visit: https://www.nxp.com Document feedback Date of release: 26 June 2025 Document identifier: RM00293

Selected Specification

NXP Semiconductors RM00293 overview.

Overview

RM00293 is listed in the Power Management category. Available datasheets include documents from NXP Semiconductors. DigiCamel provides a local PDF and searchable HTML technical text for online reference.

Summary

i.MX Linux Reference Manual 26 June 2025

Description

i.MX Linux Reference Manual 26 June 2025

Source title RM00293 Datasheet(PDF) - NXP Semiconductors

Related Parts

More parts from the same family.

Browse manufacturer