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

This blog enables support of Qemu emulation for iMX8MM EVK.  Imagine not having the hardware but still you want to test the software. Qemu gives you exactly that. 1. Booting uboot, linux and user-space application even when you do not possess a real hardware. 2. Early firmware development when the silicon doesn’t yet exist. 3. Linux driver development, debugging and testing.

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.

This page serves as a hub to gather the links to all the currently available ISP supported camera lists for the i.MX Applications processors.  Camera Compatibility Guides Processor/Family Link to Guide i.MX 8M Plus i.MX 8M Plus ISP Camera Compatibility Guide i.MX 95 i.MX 95 ISP Camera Compatibility Guide   Additional Resources i.MX Camera Software Pack AN AN14376: i.MX Camera Software Pack | NXP Semiconductors

The purpose of this page is to provide supportive information for the selection of suitable camera modules that are supported by the i.MX95. The guide is attached in this page. This helps customers evaluate project feasibility and integration aspects when considering i.MX 95 SoCs for their products. It is strongly recommended to consult with NXP and the camera module vendor before finalizing the choice of the camera part number to ensure compatibility, availability, longevity, and pricing requirements.   NXP Supported Sensors: Sensor Vendor Image Sensor Max Resolution Camera Module OmniVision OS08A20 8MP IMX95-OS08A20 | NXP Semiconductors EXPI-OS08A20 OmniVision OX05B1S 5MP   OmniVision OX03C10 3MP   Onsemi AR0144 1MP AR0144   Partner Enabled Sensors: Partner Sensor Vendor Image Sensor Max Resolution ISP Tuning Camera Module Location FRAMOS Sony IMX662 2MP ✔ FSM:GO Munich, Germany/ Canada/USA Sony IMX678 8MP Sony IMX900 3.2MP Sony IMX676 12MP Onsemi Onsemi AR2020 19MP   Module available through Future Electronics   Entron OmniVision OS08A20 8MP ✔ EXPI-OS08A20 China Onsemi AR0820 8MP Order with Entron Onsemi AR0823 8MP Technexion Onsemi AR0144 1MP       Onsemi AR0145 1MP     Onsemi AR0234 2MP     Onsemi AR0235 2MP     Onsemi AR0236 2MP     Onsemi AR0521 5MP     Onsemi AR0522 5MP     Onsemi AR0544 5MP     Onsemi AR0821 8MP       Onsemi AR0822 8MP     Onsemi AR0830 8MP     Onsemi AR1335 13MP     PHYTEC Onsemi AR0144 1MP     Germany/ China/India/ USA Onsemi AR0234 2.3MP   Onsemi AR0521 5MP   E-consystems Sony IMX662 2.4MP     Riverside, CA, USA/India Sony IMX900 3.2MP    

Use Raspberry Pi Debug Probe with OpenOCD and i.MX93 FRDM   This document explains the integration process of the Raspberry Pi Debug Probe (Very low cost debugger) with the OpenOCD (On Chip Debugger) tool with the i.MX93 FRDM board.   Also, we will use GDB (GNU DeBugger) to interact with the OpenOCD.   1. Install and Configure OpenOCD   Update and install dependencies sudo apt update sudo apt install build-essential libtool automake pkg-config libusb-1.0-0-dev libhidapi-dev libftdi1-dev libjim-dev jimsh   Clone the OpenOCD repo git clone https://github.com/openocd-org/openocd.git cd openocd   Run ./bootstrap to create the configuration file git submodule update --init --recursive ./bootstrap ./configure --enable-cmsis-dap --enable-hidapi   Make OpenOCD make -j$(nproc) sudo make install   Download the configuration file for i.MX93 You can dowload the  imx93.cfg  in the Table 2. Software requirements on Ubuntu PC of the AN14367 Then, copy the downloaded file to the openocd/tcl/target/ as below: cp ../imx93_new-b42b7c4cac18508442d3df035cec1c6d.cfg tcl/target/imx93.cfg   2. Create UDEV rules   sudo nano /etc/udev/rules.d/99-openocd.rules Add the below in that file: ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="000c", MODE="660", GROUP="plugdev", TAG+="uaccess"   Reload rules sudo udevadm control --reload-rules && sudo udevadm trigger   3. Connecting the Hardware   To make the DAP works in the i.MX93 FRDM, we must rework the board removing the resistors R3017 and R3018:     Now, we need to connect the Raspberry Pi Debug Probe with the SWD (P14) of our i.MX93 FRDM board:       4. Running the Debug Session   In this moment, with the RP Debug Probe connected, we can Boot the i.MX93 FRDM board and run the below command to start the OpenOCD: $ openocd -s tcl -f interface/cmsis-dap.cfg -c "adapter speed 1000" -f target/imx93.cfg   tic-mpu@tic-mpu:~/Debug_test/openocd$ openocd -s tcl -f interface/cmsis-dap.cfg -c "adapter speed 1000" -f target/imx93.cfg Open On-Chip Debugger 0.12.0+dev-02429-ge4c49d860 (2026-03-21-23:05) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 1000 kHz Warn : DEPRECATED: auto-selecting transport "swd". Use 'transport select swd' to suppress this message. Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6633861A33A1B2C Info : CMSIS-DAP: SWD supported Info : CMSIS-DAP: Atomic commands supported Info : CMSIS-DAP: Test domain timer supported Info : CMSIS-DAP: FW Version = 2.0.0 Info : CMSIS-DAP: Interface Initialised (SWD) Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0 Info : CMSIS-DAP: Interface ready Info : clock speed 1000 kHz Info : SWD DPIDR 0x5ba02477 Info : imx93.a55.0: hardware has 6 breakpoints, 4 watchpoints Info : [imx93.a55.0] external reset detected Info : [imx93.a55.0] Examination succeed Info : [imx93.m33] Cortex-M33 r1p0 processor detected Info : [imx93.m33] target has 8 breakpoints, 4 watchpoints Info : [imx93.m33] Examination succeed Info : [imx93.ahb] Examination succeed Info : [imx93.a55.0] starting gdb server on 3333 Info : Listening on port 3333 for gdb connections Info : [imx93.m33] starting gdb server on 3334 Info : Listening on port 3334 for gdb connections Info : [imx93.ahb] gdb port disabled   From the Logs, we can see we have two ports: 3333 for Cortex A55 [imx93.a55.0] 3334 for Cortex M33 [imx93.m33]   Install gdb-multiarch   Now, we can install GDB: sudo apt install gdb-multiarch And start a Debug session: $ gdb-multiarch ~/linux-imx/vmlinux   $ gdb-multiarch ~/linux-development/linux-imx/vmlinux GNU gdb (Ubuntu 15.1-1ubuntu1~24.04.1) 15.1 Copyright (C) 2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/tic-mpu/linux-development/linux-imx/vmlinux... (gdb) target extended-remote localhost:3333 Remote debugging using localhost:3333 0x00000000fff118fc in ?? ()   A simple example of how to read a register with GDB: (gdb) x/xw 0x43810000 0x43810000: 0x02010001     Happy debugging!     Best regards, Salas. 

Tested in FRDM-i.MX91 Written in C LF-6.12.49

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"  

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  

This tutorial describes the complete procedure for calibrating a touchscreen display using Weston, specifically validated with the DY1212W LVDS panel on the following NXP development platforms: i.MX93‑EVK FRDM‑i.MX95 FRDM‑i.MX8MP While the initial calibration performed by Weston works only temporarily, this guide will walk you through configuring the system so that the calibration becomes persistent across reboots. The steps below include performing the initial calibration, editing Weston’s configuration, creating a calibration helper script, and applying udev rules to store the calibration matrix automatically.   Temporary Touchscreen Calibration To begin, run the following command to perform an initial calibration of your touchscreen: weston-touch-calibrator LVDS-1   After running this command, your display should be correctly calibrated. However, this calibration is not persistent, and you will need to recalibrate after every reboot unless you complete the persistence steps below.   Making the Calibration Persistent Follow the steps below to ensure that calibration settings are preserved across system restarts. Step 1: Edit the Weston Configuration File Open the following file: /etc/xdg/weston/weston.ini Under the [libinput] section, add these lines: [libinput] touchscreen_calibrator=true + calibration_helper=/usr/bin/save-calibration.sh This enables the calibration helper script that will automatically save your settings. Step 2: Create the Calibration Helper Script Create a new script at: /usr/bin/save-calibration.sh   Insert the following content: #!/bin/bash # Store the transformation arguments for the resistive touchscreen as udev rule echo 'SUBSYSTEM=="input", KERNEL=="event[0-9]*", ENV{ID_INPUT_TOUCHSCREEN}=="1", ENV{LIBINPUT_CALIBRATION_MATRIX}="'$2' '$3' '$4' '$5' '$6' '$7'"' >> /etc/udev/rules.d/touchscreen.rules   Make the script executable: chmod 755 /usr/bin/save-calibration.sh   Step 3: Restart Weston and Recalibrate Restart the Weston service: systemctl restart weston   Run the calibration tool again to generate the persistent settings: weston-touch-calibrator LVDS-1 reboot   Conclusion After completing all of the steps above, your touchscreen calibration will now persist across reboots, ensuring a consistent user experience even after powering off the board. This configuration allows the system to automatically store and apply calibration data through a udev rule generated by your helper script. If you encounter any issues or require further assistance, feel free to reach out. Best regards, Chavira

this poring is based on the imx415 driver, the capture format is based on raw10, the bsp version is 6.6.52, the patches are attached Disclaimer: − “Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.”

i.MX 93 EVK LF-6.12.49 patches

GUI Guider version:  1.9.x, 1.10.x LVGL version: v8.x.x , v9.x.x Host software requirements: Ubuntu 20.04, Ubuntu 22.04 or Debian 12 Target  software requirements:  BSP 6.6 or higher  Hardware requirements: FRDM i.MX 93 Development Board i.MX 93 Evaluation Kit FRDM i.MX 91 Development Board i.MX 91 Evaluation Kit i.MX95  Steps: 1. Export your project from the folder GUI-Guider-Projects to your Linux PC. 2. Build an image for iMX9 using The Yocto Project. Based on iMX Yocto Porject Users Guide set directories and download the repo a. Based on iMX Yocto Porject Users Guide set directories and download the repo $ mkdir imx-bsp-6.6 $ cd imx-bsp-6.6 $: repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.52-2.2.0.xml $ repo sync Use distro fsl-imx-xwayland and select machine imx93evk and use this commnad with a build folder name: $ MACHINE=imx93evk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh - b bld-imx93evk b. Use bitbake command to start the build process. Also, add the -c populate_sdk to get the toolchain. $ bitbake imx-image-full -c populate_sdk  c. Install the Yocto toolchain located on <build-folder>/tmp/deploy/sdk/.  $ sudo sh ./fsl-imx-xwayland-glibc-x86_64-imx-image-full-armv8a-imx93evk-toolchain-6.6-scarthgap.sh d. Install ninja utility on the build host $ sudo apt update $ sudo apt upgrade -y $ sudo apt install ninja-build   3. Once your Yocto SDK has been generated and installed, you can build the required binaries using the script attached to this post.      a) Place the script           Copy the script into the same directory where your meta-gui-guider folder is located.      b) Run the script to build the Gui Guider binary           The script includes several options to rebuild, clean, or use a different toolchain in                case you are working with a Yocto SDK version other than the default one (6.6-scarthgap). Build Options Build the Gui Guider binary using the default Yocto SDK ./guider_1.9_project_builder.sh Build the Gui Guider binary using another Yocto SDK version ./guider_1.9_project_builder.sh -t <yocto_sdk_path>/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake Prepare the source code before building ./guider_1.9_project_builder.sh -p Clean the previous build and recompile (Use -t if needed to specify a different toolchain) ./guider_1.9_project_builder.sh -c   4. The generated Gui Guider binary can be found at the following path: /meta-gui-guider/recipes-graphics/gui-guider/gui-guider/build/gui_guider Copy this binary to your board using either USB or SCP, and then execute it directly on the target device.   Using this method provides the flexibility to modify the source code before compilation. This is important because, by default, some configuration options are not available when using Gui Guider directly or when compiling inside Yocto. If you encounter any issues during this process, please open a new thread so we can assist you. Best regards, Chavira

This patch series enables the external 3.3 V and 5 V power rails used by the Raspberry Pi expansion connector on the i.MX93-QSB, i.MX93-FRDM, and i.MX91-FRDM boards. These regulators were already defined in the device tree but left disabled by default. By activating them, the RPI-compatible expansion header can properly power external modules, HATs, and add‑on boards. Changes by board: i.MX93-QSB Enables the 3.3 V and 5 V external supply lines used by the RPI connector.   i.MX93-FRDM Enables the 3.3 V and 5 V external supply lines used by the RPI connector.   i.MX91-FRDM Enables the 3.3 V and 5 V external supply lines used by the RPI connector.   Purpose: Provide proper power to the Raspberry Pi compatible expansion port. Improve hardware compatibility for users attaching external HATs or modules. Align all i.MX9 reference boards to use a consistent power‑tree configuration for the RPI connector.

SW : uboot-imx lf_v2025.04 HW : i.MX 8MP EVK board, Oscilloscope   1. Introduction This guide explains the concept of DDR clock spread spectrum on the i.MX 8MP EVK platform. Note that the official NXP BSP does not enable this feature by default. Additionally, this guide provides an example code patch and verification steps to enable the LPDDR4 clock spread spectrum feature on the NXP i.MX 8MP EVK board.   2. What is Spread Spectrum? Spread Spectrum (SS) is a technique used to reduce electromagnetic interference (EMI) by slightly modulating the clock frequency around its nominal value. Instead of operating at a fixed frequency (e.g., 800 MHz), the clock signal is varied within a small range (e.g., ±0.5%). This modulation spreads the energy of the clock signal over a wider frequency band, reducing the peak energy at any single frequency. In other words, SS does not change the average clock speed significantly, but it helps to distribute the spectral energy, making the system less likely to violate EMI regulations.   3. Why Enable Spread Spectrum on DRAM Clock? Enabling Spread Spectrum on the DRAM clock helps reduce electromagnetic interference (EMI) by slightly modulating the clock frequency, lowering peak emissions and making it easier to meet regulatory standards such as FCC and CE. This approach improves system reliability by minimizing interference with other components, offers a cost-effective alternative to hardware changes like shielding or PCB redesign, and is widely adopted in high-speed interfaces such as DDR, PCIe, and SATA to ensure compliance without additional hardware complexity.   4. Related registers CCM_ANALOG_DRAM_PLL_SSCG_CTRL                             Note :  PLL_MFREQ_CTL[19 : 12] : Value of modulation frequency control The larger the mfr value, the lower the MF value (the slower the modulation); the smaller the mfr value, the higher the MF value. MF : The frequency of spread spectrum modulation is the speed at which the triangular/sawtooth modulated wave travels back and forth once per second, measured in Hz (commonly in the tens of kHz range). The speed of the spread spectrum "jitter" is determined. Usually, around 20–50 kHz is chosen to make the energy "swipe evenly" within the bandwidth of the EMI test receiver, thereby reducing the peak radiation at a certain frequency point. PLL_MRAT_CTL[9 : 4] : Value of modulation rate control The larger mrr is, the larger MR is (the wider the range); similarly, MR is also directly proportional to mfr and inversely proportional to m. MR : Peak-to-peak percentage of spread spectrum (the percentage of the total range of the clock frequency swinging around the center value). For example, MR = 0.5% means that the frequency swings around the center value by a total of 0.5% (if it is center-spread spectrum, it is usually ±0.25%).The MR determines the depth (width) of the spread spectrum. The larger the MR, the wider the spectral energy distribution and the lower the peak value, but it comes at the cost of jitter/timing margin (timing should be carefully selected for DDR, SerDes, etc.). 5. About Uboot code patch. Please refer the attachment patch file. At high DRAM frequency, Enable SS may cause not stable problem. So, in this case, I will choose 2400Mbps data clock run the test. Firstly, we should make sure that our code include the 2400Mbps PLL setting. DRAM data speed is 2400Mbps, the DRAM clock is 1200MHz. So the DDRC PLL clock should set up with 600MHz. For example, refer the below code. static struct imx_int_pll_rate_table imx8mm_fracpll_tbl[] = {     PLL_1443X_RATE(1000000000U, 250, 3, 1, 0),     PLL_1443X_RATE(933000000U, 311, 4, 1, 0),     PLL_1443X_RATE(900000000U, 300, 2, 2, 0),     PLL_1443X_RATE(800000000U, 200, 3, 1, 0),     PLL_1443X_RATE(750000000U, 250, 2, 2, 0),     PLL_1443X_RATE(650000000U, 325, 3, 2, 0),     PLL_1443X_RATE(600000000U, 300, 3, 2, 0), // 2400Mbps     PLL_1443X_RATE(594000000U, 99, 1, 2, 0),     PLL_1443X_RATE(400000000U, 400, 3, 3, 0),     PLL_1443X_RATE(266000000U, 266, 3, 3, 0),     PLL_1443X_RATE(167000000U, 334, 3, 4, 0),     PLL_1443X_RATE(100000000U, 200, 3, 4, 0), }; PLL output calculator formula is : PLL_out = 24MHz*mdiv/pdiv/(2^sdiv) So, 2400MHz * 300 / 3 / 2^2 = 600MHz   6. Test result Non Enable SS Enable SS with 1% MR and Down spread Enable SS with 2% MR and Down spread Enable SS with 2% MR and Center spread  

Some customer need to run Zephyr on i.MX8QM CM4, but there is no support on Zephyr mainline(v4.3.0). This article will share the i.MX8QM CM4_0 porting based on Zephyr v4.3.0.  For i.MX8QXP CM4, please refer this link: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QXP-CM4-support-on-Zephyr-v4-3-0/ta-p/2296957   samples/hello_world/ samples/synchronization   Add pd_ignore_unused in bootargs before entering Linux. For the OpenAMP communication, need to refer this Zephyr application. https://github.com/nxp-real-time-edge-sw/heterogeneous-multicore/blob/main/apps/rpmsg_str_echo/zephyr/main.c

Some customer need to run Zephyr on i.MX8QXP CM4, but there is no support on Zephyr mainline(v4.3.0) This article will share the porting based on Zephyr v4.3.0. For i.MX8QM CM4, please refer this link: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QM-CM4-0-support-on-Zephyr-v4-3-0/ta-p/2296962   samples/hello_world/ samples/synchronization Add pd_ignore_unused in bootargs before entering Linux. For the OpenAMP communication, need to refer this Zephyr application. https://github.com/nxp-real-time-edge-sw/heterogeneous-multicore/blob/main/apps/rpmsg_str_echo/zephyr/main.c

The purpose of this document is to provide extended guidance for selection of compatible LPDDR4 memory devices that are supported by the Ara240 (aka Ara-2) processors. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the specific SoC requirement documents. LPDDR4 - maximum supported densities SoC Max Data bus width Maximum density Number of Interfaces Assumed memory organization Notes Ara240 64-bit 128Gb/16GB 2 Dual rank, Dual channel device with 17-row addresses 1   LPDDR4 - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Memory Vendor Validated Memory Part# Notes Ara240 64Gb/(8GB) Total 128Gb/(16GB) (2 x 64Gb/8GB) Micron   MT53E2G32D4DE-046 AUT:C  MT53E2G32D4DE-046 WT:C - 64Gb/(8GB) Total 128Gb/(16GB) (2 x 64Gb/8GB)   FORESEE FLXC4008G-30  2 16Gb/(2GB) Total: 32Gb/(4GB) (2 x 16Gb/2GB) Micron MT53E512M32D1ZW-046BAUT:B     - 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB)   Micron MT53E1G32D2NP-046 WT:B - 16Gb/(2GB) Total: 32Gb/(4GB) (2 x 16Gb/2GB) SK Hynix H54G46CYRQX053N - 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB) SK Hynix H54G56CYRB-X247 421Y H54G56CYRB-X247 316A - 4Gb/(512MB) Total 8Gb/1GB (2 x 4Gb/1GB) SK Hynix H54G26AYRBX256 - 16Gb/(2GB) Total: 32Gb/(4GB) (2 x 16Gb/2GB) Samsung K4F6E3S4HB-KHCL      - 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB) ISSI IS43LQ32K01B 2 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB) Samsung K4UBE3D4AB-MGCL - 8Gb/(1GB) Total 16Gb/2GB (2 x 8Gb/1GB)   Winbond W66DP2RQQAHJ 2   Note: This device supports operation with LPDDR4 memories only. LPDDR4x operation is not supported. Dual‑mode memories that support both LPDDR4 and LPDDR4x are allowed as long as the device can operate in LPDDR4 mode, including using LPDDR4 I/O voltage levels and initialization sequences.   Note 1: The numbers are based purely on the IP documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, SoC reference manual and on the JEDEC standards JESD209-4C (LPDDR4). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 3: Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. Note 4: All memory parts are in production unless stated otherwise. Checked June 2026 Note 5: The processor does not support BYTE Mode (x8) memories.       

Platform supported Kinara Ara2: imx95frdm imx8mpfrdm In this article, let's take imx8mpfrdm as example.   1. Create a Debian LSDK2512 release system for SD boot using the command below: $ ./flex-installer -i pf -d /dev/sdX $./flex-installer -b boot_IMX_arm64_lts_6.12.20.tar.zst -f firmware_imx8mpfrdm_sdboot.img -d /dev/sdX -m imx8mpfrdm -r rootfs_lsdk2512_debian_imx8mpevk.tar.zst note: if Debian base rootfs is used, please upgrade to full function Debian rootfs first. 2. Insert SD card on imx8mpfrdm and boot the system. Once the system has completed booting and you reach the kernel prompt: $ date -s "20260101 1100" // set date $ set proxy if needed 3. download rt-sdk-ara2.deb at: https://nxp1.sharepoint.com/:u:/r/teams/ext1081/Shared%20Documents/LF_v6.12.34/Debian%20Packages/r1.3/Package%201/rt-sdk-ara2.deb?csf=1&web=1&e=i4x1zD 4. Get the uiodma.ko kernel module for Debian from NXP. 5. Disable sleep when install package: $ systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target 6. Prepare the packages ARA2 needed: $ apt update $ apt install --reinstall -y libc6-dev $ ln -sf /usr/include/aarch64-linux-gnu/sys /usr/include/sys $ apt install -y python3-dev build-essential $ e2fsck -f /dev/mmcblk1p2 7. install Ara2 package: $ dpkg -i rt-sdk-ara2.deb The tail of successful log as follows： ... [ 783.892116] Adding 2097148k swap on /swapfile. Priority:-2 extents:17 across:35913728k SS /swapfile none swap sw 0 0 Swap file of 2G configured and enabled successfully. Enable rt-sdk-ara2.service service... Created symlink '/etc/systemd/system/multi-user.target.wants/rt-sdk-ara2.service' → '/etc/systemd/system/rt-sdk-ara2.service'. rt-sdk-ara2.service has been enabled. To stop the service from starting automatically on boot run: systemctl disable rt-sdk-ara2.service Post-install script completed successfully. 8. overwrite the kernel module: $ cp /root/uiodma.ko /root/kinara/rt_sdk_r1.3/art/linux/drivers/uiodma_cache_management/uiodma.ko $ systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target // re-enable sleep 9. reboot the system： $ reboot You will see the log as bellow: ... [ 57.855988] bash[1492]: +----------+-----------------+ [ 57.856188] bash[1492]: | Product | Current Version | [ 57.856297] bash[1492]: +----------+-----------------+ [ 57.856397] bash[1492]: | firmware | 1.1.2.0 | [ 57.856501] bash[1492]: | proxy | 1.3.0.0 | [ 57.856593] bash[1492]: | sysapi | 1.1.61.0 | [ 57.856695] bash[1492]: +----------+-----------------+ [ 57.856788] bash[1492]: [I:20260109:09:02:44:636750] [DeviceManager] [kinara_main_1479][DeviceManager] [ 57.856894] bash[1492]: +------------+--------------------+ [ 57.857019] bash[1492]: | Product | Supported Versions | [ 57.857124] bash[1492]: +------------+--------------------+ [ 57.857227] bash[1492]: | client_lib | 1.0.0.0 | [ 57.857327] bash[1492]: | client_lib | 1.1.1.0 | [ 57.857419] bash[1492]: | client_lib | 1.1.2.0 | [ 57.857525] bash[1492]: | client_lib | 1.3.0.0 | [ 57.857642] bash[1492]: | cnn_model | 2.0.0.0 | [ 57.857741] bash[1492]: | cnn_model | 2.1.0.0 | [ 57.857833] bash[1492]: | firmware | 0.5.2.0 | [ 57.857931] bash[1492]: | firmware | 1.1.2.0 | [ 57.858030] bash[1492]: | llm_model | 3.0.0.0 | [ 57.858129] bash[1492]: | llm_model | 3.1.0.0 | [ 57.858222] bash[1492]: | pci_driver | 1.0.4.0 | [ 57.858322] bash[1492]: | pci_driver | 1.0.6.6 | [ 57.858421] bash[1492]: | proxy | 0.8.0.0 | [ 57.858533] bash[1492]: | proxy | 0.9.0.0 | [ 57.858633] bash[1492]: | proxy | 1.1.1.0 | [ 57.858732] bash[1492]: | proxy | 1.3.0.0 | [ 57.858823] bash[1492]: +------------+--------------------+ [ 57.858930] bash[1492]: 2026-01-09 09:02:44 - Proxy launched succesfully [ 58.752944] bash[1514]: 2026-01-09 09:02:45 - Hardware bringup is done (1 device(s) configured) and proxy is launched successfully in the background. [ 58.755142] bash[392]: Logs saved in: /root/kinara/rt_sdk_r1.3/saved_logs/rt-sdk-ara2_logs.txt Now, enjoy your AI journey.