This article describes a Full-Bridge PCIe reference design that connects an NXP i.MX95 SoC (acting as PCIe Root Complex) to a Lattice CertusPro-NX / Certus-NX FPGA endpoint, together with a Linux kernel driver. Updating the FPGA bitstream over PCIe is demonstrated as the reference use case, built on top of a general-purpose PCIe data-transfer, register-access and MSI-completion interface. Hardware Host / Root Complex: NXP i.MX95 SoC running Linux (DesignWare PCIe controller) FPGA target / endpoint: Lattice CertusPro-NX PCIe Bridge board (Device ID  0x9C25 ) or Certus-NX (Device ID  0x9C1D ) — Lattice Vendor ID  0x1204 PCIe link: 1-lane (x1), single BAR (BAR1) design Interrupt: 1 MSI vector, EP→Host completion signalling   hemantagrawal_0-1788853274669.jpeg   board_photo.jpg Architecture The host application talks to the FPGA through the  kernel driver. The driver exposes BAR1 as a character device and manages two host-side DMA-coherent buffers. Because the design is a full bridge, both sides can initiate PCIe transactions: the host issues MWr/MRd to BAR1, and the FPGA (as bus master) issues its own MWr/MRd back into host memory. hemantagrawal_1-1788853274491.png   arch_diagram.png   Block Role Application (userspace) Issues IOCTLs; supplies payload and DMA target addresses Driver  lattice_nxp_pcie_ep.c BAR1 MMIO window, SRC/DST DMA buffers, MSI completion, char device  /dev/lattice_nxp_pcie_bar1 FPGA (CertusPro-NX / Certus-NX) PCIe endpoint; executes command, performs MRd/MWr, raises MSI on completion Host memory DMA-coherent SRC and DST buffers   What the driver covers The kernel module is a general-purpose PCIe endpoint transport, not a bitstream-specific driver. It contains no bitstream or image parsing — bitstream update is simply the reference application layered on top of these primitives. It provides three planes: FPGA→Host DMA path (EP-initiated bulk transfer): two host DMA-coherent buffers (SRC/DST, default 4 KB, tunable up to 1 MB). The host fills SRC, programs the FPGA SRC/DST mailbox registers and rings a doorbell; the FPGA (bus master) then moves data via its own MRd/MWr and writes results into the host DST buffer. Usable for any payload. Host↔FPGA BAR1 MMIO window: the char-device  read() / write()  path exposes the whole BAR1 aperture as an 8-byte-granular, byte-addressable window ( readq / writeq , or paired  readl / writel  on 32-bit) for register/RAM access and MWr+MRd readback tests. Control + completion plane: arbitrary 32-bit BAR1 register read/write by offset (the "command" and "doorbell" registers are conventions the application chooses), plus MSI-based completion notification (atomic counter + wait/poll IOCTLs). In short, it is a generic data-transfer + register-access + interrupt-notification interface. Bitstream loading is one application built on it; any host↔FPGA bulk transfer or register-control workflow uses the same primitives.   Driver overview —  Probe & init: enable the PCIe device and set bus master → configure the DMA mask (32-bit default, 64-bit fallback) → map BAR1 MMIO → allocate SRC + DST coherent DMA buffers → allocate 1 MSI vector → register  /dev/lattice_nxp_pcie_bar1 . IOCTL interface (9 commands): Command Di r  Description IOCTL_GET_INFO R Return BAR1 size, SRC/DST DMA handles, MSI IRQ number IOCTL_FILL_SRC W Copy userspace buffer into the SRC DMA buffer IOCTL_CLEAR_DMA – Zero the DST DMA buffer before a transfer IOCTL_READ_DMA R Read back bytes from the DST DMA buffer after the FPGA copy IOCTL_WAIT_MSI W Block until the next MSI fires (with  timeout_ms ) IOCTL_WAIT_MSI_SINCE W Block until  msi_count  exceeds a given baseline (race-free) IOCTL_GET_MSI_COUNT R Read the current MSI interrupt counter (atomic u64) IOCTL_WRITE_REG W Write one 32-bit MMIO register in BAR1 by offset IOCTL_READ_REG R Read one 32-bit MMIO register from BAR1 by offset   Driver internals BAR1 read/write paths:  pcie_read()  /  pcie_write()  expose BAR1 as a char device. Accesses must be 8-byte aligned; 64-bit uses  readq / writeq , 32-bit uses paired  readl / writel . MSI ISR:  pcie_isr()  atomically increments  msi_count  and wakes the wait-queue, unblocking  WAIT_MSI  /  WAIT_MSI_SINCE  callers. Verbosity level 2 logs each interrupt with its running count. iATU resync workaround ( FORCE_SYNC_IATU  on probe, the driver clears and then restores the root-port Memory Base/Limit registers to force the DesignWare PCIe block to rebuild its inbound iATU translation table. This is required after an FPGA reconfiguration + PCIe remove + rescan cycle. The macro can be commented out if the workaround is not needed. Note that this alters the upstream port and can affect other PCIe devices on the same bus. Vendor ID:  0x1204   |  Device IDs:  0x9C25  (CertusPro-NX),  0x9C1D  (Certus-NX). Module parameters Parameter Type / default / perm Description verbose int / 1 / 0644 0 = minimal (critical errors only); 1 = info (probe steps, DMA sizes, MSI events); 2 = chatty (all IOCTL calls, read/write rejections, MSI interrupts) dma_bits int / 32 / 0644 DMA address width for coherent-buffer allocation. 32 = default (most platforms); 64 = use if probe fails with  -ENOMEM  (-12) on a 32-bit mask dma_buf_bytes uint / 4096 / 0644 Size (bytes) of each DMA coherent buffer (SRC and DST). Min 256, default 4096 All three parameters are adjustable at load time;  verbose  and  dma_bits  can also be changed at runtime via sysfs.   Known limitations — unsupported PCIe transaction types Configuration Read (CfgRd0 / CfgRd1) — PCIe TLP Type 0/1 config reads are not supported Configuration Write (CfgWr0 / CfgWr1) — PCIe TLP Type 0/1 config writes are not supported Legacy I/O Read (IORd) — x86-style I/O reads are not supported; no I/O BARs are mapped Legacy I/O Write (IOWr) — x86-style I/O writes are not supported; all access goes through BAR1 MMIO Supported: Memory Read (MRd), Memory Write (MWr), and MSI interrupt signalling via the BAR1 mailbox. Reference lattice_nxp_pcie_ep.c  — Linux kernel PCIe EP driver

i.MX95 Triple Display Patches for LF-6.6.52-2.2.0 BSP. iMX95 19x19 EVK. qiang_limpu_se_0-1739859470230.png     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: qiang_limpu_se_0-1739858854733.png For 1 MIPI DSI + 2 LVDS Interleave mode: qiang_limpu_se_2-1739859096402.png     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   2026-9-7 update: Add patch for L6.18.37_2.1.0 BSP based on FRDM-IMX95.  

This document analyzes IMX95 supported TSN protocols such as 802.1Qav, 802.1Qbv, 802.1Qbu and 802.1Qci, and introduces use cases design to implement these protocols on I.MX95 platform.

Market Demand: Due to the inclusion of the Linux Kernel, Android Framework, Vehicle HAL, CarService, and numerous IVI applications, the traditional cold start time of the Android Automotive system is typically long, making it difficult to meet the user experience requirements of "power on and ready to use" in automobiles. Proposed Solution: The Hibernate (Suspend-to-Disk) solution significantly shortens startup time by saving a snapshot of the system's runtime and restoring it to its running state upon the next power-on, while preserving the state of applications such as navigation,music, and Bluetooth. Hardware and software platforms for implementing Hibernate : HW: i.MX95 B0 19*19 EVK SW: Android auto imx-automotive-15.0.0_2.1.0 Lunch device : lunch evk_95_car2-nxp_stable-userdebug  

Background: The i.MX95 introduces a system manager firmware, which is responsible for power, clock, resource isolation, security management, and system-level control between kernels, essentially acting as the "backend manager" for the entire SoC. Switching between different driver modes is necessary to change the VDD_SOC voltage of the i.MX 95. But, Unlike the i.MX 93, the i.MX 95 does not support DVFS and the i.MX 95 has only one fixed DDR frequency point., it is not possible to switch between OD, ND, and LD modes under userspace. This article will explain how to switch from OD to ND mode.   1. Test environment HW: i.MX95 EVK board SW: imx-oei, imx-sm 2. Voltage and frequency of i.MX 95 series processors in different modes The voltage VDD_SOC varies in different modes. pengyong_zhang_2-1787043053405.pngMaximum frequency of i.MX 95 series processor modules in different modes. pengyong_zhang_1-1787043037623.png 3. Code change(Switching to ND mode as an example) 3.1. imx-sm https://github.com/nxp-imx/imx-sm/blob/master/boards/mcimx95evk/sm/brd_sm.c#L107 index 077fa06..023a580 100755 --- a/boards/mcimx95evk/sm/brd_sm.c +++ b/boards/mcimx95evk/sm/brd_sm.c @@ -104,7 +104,7 @@      BRD_SM_REC_VLD_MASK)  /* Performance parameters */ -#define BOARD_PERF_LEVEL  DEV_SM_PERF_LVL_ODV  /* Target perf level */ +#define BOARD_PERF_LEVEL  DEV_SM_PERF_LVL_NOM  /* Target perf level */  #if BOARD_VOLT_SOC >= ES_ODV_UV_VDD_SOC  #define BOARD_BOOT_LEVEL  DEV_SM_PERF_LVL_ODV  /* Boot perf overdrive */  #elif BOARD_VOLT_SOC >= ES_NOM_UV_VDD_SOC diff --git a/configs/mx95evk.cfg b/configs/mx95evk.cfg index 8ac5392..5f19d42 100755 --- a/configs/mx95evk.cfg +++ b/configs/mx95evk.cfg @@ -459,7 +459,7 @@ PD_A55C2            stop=5  PD_A55C3            stop=4  PD_A55C4            stop=3  PD_A55C5            stop=2 -PERF_A55            start=3|3 +PERF_A55            start=3|2  CPU_A55C0           start=4  CPU_A55P            stop=1 @@ -473,7 +473,7 @@ PD_A55C2            msel=1, stop=5  PD_A55C3            msel=1, stop=4  PD_A55C4            msel=1, stop=3  PD_A55C5            msel=1, stop=2 -PERF_A55            msel=1, start=3|3 +PERF_A55            msel=1, start=3|2  CPU_A55C0           msel=1, start=4  CPU_A55P            msel=1, stop=1 @@ -487,7 +487,7 @@ PD_A55C2            msel=2, stop=5  PD_A55C3            msel=2, stop=4  PD_A55C4            msel=2, stop=3  PD_A55C5            msel=2, stop=2 -PERF_A55            msel=2, start=3|3 +PERF_A55            msel=2, start=3|2  CPU_A55C0           msel=2, start=4  CPU_A55P            msel=2, stop=1 diff --git a/configs/mx95evk/config_lmm.h b/configs/mx95evk/config_lmm.h index 3e3f508..999a4a1 100755 --- a/configs/mx95evk/config_lmm.h +++ b/configs/mx95evk/config_lmm.h @@ -152,11 +152,11 @@      {.lmId = 2U, .mSel = 1U, .ss = LMM_SS_PD, .rsrc=DEV_SM_PD_A55P}, \      {.lmId = 2U, .mSel = 2U, .ss = LMM_SS_PD, .rsrc=DEV_SM_PD_A55P}, \      {.lmId = 2U, .mSel = 0U, .ss = LMM_SS_PERF, .rsrc=DEV_SM_PERF_A55, \ -     .numArg = 1, .arg[0] = 3U, }, \ +     .numArg = 1, .arg[0] = 2U, }, \      {.lmId = 2U, .mSel = 1U, .ss = LMM_SS_PERF, .rsrc=DEV_SM_PERF_A55, \ -     .numArg = 1, .arg[0] = 3U, }, \ +     .numArg = 1, .arg[0] = 2U, }, \      {.lmId = 2U, .mSel = 2U, .ss = LMM_SS_PERF, .rsrc=DEV_SM_PERF_A55, \ -     .numArg = 1, .arg[0] = 3U, }, \ +     .numArg = 1, .arg[0] = 2U, }, \      {.lmId = 2U, .mSel = 0U, .ss = LMM_SS_CPU, .rsrc=DEV_SM_CPU_A55C0}, \      {.lmId = 2U, .mSel = 1U, .ss = LMM_SS_CPU, .rsrc=DEV_SM_CPU_A55C0}, \      {.lmId = 2U, .mSel = 2U, .ss = LMM_SS_CPU, .rsrc=DEV_SM_CPU_A55C0}, 3.2. imx-oei Add the timing.c file for different DRAM frequencies under different modes to the following file, and then recompile imx-oei: https://github.com/nxp-imx/imx-oei/tree/master/boards/mx952lp5-19/ddr pengyong_zhang_1-1787035595967.png 4. Boot log: The boot log shows that the CPU frequency had dropped to 1404MHz at this point. pengyong_zhang_3-1787035619561.png Note: Ensure that you are using the DRAM timing.c file corresponding to the specified mode and that the compilation is error-free. To guarantee a complete error-free compilation, it is recommended to create a new timing.c file in the directory corresponding to imx-oei, complete the configuration in the Makefile, and then compile. Do not completely overwrite the contents of the current timing.c file. For instructions on how to use Config Tool and how to update the timing.c file, please refer to the Config Tool User Guide.  

In this post, we will review the YOLO model export process for three popular NXP families: i.MX8MP, i.MX93, and i.MX95. These processors are increasingly used in edge AI applications such as smart vision, industrial automation, robotics, and intelligent HMI systems. Although they all support machine learning deployment, the export path, supported runtimes, and hardware acceleration options may differ depending on the device. The purpose of this guide is to provide a clearer starting point for developers who want to take a trained YOLO model and prepare it for execution on these i.MX platforms. Whether your workflow targets CPU, NPU. YOLO Model Export Workflow for i.MX Processors 1) Install Ultralytics Install or upgrade the Ultralytics package from PyPI: pip install -U ultralytics   2) Export the YOLO Model (TFLite INT8) Export your trained YOLO model to TensorFlow Lite (TFLite) format with INT8 quantization: yolo export model=<your_model>.pt format=saved_model quantize=8 Example: yolo export model=yolov8n.pt format=saved_model quantize=8   Notes: The model must be exported in TFLite format and fully INT8 quantized. After the export process, a directory named "<your_model>_saved_model" Inside this directory, you should use the following file as the input for the converter called "<your_model>_full_integer_quant.tflite"  This is the fully quantized INT8 model required for NPU deployment. Using any other file from the export directory may result in compatibility issues or prevent proper NPU acceleration. After obtaining the *_full_integer_quant.tflite file, you can proceed with the needed conversion workflow to generate the final model optimized for execution on the NPU. For additional valid export options, please refer to the official Ultralytics documentation: https://docs.ultralytics.com/modes/export/ At this stage: The model can run on CPU for: i.MX8MP i.MX93 i.MX95 On i.MX8MP, this TFLite model can also be deployed to the NPU using the appropriate delegate. 3) i.MX93  Compile for Ethos-U NPU (Vela) For i.MX93, an additional compilation step is required to use the Ethos-U NPU. Run the Vela compiler to convert the TFLite model into an optimized format: vela <model>.tflite --output-dir <output_folder> Notes: This step generates a model optimized for the Ethos-U NPU. The resulting output files are required for deployment using the NPU delegate on the i.MX93 platform. Please ensure that the model complies with the Ethos-U operator constraints, as only supported operations can be accelerated by the NPU. This command can be executed directly on the i.MX93 target, or alternatively by using the eIQ Toolkit (please refer to the eIQ Converter documentation for more details). 4)  i.MX95 Convert Model Using Neutron SDK For i.MX95, the model must be converted using the Neutron Converter, depending on the BSP version installed on your board. .\neutron-converter.exe ` --input "<model>.tflite" ` --target imx95 ` --output "<model_neutron>.tflite" ` --optimization-level OOpt Notes: The Neutron toolchain prepares the model for i.MX95 NPU acceleration. Supported formats and flags may vary depending on the Neutron SDK version. Always verify compatibility with your BSP release. You can check the compatibility details of the Neutron SDK in the "docs" folder of your downloaded Neutron SDK package.   5) Benchmark the Model After exporting and converting the model, you can validate performance using benchmarking tools. Typical options include: TFLite benchmark tool (CPU / delegate): benchmark_model --graph=<model>.tflite --num_threads=X 6) Results iMX8MP CPU root@imx8mpevk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant.tflite --mum_threads=4 INFO: STARTING! WARN: Unconsumed cmdline flags: --mum_threads=4 INFO: Log parameter values verbosely: [0] INFO: Graph: [yolov8n_full_integer_quant.tflite] INFO: Signature to run: [] INFO: Loaded model yolov8n_full_integer_quant.tflite INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 3.42652 INFO: Initialized session in 86.368ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=1 curr=1029584 p5=1029584 median=1029584 p95=1029584 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=986237 curr=985536 min=983921 max=993982 avg=985863 std=1497 p5=984152 median=985947 p95=986715 INFO: Inference timings in us: Init: 86368, First inference: 1029584, Warmup (avg): 1.02958e+06, Inference (avg): 985863 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=11.207 overall=40.918 root@imx8mpevk:~#   NPU root@imx8mpevk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant.tflite --num_threads=4 --external_delegate_path=/usr/lib/libvx_delegate.so INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [4] INFO: Graph: [yolov8n_full_integer_quant.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [4] INFO: #threads used for CPU inference: [4] INFO: External delegate path: [/usr/lib/libvx_delegate.so] INFO: Loaded model yolov8n_full_integer_quant.tflite INFO: Vx delegate: allowed_cache_mode set to 0. INFO: Vx delegate: device num set to 0. INFO: Vx delegate: allowed_builtin_code set to 0. INFO: Vx delegate: error_during_init set to 0. INFO: Vx delegate: error_during_prepare set to 0. INFO: Vx delegate: error_during_invoke set to 0. INFO: EXTERNAL delegate created. INFO: Explicitly applied EXTERNAL delegate, and the model graph will be completely executed by the delegate. INFO: The input model file size (MB): 3.42652 INFO: Initialized session in 39.515ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=1 curr=16831746 p5=16831746 median=16831746 p95=16831746 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=67167 curr=67190 min=67048 max=67366 avg=67187 std=64 p5=67094 median=67184 p95=67295 INFO: Inference timings in us: Init: 39515, First inference: 16831746, Warmup (avg): 1.68317e+07, Inference (avg): 67187 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=9.47266 overall=224.398 root@imx8mpevk:~# iMX93 CPU root@imx93evk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant.tflite --num_threads=2 INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [2] INFO: Graph: [yolov8n_full_integer_quant.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [2] INFO: #threads used for CPU inference: [2] INFO: Loaded model yolov8n_full_integer_quant.tflite INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 3.42652 INFO: Initialized session in 57.963ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=3 first=247896 curr=198973 min=198973 max=247896 avg=215381 std=22991 p5=198973 median=199275 p95=247896 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=199533 curr=198880 min=197719 max=205262 avg=199032 std=1005 p5=198344 median=198886 p95=199961 INFO: Inference timings in us: Init: 57963, First inference: 247896, Warmup (avg): 215381, Inference (avg): 199032 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=11.2539 overall=40.9961 root@imx93evk:~#   NPU root@imx93evk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant_vela.tflite --num_threads=2 --external_delegate_path=/usr/lib/libethosu_delegate.so INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [2] INFO: Graph: [yolov8n_full_integer_quant_vela.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [2] INFO: #threads used for CPU inference: [2] INFO: External delegate path: [/usr/lib/libethosu_delegate.so] INFO: Loaded model yolov8n_full_integer_quant_vela.tflite INFO: Ethosu delegate: device_name set to /dev/ethosu0. INFO: Ethosu delegate: cache_file_path set to . INFO: Ethosu delegate: timeout set to 60000000000. INFO: Ethosu delegate: enable_cycle_counter set to 0. INFO: Ethosu delegate: enable_profiling set to 0. INFO: Ethosu delegate: profiling_buffer_size set to 2048. INFO: Ethosu delegate: pmu_event0 set to 0. INFO: Ethosu delegate: pmu_event1 set to 0. INFO: Ethosu delegate: pmu_event2 set to 0. INFO: Ethosu delegate: pmu_event3 set to 0. INFO: EXTERNAL delegate created. INFO: EthosuDelegate: 8 nodes delegated out of 15 nodes with 8 partitions. INFO: Explicitly applied EXTERNAL delegate, and the model graph will be partially executed by the delegate w/ 8 delegate kernels. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 2.9511 INFO: Initialized session in 638.148ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=7 first=87215 curr=81264 min=81079 max=87215 avg=82056.4 std=2107 p5=81079 median=81187 p95=87215 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=81497 curr=81232 min=80887 max=81783 avg=81153.1 std=178 p5=80921 median=81148 p95=81497 INFO: Inference timings in us: Init: 638148, First inference: 87215, Warmup (avg): 82056.4, Inference (avg): 81153.1 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=7.36328 overall=8.73828 root@imx93evk:~# iMX95 CPU root@imx95evk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant.tflite --num_threads=6 INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [6] INFO: Graph: [yolov8n_full_integer_quant.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [6] INFO: #threads used for CPU inference: [6] INFO: Loaded model yolov8n_full_integer_quant.tflite INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 3.42652 INFO: Initialized session in 35.268ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=7 first=115073 curr=74468 min=74170 max=115073 avg=80310.4 std=14192 p5=74170 median=74581 p95=115073 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=74143 curr=74135 min=73657 max=76392 avg=74346.9 std=447 p5=73829 median=74307 p95=75020 INFO: Inference timings in us: Init: 35268, First inference: 115073, Warmup (avg): 80310.4, Inference (avg): 74346.9 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=11.5195 overall=40.8867 root@imx95evk:~# NPU: root@imx95evk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant_neutron.tflite --num_threads=6 --external_delegate_path=/usr/lib/libneutron_delegate.so INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [6] INFO: Graph: [yolov8n_full_integer_quant_neutron.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [6] INFO: #threads used for CPU inference: [6] INFO: External delegate path: [/usr/lib/libneutron_delegate.so] INFO: Loaded model yolov8n_full_integer_quant_neutron.tflite INFO: EXTERNAL delegate created. INFO: NeutronDelegate delegate: 1 nodes delegated out of 33 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-7399a58e, zerocp enabled. INFO: Explicitly applied EXTERNAL delegate, and the model graph will be partially executed by the delegate w/ 1 delegate kernels. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 3.20989 INFO: Initialized session in 12.756ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=17 first=31509 curr=27588 min=27555 max=31509 avg=29101.2 std=1166 p5=27555 median=29071 p95=31509 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=28068 curr=29081 min=26573 max=31340 avg=29104.1 std=1204 p5=27306 median=29141 p95=31171 INFO: Inference timings in us: Init: 12756, First inference: 31509, Warmup (avg): 29101.2, Inference (avg): 29104.1 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=6.98438 overall=12.2344 root@imx95evk:~ Disclaimer: Ultralytics YOLO models have not been officially validated/supported by NXP. Therefore, compatibility with i.MX processors and their corresponding NPUs cannot be guaranteed. Some models or configurations may not work as expected depending on operator support and hardware limitations.

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: Media.jpg 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 JorgeCas_0-1782324986101.png Once this script have been executed you can see the USB port in ALSA as a sink/source device: JorgeCas_2-1782325559529.png Then, you need to connect the USB port to a host computer and will be recognized as an USB interface: JorgeCas_4-1782325847685.png You can validate that the device is working according to the configuration defined in setup script: Screenshot 2026-07-29 104314.png I will use Audacity to test audio transfer from on board microphones, in Edit -> Preferences -> Audio settings select i.MX Active as recording device: JorgeCas_5-1782326183462.png 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: JorgeCas_0-1782327009216.png 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: JorgeCas_3-1782325608663.png 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. Rita_Wang_0-1783441433568.png     Details in the naming rules: Rita_Wang_1-1783441433666.png   For the operating ranges in our datasheet can see the details: Rita_Wang_2-1783441433728.png   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. Rita_Wang_3-1783441433750.png   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 Rita_Wang_4-1783441433771.png   /* 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

The layer attached to this article is obsolete. Please use the meta-imx-fastboot GitHub repo instead.   The purpose of this article is to show how to reduce the boot time on i.MX 8QXP using U-Boot Falcon Mode. The general technique is presented in the AN14093. This article was tested on LF-6.6.23-2.0.0 BSP. How to do it 1. Follow the steps in the i.MX Yocto Project User's Guide and prepare your Yocto building environment. We will further assume that the BSP is in the ~/imx-yocto-bsp directory and the build directory is ~/imx-yocto-bsp/build. 2. Unpack the attached archive in ~/imx-yocto-bsp/sources. This should create the ~/imx-yocto-bsp/sources/meta-imx-fastboot directory.  3. Add the meta-imx-fastboot layer to your build using the following command: bitbake-layers add-layer ~/imx-yocto-bsp/sources/meta-imx-fastboot 4. If you've previously built an image in the same tree, clean the u-boot-imx and imx-boot packages using the following command: bitbake -c clean u-boot-imx imx-boot 5. Build the new image. Out of the box, this package is configured for core-image-minimal. We will show you below how to adapt it for other images: bitbake core-image-minimal 6. Write the resulted image on eMMC/SD using your preferred method and boot the board. 7. By default, the board will boot normally. To enable fast boot, stop the board in U-Boot, and run the following command: u-boot => run prepare_fdt 8. Reboot the board. From this point on, the board should boot in fast mode. Far less messages will be printed by the kernel or systemd during boot. You may further optimize the boot time by removing unnecessary features from the kernel and/or removing unnecessary services started by systemd. Please refer to AN14093. 9. If you ever want to re-enter U-Boot, please keep the 'c' key pressed in the serial console during board power-on. It's easiest if you press and keep the 'c' key pressed before powering on/pressing the reset button. How it works The layer we've added contains patches for U-Boot, ATF and imx-mkimage. In addition, it modifies the core-image-minimal recipe. In U-Boot, the necessary options for Falcon Mode are added in a new configuration file, named imx8qxp_mek_falcon_defconfig, as well as an implementation of the spl_start_uboot() function. In ATF, the device tree load address is added in the correct parameter. In mkimage, two new targets are created: kernel-atf-container.img (to be deployed in the boot partition) and uImage (to be deployed in the rootfs). The change in the core-image-minimal recipe ensures that the new files are copied in the resulting image. If you want to build a different image, you need to copy the content of core-image-minimal.bbappend in a new file, named according to the image you want to build. For example, if you want to build imx-image-full, you could use the following command: cp ~/imx-yocto-bsp/sources/meta-imx-fastboot/recipes-fsl/images/core-image-minimal.bbappend ~/imx-yocto-bsp/sources/meta-imx-fastboot/recipes-fsl/images/imx-image-full.bbappend       *** 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.

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 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

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.       

The i.MX95 EVK features an M.2 Key E slot, typically used for WiFi/BT combo cards. While plugging in a module is straightforward, understanding how the PCIe link actually comes up require diving into hardware signals, firmware initialization, and software enumeration.  In this blog, we will: - 1. Examine the M.2 Key E physical connector and identify PCIe signals on it. 2. Understand what those PCIe signals do and why are they needed? 3. What could be the possible routes while debugging PCIe in a system?

Hardware:​  Soc: NXP i.MX 93 11x11 EVK FPGA:​ Lattice ECP5 Evaluation Board winteri_wang_0-1730257820139.jpg   Deploy the driver of FlexSPI and Test​​ Apply below patch into Linux kernel and compile. (6.1.55-2.2.0 is tested)​ git apply 0001-Added-flexspi-fpga-module-support-of-i.MX93.patch​ make imx_v8_defconfig​ make –j8​ Copy the generated imx93-11x11-evk-flexspi-m2-fpga.dtb to the boot partition​ Set the dtb in uboot​ setenv fdtfile imx93-11x11-evk-flexspi-m2-fpga.dtb ​ saveenv​ boot​ Copy the generated imx93_flexspi_fpga.ko and the test app source file flexspi_fpga_latency_test.c to home directory Run blow command to do the test​ gcc flexspi_fpga_latency_test.c​ ./a.out 128​ ​ winteri_wang_1-1730258385765.jpg About driver and test app​ ​The driver can be installed in test app automatically. Insmod command is called in test app as below.​ insmod imx93_flexspi_fpga.ko mux=1 div=30​ The parameter mux can be set to 0,1,2,3. Means 24MHz, 1000MHz, 800MHz, 625MHz root clock. And div is the divider. In default, 1000/30 = 33MHz is applied. More details of hardware connection: Since the adapter board is not on NXP website and it is just for test, there are two options. Use fly-wire to connect flexspi and lattice fpga instead of the adapter card. Use M.2 adapter card but need be produced by customer themselves.  If M.2 adapter is not used, fly-wire can be applied to connect i.MX93 to FPGA. The column of Pads is a pad list that can bring out signal lines from the bottom layer of i.MX93 EVK. i.MX 93 Pads of imx93 FPGA ECP5 SD3_CLK TP912 B10 SD3_CMD TP913 A9 SD3_DATA0 TP914 D8 SD3_DATA1 TP915 E8 SD3_DATA2 TP916 C7 SD3_DATA3 TP917 C6 GND   GND J1003-2 1V8   VCCIO0 Remove JP10 Jumper   winteri_wang_0-1742217018655.jpeg It is also possible that the customer would choose M.2 adapter card solution. The adapter card is simple and cheap. It can be redesigned easily with attached schematic as reference. Make sure the board thickness is 0.8mm. And recommend to apply GND copper to improve signal quality. The schematic is attached. To get the information about the demo from Lattice perspective, please check the link below. Lattice QSPI to NXP MPU Reference Design | Lattice Reference Design  

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