Voltage overshoot (>1.8V) is found on VDD_ARM_SSOC_IN when the EVK board is powered down by POWER BUTTON long pressed after the Linux kernal loaded. It would not happen if only U-boot is run. It happens also when the system recovers from idle. The overshoot is out of i.MX6UL maximum rating.

The document includes the following contents: (1)document how to port ov5646 to android jb4.2.2 (2) ov5645 driver for Linux 3.0.35 (3) ov5645 schematic based on i.MX6Q/DL (4)ov5645 for android camera HAL   [Note:]      P5V29A-0JG is a camera module based on OV5645, and PAO532-0JG is based on OV5640, both manufactured by NINGBO SUNNY OPOTECH CO.LTD (China), If customer wants to use them on i.MX6 platform, can send me email to ask for datasheets of P5V29A & PAO532 , or discuss corresponding questions on porting.   Email: [email protected]

ERR005723           PCIe: PCIe does not support L2 Power Down   Description: When PCIe works as Root Complex, it can exit L2 mode only through reset. Since PCIe doesn't have a dedicated reset control bit, it cannot exit L2 mode.   Projected Impact: PCIe does not support L2 Power Down   Workarounds: The PCIe can be put in PDDQ mode to save on PCIe PHY power and wakeup only by the OOB (Out of Band) wakeup signal (since wakeup by a beacon from link partner is not supported) driven from the link partner (End Point). This signal could be used as a GPIO interrupt to exit this mode. The limitation of this workaround is that the link partner cannot be put into L2.   Proposed Solution:                 No fix scheduled   Linux BSP Status:                 No software workaround available   SW workaround used to fix ERR005723 in Linux BSP Why the original workarounds can’t be implemented in Linux BSP * PCIe controller doesn’t have the reset mechanism that can be used when re-insmod the PCIe driver without power down/up PCIe module. * During the PCie driver rmmod/insmod operations, the PCIe CLKs would be turned off/on. IC can’t guarantee that the PCIe PHY can work well and re-establish the PCIe link properly. One SIMPLE SW workaround for this errata imx: pcie: toggle bit18 of grp1 fix pcie can't exit L2 issue.   Set bit18 of gpr1 before enter into supend, and clean it after resume, can fix the following errata. Errata ERR005723_PCIe PCIe does not support L2 Power Down. About the details, please refer to the attached patch. "0001-imx-pcie-toggle-bit18-of-grp1-fix-pcie-can-t-exit-L2.patch"   The conception of the other SW workaround (System warm-reset) The procedures of the original suspend/resume. Suspend User suspend command echo mem > /sys/power/state All driver call suspend function SRPG,  ARM save all state to memory Enter Stop mode and Power down ARM Resume: GPC receive IRQ Wake up system Power on ARM domain. ROM code running Jump to SRPG point Recovery ARM status from memory Call all devices resume function. Because PCIe only reset by system reset, we need change above follow. Resume: GPC receive IRQ Wake up system Power on ARM domain. ROM code running Jump to SRPG point Warm Reset system, memory context will be kept. But all peripheral status lost. ROM code running Jump to SRPG point again. Recovery ARM status from memory Call all devices resume function. Resume function call init to initialize it.  And recover to the status saved before. Impact: Can’t support usb remote wake up, which required 4ms responsive Longer latency, warm reset need some ms.  The recovery of the device status needs some more ms. Risk: Current BSP have not tested above follow Device driver have not supported this follow yet. Need additional work to enable \debug\test it. Modules enabled in this workaround now: * UART* ENET* PCIe Tests procedure. HW: one i.MX6Q SD boards, and one INTEL pciex1 1000M CT network card. SW(The images used by me are attached): * Apply the attached patches(kernel and uboot) to the kernel/uboot source codes, re-build, get the images. Kernel is based on imx_3.0.35_4.0 release, uboot , is based on imx_v2009.08 # build out SD/MMC and USB driver to make DRAM hibernate work # build pcie in. *procedure of the suspend/resume tests;     # unload ep's driver --> suspend/resume --> reload ep's driver. NOTE: Please make sure that the command line contains “no_console_suspend”The command used to enable the console input wake up after login the consol:echo enabled > /sys/devices/platform/imx-uart.0/tty/ttymxc0/power/wakeup Log when the INTEL CT 1G network card is used: -------------------------------log--------------------------------------------PM: Syncing filesystems ... done.                                             start suspendFreezing user space processes ... (elapsed 0.01 seconds) done.Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.add wake up source irq 101add wake up source irq 99add wake up source irq 103add wake up source irq 51add wake up source irq 58PM: suspend of devices complete after 15.482 msecsPM: late suspend of devices complete after 0.823 msecsDisabling non-boot CPUs ...CPU1: shutdownCPU2: shutdownCPU3: shutdownIMX PCIe imx_pcie_pltfm_suspend entering.IMX PCIe imx_pcie_pltfm_suspend exit.          suspendedU-Boot 2009.08-00679-g6ec6783 (May 20 2013 - 14:50:20)     resumeCPU: Freescale i.MX6 family TO1.2 at 792 MHzsrc 0x92eac8resume 0x92eac8jump to resumeIMX PCIe imx_pcie_pltfm_resume entering.IMX PCIe imx_pcie_pltfm_resume pcie start re-link.IMX PCIe port imx_pcie_pltfm_resume: re-link up.Enabling non-boot CPUs ...CPU1: Booted secondary processorCalibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU1 is upCPU2: Booted secondary processorCalibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU2 is upCPU3: Booted secondary processorCalibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU3 is up PM: early resume of devices complete after 0.974 msecs remove wake up source irq 58 imx-ipuv3 imx-ipuv3.0: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7) imx-ipuv3 imx-ipuv3.1: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7) remove wake up source irq 51 remove wake up source irq 103 remove wake up source irq 101 remove wake up source irq 99 PM: resume of devices complete after 54.174 msecs Restarting tasks ... done. PHY: 1:01 - Link is Up - 100/Full                            resume is ok, reload ep’s driver num is 61 e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2 e1000e: Copyright(c) 1999 - 2011 Intel Corporation. e1000e 0000:01:00.0: Disabling ASPM L0s e1000e 0000:01:00.0: (unregistered net_device): Failed to initialize MSI-X interrupts.  Falling back to MSI interrupts. e1000e 0000:01:00.0: (unregistered net_device): Failed to initialize MSI interrupts.  Falling back to legacy interrupts. e1000e 0000:01:00.0: eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:3a:18:8b e1000e 0000:01:00.0: eth1: Intel(R) PRO/1000 Network Connection e1000e 0000:01:00.0: eth1: MAC: 3, PHY: 8, PBA No: E42641-005 e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: seq=0 ttl=64 time=3.126 ms 64 bytes from 192.168.0.1: seq=1 ttl=64 time=0.244 ms 64 bytes from 192.168.0.1: seq=2 ttl=64 time=0.232 ms 64 bytes from 192.168.0.1: seq=3 ttl=64 time=0.206 ms 64 bytes from 192.168.0.1: seq=4 ttl=64 time=0.222 ms 64 bytes from 192.168.0.1: seq=5 ttl=64 time=0.207 ms 64 bytes from 192.168.0.1: seq=6 ttl=64 time=0.250 ms 64 bytes from 192.168.0.1: seq=7 ttl=64 time=0.209 ms 64 bytes from 192.168.0.1: seq=8 ttl=64 time=0.154 ms 64 bytes from 192.168.0.1: seq=9 ttl=64 time=0.211 ms   --- 192.168.0.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 0.154/0.506/3.126 ms PM: Syncing filesystems ... done.                                   ep’s functions are ok, re-do the suspend/resume tests Freezing user space processes ... (elapsed 0.01 seconds) done. -------------------------------end-------------------------------------------- Original Attachment has been moved to: uboot_patch_image.zip Original Attachment has been moved to: 0001-imx-pcie-toggle-bit18-of-grp1-fix-pcie-can-t-exit-L2.patch.zip Original Attachment has been moved to: kernel_patch_image.zip

Overview The document describes the procedure to measure the memory to memory copy performance by using SDMA on i.MX6Q. Materials i.MX6Q Sabre SD board L3.0.35_4.1.0_130816 BSP Procedure Install BSP and build kernel Extract imx unit test source: ./ltib -p imx-test -m prep Apply attached patch to sdma memcopy code cd ltib/rpm/BUILD/imx-test-3.0.35-4.1.0 patch -p1 -i LTIB_4.1.0_sdma_m2m_test.patch Build imx unit test ./ltib -p imx-test -f Copy kernel and rootfs to SD Card. Boot kernel and login Insert the kernel module for SDMA memory copy test: insmod /lib/modules/XXX/test/mxc_sdma_memcopy_test.ko Start SDMA memory copy test /unit_tests/mxc_sdma_test.out Result root@freescale ~$ insmod /lib/modules/3.0.35-2666-gbdde708-g1c42f8b/test/mxc_sdma_memcopy_test.ko SDMA test major number = 248 SDMA test Driver Module loaded root@freescale ~$ /unit_tests/mxc_sdma_test.out in dma_m2m_callback 65532byte / 0.003382sec buffer 1 copy passed! root@freescale ~$ /unit_tests/mxc_sdma_test.out in dma_m2m_callback 65532byte / 0.003367sec buffer 1 copy passed! root@freescale ~$ /unit_tests/mxc_sdma_test.out in dma_m2m_callback 65532byte / 0.003364sec buffer 1 copy passed! In summary, > 19Mbyte/sec

 

We are pleased to announce that Config Tools for i.MX 26.09 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.09 Framework Added support for downloading all boards associated with a processor when downloading the processor. DDR tool Added support for i.MX 937 Added DDR3 support for i.MX 8MP FRDM board Added support for i.MX93W FRDM and EVK boards at 3600 MT/s Enabled PMIC PF9453 support for i.MX 91 Minor improvements, enhancements, and bug fixes SerDes tool Added support for i.MX 952 System Manager Multiple validation ID issues are resolved. DDR tool – NXP-validated memory configurations for multiple vendors is available System Manager – extended CLI support for a headless setting      

Enabling a 2-Channel CAN HAT (MCP2515) on the NXP i.MX93 FRDM Board   This article documents the process of adding hardware support for a 2-Channel CAN HAT from WaveShare using dual Microchip MCP2515 controllers over SPI on the NXP i.MX93 FRDM evaluation board. By default, the board exposes native FlexCAN interfaces, but utilizing a popular Raspberry Pi-compatible CAN HAT requires customizing the Linux device tree and kernel configuration.   Prerequisites   Hardware: NXP i.MX93 FRDM board, 2-Channel CAN HAT. Software: NXP Linux BSP (Tested in 6.18.y). Toolchain: Toolchain obtained from Yocto (Refer to the 4.5.12 How to build U-Boot and Kernel in standalone environment from i.MX Linux User's Guide).   Step 1: Modify the Device Tree   We need to edit the main board device tree file  arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts  to configure the SPI master, add the dual MCP2515 nodes, assign interrupt pins, and disable conflicting native interfaces. The key changes:   Power Regulators: Ensured the expansion connectors ( VEXP_3V3 and VEXP_5V ) correctly pull up and preserve state using pinctrl-assert-gpios . Fixed Clock: Defined an external 16MHz clock element required by the MCP2515 crystal oscillators. FlexCAN Deactivation: Disabled conflicting native flexcan2 nodes sharing pins. LPSPI3 Configuration: Replaced the default spidev dummy node with two microchip,mcp2515 nodes, adding two distinct Chip Select (CS) pins ( GPIO2_IO08 and GPIO2_IO07 ) and mapping the respective hardware interrupts ( GPIO2_IO23 and GPIO2_IO25 ). Device Tree Git Diff: diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts index 18afe964e020..7b3af73f144f 100644 --- a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts @@ -134,6 +134,7 @@ reg_vexp_3v3: regulator-vexp-3v3 { compatible = "regulator-fixed"; regulator-name = "VEXP_3V3"; gpio = <&pcal6524 2 GPIO_ACTIVE_HIGH>; + pinctrl-assert-gpios = <&pcal6524 2 GPIO_ACTIVE_HIGH>; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; enable-active-high; @@ -144,6 +145,7 @@ reg_vexp_5v: regulator-vexp-5v { compatible = "regulator-fixed"; regulator-name = "VEXP_5V"; gpio = <&pcal6524 8 GPIO_ACTIVE_HIGH>; + pinctrl-assert-gpios = <&pcal6524 8 GPIO_ACTIVE_HIGH>; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; enable-active-high; @@ -269,6 +271,15 @@ K3: user_btn2 { interrupts = <6 IRQ_TYPE_EDGE_FALLING>; }; }; + + clocks { + clk16m: clk16m { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <16000000>; + clock-output-names = "clk16m"; + }; + }; }; &adc1 { @@ -292,7 +303,7 @@ &flexcan2 { pinctrl-0 = <&pinctrl_flexcan2>; pinctrl-1 = <&pinctrl_flexcan2_sleep>; xceiver-supply = <&reg_can2_stby>; - status = "okay"; + status = "disabled"; }; &mu1 { @@ -620,15 +631,29 @@ typec1_dr_sw: endpoint { &lpspi3 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_lpspi3>; - cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>; - pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>; + cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>, <&gpio2 7 GPIO_ACTIVE_LOW>; + pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_LOW>; status = "okay"; - spidev0: spi@0 { + can0: can@0 { + compatible = "microchip,mcp2515"; reg = <0>; - compatible = "lwn,bk4"; - spi-max-frequency = <1000000>; + clocks = <&clk16m>; + interrupt-parent = <&gpio2>; + interrupts = <23 IRQ_TYPE_LEVEL_LOW>; + spi-max-frequency = <10000000>; }; + + can1: can@1 { + compatible = "microchip,mcp2515"; + reg = <1>; + clocks = <&clk16m>; + interrupt-parent = <&gpio2>; + interrupts = <25 IRQ_TYPE_LEVEL_LOW>; + spi-max-frequency = <10000000>; + }; + + }; &lpuart1 { /* console */ @@ -894,9 +919,12 @@ MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e pinctrl_lpspi3: lpspi3grp { fsl,pins = < MX93_PAD_GPIO_IO08__GPIO2_IO08 0x39e + MX93_PAD_GPIO_IO07__GPIO2_IO07 0x39e MX93_PAD_GPIO_IO09__LPSPI3_SIN 0x39e MX93_PAD_GPIO_IO10__LPSPI3_SOUT 0x39e MX93_PAD_GPIO_IO11__LPSPI3_SCK 0x39e + MX93_PAD_GPIO_IO23__GPIO2_IO23 0x39e + MX93_PAD_GPIO_IO25__GPIO2_IO25 0x39e >; };   After modifying the file, compile your device tree blobs (.dtb) and deploy them to your target boot partition. You can refer to the below post to know the process: How to compile Linux Kernel Image and device tree using Yocto SDK.   Step 2: Enable Kernel Driver Support   The MCP251x driver must be enabled within the Linux kernel configuration framework. Run the configuration tool: user@host:~/linux-imx$ make menuconfig   Navigate through the menu to enable the driver either statically ( [*] ) or as a module ( [M] 😞 [*] Networking support <*> CAN bus subsystem support <*> Raw CAN Protocol (raw access with CAN-ID filtering)   <*> Broadcast Manager CAN Protocol (with content filtering) <*> CAN Gateway/Router (with netlink configuration) And: Device Drivers [*] Network device support <*> CAN Device Drivers CAN SPI interfaces <*> Microchip MCP251x and MCP25625 SPI CAN controllers <*> Microchip MCP251xFD SPI CAN controllers   Save your configuration and compile your kernel/modules.   Step 3: Initialize and Test Interfaces   Once the board boots with the new device tree and kernel, you should see two new network interfaces listed under ip link show ( can0 and can1 ).   Now, you can setup the CAN interfaces: $ sudo ip link set can0 up type can bitrate 1000000 $ sudo ip link set can1 up type can bitrate 1000000 $ sudo ifconfig can0 txqueuelen 65536 $ sudo ifconfig can1 txqueuelen 65536   Connect the HAT in loopback:     From Interface can0: candump can0   From interface can1: cansend can1 000#11.22.33.44         Hope this can be helpful.   Best regards, Salas.        

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   Board Connection 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. Driver Architecture 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

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. Maximum frequency of i.MX 95 series processor modules in different modes. 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 4. Boot log: The boot log shows that the CPU frequency had dropped to 1404MHz at this point. 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.  

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.  

Updates i.MX 93 Reference Manual Rev. 7. 

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

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.

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

As part of the patches attached with this blog, we will relay the pcie write transaction from Endpoint-A to Endpoint-B connected to iMX95FRDM PRO.   Linux-imx used - lf-6.18.2-1.0.0 Attached are the following files:-   imx95-19x19-frdm-pro-pcie0-ep-dtbs - EP A shall use the dtb built with this dtbs imx95-19x19-frdm-pro-pcie1-ep-dtbs - EP B shall use the dtb built with this dtbs rc_pcie_dma_relay.c - driver used on RC to relay pcie write from EP-A to EP-B conf_pcie0.sh - script to be executed on Endpoints A and B to configure the EPF driver //To build the dtb and relay kernel driver 1. git clone  git clone https://github.com/nxp-imx/linux-imx.git git checkout origin/lf-6.18.y 2. Copy the dtbs to arch/arm64/boot/dts/freescale/ Copy rc_pcie_dma_relay.c to drivers/pci/   3. Make the following changes as per this diff   diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile index aa3cfdf1aafc..56e3db653208 100644 --- a/arch/arm64/boot/dts/freescale/Makefile +++ b/arch/arm64/boot/dts/freescale/Makefile @@@ -1205,6 +1205,16 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm-8mic-reve.dt    dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro.dtb imx95-19x19-frdm-pro-aud-hat.dtb   + +dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro-pcie0-ep.dtb +dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro-pcie1-ep.dtb + +imx95-19x19-frdm-pro-pcie0-ep-dtbs := imx95-19x19-frdm-pro.dtb \ +                      imx95-19x19-frdm-pro-pcie0-ep.dtbo + +imx95-19x19-frdm-pro-pcie1-ep-dtbs := imx95-19x19-frdm-pro.dtb \ +                      imx95-19x19-frdm-pro-pcie1-ep.dtbo +  imx95-19x19-frdm-pro-os08a20-isp-dtbs := imx95-19x19-frdm-pro.dtb \                                          imx95-19x19-frdm-pro-os08a20.dtbo  dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-frdm-pro-os08a20-isp.dtb     4. Add the following to drivers/pci/Makefile +obj-m      += rc_pcie_dma_relay.o   5. Trigger the kernel build. You will obtain rc_pcie_dma_relay.ko, imx95-19x19-frdm-pro-pcie0-ep.dtb and imx95-19x19-frdm-pro-pcie1-ep.dtb. 6. We are only using pcie0 M.2 Key M slots of Endpoint A and Endpoint B so you only need to upload this dtb to both the endpoint boards - imx95-19x19-frdm-pro-pcie0-ep.dtb and boot linux with it after passing 'iommu.passthrough=1' at uboot mmcargs. This is to disable smmu for our tests. RC will boot with the default dtb - imx95-19x19-frdm-pro.dtb 7. Connect the Endpoint-A to RC's K1 via M.2 Key M to Key M cable. Similarly connect the other Endpoint-B to other RC's K2 M.2 slot via Key M to Key M cable. 8. Execute this script on both the endpoints - ./conf_pcie0.sh 9. Then reboot the RC iMX95 FRDM Pro and ensure that you see both the endpoints:-   0000:01:00.0 and 0001:01:00.0 are the enumerated endpoints. 10. Upload rc_pcie_dma_relay.ko to the RC board and insert it like this:-  insmod rc_pcie_dma_relay.ko src_phys=0x910100000 dst_phys=0xa10100000 relay_len=0x100000 chunk_len=0x10000 you will observe similar logs on dmesg:-   [ 4949.082087] rc_pcie_dma_relay: init src=0x910100000 dst=0xa10100000 len=1048576 chunk=65536 [ 4949.082150] rc_pcie_dma_relay src_before: [0]=0xdeadbeef [1]=0xdeadbeef [2]=0xdeadbeef [3]=0xdeadbeef [ 4949.082171] rc_pcie_dma_relay dst_before: [0]=0x00000000 [1]=0x00000000 [2]=0x00000000 [3]=0x00000000 [ 4949.125779] rc_pcie_dma_relay dst_zeroed: [0]=0x00000000 [1]=0x00000000 [2]=0x00000000 [3]=0x00000000 [ 4949.141380] rc_pcie_dma_relay src_after: [0]=0xdeadbeef [1]=0xdeadbeef [2]=0xdeadbeef [3]=0xdeadbeef [ 4949.141427] rc_pcie_dma_relay dst_after: [0]=0xdeadbeef [1]=0xdeadbeef [2]=0xdeadbeef [3]=0xdeadbeef [ 4954.272981] rc_pcie_dma_relay: verify OK for 1048576 bytes [ 4954.273000] rc_pcie_dma_relay: DMA relay verify PASSED   11. Finally, via devmem5 on RC, you can verify the data of EP-A transferred to EP-B  ./devmem5 r 0xa10100000 w  

As part of this brief blog, we are enabling Asymmetric Multiprocessing (AMP) boot support for the Cortex-M7 core on the i.MX8MP SoC device model in Qemu. The M7 firmware can be loaded and started from Linux running on the Cortex-A53 cores via the remoteproc framework.

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