Q:Is there an issue using odd DIV_SELECT values? When setting the CPU clock (maybe others also) in uboot, the code will only use even valuesfor the DIV_SELECT field. There is nothing in the Reference Manual or Errata that indicates only even values can be used for this field. There were 2 SR's that had conflicting answers and we are trying to determine what can be used. The CPU freq setting trying to be achieved is 996MHz. With a 24MHz source, you need 24MHz x 41.5 = 996MHz. Since the DIV_SELECT is x2, a value of 83 would be needed. A: Below is the DIV_SELECT description of ARM PLL, since the Fin is 24MHz, so there is no odd issue of DVI_SELECT, as 24 / 2 = 12MHz. Such as for 996M, this value is 83, that is fine. "This field controls the pll loop divider. Valid range for divider value: 54-108. Fout = Fin * div_select/2.0." This document was generated from the following discussion: mx6Q PLL Setting

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.

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

We are pleased to announce that Config Tools for i.MX v25.12 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...) DDR tool – Support for detecting multiple boards connected to the host system is added. – Automatic detection and selection of newly connected COM ports is implemented. – A Connection Test option to validate connectivity before running tests on the target is introduced. – i.MX 93 EVK LP4 configuration is added. – Training execution time information for i.MX 95 and i.MX 943 is included in logs. – Bus signal naming in the UI to align with i.MX pin naming conventions is consolidated. – CA bus values for i.MX943 with LPDDR4 are updated. – DRAM density calculation for i.MX 95 and i.MX 943 with LP4/4x is corrected. – Incorrect calculation of number of banks for i.MX 8M with DDR3L is fixed. – CS1_BNDs calculation for i.MX 91 is corrected. SerDes tool – i.MX 943 RFP support is added. System Manager – The ability to export user configuration in the CFG format is added. – Information about atomic resources to the Details view is added. – Generation and configuration of the config_fusa.h file is supported. – Resource and template assignment is improved. – Grayed-out resource assignments for unavailable configuration parameters in the Resources view are implemented. – Validation of configuration and user input is improved. – Problem decorators to the System and Boot view are added. – Design of the Boot and Details view is improved. – 5600 MT/s for i.MX 95 and i.MX 943 with LPDDR5 is enabled. – LP4/4x settings for DDR_SDRAM_ZQ_CNTL for i.MX 95 and i.MX 943 are updated. – Dual-rank configurations for i.MX 91 and i.MX 93 are updated. – LP4/4x configuration to support non-binary densities for i.MX 95 and i.MX 943 is updated. – Support for non-binary aligned LP4 density for i.MX 91 is added. – FRDM board support (LPDDR4X 15x15 at 4000 MT/s) for i.MX 95 is added. – Timing file discrepancies for i.MX 8MN with DDR3L are fixed. – Issue where changing PHY log level did not update generated code is fixed.

This article describes how to create a tiny rootfs based on BusyBox.   Test platform: i.MX 95 19x19 LPDDR5 EVK. The attached layer can be used with other platforms as well. Software: Linux BSP 6.12.34-2.1.0 Boot device: SD card   This article provides a custom meta-tiny-rootfs layer, to simplify the enablement. The layer: creates a custom distribution based on Poky, with no extra features creates a custom image based on BusyBox that only starts a terminal removes most of the machine features uses musl, instead of glibc   Using the default DISTRO=fsl-imx-wayland and core-image-minimal, the rootfs size is 800MB. Using the custom DISTRO=tiny-rootfs and core-image-tiny, the rootfs size reduces to 2.6MB.   How to? 1. Prepare the Yocto environment according to Section 3, 4, 5 in i.MX Yocto Project User's Guide. In the next commands, we'll assume the Yocto directory is imx-yocto-bsp, and the build directory is build. 2. Configure the build directory: cd ~/imx-yocto-bsp/ DISTRO=fsl-imx-wayland MACHINE=imx95-19x19-lpddr5-evk source ./imx-setup-release.sh -b build Note: The imx-setup-release.sh script accepts only Wayland distributions. We'll set the custom distro at the next step. 3. Set the custom distro. In the build directory, run: echo 'DISTRO = "tiny-rootfs"' >> conf/local.conf 4. Download the meta-tiny-rootfs archive, and extract it into the ~/imx-yocto-bsp/sources directory. cd ~/imx-yocto-bsp/sources tar -xvf meta-tiny-rootfs.tar.gz 5. Add the meta-tiny-rootfs layer to BBLAYERS: cd ~/imx-yocto-bsp/build bitbake-layers add-layer ../sources/meta-tiny-rootfs 6. Build the core-image-tiny image. bitbake core-image-tiny 7. Write the image on an SD card, and boot. You should be able to see a similar log: [ 6.183401] Run /sbin/init as init process init started: BusyBox v1.37.0 () starting pid 163, tty '': '/bin/mount -t proc proc /proc' starting pid 164, tty '': '/bin/mount -t sysfs sysfs /sys' starting pid 165, tty '': '/bin/mount -t devtmpfs devtmpfs /dev' mount: mounting devtmpfs on /dev failed: Resource busy starting pid 166, tty '': '/bin/mount -o remount,rw /' [ 6.246037] EXT4-fs (mmcblk1p2): re-mounted a5abac39-6c11-419f-97ef-86532e2616ad. starting pid 167, tty '': '/bin/mkdir -p /dev/pts' starting pid 168, tty '': '/bin/mount -t devpts devpts /dev/pts' starting pid 169, tty '': '/bin/mount -a' starting pid 170, tty '': '/sbin/swapon -a' starting pid 176, tty '': '/etc/init.d/rcS' starting pid 177, tty '/dev/ttyLP0': '/usr/sbin/ttyrun ttyLP0 /sbin/getty 115200 ttyLP0' Tiny Rootfs Operating System 1.0.0 imx95-19x19-lpddr5-evk /dev/ttyLP0 imx95-19x19-lpddr5-evk login:   How to add additional features?  If you want to add additional features to DISTRO_FEATURES, MACHINE_FEATURES, or IMAGE_FEATURES, please use the DISTRO_TINY_FEATURES, MACHINE_TINY_FEATURES and IMAGE_TINY_FEATURES variables. For example, to add bluetooth to MACHINE_FEATURES, add the following line in conf/local.conf. MACHINE_TINY_FEATURES = "bluetooth"   Note: If you need to add a package that requires the full libc (instead of musl), add the following in conf/local.conf: TCLIBC = "glibc"   These optimizations were inspired by this presentation: Honey, I shrunk the rootfs!

  This article is an example for users to change the DDR clock on i.MX6ULL board Environment: Hardware : i.MX6ULL EVK board Concept of MMDC controller clock source on i.MX6ull Consult Chapter 18 Clock Controller Module(CCM) in the I.MX 6ull reference manual. The MMDC clock source is shown in Figure 23.3.3.1:   Figure 23.3.3.1 MMDC Clock Source Figure 23.3.3.1 shows the clock source path diagram of MMDC, which is mainly divided into three parts. 1. CBCMR[PRE_PERIPH2_CLK_SEL] : The pre_periph2 clock selector, which is the pre-selector of periph2_clkd, is controlled by the PRE_PERIPH2_CLK_SEL bit (bit22:21) of the CBCMR register. 2. CBCDR[PERIPH2_CLK_SEL] : periph2_clk clock selector, controlled by the PERIPH2_CLK_SEL bit (bit26) of the CBCDR register,When it is 0, pll2_main_clk is selected as the clock source of periph2_clk. When it is 1, periph2_clk2_clk is selected as the clock source of periph2_clk. 3. CBCDR[FABRIC_MMDC_PODF] : It is a frequency divider. The frequency division value is set by the FABRIC_MMDC_PODF bit (bit5:3) of the CBCDR register. It can be set to 0~7, corresponding to 1~8 frequency divisions respectively. To configure the clock source of the MMDC to 396MHz, it must be set to 1 here, so FABRIC_MMDC_PODF=0. The above is the clock source setting of MMDC. Implementation Step 1 : git clone the uboot code from NXP github web $ git clone https://github.com/nxp-imx/uboot-imx.git Step 2 : Modify the different frequencies of DDR by modifying the following files : uboot-imx/board/freescale/mx6ullevk/imximage.cfg As default BSP code, our DDR run frequency is 400MHz (Actually, it's 396MHz), If you want DDR to boot at 132MHz, we need to configurate the CCM_CBCDR[FABRIC_MMDC_PODF] bit,  from this bit content, we need to set it to 010. The frequency division value is 3 based on 396MHz   Change code as following: DATA 4 0x020c4014 0x00018910, Add this code in imximage.cfg file. Step 3 : Re-compile the uboot and flash the uboot to the board. Result Now, We can see that DDR is running at successfully at 132MHz. Before modification:   After modification:      

Test environment: i.MX8ULP EVK, SDK2.16 Some customer want to use LPUART2 in DSP domain on M33 core. This patch is based on lpuart_edma example.   Hardware test point:   You will get such log from LPUART2 if we enter 3 on keyboard LPUART EDMA example Send back received data Echo every 8 characters 33333333   Modify M33 debug console from LPUART1 to LPUART2 is similiar.

There are several vulnerabilities been found recently as below: ZIMPERIUM’s report: http://jiveon.jivesoftware.com/mpss/c/7gA/PDcDAA/t.1p4/5z0zjG0pTd2TX1EnZDdFDQ/h3/hAMy2Th8Lsdoz-2BI-2B-2B4FlQpxshE-2Fm9XH3UWXhoYdrt6y4Crt0q1GUsW8pizm7YGWnxGc52SR4U4vCgooHeqoe1S9fu9dc4l1m2ew0Kz-2BSCbA-3D     They are reported as CVE-2015-1538, CVE-2015-1539, CVE-2015-3824, CVE-2015-3826, CVE-2015-3827, CVE-2015-3828 and CVE-2015-3829.   Trendmicro’s  report:http://blog.trendmicro.com/trendlabs-security-intelligence/trend-micro-discovers-vulnerability-that-renders-android-devices-silent/   All above vulnerabilities are related with stagefright’s stackoverflow, which exist all android version since JellyBean 4.2. The stagefright is the default Multimedia framework in Android’s AOSP source code.   To avoid attacking toward stagefright, it is recommended to have patches in this attach, which should be applied to myandroid/frameworks/av.   Reference: https://github.com/WhisperSystems/TextSecure/issues/381   This document was generated from the following discussion: Android vulnerability related with stagefright   Created by Hui Fang

Question: How to enable touch functions on LVDS1/SabreAI base board? what should be soldered in order to connect the signals to i2c what to add in the Linux kernel (board-mx6q_sabreauto.c) BTW.: Why did we leave these disconnected? Is there any conflict on i2c? Answer: You can mount R305 and R306 to support touch on LVDS1, no code modification was needed. The only limitation is that the two LVDS's touch can't be connected to same I2C port, because they are using the same I2C address. Question: How is this working because the touch interrupt signal from LVDS1 called LCD1_TOUCH_INT_B is connected to pin21 on J44 on base board which is left floating (TP1) on CPU card P1A connector? Are both LVDS needed to work in the same time. Answer: That's the problem, the LVDS1 touch interrupt pin hasn't been connected to IMX6 CPU. Maybe you can use the SabreSD board, the two touch are ready on that board.

The refine to TV mode of R10.3.1 causes dual video function fail. The attached patch recovers dual video function. Attached dual_video.patch only work for RGB output (HDMI support). For legacy TVout (YUV output), the extra patch is necessary, see the attached "legacy_tvout.zip". Refer to Dual video with single UI on i.MX53 SMD with Android R10.4  for setup.

imx7 supports TRULY-WVGA-TFT3P5581E display, the connector is J30, which is a connector on the imx7d board, normally, one can find the part number from BOM file, but imx7 Sabre-SDB board  BOM file missed this information. got connector information from expert team as below: The connector manufacture’s part number is: DF40C-24DS-0.4V(51)   For more detailed information about sabre board information information is available from nxp.com in the Design files for i.MX7Dual   For data sheet of this, which is under NDA, if you need it, pls create a salesforce case to get this, I couldn’t post this on public community.

Attached is the Kernel image needed to construct the Linux Image i.MX 6Dual/6Quad Power Consumption Measurement Linux Image

Hi all !      I found a problem, wiif connection issue .  When I connect to WiFi hotspots, reported a warning ！     <4>RTL871X: assoc success <4>------------[ cut here ]------------ <4>WARNING: at net/wireless/sme.c:482 __cfg80211_connect_result+0x2f4/0x32c() <4>Modules linked in: 8188eu <4>[<c0054044>] (unwind_backtrace+0x0/0x138) from [<c008c1b8>] (warn_slowpath_common+0x4c/0x64) <4>[<c008c1b8>] (warn_slowpath_common+0x4c/0x64) from [<c008c1ec>] (warn_slowpath_null+0x1c/0x24) <4>UpdateHalRAMask8188EUsb => mac_id:0, networkType:0x0b, mask:0x000fffff <4>     ==> rssi_level:0, rate_bitmap:0x000ff015 <4>[<c008c1ec>] (warn_slowpath_null+0x1c/0x24) from [<c069e3a0>] (__cfg80211_connect_result+0x2f4/0x32c) <4>[<c069e3a0>] (__cfg80211_connect_result+0x2f4/0x32c) from [<c06893f4>] (cfg80211_process_rdev_events+0x1e0/0x204) <4>[<c06893f4>] (cfg80211_process_rdev_events+0x1e0/0x204) from [<c0686ec0>] (cfg80211_event_work+0x24/0x54) <4>[<c0686ec0>] (cfg80211_event_work+0x24/0x54) from [<c00a66f0>] (process_one_work+0x12c/0x494) <4>[<c00a66f0>] (process_one_work+0x12c/0x494) from [<c00a6bc8>] (worker_thread+0x170/0x3cc) <4>[<c00a6bc8>] (worker_thread+0x170/0x3cc) from [<c00aacbc>] (kthread+0x80/0x88) <4>[<c00aacbc>] (kthread+0x80/0x88) from [<c004d408>] (kernel_thread_exit+0x0/0x8) <4>---[ end trace 14efbc2d6eba2439 ]---       This document was generated from the following discussion: 

Q: What is quality level of IBIS file? In chapter 8.6 in IMX6DQ6SDLHDG (Rev.0). It says the following about quality assurance. ===== All models (GPIO, DDR, LVDS, MLB) have passed the following checks: • IBISCHK without errors or unexplained warnings • Data for basic simulation checked • Data for timing analysis checked • Data for power analysis checked • Correlated against Spice simulations Validation reports can be provided upon demand. ==== A: In addition, please see http://www.vhdl.org/pub/ibis/quality_wip/checklist/Using_IQ_2.0_checklist.pdf. This document says about quality level. According to these information, the IBIS quality level is IQ4 (IQ3 + data for power  analysis checked) + "Correlated against Spice simulations". This document was generated from the following discussion: IBIS QUALITIY LEVEL

Attached is the Kernel needed to construct the following image: i.MX 6Dual/6Quad Power Consumption Measurement Linux Image

New i.mx6Q core board from OpenEmbed.com

Question: LVDS in split mode (dual lvds) is used. In this configuration, only LVDS0_CLK is used. What is the suggestion for the LVDS1_CLK?  The HW user guide says that if this is unused, then to leave it floating.  Would we also suggest the same for this case or would termination be more appropriate?  Or is there some possible way to gate this clock?  (if so, it isn't obvious in the RM) Answer: According to the MX6 Developer's Guide, any unused LVDS pins should be left floating, so the LVDS1_CLK pair, in this case should be left floating. In order to minimize any potential EMC, the lands for those balls should not have any additional traces leading away. To add a bit more information, the customer ran some tests and found that the clock gate bits for the LVDS1 are essentially ignored in Dual mode.  The only way to disable it is if they are both disabled which is not helpful in this case.  It seems that the Dual mode setting overrides the CG.

LSIO_GPIO0_IO0x toggling on i.MX8QM Issue customer met: Customer met LSIO_GPIO0_IO0x not toggling on i.MX8QM, they are working through the software on their board, part of that involves getting a few GPIO pins working. They have been using several GPIO pins for a while now, we have some simple toggles and some others where we bit bang i2c, all of those have worked fine. However, They have not been able to get 3 pins to either read or set successfully at all: LSIO_GPIO0_IO00 (SIM0_CLK) LSIO_GPIO0_IO01 (SIM0_RST) LSIO_GPIO0_IO02 (SIM0_IO) 1\ Reproduce on our i.MX8QM EVK board  a. Check the hardware connection Check the LSIO_GPIO0_IO00 (SIM0_CLK), LSIO_GPIO0_IO01 (SIM0_RST) and LSIO_GPIO0_IO02 (SIM0_IO) connection in our i.MX8QM EVK board. In the default design in NXP i.MX8QM EVK board, the pins SIM0_CLK, SIM0_RST and SIM0_IO connect to the SIM CARD on the base board.         b. To make these pins work as GPIO pins In the default pins mux, default pins mux on the SIM0, to make these pins work as GPIO, need to mux them to the GPIO functions. SIM0_CLK (SIM0_CLK)     SIM0_RST (SIM0_RST)   SIM0_IO (SIM0_IO)     c. In the source code change these pins mux to GPIO configuration: Defalt setting for these pins : linux-imx/arch/arm64/boot/dts/freescale/imx8qm-mek.dts at lf-6.12.y · nxp-imx/linux-imx · GitHub   pinctrl_sim0: sim0grp {                              fsl,pins = <                                            IMX8QM_SIM0_CLK_DMA_SIM0_CLK           0xc0000021                                            IMX8QM_SIM0_IO_DMA_SIM0_IO                 0xc2000021                                            IMX8QM_SIM0_PD_DMA_SIM0_PD               0xc0000021                                           IMX8QM_SIM0_POWER_EN_DMA_SIM0_POWER_EN                         0xc0000021                                            IMX8QM_SIM0_RST_DMA_SIM0_RST            0xc0000021                              >;               }; Linux dts should set them to GPIO0 functions:               IMX8QM_SIM0_CLK_LSIO_GPIO0_IO00 0xc0000021               IMX8QM_SIM0_RST_LSIO_GPIO0_IO01 0xc2000021               IMX8QM_SIM0_IO_LSIO_GPIO0_IO02 0xc0000021 Build the source code, download the images to board, test on the SIM pins to see if these pins can work or not. Test on the J45 pins 3,5,6.   Test the SIM_CLK as an example: Test commands in Linux echo 480 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio480/direction #output high echo 1 > /sys/class/gpio/gpio480/value #measure the PINs #output low echo 0 > /sys/class/gpio/gpio480/value #measure the PINs Found these pins can not toggling well. 2\ Go next further test and consideration Foud the SCU_GPIO0_00, SCU_GPIO0_01, SCU_GPIO0_02 are also configurate as GPIO function in the SCFW,  in the default setting for the SC_P_SCU_GPIO0_00is the function GPIO0_00 , and when setting the SIM0_CLK to GPIO0_00 function then the GPIO0_00 can not work normally. So if setting the SIM0_CLK as GPIO0_00 function, then we need to set the SC_P_SCU_GPIO0_00 this PIN to others function, so that no conflict of them. Even no use the pin SC_P_SCU_GPIO0_00 in hardware, we also need to set them to others function to avoid the conflict. SCU_GPIO Pins mux: SCU_GPIO0_00 (SCU_GPIO0_00)   SCU_GPIO0_01 (SCU_GPIO0_01)   SCU_GPIO0_02 (SCU_GPIO0_02)         Tested the PINs "SIM0_CLK, SIM0_IO, SIM0_RST" on iMX8QM MEK with base board. All of them works fine.  The key points are already listed. VDD_SIM0 power should be supplied (It is 3.3V on MEK from PF8100 LDO)   Linux dts should set them to GPIO0 functions:     IMX8QM_SIM0_CLK_LSIO_GPIO0_IO00 0xc0000021     IMX8QM_SIM0_RST_LSIO_GPIO0_IO01 0xc2000021     IMX8QM_SIM0_IO_LSIO_GPIO0_IO02 0xc0000021 The default IOMUX for PINs SC_P_SCU_GPIO0_00, SC_P_SCU_GPIO0_01, SC_P_SCU_GPIO0_02 should be changed from 0 to others.  Test on MEK, we used followed codes in SCFW board_init():     else if (phase == BOOT_PHASE_FINAL_INIT)     {         /* Configure SNVS button for rising edge */         SNVS_ConfigButton(SNVS_DRV_BTN_CONFIG_RISINGEDGE, SC_TRUE);           /* Init PMIC if not already done */         pmic_init();         pad_force_mux(SC_P_SCU_GPIO0_00, 2,             SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);         pad_force_mux(SC_P_SCU_GPIO0_01, 2,             SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);         pad_force_mux(SC_P_SCU_GPIO0_02, 2,             SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);     }  Note: In SCFW, should also set SC_P_SCU_GPIO0_00, SC_P_SCU_GPIO0_01, SC_P_SCU_GPIO0_02 to other functions, because they are set to GPIO0_0x function default, if two PINs set to the same functions, such as SIM0_CLK_DMA pin and SCU_GPIO0_00 pin are set to GPIO0_00 together, the function will not work correctly.   Test commands in LInux: echo 480 > /sys/class/gpio/export echo 481 > /sys/class/gpio/export echo 482 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio480/direction echo out > /sys/class/gpio/gpio481/direction echo out > /sys/class/gpio/gpio482/direction #output high echo 1 > /sys/class/gpio/gpio480/value echo 1 > /sys/class/gpio/gpio481/value echo 1 > /sys/class/gpio/gpio482/value #measure the PINs, they are correct high  ( 3V ) #output low echo 0 > /sys/class/gpio/gpio480/value echo 0 > /sys/class/gpio/gpio481/value echo 0 > /sys/class/gpio/gpio482/value #measure the PINs, they are correct low ( 0V ) The test result is based on real measurement on iMX8QM MEK.    Note: 1\In customer's side If still not work, To confirm the issue, please suggest customer build SCFW with parameter "-m", then use followed commands to dump the IOMUX registers: md 0x41F80000 1 md 0x41F80040 1 md 0x41F80080 1 md 0x41F82140 1 md 0x41F82180 1 md 0x41F83000 1   The "md" command should run from SCFW debug UART, not linux/uboot UART. 2\Make sure the hardware in customer's side VDD_SIM0 power should be supplied .    

I am designing settop using iMX.6Q sabre solution. What is the android platform key? Why need  the android platform key? Thank in advance