i.MX Processors Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Sort by:
Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with MMDC initialization. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP validation boards.
View full article
(DEPRECATED. Please check this document for Real Time Streaming) A server can be streaming video and a client, in this case a i.MX6 target, is receiving and decoding it. For example, a server with GStreamer and a web camera connected, can be streaming with the following command: $ # Pipeline 1 $ gst-launch v4l2src ! 'video/x-raw-yuv, format=(fourcc)I420, width=(int)1280, height=(int)800' ! ffenc_mpeg4 ! tcpserversink host=$CLIENT_IP port=$PORT and on the target, the client receives, decodes and display with $ # Pipeline 2 $ gst-launch tcpclientsrc host=$SERVER_IP port=$PORT  ! 'video/mpeg, width=(int)1280, height=(int)800, framerate=(fraction)10/1, mpegversion=(int)4, systemstream=(boolean)false' ! vpudec ! mfw_isink The filter caps between the tcpclientsrc and the decoder (vpudec) depend on the sink caps coming from the server encoder (ffenc_mpeg4), so these may change depending on your needs. Running the above pipelines require the environment variables SERVER_IP, CLIENT_IP and PORT. In case you want the i.MX6 to act as a server, just change the video source (either mfw_v4lsrc of v4l2src) and the encoder (vpuenc), so $ # Pipeline 3 $  gst-launch v4l2src  !  'video/x-raw-yuv, format=(fourcc)I420, width=(int)640, height=(int)480, interlaced=(boolean)false, framerate=(fraction)10/1'  ! vpuenc ! tcpserversink host=$CLIENT_IP port=$PORT For testing purposes, set SERVER_IP=127.0.0.1, CLIENT_IP=127.0.0.1 and PORT=500, and run pipeline 3 and 2 in two different consoles. Check with 'top' the  CPU usage and see that VPU is actually doing most of the work.
View full article
The article has just been published by EDN website, under “Design Center” and “BBS” channels. Here is the coverage: 如何灵活使用飞思卡尔i.MX应用处理器的GPIO http://bbs.ednchina.com/FORUM_POST_30_529551_0.HTM http://www.ednchina.com/ART_8800518371_15_20034_AN_20f46fd3.HTM Title translation: How to easily use the GPIO of Freescale i.MX processors. If you are interested in the post and would like to have reply in English, please contact the owner of this post.
View full article
This is the procedure and patch to set up Ubuntu 13.10 64bit Linux Host PC and building i.MX28 L2.6.35_1.1.0_130130. It has been tested to build GNOME profile and with FSL Standard MM codec. A) Basic Requirement: Set up the Linux Host PC using ubuntu-13.10-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC $ sudo apt-get update $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 $ sudo apt-get install libc6-dev-i386 $ sudo apt-get install u-boot-tools $ sudo apt-get install scrollkeeper $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd $ sudo ln -s /usr/lib/x86_64-linux-gnu/librt.so   /usr/lib/librt.so C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L2.6.35_1.1.0_130130_source.tar.gz $ ./L2.6.35_1.1.0_130130_source/install After that, you will find ~/ltib directory created D) Apply the patch to make L2.6.35_1.1.0_130130 could be installed and compiled on Ubuntu 13.10 64bit OS $ cd ~/ltib $ git apply 0001_make_L2.6.35_1.1.0_130130_compile_on_ubuntu_13.10_64bit_OS.patch What the patch is doing: a) The patch modifies the following files: dist/lfs-5.1/base_libs/base_libs.spec dist/lfs-5.1/elftosb/elftosb.spec dist/lfs-5.1/lkc/lkc.spec dist/lfs-5.1/mux_server/mux_server.spec dist/lfs-5.1/ncurses/ncurses.spec b) Add the following files to the pkgs directory: pkgs/elftosb-2.6.35.3-1385779630.patch pkgs/elftosb-2.6.35.3-1385779630.patch.md5 pkgs/lkc-1.4-lib.patch pkgs/lkc-1.4-lib.patch.md5 E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib Reference: L2.6.35_1.1.0_130130_docs/doc/mx28/Setting_Up_LTIB_Host_on_Ubuntu_9_04.pdf https://community.freescale.com/docs/DOC-93394 https://community.freescale.com/message/332385#332385 https://community.freescale.com/thread/271675 https://community.freescale.com/message/360556#360556 scrollkeeper is for the gnome-desktop compilation elftosb compilation issue fixed by added -lm to LIBS in the elftosb-2.6.35.3-1.1.0/makefile.rules NOTE: When compiling gstreamer, this warning was pop up.  Just ignore it seems okay.
View full article
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]
View full article
This page describes how to determine the NAND timing parameters for use in the NAND driver. This is independent of any OS that may be used. Analyzing NAND Datasheets  We use a spreadsheet to capture and analyze NAND features. That spreadsheet is [attached to this wiki page|Adding support for a new NAND with i.MX28– Nand Analysis^nand_analysis_template.xls]. We analyze a NAND as described below. We must have the NAND datasheet to do the analysis. Copy the *analysis spreadsheet* to a new filename with the exact part number(s) of the NAND(s) being analyzed. Fill in sheet 1 ("Cover Page") of the analysis spreadsheet. Work on sheet 3 next: Fundamental Features. Other tables. If the NAND is one of a family listed together in a data sheet, then analyze the whole family with one spreadsheet. You can use the "Similar to" rows for the additional members of the family. Add more rows if needed. Most NANDs have an asyncrhronous interface, so there is not a simple clock frequency involved. Instead, there are various setup times, hold times, and output delays that imply limits on the I/O rate to/from the NAND. The spreadsheet compares the NAND's timing specifications to see if sums of the setup, hold, and output times are shorter than the minimim read-cycle or write-cycle times. The spreadsheet is specifically intended for use with the Nand controller in STMP378x/i.MX233/i.mx28 chips, so the spreadsheet performs the timing calculations with the goal of deriving the timing parameters *TSU*, *TDS*, and *TDH* for those CPUs. If the TDS and/or TDH quantities {color:#ff0000}turn red{color} after all the timings have been computed, then the computed TDS and/or TDH are too short for the specified cycle-time of the NAND. In that case:           You will have to increase one or both of them in the software. Write a note somewhere in the analysis spreadsheet about the values that you choose, but don't mess up the automatic computations. Record how the flash denotes factory-marked bad-blocks. (Some use the first page of a block, some use the last page,, etc.) Compare it to this [current superset of bad-block marking methods [http://wiki.freescale.net/display/PSGSW/Storage+Media%2C+Flash+Bad+Block+Marks] used to detect any flash factory bad block. Example Analysis Examples of NAND datasheets and analyses can be found on the [Hynix NAND Page | http://wiki.freescale.net/display/PSGSW/Hynix+NAND+Flash+Documents].
View full article
  The mfgtool is the tool download the images to i.MX series of applications processors. It’s convenient and easy use to download the images to your board. About its introductions, work flow and use guide you can see details in the Document file of mfgtool. If customers use our reference boards, they can directly use the default mfgtools we supply for every version BSP and board. But when customers design board and do porting with our i.MX series processors. As they do many changes from our reference board, they need to rebuild the images for their board and for the download tool mfgtool. In the old version BSP, take the L3.0.35_4.1.0_130816 version as an example. When finishing porting the BSP for design board. Run the following command line to generate the manufacturing firmware. ./ltib --profile config/platform/imx/updater.profile --preconfig config/platform/imx/imx6q_updater.cf --continue –batch For android BSP Android4.2.2, one can use the follow command: make distclean make mx6dl_sabresd_mfg_config make In the newest BSP, for linux BSP in yocto use the command: $ bitbake fsl-image-mfgtool-initramfs For the newest android BSP, the command” make mx6dl_sabresd_mfg_config” can not use anymore. So how to get the \Profiles\Linux\OS Firmware\firmware\u-boot-imx6dlsabresd_sd.imx? The easiest way that you can use the u-boot you build for your board, and in the newest BSP, mfgtool can use the same u-boot with the normal u-boot for your board. You do not need to build the u-boot for mfgtool separately. They can use the same one. Hope this can do some help for you.
View full article
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
View full article
This document is a user guide for the GStreamer version 1.0 based accelerated solution included in all the i.MX 8 family SoCs supported by NXP BSP L5.4.24_1.1.0. Some instructions assume a host machine running a Linux distribution, such as Ubuntu, connected to i.MX 8 device. These commands were tested using Ubuntu 18.04 LTD, and while Ubuntu is not required on the host machine, other distributions have not been tested. These instructions are targeted for use with the following hardware: • i.MX 8MQ EVK • i.MX 8MN EVK • i.MX 8MN EVK • i.MX 8QXP MEK B0 • i.MX 8QM MEK B0   Release History v1.0 - Mar 2020 - Initial release. v2.0 - Sep 2020: Added the following content: - Mux/Demux Examples - Audio Examples - Image Examples - Transcode Examples - Streaming Examples - Multi-Display Examples - Scaling and Rotation Examples - Zero-copy Examples - Debug Examples Maintainers: . Marco Franchi . Pedro Jardim
View full article
How to connect i.MX51 and Ubuntu using USB cable: i.MX51 Side Plug in USB cable. getprop debug.adb.usb - Shows that debug.adb.usb are not set by default setprop persist.service.adb.enable 0 -> disable adb setprop debug.adb.usb 1 - adb will be through USB (for Ethernet, use setprop debug.adb.usb 0) setprop persist.service.adb.enable 1 -> enable adb Example: # getprop debug.adb.usb  # # # setprop persist.service.adb.enable 0 disabling adb # adb_release android_usb gadget: high speed config #1: android setprop debug.adb.usb 1 # # setprop persist.service.adb.enable 1 enabling adb # adb_open adb_release adb_open android_usb gadget: high speed config #1: android # Ubuntu Side On Ubuntu side, the most important tip is regarding permission. ADB server MUST be started with root right. Example of right mistake: $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb devices List of devices attached ????????????    no permissions  $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb shell error: insufficient permissions for device How to proceed to get permission: $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb kill-server $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb start-server * daemon not running. starting it now * * daemon started successfully * $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb devices List of devices attached 0123456789ABCDEF    device  $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb shell ADB over Ethernet/Wi-Fi To make ADB work in i.MX51 using TCP: In your host machine: - Install Android SDK - export ADBHOST=BOARD_IP (setenv ADBHOST=xxx.xxx.xxx.xxx) - adb kill-server In your board: - make sure that ro.secure property is *not* set when the adbd daemon is launched, so edit the file default.prop - make sure that /dev/android_adb or /dev/android do *not* exist - stop adbd - start adbd Now you will be able to list the device: hamilton@saygon:/opt/work/androidsdk/android-sdk-linux_86/tools$ ./adb kill-server hamilton@saygon:/opt/work/androidsdk/android-sdk-linux_86/tools$ ./adb devices * daemon not running. starting it now * * daemon started successfully * List of devices attached emulator-5554   device
View full article
The Linux L4.1.15_2.0.3 Patch for i.MX 6ULL@900MHz Release is now available on www.nxp.com. BSP Updates and Releases -> Linux -> Linux 4.1.15_2.0.3 Patch.   Files available: # Name Description 1 L4.1.15_2.0.3_6ULL_patch_images.tar.gz i.MX 6ULL-EVK@900MHz Linux Binary Demo Files   Information of release, see: README: http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-4.1-krogoth ChangeLog: http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/ChangeLog?h=imx-4.1-krogoth
View full article
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.  
View full article
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
View full article
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?
View full article
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=tflite int8=True   Notes: The model must be exported in TFLite format and quantized to INT8. 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.
View full article
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
View full article
  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
View full article
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  
View full article
Background: This article discusses the reboot mechanism on the i.MX8MP and i.MX93 platforms. It aims to help customers understand how the reboot command works. We will discuss two different kernel versions separately.   1. Linux version : LF_6.12.34_2.1.0 The executable file for the reboot command is as follows: When the ”reboot“ command is executed, the system enters the ”do_kernel_restart()“ function and executes the reboot mechanism by determining the priority of the registered functions. Since the ”reboot.c“ file does not print out the registered functions, a print function is added to the file to identify the function that is ultimately executed.   The print output is as follows: As shown in the figure above, in version 5.12, the reboot is performed via a reset executed by psci. Continuing to trace the ”psci_sys_reset()“ function, we can see that the system sends the function ID via the PSCI interface to initiate an SMC call, instructing the underlying firmware (ATF/EL3) to perform a system reboot (typically a cold reset). The value of PSCI_0_2_FN_SYSTEM_RESET is 0x80000009   According to the Arm Power State Coordination Interface Platform Design Document, this ID represents a cold reset of the system.     2. Linux version : LF_6.18.2_1.0.0 Use the same debugging method to examine the reboot mechanism in version 6.18 As shown in the output below, in version 6.18, the system reset is triggered by the `sys_off_notify()` function. The final execution function is pca9450_i2c_restart_handler()   By examining the `pca9450_i2c_restart_handler()` function, we can see that the system writes a `SW_RST_COMMAND` value to the PMIC via I²C, where `SW_RST_COMMAND = 0x14`. According to the PMIC data sheet, 10b = Cold Reset; all voltage regulators are reset except LDO1/LDO2   Summary: Regardless of the kernel version, the `reboot` command triggers a system cold reset. The triggering mechanism has been updated in versions 6.18 and later.
View full article
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.
View full article