The following table summarizes the assignment of the Low Power UARTs (LPUARTs) on the i.MX 943 EVK when running the NXP Linux BSP. LPUART instance Hardware interface FTDI channels/Pins Comment LPUART8 On-board FT4232H UART-USB adapter Channel A Used by Cortex-M33 Sync core (M33 core 1) N/A(BCU)/LPUART11/LPUART12 Channel B Used by the BCU tool, or used as serial port for Cortex-M70 (LPUART11), or Cortex-M71 (LPUART12) LPUART1 Channel C Used by Cortex-A55 (U-Boot/Linux) LPUART2 Channel D Used by Cortex-M33 (M33 core 0, System Manager) LPUART11 External UART pins (board connectors) M2_UART11_RXD M2_UART11_TXD Used by the Cortex-M70 (a UART to USB adapter is needed) LPUART12 M1_UART12_RXD M1_UART12_TXD Used by the Cortex-M71 (a UART to USB adapter is needed)   If USB DBG port is connected to a Linux host PC, the channels A..D of the FTDI will appear as /dev/ttyUSB0..3 in that order. 1. LPUART8 is used by the Cortex-M33 Sync core application. LPUART8 shares the pins with the JTAG interface, so to route these pins to the FTDI adapter, set: SW7[4] = 1 and SW7[3] = 0. 2. If the JTAG is needed, the M33 Sync core can use LPUART3 instead of LPUART8. In the MCUXSDK applications, the only required code change is to set BOARD_DEBUG_UART_INSTANCE to 3. Board pin connections for LPUART3: J51-18  - M1_PWM_CX (LPUART3_TX) ----- RX of USB-UART converter    ---- PC J44-10 - M1_LED_TP1   (LPUART3_RX) ----- TX of USB-UART converter    ---- PC J45-12 - GND                                        ----- GND of USB-UART converter ---- PC 3. The FTDI Channel B is multiplexed between two functionalities: for the Board Remote Control Utilities (BCU). In this case, set SW7[1] = 0. Do not open ttyUSB1 in a terminal while using the BCU tool. connection to LPUART11 (Cortex-M70) or LPUART12 (Cortex-M71). Set SW7[1] = 1. To select between the two UARTs, set: SW7[2] = 1 for LPUART11, or SW7[2] = 0 for LPUART12. To route the two UARTs towards the FTDI, an additional multiplexer needs to be configured through an IO expander pin (UART_M_FT_SEL in the figure below). The following software changes are required: In the MCUXSDK application source code, call BOARD_SelectFTUART() in the BOARD_InitHardware() function in hardware_init.c. In the System Manager configuration file mx94evk.cfg, move the LPI2C6 and its pins (PIN_GPIO_IO28 and PIN_GPIO_IO29) to the the M7 core that will use the routed UART. LPI2C6 is needed to set UART_M_FT_SEL. In the Linux kernel device tree, disable the I2C6 peripheral. 4. LPUART1 is routed to the FTDI Channel C and is used by the A55 core (SPL, U-Boot, Linux). This path works by default. 5. LPUART2 is routed to the FTDI Channel D and is used by the M33 Core 0 (OEI, System Manager). 6. In the default configuration, LPUART11 (M70) and LPUART12 (M71) are routed to the M2 connectors. Board pin connections for LPUART11 (for Cortex-M70): J48-2 - M2_UART11_RXD   ---- TX of USB-UART adapter     ---- PC J48-4 - M2_UART11_TXD   ---- RX of USB-UART adapter     ---- PC GND                                     ---- GND of USB-UART adapter  ---- PC Board pin connections for LPUART12 (for Cortex-M71): J44-2 - M1_UART12_RXD   ---- TX of USB-UART adapter     ---- PC J44-4 - M1_UART12_TXD   ---- RX of USB-UART adapter     ---- PC GND                                     ---- GND of USB-UART adapter  ---- PC

i.MX95 Triple Display Patches for LF-6.6.52-2.2.0 BSP. iMX95 19x19 EVK.     Patches files: 0001-iMX95-EVK-IT6263-LVDS-to-HDMI-bridge-chip-combine-it.patch Combine IT6263 with simple panel driver, no EDID is needed, 720P and 1080P display mode had been added as two examples.   0002-IT6263-Always-reported-connected-for-force-output.patch Let IT6263 always report cable connected to force output HDMI signals.   0003-iMX95-EVK-add-LVDS-clone-mode-based-on-IT6263.patch LVDS clone mode is supported on two LVDS ports, they output same content and same timing from one DPU display engine (1920*1080@60fps).   0004-iMX95-EVK-add-dual-LVDS-interleaver-mode-based-on-IT.patch LVDS interleave mode is supported on two LVDS ports, they output different content and same timing from one DPU display engine (3840*1080@60fps).   0005-iMX95-EVK-add-triple-display-support.patch Triple display is supported, 1 MIPI DSI + 2 LVDS.  imx95-19x19-evk-triple-display-lvds-clone.dtb: the two LVDS is in clone mode. imx95-19x19-evk-triple-display-lvds-interleaver.dtb: the two LVDS is in interleave mode.   For 1 MIPI DSI + 2 LVDS display clone mode: For 1 MIPI DSI + 2 LVDS Interleave mode:     Know issues:  Due to bridge numbers (3) and DPU engine/Pixel link/Pixel Interleaver number (2) is not aligned, during kernel boot up, there will be followed link error log, but there is no real function impact.   [    3.178741] imx95-ldb 4b0c0000.syscon:ldb@4: Failed to create device link (0x180) with 4b010000.syscon:bridge@8 ... [    4.209299] imx95-pixel-interleaver 4b0d0000.bridge: Failed to create device link (0x180) with 4b400000.display-controller [    4.220355] imx95-pixel-interleaver 4b0d0000.bridge: Failed to create device link (0x180) with 4b400000.display-controller ...     2025-8-19 update: Add the patch for L6.12.20_2.0.0 BSP. lf-6.12.20-2.0.0_triple_display_patches.zip  

Background: This article discusses the reboot mechanism on the i.MX8MP and i.MX93 platforms. It aims to help customers understand how the reboot command works. We will discuss two different kernel versions separately.   1. Linux version : LF_6.12.34_2.1.0 The executable file for the reboot command is as follows： When the ”reboot“ command is executed, the system enters the ”do_kernel_restart()“ function and executes the reboot mechanism by determining the priority of the registered functions. Since the ”reboot.c“ file does not print out the registered functions, a print function is added to the file to identify the function that is ultimately executed.   The print output is as follows: As shown in the figure above, in version 5.12, the reboot is performed via a reset executed by psci. Continuing to trace the ”psci_sys_reset()“ function, we can see that the system sends the function ID via the PSCI interface to initiate an SMC call, instructing the underlying firmware (ATF/EL3) to perform a system reboot (typically a cold reset). The value of PSCI_0_2_FN_SYSTEM_RESET is 0x80000009   According to the Arm Power State Coordination Interface Platform Design Document, this ID represents a cold reset of the system.     2. Linux version : LF_6.18.2_1.0.0 Use the same debugging method to examine the reboot mechanism in version 6.18 As shown in the output below, in version 6.18, the system reset is triggered by the `sys_off_notify()` function. The final execution function is pca9450_i2c_restart_handler()   By examining the `pca9450_i2c_restart_handler()` function, we can see that the system writes a `SW_RST_COMMAND` value to the PMIC via I²C, where `SW_RST_COMMAND = 0x14`. According to the PMIC data sheet, 10b = Cold Reset; all voltage regulators are reset except LDO1/LDO2   Summary: Regardless of the kernel version, the `reboot` command triggers a system cold reset. The triggering mechanism has been updated in versions 6.18 and later.

The purpose of this document is to provide extended guidance for selection of compatible Non-Volatile Memory (NVM) devices that are supported by the Ara240 (aka Ara-2) processors. In all cases, it is strongly recommended to follow the memory layout guidelines outlined in the specific SoC requirement documents.   Manufacturer Memory Part Number Capacity Renesas NOR SPI FLASH AT25SL321-UUE-T 32Mbit (4MB) ISSI NOR SPI FLASH IS25WJ032F-JTLE-TR 32Mbit (4MB) ISSI NOR SPI FLASH IS25WP032D-JBLE 32Mbit (4MB) Winbond NOR SPI FLASH W25Q16JVSNIQ 16Mbit (2MB) Winbond NOR SPI FLASH W25Q32JWUUIQ 32Mbit (4MB) Winbond NOR SPI FLASH W25Q64JWSSIQ 64Mbit (8MB) XMC NOR SPI FLASH XM25LU64CVIQT 64Mbit (8MB)   Note 1: All memory parts are in production unless stated otherwise. Checked June 2026

We are pleased to announce that Config Tools for i.MX 26.03 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...) Version 26.03 System Manager Memory sector information for resources with memory configuration is added to the Resources overview. Support for memory sectors splitting. Memory configuration input for resources using MBC/MRC is improved. Support for macOS (aarch64 and x86_64) is added. Clocks Hierarchy for local configuration element settings is supported. TEE Multicore Interrupt Handling for Single Security Domain is supported. Option to filter only user-defined memory regions is added. Interrupts are now separated into groups based on the core.

There are currently no additional test programs in I.MX Jailhouse program. This demo shares how to test USB function in Jailhouse inmate. Inmate boot log: root@imx8mmevk:~# dmesg | grep usb [ 0.312280] usbcore: registered new interface driver usbfs [ 0.317206] usbcore: registered new interface driver hub [ 0.322279] usbcore: registered new device driver usb [ 0.911649] usbcore: registered new device driver r8152-cfgselector [ 0.917711] usbcore: registered new interface driver r8152 [ 0.994200] usbcore: registered new interface driver uas [ 0.999359] usbcore: registered new interface driver usb-storage [ 1.005192] usbcore: registered new interface driver usbserial_generic [ 1.011486] usbserial: USB Serial support registered for generic [ 1.017274] usbcore: registered new interface driver ftdi_sio [ 1.022813] usbserial: USB Serial support registered for FTDI USB Serial Device [ 1.029852] usbcore: registered new interface driver usb_serial_simple [ 1.036148] usbserial: USB Serial support registered for carelink [ 1.042016] usbserial: USB Serial support registered for flashloader [ 1.048144] usbserial: USB Serial support registered for funsoft [ 1.053931] usbserial: USB Serial support registered for google [ 1.059643] usbserial: USB Serial support registered for hp4x [ 1.065185] usbserial: USB Serial support registered for kaufmann [ 1.071051] usbserial: USB Serial support registered for libtransistor [ 1.077334] usbserial: USB Serial support registered for moto_modem [ 1.083371] usbserial: USB Serial support registered for motorola_tetra [ 1.089745] usbserial: USB Serial support registered for nokia [ 1.095368] usbserial: USB Serial support registered for novatel_gps [ 1.101486] usbserial: USB Serial support registered for siemens_mpi [ 1.107612] usbserial: USB Serial support registered for suunto [ 1.113316] usbserial: USB Serial support registered for vivopay [ 1.119111] usbserial: USB Serial support registered for zio [ 1.124578] usbcore: registered new interface driver usb_ehset_test [ 1.215499] usbcore: registered new interface driver usbhid [ 1.220879] usbhid: USB HID core driver [ 1.396384] usb_phy_generic usbphynop1: dummy supplies not allowed for exclusive requests [ 42.414253] usb 1-1: new high-speed USB device number 2 using ci_hdrc [ 42.577822] usb-storage 1-1:1.0: USB Mass Storage device detected [ 42.579492] scsi host0: usb-storage 1-1:1.0  

To simplify development on the NXP FRDM board family, new device trees have been created for the i.MX91, i.MX93, i.MX95, and i.MX8MP platforms. These device trees are intended to provide a more ready to use out of the box experience by preconfiguring the Raspberry Pi connector with the same peripheral mapping commonly expected on Raspberry Pi compatible hardware. With this approach, developers, students, and makers can use compatible expansion boards and HAT style accessories more easily, without needing to create or significantly modify additional device tree files. Instead of spending time on low level hardware description updates, users can start evaluating peripherals and building applications directly on top of the provided configurations. For convenience, this post includes a .zip package containing: The compiled device tree binaries (.dtb) The device tree source files (.dts) The kernel patch for the NXP Linux Kernel 6.18 required to integrate these changes All files are attached to this post, allowing users to easily reuse, modify, or integrate the device trees into their own projects. To configure a new device tree, compile it, and flash it onto the target, you can refer to the following guides: How to compile Linux Kernel Image and device tree using Yocto SDK Flash customized Linux Kernel Image and device tree using UUU Tool

  Overview When using the OX03C10 camera with the deserializer (X-MX95MBDESER01) on i.MX95 platforms, systems are often deployed with fewer than four cameras (e.g., single-camera evaluation setups). This guide provides best practices and configuration guidance to ensure a smooth experience when using 1–3 cameras, including correct hardware connections and software configuration.   Key Recommendations 1. Connect Cameras in Port Order For proper operation, cameras should always be connected starting from the first deserializer port, then incrementally: ✅ 1 camera → connect to Port 0 ✅ 2 cameras → connect to Port 0 and Port 1 ✅ 3 cameras → connect to Port 0, Port 1, Port 2   Avoid skipping ports (e.g., connecting only to Port 2). Note: Starting with release 6.18.20, this constraint is relaxed. However, following this order remains recommended for consistency across software versions. 2. Understand Default Resolution Behavior Resolution handling depends on the software version used: Kernel Version Supported Camera Modes ≤ 6.6.y 1920 × 1280 only ≥ 6.12.y 1920 × 1280 and 1920 × 1080   In newer versions, the system may automatically select different resolutions across components, which can lead to mismatches if not explicitly configured. Recommended Configuration Approach To ensure consistent operation across all supported resolutions, it is recommended to configure the resolution centrally in the libcamera pipeline configuration. Update config.yaml Edit the following file: /usr/share/libcamera/pipeline/nxp/neo/config.yaml Add or update the format section for your camera entity: - entity: mx95mbcam 8-0040 format: { size: [1920,1082] }   Why this is recommended ✅ Works with both 1920×1280 and 1920×1080 ✅ Avoids pipeline mismatches between camera and ISP ✅ Provides consistent behavior across applications   Summary To ensure optimal operation when using fewer than four cameras: ✔ Connect cameras starting from the first port ✔ Use sequential port order (no gaps) ✔ Prefer configuring resolution in config.yaml

There are currently no additional test programs in I.MX Jailhouse program. This demo shares how to test RM67199 MIPI panel in Jailhouse inmate.   Please refer run.sh in attachments. modprobe jailhouse insmod jailhouse_clk.ko # adjust pixel clock for MIPI PANEL RMP67199 echo 129937500 > /sys/bus/platform/devices/jailhouse_clk/rate_pix export PATH=$PATH:/usr/share/jailhouse/tools/ jailhouse enable /root/imx8mm.cell jailhouse cell linux /root/imx8mm-inmate-demo.cell /root/Image.bin -d /root/imx8mm-evk-inmate.dtb -c "clk_ignore_unused console=ttymxc3,115200 earlycon=ec_imx6q,0x30890000,115200 root=/dev/mmcblk2p2 rootwait rw"  

Updates i.MX 93 Reference Manual Rev. 7. 

Introduction.  USB is a highly efficient interface for transporting audio and voice data, offering sufficient bandwidth for applications from voice telephony to high-quality audio playback and recording. To ensure compatibility between devices, the USB Audio Class specification defines standardized mechanisms for audio transport and control, allowing audio peripherals to operate with generic drivers and minimizing platform software requirements.    For i.MX processors, this article describes how an i.MX board can function as a standard USB audio device, enabling audio data to be streamed through the USB port to a host computer. This capability is important for applications such as USB microphones, speakers, audio gateways, and voice-processing systems.   As a result, developers can efficiently implement real time audio transfer between i.MX boards and host systems using standard USB audio drivers without requiring additional proprietary interfaces.   Required equipment. i.MX95 FRDM board (this is the selected board for this post, it works for others). Debug USB-C cable. Data USB-C cable. USB-C power supply. Ethernet cable. Speakers or headphones with 3.5mm input plug. Personal computer. To start, we need to flash our Linux BSP into the board. You can build it by yourself or use the pre-built BSP to facilitate the process. This post was tested with Linux 6.18.20_2.0.0, if you have issues to flash the board, please refer to this article: Flashing Linux BSP using UUU This is how my hardware setup looks: USB gadget setup. The following script configures the board to work as an USB audio gadget in Linux. This setup allows the board to be detected as a standard audio device, enabling audio streaming over the USB connection without requiring a custom USB protocol on the host side. The script creates the USB gadget configuration, assigns the required USB descriptors, with predefined audio parameters such as 16 kHz sample rate, 32-bit sample size, and single-channel capture/playback support. This example is useful for applications such as voice capture, audio processing, USB microphones, or embedded audio demos. #!/bin/sh # USB gadget ConfigFS paths CONFIGFS=/sys/kernel/config/usb_gadget GADGET=$CONFIGFS/g1 CONFIG=$GADGET/configs/c.1 FUNCTIONS=$GADGET/functions # USB device descriptors and audio configuration VID="0x1fc9" PID="0x0330" SERIALNUMBER="0123456789" MANUFACTURER="NXP Semiconductors" PRODUCT="i.MX USB Audio Gadget" SAMPLE_RATE=16000 SAMPLE_SIZE=4 # 32-bit audio samples echo "Setting up USB gadget with the following parameters:" echo " Vendor ID: $VID" echo " Product ID: $PID" echo " Serial Number: $SERIALNUMBER" echo " Manufacturer: $MANUFACTURER" echo " Product: $PRODUCT" echo " Sample Rate: $SAMPLE_RATE Hz" function add_uac2_function() { # Create a USB Audio Class function instance mkdir $FUNCTIONS/uac2.$1 echo "$PRODUCT $1" > $FUNCTIONS/uac2.$1/function_name # c_* parameters configure USB Capture # p_* parameters configure USB Playback # Audio sample rate configuration echo $SAMPLE_RATE > $FUNCTIONS/uac2.$1/c_srate echo $SAMPLE_RATE > $FUNCTIONS/uac2.$1/p_srate # Audio sample size in bytes echo $SAMPLE_SIZE > $FUNCTIONS/uac2.$1/c_ssize echo $SAMPLE_SIZE > $FUNCTIONS/uac2.$1/p_ssize echo $2 > $FUNCTIONS/uac2.$1/c_chmask echo $3 > $FUNCTIONS/uac2.$1/p_chmask # Enable mute and volume controls visible to the USB host echo 0x1 > $FUNCTIONS/uac2.$1/c_mute_present echo 0x1 > $FUNCTIONS/uac2.$1/c_volume_present echo 0x1 > $FUNCTIONS/uac2.$1/p_mute_present echo 0x1 > $FUNCTIONS/uac2.$1/p_volume_present # Add the UAC2 function to the active USB configuration ln -s $FUNCTIONS/uac2.$1 $CONFIG } function create_config() { # Create the USB gadget device mkdir $GADGET # Set USB Vendor ID and Product ID echo $VID > $GADGET/idVendor echo $PID > $GADGET/idProduct # Standard USB string descriptors mkdir $GADGET/strings/0x409 echo $SERIALNUMBER > $GADGET/strings/0x409/serialnumber echo $MANUFACTURER > $GADGET/strings/0x409/manufacturer echo $PRODUCT > $GADGET/strings/0x409/product # Create USB configuration description mkdir -p $CONFIG/strings/0x409 echo $1 > $CONFIG/strings/0x409/configuration } # Create a UAC2 audio gadget with mono capture and mono playback create_config "UAC2" add_uac2_function "Active" 0x1 0x1 echo "Done" Clean USB gadget. If you need to free up the USB port, it is necessary to run the following script. #!/bin/sh # USB gadget ConfigFS paths CONFIGFS=/sys/kernel/config/usb_gadget GADGET=$CONFIGFS/g1 CONFIG=$GADGET/configs/c.1 FUNCTIONS=$GADGET/functions # Verify that the gadget exists before attempting cleanup if [ ! -d "$GADGET" ]; then echo "Gadget does not exist" exit 0 fi # Disconnects the gadget from the host before removal. echo "" > $GADGET/UDC 2>/dev/null # Remove UAC2 function links from the configuration rm -f $CONFIG/uac2.* 2>/dev/null # Remove UAC2 function instances rmdir $FUNCTIONS/uac2.* 2>/dev/null # Remove configuration strings and configuration directory rmdir $CONFIG/strings/0x409 2>/dev/null rmdir $CONFIG/strings 2>/dev/null rmdir $CONFIG 2>/dev/null # Remove gadget string descriptors rmdir $GADGET/strings/0x409 2>/dev/null rmdir $GADGET/strings 2>/dev/null # Remove the gadget itself rmdir $GADGET 2>/dev/null echo "Cleanup completed" Testing. Both scripts can be created into the board using nano or a similar text editor through the console but is easier to do it in your host machine and send it for example using SCP. After you created both scripts you can send them with the next command: scp <file_to_transfer> <user>@<ip_address>:<destination_path> Once you connected the Ethernet cable in any of the available RJ45 connectors in your board, you can get the IP address with the next command: ifconfig Now, in your host machine, you can go to the path where are your USB scripts and send them: scp cleanup_usb_gadget.sh root@<frdm_board_ip>:~/ scp setup_usb_gadget.sh root@<frdm_board_ip>:~/ After transfer the scripts to the board, you need to change file permissions to execute the scripts with chmod and run USB gadget setup script to configure the board as a USB audio interface. chmod u+x *_usb_gadget.sh Once this script have been executed you can see the USB port in ALSA as a sink/source device: Then, you need to connect the USB port to a host computer and will be recognized as an USB interface: You can validate that the device is working according to the configuration defined in setup script: I will use Audacity to test audio transfer from on board microphones, in Edit -> Preferences -> Audio settings select i.MX Active as recording device: Note: Use the same sample rate of setup_usb_gadget.sh configuration to avoid errors with the DAW. In the board, I will start the recording by running the following GStreamer pipeline, which captures audio from the onboard microphones and streams it through the USB port: gst-launch-1.0 alsasrc device=hw:micfilaudio,0 ! queue ! audioconvert ! audio/x-raw,channels=1,rate=16000,format=F32LE ! audioconvert ! alsasink device=hw:UAC2Gadget,0 After this configuration, add an audio track and now, is possible to get the audio and record it directly in the DAW: If you want to play audio from host PC trough the i.MX board, you need to run the next command before start the audio playback in host. Make sure that the audio card selected is not busy: gst-launch-1.0 -v alsasrc device=hw:UAC2Gadget,0 ! audio/x-raw,format=S32LE,rate=16000,channels=1 ! audioconvert ! audioresample ! audio/x-raw,format=S16LE,rate=48000,channels=2 ! audioconvert ! alsasink device=plughw:mqsaudio,0 In this case, I selected the MQS output in 3.5mm output jack, you can connect the speakers or headphones with this connector. After run the clean USB gadget script, the USB audio device is not longer detected in host PC and the board output is the next: References. USB Implementers Forum. (1998, March 18). Universal Serial Bus device class definition for audio devices (Release 1.0) [PDF]. USB-IF. https://www.usb.org/sites/default/files/audio10.pdf   

Some customer wants to know how to enable the SOD for MIMX9596DVZXQAC, commercial qualification in 19mm. They want to test the SOD mode which is A55 running at 2.0GHz, there is no any documentation in our NXP side explaining how to do that. Here this article give the describe and enable the Super Overdrive mode on the i.MX95. 1\Introduction the i.MX95 Voltage Operating Modes The i.MX power architecture is designed with the expectation that a dedicated PMIC supplies all required power rails, ensuring compliance with stringent power-up and power-down sequencing requirements. Majority of the digital logic is supplied with two supplies: VDD_ARM and VDD_SOC. VDD_ARM is for the CORTEXAMIX. VDD_SOC is for the rest of the modules in SoC. The VDD_SOC has following modes: Overdrive mode Nominal mode Underdrive mode Suspend mode The VDD_ARM has following modes: Super Overdrive mode Overdrive mode Nominal mode Underdrive mode Suspend mode The i.MX95 power management architecture is based on multiple performance setpoints controlled by the System Manager (SM). These setpoints control: Cortex-A55 operating frequency VDD_ARM voltage Power consumption Thermal dissipation The available performance modes are:PRK,LOW,NOM,ODV,SOD Where SOD (Super Overdrive) is available only on qualified 2.0 GHz capable devices such as MIMX9596DVZXQAC. In our datasheet we can see that for the part number only MIMX9596DVZXQAC A core support the 2.0 GHz.     Details in the naming rules:   For the operating ranges in our datasheet can see the details:   Only the Cortex-A55 support the super overdrive mode, and for the typical voltage is 1.0V. In our reference design the VDD_ARM and VDD_SOC from different PMIC. And for the frequency of modules can also see in the datasheet, for the default setting is 1.8GHz, the maximum is 2004MHz.   2\ Enable Super Overdrive (SOD) Mode (2.0 GHz) on MIMX9596DVZXQAC Understanding about SOD mode:  The default NXP BSP SM (System Manager) code will automatically detect if the iMX 95 device it is running on is a 2.0 GHz capable device, and then the code will enable operation at 2.0 GHz with Super Overdrive voltage mode.  Linux on the iMX 95 only needs to request 2.0 GHz from the System Manager to enable it. Default BSP support code: In the download source code path : /imx95BSP/tmp/work/imx95_19x19_lpddr5_evk-poky-linux/imx-system-manager/2025q4/git/devices/MIMX95/sm/dev_sm_perf.c Or in our github source can see the code: imx-sm/devices/MIMX95/sm/dev_sm_perf.c at master · nxp-imx/imx-sm · GitHub The NXP BSP already contains logic to detect whether the device supports 2.0 GHz operation   /* Check for 2+GHz device */ if (speedGrade >= 2000000000U) { /* 2+GHz devices support PRK, LOW, NOM, ODV, SOD setpoints */ s_perfNumLevels[PS_VDD_ARM] = DEV_SM_NUM_PERF_LVL_ARM; }  When the System Manager reads: speedGrade >= 2000000000 the BSP automatically: Enables the SOD performance level Enables 2.0 GHz OPP Manages required ARM voltage transitions The above code will enable the SOD without changing anything. Then in Linux you can use performance to run at 2.0GHz. Using the following command: echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor Then we can check the frequency and voltage of the VDD_ARM.  3\ Enabling SOD on a Non-2.0 GHz EVK (Evaluation Only) For evaluation on the EVK with the 1.8 GHz i.MX95, the process to enable 2.0 GHz and Super Overdrive voltage mode is to modify a single line of SM (System Manager) code so that 2 GHz is enabled even if the iMX 95 does not report 2 GHz operation is possible. Change this file: /MIMX95/sm/dev_sm_perf.c else { /* All other devices support PRK, LOW, NOM, ODV setpoints */ s_perfNumLevels[PS_VDD_ARM] = DEV_SM_NUM_PERF_LVL_ARM - 1U; }// This the the default running code for the 1.8GHz for the i.MX95 FROM: s_perfNumLevels[PS_VDD_ARM] = DEV_SM_NUM_PERF_LVL_ARM - 1U; TO: s_perfNumLevels[PS_VDD_ARM] = DEV_SM_NUM_PERF_LVL_ARM;//Force to work on the SOD mode.  Then rebuild the imx-system-manager and generate a new image. Write the images to the i.MX95 19x19 lpddr5 EVK board. Run the board and boot up. root@imx95-19x19-lpddr5-evk:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 500000 900000 1404000 1800000 2004000 root@imx95-19x19-lpddr5-evk:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 2004000 BCU tool show that VDD_ARM is 1.0v when "running" at 2.0GHz and VDD_ARM is 0.9v when running at 1.8GHz, so the SOD is working. I did the the above change and tested on NXP imx95 1.8GHz 19x19 lpddr5 EVK board and the SOD worked 4\Summary So For the MIMX9596DVZXQAC the BSP is expected to automatically detect 2.0 GHz capability and enable SOD mode without source code modifications. EVK Modification The forced SM modification described above: DEV_SM_NUM_PERF_LVL_ARM is intended only for evaluation and debug purposes. It bypasses the normal speed-grade detection mechanism and should not be considered a production configuration for non-qualified devices. For the customer's MIMX9596DVZXQAC device: No BSP modification should be required. System Manager automatically checks the speed grade. If the device reports 2.0 GHz capability, SOD is enabled automatically. Linux only needs to request the highest CPU frequency. SOD operation can be verified by: Availability of 2004000 kHz CPU running at 2.0 GHz VDD_ARM increasing from ~0.9 V to ~1.0 V This confirms successful operation in Super Overdrive (SOD) Mode.  

We are pleased to announce that Config Tools for i.MX 26.06 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...) Version 26.06 DDR tool – NXP-validated memory configurations for multiple vendors is available System Manager – extended CLI support for a headless setting