In some applications, we need to shift frequencies to avoid interference from certain frequencies, such as shifting to avoid Wi-Fi interference. The document is a guide for shifting DDR3 frequency.   The document uses the iMX8M Nano DDR3 as an example, but the process is the same for the iMX8M mini, iMX8M Plus, LPDDR4, etc. The main issue is resolving the DDR pll configuration. Before reading this article, we assume you are already familiar with using the DDR stress tool and DDR config rpa, or the DDR tool of the config tools.   pll_to_table_entry_rates.py can help you to find the settings. 

Fix cdc_ether connection over usb0 stalls and cannot recover after transmitting few MByte data The patch is modified from ENGR00278073.

Attached is a chunk of the Filesystem needed to construct the Linux Image https://community.freescale.com/docs/DOC-93887

Attached is a chunk of the filesystem for the Linux Image https://community.freescale.com/docs/DOC-93887

Some customer need to run Zephyr on i.MX8QXP CM4, but there is no support on Zephyr mainline(v4.3.0) This article will share the porting based on Zephyr v4.3.0. For i.MX8QM CM4, please refer this link: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QM-CM4-0-support-on-Zephyr-v4-3-0/ta-p/2296962   samples/hello_world/ samples/synchronization Add pd_ignore_unused in bootargs before entering Linux. For the OpenAMP communication, need to refer this Zephyr application. https://github.com/nxp-real-time-edge-sw/heterogeneous-multicore/blob/main/apps/rpmsg_str_echo/zephyr/main.c

Attached is a chunk of the Filesystem needed to construct the Linux Image https://community.freescale.com/docs/DOC-93887

Purpose: Introduce how to debug M4 using trace 32 and the difference with regular debug mode for imx6sx. If you are using other jtag debug tools, maybe you need to do the similar configuration. Debug tools: Trace32 – you can refer to http://www.lauterbach.cn/ for more information about this tool.

this poring is based on the imx415 driver, the capture format is based on raw10, the bsp version is 6.6.52, the patches are attached Disclaimer: − “Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.”

i.MX 93 EVK LF-6.12.49 patches

Seeing a block diagram in IMX6SLRM 1.5.1, it looks like i.MXSL has Touch Panel Control. Is there interfaces for touch panel  in IMX6SL? Otherwise if I build HW using ADC or GPIO, can I be provided some SW drivers? Regards. The i.MX6 SL does not have embedded touch / ADC interface, sorry. Have a great day, Yuri ----------------------------------------------------------------------------------------------------------------------- Note: If this post answers your question, please click the Correct Answer button. Thank you! ----------------------------------------------------------------------------------------------------------------------- This document was generated from the following discussion: 

Attached is a chunk of the filesystem for the Linux Image https://community.freescale.com/docs/DOC-93887

This tutorial describes the complete procedure for calibrating a touchscreen display using Weston, specifically validated with the DY1212W LVDS panel on the following NXP development platforms: i.MX93‑EVK FRDM‑i.MX95 FRDM‑i.MX8MP While the initial calibration performed by Weston works only temporarily, this guide will walk you through configuring the system so that the calibration becomes persistent across reboots. The steps below include performing the initial calibration, editing Weston’s configuration, creating a calibration helper script, and applying udev rules to store the calibration matrix automatically.   Temporary Touchscreen Calibration To begin, run the following command to perform an initial calibration of your touchscreen: weston-touch-calibrator LVDS-1   After running this command, your display should be correctly calibrated. However, this calibration is not persistent, and you will need to recalibrate after every reboot unless you complete the persistence steps below.   Making the Calibration Persistent Follow the steps below to ensure that calibration settings are preserved across system restarts. Step 1: Edit the Weston Configuration File Open the following file: /etc/xdg/weston/weston.ini Under the [libinput] section, add these lines: [libinput] touchscreen_calibrator=true + calibration_helper=/usr/bin/save-calibration.sh This enables the calibration helper script that will automatically save your settings. Step 2: Create the Calibration Helper Script Create a new script at: /usr/bin/save-calibration.sh   Insert the following content: #!/bin/bash # Store the transformation arguments for the resistive touchscreen as udev rule echo 'SUBSYSTEM=="input", KERNEL=="event[0-9]*", ENV{ID_INPUT_TOUCHSCREEN}=="1", ENV{LIBINPUT_CALIBRATION_MATRIX}="'$2' '$3' '$4' '$5' '$6' '$7'"' >> /etc/udev/rules.d/touchscreen.rules   Make the script executable: chmod 755 /usr/bin/save-calibration.sh   Step 3: Restart Weston and Recalibrate Restart the Weston service: systemctl restart weston   Run the calibration tool again to generate the persistent settings: weston-touch-calibrator LVDS-1 reboot   Conclusion After completing all of the steps above, your touchscreen calibration will now persist across reboots, ensuring a consistent user experience even after powering off the board. This configuration allows the system to automatically store and apply calibration data through a udev rule generated by your helper script. If you encounter any issues or require further assistance, feel free to reach out. Best regards, Chavira

Some customer need to run Zephyr on i.MX8QM CM4, but there is no support on Zephyr mainline(v4.3.0). This article will share the i.MX8QM CM4_0 porting based on Zephyr v4.3.0.  For i.MX8QXP CM4, please refer this link: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QXP-CM4-support-on-Zephyr-v4-3-0/ta-p/2296957   samples/hello_world/ samples/synchronization   Add pd_ignore_unused in bootargs before entering Linux. For the OpenAMP communication, need to refer this Zephyr application. https://github.com/nxp-real-time-edge-sw/heterogeneous-multicore/blob/main/apps/rpmsg_str_echo/zephyr/main.c

The purpose of this document is to provide extended guidance for the selection of compatible LPDDR4 memory devices that are supported by the i.MX 91 series of processors. 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. 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.   LPDDR4 - Maximum Supported Densities SoC Max Data bus width Maximum density Assumed memory organization Notes i.MX 91 (i.MX 91xx) 16-bit 16 Gb / (2 GB) single rank, single channel device with 17-row addresses (R0 - R16) 1, 2, 3   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 91 16 Gb / (2 GB) Micron MT53E1G16D1FW-046 AAT:A MT53E1G16D1ZW-046 AAT:C 5    2 Gb / (256 MB)  Winbond  W66BP6NBHAHJ 4 8 Gb / (1 GB) Nanya NT6AN512M16AV-J1I   4 Gb / (512 MB) Nanya NT6AN256M16AV-J1I 4 8 Gb / (1 GB) ISSI IS43LQ16512B-046BLI 4 12 Gb / (1.5 GB) Micron MT53E768M16D1ZW-046 4 16 Gb / (2 GB) Intelligent Memory IMAG16L4KBBG 4 2 Gb / (256 MB) Nanya NT6AN128M16AV-J1 4 4 Gb / (512 MB) UniIC SCB11N4G160BF-04ZI 4 4 Gb / (512 MB) ISSI IS43LQ16256B-053BLI 4 4 Gb / (512 MB) Winbond W66CP6RBHAHJ 4     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: LPDDR4 devices from certain memory vendors may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low-speed operation is planned in the use case, please consult with the memory vendor about the configuration aspects and possible customization of the memory device so correct functionality is ensured. 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-4B (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: 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 SoC also supports dual rank single channel devices therefore, 16Gb/2GB density can be also achieved by using a dual rank single channel device with 16-row addresses (R0 - R15). Note 4: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 5: The memory part number is not recommended for new designs and superseded by a new part number

We are pleased to announce that Config Tools for i.MX 26.03 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.03 System Manager Memory sector information for resources with memory configuration is added to the Resources overview. Support for memory sectors splitting. Memory configuration input for resources using MBC/MRC is improved. Support for macOS (aarch64 and x86_64) is added. Clocks Hierarchy for local configuration element settings is supported. TEE Multicore Interrupt Handling for Single Security Domain is supported. Option to filter only user-defined memory regions is added. Interrupts are now separated into groups based on the core.

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  

There are currently no additional test programs in I.MX Jailhouse program. This demo shares how to test USB function in Jailhouse inmate. Inmate boot log: root@imx8mmevk:~# dmesg | grep usb [ 0.312280] usbcore: registered new interface driver usbfs [ 0.317206] usbcore: registered new interface driver hub [ 0.322279] usbcore: registered new device driver usb [ 0.911649] usbcore: registered new device driver r8152-cfgselector [ 0.917711] usbcore: registered new interface driver r8152 [ 0.994200] usbcore: registered new interface driver uas [ 0.999359] usbcore: registered new interface driver usb-storage [ 1.005192] usbcore: registered new interface driver usbserial_generic [ 1.011486] usbserial: USB Serial support registered for generic [ 1.017274] usbcore: registered new interface driver ftdi_sio [ 1.022813] usbserial: USB Serial support registered for FTDI USB Serial Device [ 1.029852] usbcore: registered new interface driver usb_serial_simple [ 1.036148] usbserial: USB Serial support registered for carelink [ 1.042016] usbserial: USB Serial support registered for flashloader [ 1.048144] usbserial: USB Serial support registered for funsoft [ 1.053931] usbserial: USB Serial support registered for google [ 1.059643] usbserial: USB Serial support registered for hp4x [ 1.065185] usbserial: USB Serial support registered for kaufmann [ 1.071051] usbserial: USB Serial support registered for libtransistor [ 1.077334] usbserial: USB Serial support registered for moto_modem [ 1.083371] usbserial: USB Serial support registered for motorola_tetra [ 1.089745] usbserial: USB Serial support registered for nokia [ 1.095368] usbserial: USB Serial support registered for novatel_gps [ 1.101486] usbserial: USB Serial support registered for siemens_mpi [ 1.107612] usbserial: USB Serial support registered for suunto [ 1.113316] usbserial: USB Serial support registered for vivopay [ 1.119111] usbserial: USB Serial support registered for zio [ 1.124578] usbcore: registered new interface driver usb_ehset_test [ 1.215499] usbcore: registered new interface driver usbhid [ 1.220879] usbhid: USB HID core driver [ 1.396384] usb_phy_generic usbphynop1: dummy supplies not allowed for exclusive requests [ 42.414253] usb 1-1: new high-speed USB device number 2 using ci_hdrc [ 42.577822] usb-storage 1-1:1.0: USB Mass Storage device detected [ 42.579492] scsi host0: usb-storage 1-1:1.0  

There are currently no additional test programs in I.MX Jailhouse program. This demo shares how to test RM67199 MIPI panel in Jailhouse inmate.   Please refer run.sh in attachments. modprobe jailhouse insmod jailhouse_clk.ko # adjust pixel clock for MIPI PANEL RMP67199 echo 129937500 > /sys/bus/platform/devices/jailhouse_clk/rate_pix export PATH=$PATH:/usr/share/jailhouse/tools/ jailhouse enable /root/imx8mm.cell jailhouse cell linux /root/imx8mm-inmate-demo.cell /root/Image.bin -d /root/imx8mm-evk-inmate.dtb -c "clk_ignore_unused console=ttymxc3,115200 earlycon=ec_imx6q,0x30890000,115200 root=/dev/mmcblk2p2 rootwait rw"  

The following table summarizes the assignment of the Low Power UARTs (LPUARTs) on the i.MX 943 EVK when running the NXP Linux BSP. LPUART instance Hardware interface FTDI channels/Pins Comment LPUART8 On-board FT4232H UART-USB adapter Channel A Used by Cortex-M33 Sync core (M33 core 1) N/A(BCU)/LPUART11/LPUART12 Channel B Used by the BCU tool, or used as serial port for Cortex-M70 (LPUART11), or Cortex-M71 (LPUART12) LPUART1 Channel C Used by Cortex-A55 (U-Boot/Linux) LPUART2 Channel D Used by Cortex-M33 (M33 core 0, System Manager) LPUART11 External UART pins (board connectors) M2_UART11_RXD M2_UART11_TXD Used by the Cortex-M70 (a UART to USB adapter is needed) LPUART12 M1_UART12_RXD M1_UART12_TXD Used by the Cortex-M71 (a UART to USB adapter is needed)   If USB DBG port is connected to a Linux host PC, the channels A..D of the FTDI will appear as /dev/ttyUSB0..3 in that order. 1. LPUART8 is used by the Cortex-M33 Sync core application. LPUART8 shares the pins with the JTAG interface, so to route these pins to the FTDI adapter, set: SW7[4] = 1 and SW7[3] = 0. 2. If the JTAG is needed, the M33 Sync core can use LPUART3 instead of LPUART8. In the MCUXSDK applications, the only required code change is to set BOARD_DEBUG_UART_INSTANCE to 3. Board pin connections for LPUART3: J51-18  - M1_PWM_CX (LPUART3_TX) ----- RX of USB-UART converter    ---- PC J44-10 - M1_LED_TP1   (LPUART3_RX) ----- TX of USB-UART converter    ---- PC J45-12 - GND                                        ----- GND of USB-UART converter ---- PC 3. The FTDI Channel B is multiplexed between two functionalities: for the Board Remote Control Utilities (BCU). In this case, set SW7[1] = 0. Do not open ttyUSB1 in a terminal while using the BCU tool. connection to LPUART11 (Cortex-M70) or LPUART12 (Cortex-M71). Set SW7[1] = 1. To select between the two UARTs, set: SW7[2] = 1 for LPUART11, or SW7[2] = 0 for LPUART12. To route the two UARTs towards the FTDI, an additional multiplexer needs to be configured through an IO expander pin (UART_M_FT_SEL in the figure below). The following software changes are required: In the MCUXSDK application source code, call BOARD_SelectFTUART() in the BOARD_InitHardware() function in hardware_init.c. In the System Manager configuration file mx94evk.cfg, move the LPI2C6 and its pins (PIN_GPIO_IO28 and PIN_GPIO_IO29) to the the M7 core that will use the routed UART. LPI2C6 is needed to set UART_M_FT_SEL. In the Linux kernel device tree, disable the I2C6 peripheral. 4. LPUART1 is routed to the FTDI Channel C and is used by the A55 core (SPL, U-Boot, Linux). This path works by default. 5. LPUART2 is routed to the FTDI Channel D and is used by the M33 Core 0 (OEI, System Manager). 6. In the default configuration, LPUART11 (M70) and LPUART12 (M71) are routed to the M2 connectors. Board pin connections for LPUART11 (for Cortex-M70): J48-2 - M2_UART11_RXD   ---- TX of USB-UART adapter     ---- PC J48-4 - M2_UART11_TXD   ---- RX of USB-UART adapter     ---- PC GND                                     ---- GND of USB-UART adapter  ---- PC Board pin connections for LPUART12 (for Cortex-M71): J44-2 - M1_UART12_RXD   ---- TX of USB-UART adapter     ---- PC J44-4 - M1_UART12_TXD   ---- RX of USB-UART adapter     ---- PC GND                                     ---- GND of USB-UART adapter  ---- PC

  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