vpuwraper can fulfill VPU decoder/encoder, if customer’s user case is simple, for example they just need to encode yuv stream to H264, or decode H264 stream to yuv, There is no need to use gstreamer or V4L2 complex framework, you can use vpuwraper. Platform: i.MX8MP + L5.4.70.2.3.0 Build Procedure: mkdir vpu cd vpu git clone https://github.com/nxp-imx/imx-vpuwrap   cd imx-vpuwrap/ git tag -l   git switch -c rel_imx_5.4.70_2.3.0   source ../../.././5.4.70.2.3.0/sdk/environment-setup-aarch64-poky-linux   make -f Makefile_8mp   Test on i.MX8MP EVK board Pls find attached test log for decode and encode If busChromaU in YUV file is null, you will failed to encode it, pls apply vpuwraper patch for L5.4.70.2.3.0.patch to fix it If YUV file is interleave format, you need to add interleave parameter : -interleave 1 ./test_enc_arm_elinux -i test.yuv -o aaa.h264 -f 2 -w 176 -h 96 -interleave 1   Thanks, Lambert

On customer design, they may need to fine tune LVDS driver strength for different case, for example, PCB impedance does not match, or the value of terminal resistor in panel side is lower or bigger. In IMX8MPRM.pdf, it has reg for this feature:         LVDS is constant current source, when voltage on terminal or panel side is lower than spec, you need to increase output current to get higher voltage to meet spec. otherwise ,you need to reduce it There is no detail description for these bits, pls refer to below: CC_ADJ = 000b => 3.5mA as default CC_ADJ = 001b => 3.5mA + 0.215mA x 1 CC_ADJ = 010b => 3.5mA + 0.215mA x 2 CC_ADJ = 011b => 3.5mA + 0.215mA x 4 CC_ADJ = 100b => 3.5mA - 0.215mA x 4 CC_ADJ = 101b => 3.5mA - 0.215mA x 3 CC_ADJ = 110b => 3.5mA - 0.215mA x 2 CC_ADJ = 111b => 3.5mA - 0.215mA x 1   Thanks, Lambert

  Platform: i.MX8MP EVK , L6.1.22-2.0.0 LT9211 is a chip that can realize the conversion of MIPI DSI signals to LVDS signals. This patch is based on this mainline driver:https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/gpu/drm/bridge/lontium-lt9211.c Keypoint Move lt9211_host_attach function to lt9211_attach to skip bridge attach error.  

Traditional non-matter devices cannot directly join the matter network. But Matter Bridge solves the problem. Matter bridge can join a Matter network as a Matter device and nonmatter devices need to be mapped to Matter network as a dynamic endpoint. In this way, other Matter devices can communicate with non-matter devices through dynamic endpoints. The Guide is a Matter Zigbee Bridge implement based on i.MX93 + K32W0.     Feature List • Matter over Ethernet • Matter over Wi-Fi • Register and Remove Zigbee Deivces • Connect Zigbee devices into Matter ecosystem seamlessly • Zigbee Devices • On/Off cluster • Temperature Sensor Cluster • Matter Actions • Start Zigbee Network • Zigbee Network Permit Join • Factory Reset • No limitation if migrating to other i.MX MPU like i.MX6ULL, i.MX8MP • OTBR and Zigbee bridge can be integrated into one single device

The purpose of this document is to specify the maximum LPDDR3, LPDDR4, & LPDDR4X densities that are supported by i.MX 8ULP processor along with a running list of tested memories to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products.  It is strongly recommended to consult with NXP and the memory vendor the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs. For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket.  LPDDR4/LPDDR4X Maximum Support Density Please note that the SoC limits the addressable DDR memory map range to 2GB. SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8ULP 32-bit 16Gb/2GB single-rank, dual-channel  device with 16-row addresses (R0-R15) 1, 2, 6,11   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 i.MX 8ULP 16Gb/2GB Micron MT53D512M32D2DS-053 WT:D  10 16Gb/2GB Micron MT53E512M32D1ZW-046 WT:B  8 64Gb/8GB Micron MT53E2G32D4DE-046 WT:A  3, 4, 8 32Gb/4GB Micron MT53E1G32D2FW-046 AUT:B  3, 4, 10 16Gb/2GB Nanya NT6AN512T32AV-J2 3, 7, 8 8Gb/1GB Forsee FL4C2001G-D9  3, 10   LPDDR4x - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Mamory Vendor Validated Memory Part# Notes i.MX 8ULP 16Gb/ 2GB Nanya NT6AP512T32AV-J2  3, 7, 8 2Gb/ 256MB Fidelix FMF2D32VAC-4CDIR 3 4Gb/ 512MB Winbond W66CQ2NQUAFJ  3, 8 8Gb/1GB Alliance Memory AS4C256M32MD4V-062BAN  3, 8 32Gb/4GB Micron MT53E1G32D2FW-046 AUT:B (Z42M) 3, 4, 10 16Gb/ 2GB Micron MT53D512M32D2DS-053 WT:D  10 16Gb/ 2GB Micron MT53E512M32D1ZW-046 WT:B  9   LPDDR3 Maximum Support Density Please note that the SoC limits the addressable DDR memory map range to 2GB. SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8ULP 32-bit 16Gb/2GB Single Channel, Dual Chip Select 5,11   LPDDR3 - 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 i.MX 8ULP 16Gb/2GB Micron  MT52L512M32D2PF-107 WT:B  8   Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC and on the memory device used on NXP evaluation boards, and on the JEDEC standards JESD209-4/JESD209-4B (LPDDR4/4X). 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: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 4: As the i.MX 8ULP DDR memory map is limited to 2GB, only up to 2GB of the device can be utilized even though the device density exceeds the 2GB range. Note 5: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC and on the memory device used on NXP evaluation boards, and on the JEDEC standards JESD209-3C (LPDDR3). 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 6: The SoC supports also LPDDR4/4X devices with 17-row address bits however, given the SoC's memory map constraints (see Note 4), full density of those devices cannot be utilized since the dual channel (x32) 17-row address memory devices have the density of 4GB and higher. Note 7: By default, LPDDR4/4X devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity. Please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. Note 8: Part is active. Reviewed Jan 2026 Note 9: Part is active as MT53E512M32D1ZW-046BWT:B.  Note 10: Part is obsolete. Note 11: i.MX 8ULP does not support Non-Power of 2 Memory densities (e.g. 3,6,12 Gb).

This demo for all(bootloader, device tree, Linux kernel, rootfs) in spi. It uses raw read(sf read)/raw write(sf write in uuu script) to achieve that. sf probe 0; sf read ${fdt_addr} 0x500000 0x100000; sf read ${loadaddr} 0x600000 0x1E00000; sf read ${initrd_addr} 0x2400000 0x600000; setenv bootargs console=${console},${baudrate} earlycon=${earlycon},${baudrate} rdinit=/linuxrc; booti ${loadaddr} ${initrd_addr} ${fdt_addr} |-- 0001-all-in-spi-demo-lf-5.10.72-2.2.0.patch --- patch for this demo |-- demo_binary | |-- flash.b0.bin --- b0 bootloader | |-- flash.bin --- c0 bootloader | |-- Image-imx8qxpc0mek.bin --- Linux kernel | |-- imx8qxp-mek.dtb --- device tree | |-- uramdisk_boot.rootfs.aarch64.img --- ram disk | |-- uuu.qspi.all.b0.uuu --- uuu script for b0 | `-- uuu.qspi.all.uuu --- uuu script for c0 `-- readme.txt --- this file # The spi layout used is: # - --------- -------------------------------------------- # | | flash.bin | env | dtb | Image |rootfs| # - --------------- -------------------------------------- # ^ ^ ^ ^ ^ ^ ^ # | | | | | | | # 0 4kiB 4MiB 5MiB 6MiB 36MiB 42MiB 0x1000 0x400000 0x500000 0x600000 0x2400000 Test: HW: i.MX8QXP MEK SW: lf-5.10.72-2.2.0 + 0001-all-in-spi-demo-lf-5.10.72-2.2.0.patch Test log: SF: Detected mt35xu512aba with page size 256 Bytes, erase size 128 KiB, total 64 MiB device 0 offset 0x500000, size 0x100000 SF: 1048576 bytes @ 0x500000 Read: OK device 0 offset 0x600000, size 0x1e00000 SF: 31457280 bytes @ 0x600000 Read: OK device 0 offset 0x2400000, size 0x600000 SF: 6291456 bytes @ 0x2400000 Read: OK [ 4.787552] imx6q-pcie 5f010000.pcie: unable to add pcie port. [ 4.797467] Freeing unused kernel memory: 2944K [ 4.807379] Run /linuxrc as init process Starting syslogd: OK Starting klogd: OK Running sysctl: OK Starting network: OK /bin/sh: can't access tty; job control turned off / #  

This is about the case studay from two USB related issues: #1. Plugin detection issue caused by an errata in i.MX8/8X (host mode).       Very limited unit may encounter this problem. When issue happens, there will be totally no action on USB host port when a debug plugged in. #2: High Speed disconnection detection issue (host mode):       This may happen on some special USB design which have complex circuit and connector design on the USB path and long USB cable. The USB enumeration might be interrupted by an un-expected disconnection event. System log shows USB recognition started but failed at several different stages during handshake. For details, please refer to the doc attached (#1/#2). A reference patch for each has also been made by David.

We are pleased to announce that Config Tools for i.MX v13.1 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 13.1 DDR tool     - i.MX93 support for A0 pre-production launch; sync with SW BSP release Pins tool     - Fix incomplete routing of deinit functions  

Platform: i.MX8MP EVK BSP: Linux 5.4.70.2.3.0 Customer reported UI on HDMI monitor is abnormal and has more line on left side when doing HDMI hot-plug on i.MX8MP running with L5.4.70.2.3.0.   This issue can’t be reproduced on latest BSP such as 5.10 and above, several patch for HDMI from latest BSP can fix this issue.  

This doc will show: i.MX6SLL EVK board without connect hardware LCD display, using FreeRDP to share screen to remote PC which in same network, PC take this shared screen could run any command on i.MX6SLL EVK board. HW: i.MX6SLL EVK board, PC, usb network adapter SW: i.MX6SLL Linux 5.15.72_2.2.0 BSP release, and code change in this doc 1>yocto-5.15.72/6sll-bld/conf/local.conf, add below line, as freerdp depend on ffmpeg. LICENSE_FLAGS_ACCEPTED+="commercial" 2>pixman need switch to 0.42.0, enter folder yocto-5.15.72/6sll-bld/tmp/work/cortexa9t2hf-neon-poky-linux-gnueabi/pixman/1_0.40.0-r0/pixman-0.40.0, fetch latest 0.42.0 version code from https://github.com/freedesktop/pixman.git 3>freerdp need use 2.8.0, enter folder yocto-5.15.72/6sll-bld/tmp/work/cortexa9t2hf-neon-poky-linux-gnueabi/freerdp/1_2.6.1-r0/git should checkout to 2.8.0 tag; then to use neon accelerate freerdp related function, such as color space conversion, image codec encoding, apply patch freerdp-codechange-neon.diff. 4>Enter yocto-5.15.72/sources/meta-openembedded/meta-oe/recipes-support/freerdp, file freerdp_2.6.1.bb change as freerdp-2.6.1-bbfile.diff 5> bitbake -c compile ffmpeg bitbake -c install ffmpeg bitbake -c compile pixman bitbake -c install pixman bitbake -c compile freerdp bitbake -c install freerdp 6> Copy generated new libs to i.MX6SLL Linux rootfs: cp /root/imx6sllevk-linux-lib/lib* /usr/lib/ cd /usr/lib/ rm libfreerdp-client2.so.2 libfreerdp2.so.2 libpixman-1.so.0 libwinpr-tools2.so.2 libwinpr2.so.2 ln -s libfreerdp-client2.so.2.8.0 libfreerdp-client2.so.2 ln -s libfreerdp2.so.2.8.0 libfreerdp2.so.2 ln -s libpixman-1.so.0.42.0 libpixman-1.so.0 ln -s libwinpr-tools2.so.2.8.0 libwinpr-tools2.so.2 ln -s libwinpr2.so.2.8.0 libwinpr2.so.2 ln -s libavcodec.so.58.134.100 libavcodec.so.58 ln -s libavutil.so.56.70.100 libavutil.so.56 ln -s libswresample.so.3.9.100 libswresample.so.3 Make sure: libfreerdp-client2.so.2 -> libfreerdp-client2.so.2.8.0 libfreerdp2.so.2 -> libfreerdp2.so.2.8.0 libwinpr-tools2.so.2 -> libwinpr-tools2.so.2.8.0 libwinpr2.so.2 -> libwinpr2.so.2.8.0 libswresample.so.3 -> libswresample.so.3.9.100 libavutil.so.56 -> libavutil.so.56.70.100 libavcodec.so.58 -> libavcodec.so.58.134.100 7>i.MX6SLL Linux OS, file /etc/xdg/weston/weston.ini, change start-on-startup to true [screen-share] command=WLOG_APPENDER=file WLOG_FILEAPPENDER_OUTPUT_FILE_NAME=output.log WLOG_FILEAPPENDER_OUTPUT_FILE_PATH=/tmp /usr/bin/weston --backend=rdp-backend.so --shell=fullscreen-shell.so --no-clients-resize --rdp-tls-cert=/etc/freerdp/keys/server.crt --rdp-tls-key=/etc/freerdp/keys/server.key start-on-startup=true 8> i.MX6SLL Linux OS, run below cmd: mkdir /etc/freerdp mkdir /etc/freerdp/keys /root/imx6sllevk-linux-lib/winpr-makecert -path /etc/freerdp/keys mv /etc/freerdp/keys/imx6sllevk.crt /etc/freerdp/keys/server.crt mv /etc/freerdp/keys/imx6sllevk.key /etc/freerdp/keys/server.key service weston stop service weston start 9>Plug usb network adapter to i.MX6SLL EVK board J10; i.MX6SLL board and PC must in same network, ping without problem. i.MX6SLL Linux OS, there are two process name as "weston", one process is weston rdp backend will share screen to PC. If only one weston process, need check did miss copy any new lib or check libary file name. 10>PC side: wfreerdp.exe /v:IPADDRESS_OF_IMX6SLLEVK There will prompt dialog box for user name and password, just press ESC, then PC side will show i.MX6SLL Linux desktop screen; Click console button of i.MX6SLL Linux OS desktop, within that console input any i.MX6SLL Linux OS cmd, check result of it from PC side. Known issue: wfreerdp.exe is downloaded from https://ci.freerdp.com/job/freerdp-nightly-windows/ If run latest wfreerdp.exe but show nothing of remote desktop, try attached version wfreerdp.exe(3.0.0-dev). Also you can try check log files first: i.MX6SLL Linux OS file /tmp/output.log; PC side generated log file as: wfreerdp.exe /v:IPADDRESS_OF_IMX6SLLEVK /log-level:TRACE > rdp.log Reference: 1>https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applicat... 2>https://github.com/FreeRDP 3>https://github.com/freedesktop/pixman 4>https://github.com/DLTcollab/sse2neon    

  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 i.MX 8/8X DDR initialization.  For more details, refer to the i.MX 8/8X main DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8-8X-Family-DDR-Tools-Release/ta-p/...  

We are pleased to announce that Config Tools for i.MX v13 are now available.

Updated for "phase 3" after a 3rd software lockup symptom found and fixed. Updated doc/patch: Software-lockup-issue-phase3_20260318-public.pdf 0001-clk-fix-sleeping-function-called-from-invalid-contex.patch 0001-ddr-perf-fix-sleeping-function-called-from-invalid-c.patch 0001-gpu-imx-dpu-Access-ExtDst-FetchUnit-Hscaler-Vscaler-new_L4.14.98.patch (this patch will depends on https://github.com/nxp-imx/linux-imx/commit/70744429841f08efc42a63380198cdae7f9a602f) --- 20260318   This is a summary for the software lockup issue found in the following platform: −i.MX8/8X −Linux 4.14.98_2.3.3   Issue description: •Issue happens during the boot procedure, at the systemd stage. •The symptom of the issue: −From user perspective, the symptom varies, but mainly fall into several types: §At the console, there may be login prompt, but no response (only echo) when input user/password. Unable to login. §Some user service in systemd failed to start. E.g. weston. −When checking the task status using sysrq (w/t), many tasks, including some kernel core tasks stays in “D” (uninterruptable sleep) state. E.g. agetty, login, chvt, etc. •Kernel itself is still alive. This can be verified by triggering some drivers, such as plugin a USB device. Issue can be reproduced on MEK through long time stress.   Please refer to the doc/patch attached for details.

i.MX8 series contains internal HiFi4 DSP. It is targeted for Audio related signal processing. SOF (Sound Open Firmware) is open source audio DSP firmware, driver and SDK. This document introduces basic theory about IIR/FIR digital filters, how to design IIR/FIR digital filters and the Equalizer filters implementation by SOF. After that, the document also describes how HiFi4 DSP MAC engine accelerate the EQ filters calculation.

This article describes how to integrate NXP WiFi & BT module into i.MX platform, some debug tips, how to test, etc. Although it takes i.MX8MM as example, it is also suitable for all i.MX8 serials platform.

This doc will show: i.MX8DXL EVK board without connect  hardware LCD display, using FreeRDP to share screen to remote PC which is in same network,  PC take this shared screen could  run any command on i.MX8DXL EVK board.   HW: i.MX8DXL EVK board,  PC  SW: i.MX8DXL Linux 5.15.32 BSP release, and code change in this doc   1> i.MX8DXL Linux kernel side, just use imx8dxl-evk-lcdif.dts, but did not connect any LCD display,  so Linux kernel could create related drm device, and weston could be start. But on 8DXL EVK board, ENET1_RGMII_TXD3 and ADMA_LCDIF_D03 pin conflict,  so need code change as 5.15.32-imx8dxl-evk-lcdif.dts.diff.   2> yocto/bld/conf/local.conf, add below line, as freerdp depend on ffmpeg. LICENSE_FLAGS_ACCEPTED+="commercial"   3> For i.MX8DXL,  weston use software pixman render, to use NEON optimization,  pixman need switch to  latest 0.42.0,  enter folder (yocto/bld/tmp/work/armv8a-poky-linux/pixman/1_0.40.0-r0/pixman-0.40.0),  git clone (https://github.com/freedesktop/pixman.git) and checkout to latest 0.42.0:  Also chaneg related build flag at bb file as pixman_0.40.0.bb.diff.     4> Default  freerdp need switch to 2.8.0, enter folder (yocto/bld/tmp/work/armv8a-poky-linux/freerdp/1_2.4.1-r0/git),  git clone (https://github.com/FreeRDP/FreeRDP.git), check out to 2.8.0; And to use neon accelerate freerdp related function, such as color space conversion, image codec encoding ,  need apply patch  freerdp-codechange-neon.diff. And related bb file compile flag change as freerdp_2.4.1.bb.diff     5> bitbake -c compile ffmpeg bitbake -c install ffmpeg   bitbake -c compile pixman  bitbake -c install pixman    bitbake -c compile  freerdp bitbake -c install  freerdp   Copy  generated new libs to default released i.MX8DXL rootfs, make sure ffmeg , pixman, freerdp related libs are  from your build, for example: libfreerdp-client2.so.2 -> libfreerdp-client2.so.2.8.0 libfreerdp2.so.2 -> libfreerdp2.so.2.8.0 libwinpr-tools2.so.2 -> libwinpr-tools2.so.2.8.0 libwinpr2.so.2 -> libwinpr2.so.2.8.0   6> i.MX8DXL Linux rootfs:  file /etc/xdg/weston/weston.ini,  change start-on-startup to true: [screen-share] command=/usr/bin/weston --backend=rdp-backend.so --shell=fullscreen-shell.so --no-clients-resize --rdp-tls-cert=/etc/freerdp/keys/serve start-on-startup=true   7> i.MX8DXL Linux OS, run below cmd: winpr-makecert -path $PWD copy generated files to /etc/freerdp/keys/server.crt and /etc/freerdp/keys/server.key   8> reboot i.MX8DXL EVK board,  make sure  EVK board and PC in the same network; check i.MX8DXL Linux OS , there are two process name as "weston", one process is weston rdp backend to share screen to PC.   9> PC side, get wfreerdp.exe from  https://github.com/FreeRDP/FreeRDP/wiki/Prebuilds PC side run cmd as: wfreerdp.exe /v:ipaddress_of_8DXLEVK     Reference: 1>https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX#design-resources 2>https://github.com/FreeRDP 3>https://github.com/freedesktop/pixman 4>https://github.com/DLTcollab/sse2neon  

On behalf of Gopise Yuan. This is a patch to fix USB plug/unplug event detection failure issue on ChipIdea IP under corner case.

On i.MX8MP EVK, image is downloaded into eMMC/SD via OTG1, if customer wants to enable USB OTG2 on i.MX8MP for uuu tool. Pls find modification as attached.

The Config Tools for i.MX is a set of configuration tools that provide an efficient method for evaluation and configuration of pins routing and DDR memory settings when designing with NXP's application processors based on Arm® Cortex®-A cores, including i.MX MPUs. The following tools are currently available: DDR Tool DDR Configuration and Validation tool allows you to create a configuration for the DDR component and to validate the DDR configuration using various validation scenarios Features: Support for iMX8M, iMX8MM, iMX8MN, iMX8MP and LX2160A DDR configuration UI using the tokenized RPA tool PHY initialization using dynamic library Import the output of the RPA tool will bypass UI configuration Support for multiple PHY firmware version including fw2020.06 Diagnostic fw2020.06 DDR PHY support for DDR3, DDR4, and LPDDR4 Cell color code Basic/Advanced user mode DDR controller Registers View support Auto-detect of available COM ports USB target connection Basic validation tests support (Write-Read-Compare, Walking Ones, Walking Zeros) DQ ODT and driver strength test vTSA (Virtual Timing Signal Analysis) support - RX data eye, TX data eye Stress tests support Export vTSA results in JPEG format Static Code generation in Uboot style Command line posibility PBL Tool PBL tool helps you create and modify pre-boot initialization data used for configuring LX2 devices. Features: Support for LX2160A Configure reset configuration word (RCW), which is 1024 bits of information Optional configure pre-boot initialization (PBI) command sequence Allow user to have full access to configuration by using Skip error checking and Display all fields Option to directly modify the configuration from RCW registers Import different formats of input Generate different types of output, including a binary file SerDes Tool The SerDes tool allows you to configure the SerDes block and provides you with a GUI application to validate the configuration Features: Support for LX2160A UI for SerDes blocks configuration Per lane tests Bist, Power Transmitter/Receiver, Reset Transmitter/Receiver tests Jitter scope, Pattern Independent Jitter scope, Start/Stop Tx Patter generation tests Read a configuration from the target   Trusted Execution Environment Configuration tool The Trusted Execution Environment (TEE) tool facilitates the protection and isolation of the sensitive parts of the code. Features: Graphical display of memory layout and resulting access to memory regions Configuration of access policies for memory areas, bus masters, and peripherals Configuration of pin and interrupt masking and security, as well as general features related to the ARMv8 core security Configuration of MPU Validation of settings Generation of configuration files (C code or ROM preset data) Pins Tool The Pins Tool is used for pin routing configuration, validation and code generation, including pin functional/electrical properties, power rails, run-time configurations. Features: Desktop application Muxing and pin configuration with consistency checking Multicore support Localized for English and Simplified Chinese Mostly Connected: On-Demand device data download Integrates with any compiler and IDE Supports English and Chinese (simplified) languages, based on locale settings. Please refer to user manual for details. ANSI-C initialization code Graphical processor package view Multiple configuration blocks/functions Easy-to-use device configuration Selection of Pins and Peripherals Package with IP blocks Routed pins with electrical characteristics Registers with configured and reset values Power Groups with assigned voltage levels Source code for C/C++ applications Documented and easy to understand source code CSV Report and Device Tree File 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. Whats new in v12.1 Pins tool Deinit function now sets also the routing and direction to it's default state. It also tries to route the original peripheral signal to it's default pin.  

In the i.MX8MP support 3 SDIO interface, and in the reference board i.MX 8M Plus LPDDR4 EVK design default use the eMMC connect to the USDHC3 to boot up from emmc，use the SD card connect to the USDHC2 port. When the U-Boot starts, it will detect the starting slot and automatically set mmcdev and mmcroot, for the USDHC3 in the default Linux set is mmc dev 2. But some customer need to change to the mmc dev 0, make the mmc0 work, see the following introduction.   1 For the EMMC         MMC (multiMedia card) is a communication protocol that supports two modes, SPI and MMC. EMMC is a chip that supports MMC protocol. Both eMMC and SD card package the flash controller and NAND Flash together, but their interfaces are different. eMMC is generally BGA packaged and soldered on PCB.   EMMC includes 11 signals, namely CLK, CMD, DATA0-7 and Data Strobe. The specific signals are as follows: CLK: It is used to output clock signal from the host side, synchronize data transmission and drive device operation. Each cycle can be transmitted on the rising or falling edge, or both CMD: The signal is mainly used by the host to send a command to the eMMC and the eMMC to send a response to the host. DAT0-7: DAT0-7 signal is mainly used for data transmission between Host and eMMC. After the eMMC is powered on or soft reset, only DAT0 can transmit data. After initialization, DAT0-3 or DAT0-7 can be configured for data transmission, that is, the data bus can be configured as 4 bits or 8 bits. Data Strobe: The clock signal is sent to the host by eMMC with the same frequency as the CLK signal. It is used for synchronization of data reception at the host side. The Data Strobe signal can only be configured and enabled in the HS400 mode. After being enabled, the stability of data transmission can be improved and the bus tuning process can be omitted. 2 For the EMMC design on the i.MX8MP LPDDR4 EVK 2.1 The i.MX8MP The i.MX8MP there is 3 SDIO interface，and the i.MX8MP has 3 USDHC ports：USDHC1, USDHC2 and USDHC3.   At i MX8MP supports SD/MMC/eSD/eMMC/SDXC, and starts and boots using the USDHC port based on setting of the BOOT_MODE[3:0] pins.       In the reference design, eMMC is connected to USDHC3, and SD card is connected to USDHC2. USDHC3 is used as the eMMC boot device by default on the development board. We can see the detailed definitions of the three USDHC interfaces in the reference manual. Among them, USDHC1 and USDHC3 are 8 bits and support 8-bit data, while USDHC2 only supports 4-bit data.   2.2 Hardware and software design   The hardware design is as shown above. The eMMC is connected to the SD3 interface, and the software is configured in this way by default. 2.3 The port number of the default BSP In the i.MX 8M Plus LPDDR4 EVK development board design, the eMMC is connected to the USDHC3 as the default boot device When the U-Boot starts, it will detect the starting slot, and automatically set mmcdev and mmcroot. For USDHC3, the default is mmc dev 2.   The device structure of SD/MMC cards is similar. MMC should be the predecessor of SD, but the design of MMC at that time was half that of SD. Therefore, the SD/MMC driver is universal, and the device node of Linux continues the name of MMC.   Meaning of blk: blk is a block device, and the number after ⾯ is the serial number of the device   Meaning of p: p indicates partition, and p1 is the first partition   We can see the correspondence between the USDHC interface and the mmc under Linux. The kernel MMC module now uses a fixed mmcblk index for the uSDHC slot. The default BSP is "mmc2=&usdhc3":   In the design of the MX 8M Plus LPDDR4 EVK development board, by default, the eMMC is connected to the USDHC3, SD3 is used, and mmcblk2 is used in the SD3 slot. When setting the kernel parameters in the u-boot, you can see that: ### select mmc dev 2 (USDHC3) on the i.MX 8M Mini EVK, i.MX 8M Nano EVK, and i.MX 8M Plus EVK: U-Boot > mmc dev 2 0 For the emmc the related port is :mmcblk2 By default, the flash target is MMC: 2 after the Demo images burning of the development board is started.   3 mmc0 work as emmc device and boot up We need to modify the device, u-boot, kernel related part for the mmc0 work on the android BSP, 3.1 Software modify 2.2.1 u-boot： Dts section root/arch/arm/dts/imx8mp-evk.dts： memory@40000000 {                  device_type = "memory";                  reg = <0x0 0x40000000 0 0xc0000000>,                        <0x1 0x00000000 0 0xc0000000>;         }; aliases { /* SD/MMC: eMMC/SD slot numbering fix */        mmc0 = &usdhc3; /*Modify the usdhc3 and mmc0, default is mmc2*/        mmc1 = &usdhc2; /* usdhc2 and mmc0 do not change*/        mmc2 = &usdhc1; /*Modify the usdhc1 to mmc2, make the usdhc1 work*/         }; reg_can1_stby: regulator-can1-stby {…..} Board secton： root/board/freescale/imx8mp_evk/imx8mp_evk.c int board_init(void) {         struct arm_smccc_res res; } int board_mmc_get_env_dev(int devno) {        if(devno == 0)         return devno + 2;           else if (devno == 2)         return devno - 2;           else         return devno; }   int mmc_map_to_kernel_blk(int devno) {         return devno; } int board_late_init(void) {         board_late_mmc_env_init(); } SPL： root/common/spl/spl_mmc.c int spl_mmc_load_image(struct spl_image_info *spl_image,                         struct spl_boot_device *bootdev) {…..} Default settings：     2.2.2 kernel section： In the kernel section need to change all the related mmcblk2 to mmcblk0.                   2.2.3 device section modify: Change all the related mmcblk2 to mmcblk0. Change the uuu_imx_android_flash.bat /android_build/device/nxp/common/tools/fastboot_imx_flashall.bat if not [%soc_name:imx8mp=%] == [%soc_name%] (  set vid=0x1fc9& set pid=00x0146& set chip=MX8MP  set uboot_env_start=0x2000& set uboot_env_len=0x8  - set emmc_num=2& set sd_num=1 + set emmc_num=0& set sd_num=1  set board=evk  goto :device_info_end   All the modify see the Patch in the attachment.