Hello! In this post, we’ll cross-compile a kernel module for Linux 6.12.    This can be done either using a standalone kernel or a Yocto-built kernel.    Requirements:  A compiled Linux kernel 6.12.  A board running the same kernel version (Linux 6.12 in this case).  A cross-compiler toolchain.    This process applies to any i.MX processor, including i.MX8, i.MX8M, i.MX8MM, i.MX8MN, i.MX8MP, i.MX93, i.MX91, i.MX95, as well as the i.MX6 and i.MX7 families.    Step 1: Compile the Linux Kernel and get the Toolchain    First, you need to compile the Linux kernel (6.12 in this case).    You can do this in a standalone environment or using Yocto.     If you are using a Standalone environment, please refer to the Chapter 4.5.12 How to build U-Boot and Kernel in standalone environment of i.MX Linux User's Guide.  Also, in that document section, you will see how to obtain the cross-compiler toolchain.    NOTE: To get the toolchain you need use Yocto at least once (for more information please refer to i.MX Yocto Project User's Guide😞  $ DISTRO=fsl-imx-xwayland MACHINE=Target-Machine bitbake core-image-minimal -c populate_sdk   At the end of the building, you can install your toolchain populated under:    yocto-bsp/build/tmp/deploy/sdk     There you will find a file called:    fsl-imx-wayland-glibc-x86_64-imx-image-core-armv8a-your-machine-name-toolchain-6.12-walnascar.sh    Execute with:  $ sudo ./fsl-imx-wayland-glibc-x86_64-imx-image-core-armv8a-your-machine-name-toolchain-6.12-walnascar.sh   If you use the default installation, you will have your toolchain under /opt in your host machine.      (If you will use the compiled kernel from Yocto, you can avoid below step)  Download Standalone Kernel source by cloning with:  $ git clone https://github.com/nxp-imx/linux-imx -b lf-6.12.y $ cd linux-imx   To build the kernel in the standalone environment for i.MX 6 and i.MX 7, execute the following commands:    $ make imx_v7_defconfig $ Make   To build the kernel in the standalone environment for i.MX 8 and i.MX 9, execute the following commands:  $ make imx_v8_defconfig $ make   The full kernel compilation is required to generate headers and symbol files required for external module compilation, even if you don't plan to boot this kernel directly.      Step 2: Write a simple Kernel Module to test    Now that your kernel is compiled, you can write a basic kernel module for testing.    Create a new directory. It will have our hello.c and Makefile.    We will create the file hello.c:  #include <linux/init.h> #include <linux/module.h> #include <linux/kernel.h> MODULE_LICENSE("GPL"); MODULE_AUTHOR("Salas"); MODULE_DESCRIPTION("A simple kernel module example for cross-compilation."); MODULE_VERSION("0.1"); static int __init hello_init(void) { printk(KERN_INFO "Hello from the kernel module!\n"); return 0; } static void __exit hello_exit(void) { printk(KERN_INFO "Goodbye from the kernel module!\n"); } module_init(hello_init); module_exit(hello_exit);   Then, create a basic Makefile to compile the modules:    # Module name obj-m += hello.o # Build flags ldflags-y += --strip-debug # Kernel source directory (provided by Yocto) KERNEL_SRC ?= /path/to/your/compiled/kernel # Build target all: $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules # Clean target clean: $(MAKE) -C $(KERNEL_SRC) M=$(PWD) clean # Install target modules_install: $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules_install   KERNEL_SRC should be your compiled kernel from your Yocto build:   yocto-bsp/build/tmp/work/your-machine-poky-linux/linux-imx/6.12.20+git/build   Or the Standalone : path/to/linux-imx/     Step 3: Set the toolchain and compile the kernel module    Finally, we can compile the kernel module.    First, set the toolchain (in my case):  $ source /opt/fsl-imx-wayland/6.12-walnascar/environment-setup-armv8a-poky-linux   Then, compile using the makefile:  $ make   f everything goes well, at final you will have the generated files:    hello.ko hello.mod hello.mod.c hello.mod.o hello.o Makefile modules.order Module.symvers   The one we need is the hello.ko (Kernel Object).    We can check if the file was created correctly using:    $ readelf -h hello.ko ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: AArch64 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 33992 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 64 (bytes) Number of section headers: 41 Section header string table index: 40   We can see the Machine is AArch64 and the Type is a Relocatable file.      Step 4: Running the Kernel Object/Module in the board    Transfer the generated hello.ko file from your host machine to your board.    Then, In your board you can run with:    root@imx93evk:~# ls hello.ko root@imx93evk:~# insmod hello.ko root@imx93evk:~# dmesg | tail [ 5140.547447] Hello world from kernel! root@imx93evk:~# rmmod hello.ko root@imx93evk:~# dmesg | tail [ 5140.547447] Hello world from kernel! [ 5153.415215] Goodbye world from kernel!   I hope this can helps to you.    Best regards,  Salas. 

  Background : Some customer want to test the LPDDR4/X ECC feature based on the i.MX93 chip, But, for now, Our DDR Config Tool do not release this test chosen. And our ECC guide only tell the ECC feature function, does not tell the customer how to test it. So in this article, Will show you more details about ECC feature and how to run the ECC test use uboot command. But I won't put the source code of the test here, You can download the binary run the test on the i.MX93 EVK board.   HW : i.MX93 EVK board with 2GB LPDDR4 SW : 6.1.1-1.0.0   ECC Introduce what is ECC?       ECC is the abbreviation of Error Correction Code. Its function is to automatically detect and repair some minor errors in the memory to prevent data errors. How does ECC work? We can think of it as an "automatic proofreader", and its workflow is roughly as follows:  When writing data: The memory controller generates a "check code" (similar to the fingerprint of the data) for each piece of data. This check code will be stored together with the data. When reading data: The memory controller will recalculate the "fingerprint". Then compare the previously stored check code to see if there is any difference. If a difference is found: If it is just a 1-bit error, ECC can automatically correct it. But, If there are multiple errors, ECC can at least detect them and issue a warning.   ECC test step: 1. Flash the attachment file to the imx93 board. 2. Enter the uboot, run the "ecc --help" command, you will see the below help output message   3. For example : ecc 0x80000000 0x90000000, it will test the ecc feature with on bit error detect and correct , 2 bits errors detect with 256MB DRM size.   if you need this ECC_ test binary file, please contact me, i will share it to you        

  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:      

The use case from one customer we are supporting requires to run i.MX93 M33 code with a combination of DRAM and on chip TCM.  However, the examples in the official MCUXpresso SDK release support to run M33 code in TCM only. So we did some customization to achieve that. User can refer to the the attached slides and patches for the details.

NETC is a TSN capable Ethernet IP, which enables a comprehensive portfolio of Ethernet solutions. One of the major capabilities offered by NETC is the support of Time Sensitive Networking (TSN). TSN is a set of standards developed by IEEE that enables Ethernet to handle time sensitive traffic in addition to best effort traffic. TSN allows time sensitive traffic and best effort traffic to co-exist on the same network, makes Ethernet deterministic with bounded low latency, and with improved reliability and resiliency. This document introduces I.MX95 NETC functional view and capabilities; Analyze IMX95 supported TSN protocols such as 802.1Qbv, 802.1Qav, 802.1Qci, IEEE1588 and stream identifying; Provide Procedures to implement the Qbv use case scenario on I.MX95.

Platform: i.MX8MP EVK, SDK 2.16   The rpmsg debug will stuck at rpmsg_queue_recv/rpmsg_lite_send when we use Step Over debug with JLink. The error log on Linux side: [ 42.422658] remoteproc remoteproc0: kicking vq index: 1 [ 42.524256] imx-rproc imx8mp-cm7: imx_rproc_kick: failed (1, err:-62) [ 42.524286] remoteproc remoteproc0: kicking vq index: 0 [ 42.628566] imx-rproc imx8mp-cm7: imx_rproc_kick: failed (0, err:-62)   The demo source code of rpmsg in SDK uses  RL_BLOCK, this flag will cause communication stuck during debug. while (msg.DATA <= 100U) { (void)PRINTF("Waiting for ping...\r\n"); (void)rpmsg_queue_recv(my_rpmsg, my_queue, (uint32_t *)&remote_addr, (char *)&msg, sizeof(THE_MESSAGE), ((void *)0), RL_BLOCK); msg.DATA++; (void)PRINTF("Sending pong...\r\n"); (void)rpmsg_lite_send(my_rpmsg, my_ept, remote_addr, (char *)&msg, sizeof(THE_MESSAGE), RL_BLOCK); }   The solution for rpmsg step over debug is that we need to use RL_DONT_BLOCK in sdk.    

share the document for ov5640 support on imx93 evk with 6.12 bsp

This post contains a guide of how to use SDMA1 on Cortex M7 in parallel of Linux on A53. For i.MX 8M Plus, SDMA1 is a general-purpose DMA engine which can be used by low speed peripherals including UART, SPI and other peripherals. But some customers found issues when they are using SDMA1 on M7 core in parallel of Linux on A53. For example, if you try to run the sdma_uart_transfer example on the i.MX8M Plus EVK, the example works correctly when interfacing through the JLink debugger.  However, you will find that you can not run it from both the remoteproc interface and U-Boot.  It exits without error from the UART_SendSDMA function,  but the callback is never called and it seems to hang waiting for the information to be sent. On the i.MX 8MP EVK board,  uart4 is used for Cortex-M7 core. This article tries to provide an example to establish communication using UART3 and SDMA1 on the i.MX 8MP EVK, while Linux is running on Core A53.  This example is based on sdma_uart_transfer demo. The steps are verified with i.MX Linux 6.12.20_2.0.0  release and SDK_25.06.00. The software is compiled on an Ubuntu 22.04 host machine. This article is structured as follows:  1  Hardware requirements 2  Software Requirements 3  Modification in application      3.1 Pin changes     3.2 Clock changes     3.3 Application specific changes     3.4 Memory Region Control change 4  ATF changes     4.1 Download ATF source and change it      4.2 build ATF 5   U-BOOT change     5.1 build u-boot     5.2 make imx-boot image by using imx-mkimage     5.3 flash imx-boot image into i.MX 8MP EVK board 6  Running and Debugging     6.1    Debugging Cortex-M while Cortex-A is in U-BOOT     6.2   Debugging Cortex-M while Cortex-A is in Linux 7  Summary   1  Hardware requirements   -PC Host with MCUXpresso for VS Code installed -i.MX 8M Plus EVK (i.MX 8M Plus Power Evaluation Kit | NXP Semiconductors) -12V power supply -Micro USB Cable -J-Link Debug Probe. -USB To TTL( serial ) Converter   connect J21 (Pin6_GND  Pin8_UART3-TXD  Pin10_UART3-RXD) to Host PC via a USB to TTL converter.       2  Software Requirements   SDK_25_06_00_EVK-MIMX8MP This package can be download from https://mcuxpresso.nxp.com/ Next I will describe the detailed steps.   3  Modification in application     3.1 Pin changes   evkmimx8mp_iuart_sdma_transfer\pin_mux.c    3.2 Clock changes   evkmimx8mp_iuart_sdma_transfer\clock_config.c In function BOARD_BootClockRUN     3.3 Application specific changes   evkmimx8mp_iuart_sdma_transfer\board.h      app.h   Till now, we have completed all the changes for change uart4 to uart3. Compile , and debug with J-LINK, we can get the correct result.   Board receives 8 characters then sends them out.   However, if we try to load code on Cortex-M from U-Boot or Linux,  we can not get the expected results.   Below steps is a workaround to fix this issue. 3.4 Memory Region Control change   hardware_init.c In function BOARD_InitHardware ..... Then compile the application, the output are  iuart_sdma_transfer.bin and iuart_sdma_transfer_cm7.elf   4  ATF (ARM Trust Firmware)changes   4.1  Download ATF source and Change it  The RDC configuration in default BSP assign UART2 to domain 0 for A53,  and Domain 0 can read/write RDC,  and Domain 1 (M7) only can read it. $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.12.3-1.0.0   GitHub - nxp-imx/imx-atf: i.MX ARM Trusted firmware plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c We need to assign UART3 to domain 1 so Cortex M7 can access   4.2 build ATF      $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.12.3-1.0.0 $ cd imx-atf $ source /opt/fsl-imx-xwayland/6.12-walnascar/environment-setup-armv8a-poky-linux $ export ARCH=arm64 $ unset LDFLAGS $ make PLAT=imx8mp bl31   This builds the bl31.bin binary, the location is : build/imx8mp/release/bl31.bin   5   U-BOOT change   5.1 Download and build u-boot please refer to chapter 4.5.13 How to build imx-boot image by using imx-mkimage ,   $ git clone https://github.com/nxp-imx/uboot-imx -b lf_v2025.04 $ cd uboot-imx/ $ source /opt/fsl-imx-xwayland/6.12-walnascar/environment-setup-armv8a-poky-linux $ export ARCH=arm64 $ make distclean $ make imx8mp_evk_defconfig $ make   The compiled u-boot.bin location uboot-imx/u-boot.bin   5.2 make imx-boot image by using imx-mkimage   My work folder The following steps allow you to build the bootable image for i.MX 8M Plus EVK, there are 9 files needed to generate a bootable image: ├── u-boot-spl.bin ├── u-boot-nodtb.bin   ├── imx8mp-evk.dtb ├── bl31.bin ├── signed_hdmi_imx8m.bin ├── lpddr4_pmu_train_1d_dmem_202006.bin ├── lpddr4_pmu_train_1d_imem_202006.bin ├── lpddr4_pmu_train_2d_dmem_202006.bin └── lpddr4_pmu_train_2d_imem_202006.bin   Once you have the nine files , use imx-mkimage tool. 5.2.1  Download source : $ git clone https://github.com/nxp-imx/imx-mkimage.git -b lf-6.12.20-2.0.0   5.2.2  Copy and rename mkimage from u-boot/tools/mkimage to imx-mkimage/iMX8M/mkimage_uboot. $ cp uboot-imx/tools/mkimage imx-mkimage/iMX8M/mkimage_uboot   5.2.3 Copy u-boot-spl.bin from u-boot/spl/u-boot-spl.bin to imx-mkimage/iMX8M/ $ cp uboot-imx/spl/u-boot-spl.bin imx-mkimage/iMX8M/   5.2.4 Copy u-boot-nodtb.bin from u-boot/u-boot-nodtb.bin to imx-mkimage/iMX8M/ $ cp uboot-imx/u-boot-nodtb.bin imx-mkimage/iMX8M/   5.2.5 Copy  imx8mp-evk.dtb from u-boot/arch/arm/dts/ to imx-mkimage/iMX8M/. $cp uboot-imx/u-boot.dtb imx-mkimage/iMX8M/imx8mp-evk.dtb   5.2.6 Copy bl31.bin from Arm Trusted Firmware (imx-atf) to imx-mkimage/iMX8M/ $ cp imx-atf/build/imx8mp/release/bl31.bin imx-mkimage/iMX8M/   5.2.7 Copy the LPDDR4 Training Firmware Download LPDDR Training Firmware cd ~/work wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.16.bin chmod +x firmware-imx-8.16.bin ./firmware-imx-8.16.bin   copy below files from firmware/ddr/synopsys of the firmware-imx package to imx-mkimage/iMX8M/ lpddr4_pmu_train_1d_dmem_202006.bin  lpddr4_pmu_train_1d_imem_202006.bin lpddr4_pmu_train_2d_dmem_202006.bin lpddr4_pmu_train_2d_imem_202006.bin    $ cp firmware-imx-8.16/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_202006.bin imx-mkimage/iMX8M/ $ cp firmware-imx-8.16/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_202006.bin imx-mkimage/iMX8M/ $ cp firmware-imx-8.16/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_202006.bin imx-mkimage/iMX8M/ $ cp firmware-imx-8.16/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_202006.bin imx-mkimage/iMX8M/    5.2.8 Copy firmware/hdmi/cadence/signed_hdmi_imx8m.bin from the firmware-imx package to imx-mkimage/iMX8M/.   $ cp firmware-imx-8.16/firmware/hdmi/cadence/signed_hdmi_imx8m.bin imx-mkimage/iMX8M/   The folder structure after copying all the necessary files     5.2.9 Build the bootable image run make SOC=iMX8MP flash_evk to generate imx-bootimage. $ cd imx-mkimage $ make SOC=iMX8MP flash_evk The compiled file is flash.bin and its location iMX8M/flash.bin   5.3 flash imx-boot image into i.MX 8MP EVK board   In order to flash the imx-boot image,  please follow the following steps -copy  uuu.exe and flash.bin in a folder -change the board's SW4 (boot mode) to 0001 to enter serial download mode  uuu.exe -b emmc  flash.bin   uuu.exe -b emmc flash.bin -power off the board, change SW4 to switch the board back to 0010 (eMMC boot mode).    6  Running and Debugging   Download the application (iuart_sdma_transfer.bin and iuart_sdma_transfer_cm7.elf) to /run/media/boot-mmcblk1p1   6.1    Debugging Cortex-M while Cortex-A is in U-BOOT   $ fatload mmc 2:1 0x48000000 iuart_sdma_transfer.bin $ cp.b 0x48000000 0x7e0000 30000; $ bootaux 0x7e0000   $ fatload mmc 2:1 0x48000000 iuart_sdma_transfer2.bin $ cp.b 0x48000000 0x7e0000 30000; $ bootaux 0x7e0000 From M7 console, we can see the output   6.2   Debugging Cortex-M while Cortex-A is in Linux   u-boot=> setenv fdtfile 'imx8mp-evk-rpmsg.dtb' u-boot=>run prepare_mcore u-boot=>boot   u-boot=> setenv fdtfile 'imx8mp-evk-rpmsg.dtb' u-boot=>run prepare_mcore u-boot=>boot Linux system boot up:   echo /run/media/boot-mmcblk2p1/iuart_sdma_transfer_cm7.elf > /sys/class/remoteproc/remoteproc0/firmware echo start > /sys/class/remoteproc/remoteproc0/state Then we can see the output from M7 console.   7  Summary   This is a workaround to run UART with SDMA1 enabled on Cortex-M7,  and Linux running on Cortex-A53 in parallel.  In order to do that, we need to modify the ATF, and U-BOOT, and application.   With the above modifications, I can get the expected results.   References: 1. UG10163: i.MX Linux User's Guide Rev LF6.12.20_2.0.0--26 June 2025        

This guide provides a clear overview of how different versions of GUI Guider integrate with LVGL and the supported rendering backends: DRM and Wayland. It also explains how to configure and run your application based on the selected backend. Switching between backends is straightforward—simply modify a few lines in the lv_conf.h file, located in the lvgl folder of the code generated by GUI Guider.   Default Rendering Backends by GUI Guider Version GUI Guider Version LVGL v8 LVGL v9 1.9.1 DRM WAYLAND 1.9.0 WAYLAND WAYLAND   Note: Only one configuration (DRM or Wayland) can be used at a time. Configuration Settings in lv_conf.h To use DRM, set the following: #define LV_USE_WAYLAND 0 #define LV_USE_LINUX_DRM 1   To use Wayland, set: #define LV_USE_WAYLAND 1 #define LV_USE_LINUX_DRM 0   Running LVGL with DRM Before launching the gui_guider binary in DRM mode, you must stop the Weston service: systemctl stop weston ./gui_guider Note: These steps must be executed via the debug console or over SSH, as stopping Weston will disable the desktop environment and make the local display unavailable Running LVGL with Wayland No special steps are required. Simply run the binary: ./gui_guider   You can refer to the following guides to learn how to compile GUI Guider binaries according to the version you are using: Build GUI Guider projects for iMX93 (GUI GUIDER 1.9.X)  Build GUI Guider projects for iMX93 (GUI GUIDER 1.6.x, 1.7.x, 1.8x)   

The documentation is about to present a detailed build steps to implement the verification of the integrity of the rootfs for i.MX8ULP.

the enclosed code is based on How to fuse key through nvmem on i.MX93 - NXP Community and modified for the imx8mp, this article about how to fuse mac address via fuse command in the uboot or nvmem in the kernel  ================================================================ 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.

OK-MX93 SPI2CAN/ADC Release Documentation Overview This document describes how to use the KV11Z SPI2CAN driver to implement IMX93 peripheral interface expansion. The driver connects to the KV11Z microcontroller via SPI interface, extending CAN bus and ADC acquisition capabilities for the IMX93 processor. Key Features: CAN Bus Extension: Provides 1Mbps CAN 2.0A/B communication capability ADC Acquisition Extension: Supports 8-channel 16-bit ADC with 1kHz sampling rate per channel Standard Interface: Fully compatible with Linux CAN Socket API and IIO subsystem High-Performance Transfer: Efficient data transfer architecture based on SPI+DMA+interrupt With this driver, developers can easily implement industrial-grade CAN communication and multi-channel analog signal acquisition on the IMX93 platform. System Architecture System Architecture Diagram Hardware Connection Description IMX93 and KV11Z are connected via standard SPI bus: MOSI: Master Output, Slave Input MISO: Master Input, Slave Output SCLK: SPI clock signal CS: Chip select signal (controlled by GPIO) IRQ: Interrupt signal (KV11Z to IMX93) Important Configuration Notes: Must use GPIO CS + DMA method, main controller CS method has known issues For device tree configuration, refer to the  OK-MX93-C.dts  file in the project SPI frequency recommended to be set at 7-12.5MHz, DMA configuration recommended to be enabled Data Flow Diagram Directory Structure . ├── adctest.c ├── build.sh ├── cantest.c └── OKMX93-linux-kernel-6.1.36 ├── arch │   └── arm64 │   └── boot │   └── dts │   └── freescale │   └── OK-MX93-C.dts └── drivers └── net └── can └── kv11z_spi2can.c Core Components 1. kv11z_spi2can.c - Core Driver Program Function: KV11Z SPI2CAN/ADC Linux kernel driver Implements CAN network device interface, supports standard Linux CAN Socket API Implements IIO ADC device interface, supports multi-channel ADC data acquisition Communicates with KV11Z microcontroller via SPI protocol Supports interrupt-driven high-performance data transfer Key Features: CAN Function: Supports standard and extended CAN frames, configurable baud rate and filters (under development) ADC Function: 8-channel ADC acquisition, supports triggered buffer mode and direct read mode High Performance: Multi-threaded architecture, supports concurrent CAN and ADC operations Configurable: Rich module parameters, supports runtime tuning Module Parameters: # CAN Configuration g_can_bitrate=1000000 # CAN baud rate (default 1Mbps) # ADC Configuration g_adc_mask=0xFF # ADC channel enable mask (default all channels) g_adc_sample_rate=1000 # ADC sampling rate (default 1kHz) # SPI Configuration spi_speed=7000000 # SPI bus speed (default 7MHz) transfer_time_us=30 # SPI transfer interval (default 30μs) # Debug Options debug=0 # Debug information switch (0=off, 1=on) 2. adctest.c - ADC Test Application Function: ADC data acquisition test tool Supports two ADC reading modes: direct mode and buffer mode Provides real-time data display and CSV file output Supports timestamps and performance statistics Hardware compatibility detection and channel validation Key Features: Dual Mode Support: Direct read mode (sysfs) and buffer mode (IIO buffer) Flexible Configuration: Configurable channel mask and sampling rate Data Export: Supports CSV format data export for subsequent analysis Real-time Display: Color terminal output and statistical information Usage Examples: # Compile gcc -O2 -o adctest adctest.c # Buffer mode, enable channels 0-3, with timestamps ./adctest -m 1 -c 0x0F -t # Direct mode, 500ms sampling interval ./adctest -m 0 -d 500000 # Save data to CSV file ./adctest -m 1 -f /tmp/adc_data # View help ./adctest -h 3. cantest.c - CAN Bus Test Tool Function: Comprehensive CAN bus testing and benchmarking tool Supports CAN frame generation, transmission and reception Provides MD5 verification to ensure data integrity Supports file transfer over CAN bus Real-time performance monitoring and statistical analysis Key Features: Performance Testing: Supports bulk transmission testing of large numbers of frames Data Integrity: MD5 verification ensures transmission data integrity File Transfer: Supports arbitrary file transfer over CAN bus Real-time Monitoring: Progress bar display, FPS statistics, error statistics, etc. Usage Examples: # Compile gcc -O2 -o cantest cantest.c # Transmitter: Send 1000 random CAN frames ./cantest -i can0 -t -n 1000 -d 1000 # Receiver: Receive CAN frames and verify ./cantest -i can0 -r # File transfer transmitter ./cantest -i can0 -t -f /path/to/file # File transfer receiver ./cantest -i can0 -r -f /path/to/output # View help ./cantest -h Quick Start 1. Environment Setup Ensure cross-compilation toolchain is installed: # Set cross-compilation environment source environment-setup-aarch64-toolchain 2. Build System # Complete build ./build.sh all # Or step-by-step build ./build.sh uboot ./build.sh kernel ./build.sh apps ./build.sh mkfs 3. Deploy Driver # Load driver module insmod kv11z_spi2can.ko # Configure CAN interface ip link set can0 type can bitrate 1000000 ip link set can0 up # Verify ADC device ls /sys/bus/iio/devices/ 4. Function Testing # Test ADC function ./adctest -m 1 -c 0xFF -t # Test CAN function ./cantest -i can0 -t -n 100 Technical Specifications Hardware Requirements Main Controller: OK-MX93 development board (IMX93 processor) Co-processor: KV11Z microcontroller Interface: SPI bus connection CAN: Supports CAN 2.0A/B protocol ADC: 8-channel 12-bit ADC Performance Metrics CAN Baud Rate: Up to 1Mbps ADC Sampling Rate: Up to 1kHz (per channel) SPI Speed: Up to 12.5MHz Latency: CAN frame transmission latency ≤1ms Throughput: Supports 7500 frames/second CAN transmission Software Compatibility Kernel Version: Linux 6.1.36 Architecture: ARM64 (aarch64) Compiler: GCC cross-compilation toolchain API: Standard Linux CAN Socket API, IIO subsystem API Troubleshooting Common Issues Compilation Failure Check if cross-compilation environment is correctly set Confirm all dependency packages are installed Driver Loading Failure Check if device tree configuration is correct Confirm SPI interface and GPIO configuration CAN Communication Abnormal Check CAN bus hardware connections Verify if baud rate configuration matches ADC Data Abnormal Check ADC channel mask configuration Verify if sampling rate setting is reasonable Debugging Methods # Enable driver debug information echo 1 > /sys/module/kv11z_spi2can/parameters/debug # View system logs dmesg | grep kv11z # Check device status cat /proc/interrupts | grep kv11z Technical Support For technical support, please contact the development team or refer to relevant technical documentation. Note: This software package is only applicable to OK-MX93 development board. Please ensure hardware configuration is correct before use.Other boards please porting by yourself. 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."

Introduction. In some cases, such as development stages, testing, validate flash process from zero, etc. It is needed to erase the eMMC storage device, here is described the process and the required equipment: Required equipment. i.MX93 FRDM board (this is the selected board for this post, it works for others). Debug USB-C cable. Data USB-C cable. Micro SD (16GB recommended). Personal computer. How to erase the eMMC? This method will use another boot source (Micro SD) to erase the eMMC so, it is needed to flash the Micro SD with at least the bootloader (U-boot), you can use a prebuilt image for the EVK board, it can be downloaded from the following link. But, in the case of i.MX93 FRDM board, there is no pre-built image available and needs to be build: The FRDM-IMX93 BSP release is based on i.MX SW 2024 Q3 release with Yocto Project 5.0 (Scarthgap). To build FRDM-IMX93 image from source code, please first check i.MX Yocto Project User's Guide to get familiar with Yocto project and Yocto build. Then please follow below steps to build image for FRDM-IMX93. 1. Download i.MX SW 2024 Q3 BSP Release: $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.36-2.1.0.xml $ repo sync 2. Integrate FRDM-MX93 layer into Yocto code base: $ cd ${MY_YOCTO}/sources $ git clone https://github.com/nxp-imx-support/meta-imx-frdm.git 3. Yocto Project Setup: $ MACHINE=imx93frdm DISTRO=fsl-imx-xwayland source sources/meta-imx-frdm/tools/imx-frdm-setup.sh -b frdm-imx93 4. Build images: $ bitbake imx-image-full The flashing process can be consulted here. Once the board is flashed, we need to change the boot switches to boot from Micro SD and turn-on the board. To debug this process, we will use Tera Term terminal with the board connected from the Micro USB debug cable to the PC and select the next configuration: Please verify that you are selecting the corresponding COM for Cortex-A debug. After boot we need to press a key, and the board will enter to U-boot. So, then we need to select the partition of the eMMC with the next command: u-boot=> mmc dev <storage device> <partition> In the case of the eMMC, the storage device corresponds to the device "0" and if the device has an image flashed into the eMMC e.g. Linux, the device will have three partitions from 0 to 2. The next command will select the eMMC and the boot partition area: u-boot=> mmc dev 0 0 switch to partitions #0, OK mmc0(part 0) is current device Depending on the device, image, etc. This partition size can vary so, we need to know how many blocks it has. We can use the next command that will let us know the max address value that is assigned to this partition by getting an error on the address that is out of the range. u-boot=> mmc read ${loadaddr} 0x7fffffff 1 MMC read: dev # 0, block # 2147483647, count 1 ... MMC: block number 0x80000000 exceeds max(0x1d5a000) 0 blocks read: ERROR Now, with this information, we are able to erase the entire partition with the next command: u-boot=> mmc erase 0 0x1d5a000 MMC erase: dev # 0, block # 0, count 30777344 ... 30777344 blocks erased: OK As mentioned before, the device has multiple partitions so, this process needs to be done in each partition Boot area Partition. User Area 1 Partition. User Area 2 Partition. But the process is the same, let's change the partition to User Area 1: u-boot=> mmc dev 0 1 switch to partitions #1, OK mmc0(part 1) is current device  Confirm the size of the partition: u-boot=> mmc read ${loadaddr} 0x7fffffff 1 MMC read: dev # 0, block # 2147483647, count 1 ... MMC: block number 0x80000000 exceeds max(0x2000) 0 blocks read: ERROR And erase it: u-boot=> mmc erase 0 0x2000 MMC erase: dev # 0, block # 0, count 8192 ... 8192 blocks erased: OK And let's finish with User Area 2 Partition: u-boot=> mmc dev 0 2 switch to partitions #2, OK mmc0(part 2) is current device u-boot=> mmc read ${loadaddr} 0x7fffffff 1 MMC read: dev # 0, block # 2147483647, count 1 ... MMC: block number 0x80000000 exceeds max(0x2000) 0 blocks read: ERROR u-boot=> mmc erase 0 0x2000 MMC erase: dev # 0, block # 0, count 8192 ... 8192 blocks erased: OK With this done, the eMMC is completely erased and you can confirm it by turning off the board, change the boot switched to eMMC, remove the SD card and turn-on the board.  Since there is not a bootable image into the boot source, the board will jump to serial download mode and you can verify connecting the USB data cable to the board and run the next command in UUU: Conclusion. Erasing the eMMC of the board is optional step in your development stage but also helpful for testing or system recovery (e.g. test manufacture mode). By using a Micro SD you can access to the eMMC and do all the modifications in the partitions that you want without issues. With this you can go to a clean storage state into the boot device and test a new image from scratch or test recovery methods in your design.

Platform: I.MX8MMEVK uboot version:  uboot-imx_lf_v2023.04 BSP: 6.1.x Add patch in uboot git clone https://github.com/nxp-imx/uboot-imx.git git checkout lf_v2023.04 git apply 0001-Enable-imx8mm-pcie-driver-v2023.04.patch   test log: u-boot=> pci enum pcie phy base: 0x32f00000, size 0x10000 pcie phy pll is locked after 0 us. Link up, Gen1 u-boot=> pci BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 00.00.00 0x16c3 0xabcd Bridge device 0x04 01.00.00 0x1131 0x3003 Network controller 0x00 01.00.01 0x1131 0x3004 Network controller 0x00  

Hello everyone! In this document you'll find an example on how to build your own flash.bin for i.MX93 low power mode where only the Cortex-M33 rom is running after Power-On Reset, the following table provides the boot devices supported for LP boot: In LP boot, up to three containers (NXP and OEM containers) are expected to be handled by CM33 ROM code. • NXP container (optional): EdgeLock Enclave FW only (must-have in case NXP container present) • OEM container (mandatory), contains: — CM33 FW (must-have) — FCB Region Copy Image (optional) Requirements: Ubuntu 20.04 or later host PC i.MX93 EVK UUU Tool ARM GNU Toolchain (arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu) SDK package (SDK_2_16_000_MCIMX93-EVK) Build procedure: Clone imx-mkimage, it is better to use the same SW version for each source we are working with, please refer to i.MX Linux Release Notes document, table 3. BSP and multimedia standard packages for this information. $ git clone https://github.com/nxp-imx/imx-mkimage -b lf-6.6.52-2.2.0 Decompress the GNU toolchain into a path in local disk, in this guide would be /opt $ sudo tar -xvJf arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt Clone and build Uboot $ git clone https://github.com/nxp-imx/uboot-imx -b lf-6.6.52-2.2.0 $ cd uboot-imx $ make -j $(nproc --all) clean $ make -j$(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- imx93_11x11_evk_defconfig $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- Download and extract i.MX firmware $ cd .. $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-1.3.0-17945fc.bin $ chmod +x firmware-ele-imx-1.3.0-17945fc.bin $ ./firmware-ele-imx-1.3.0-17945fc.bin --auto-accept Optional if using AHAB FW $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.26-d4c33ab.bin $ chmod +x firmware-imx-8.26-d4c33ab.bin $ ./firmware-imx-8.26-d4c33ab.bin --auto-accept Clone and build ATF $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.6.52-2.2.0 $ cd imx-atf $ make -j $(nproc --all) PLAT=imx93 bl31 CROSS_COMPILE=/opt/arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- Build M33 code, in this example we are using hello world from the i.MX SDK package. $ cd .. $ tar -xvzf SDK_2_16_000_MCIMX93-EVK.tar.gz $ cd SDK_2_16_000_MCIMX93-EVK/boards/mcimx93evk/demo_apps/hello_world/armgcc $ export ARMGCC_DIR=~/gcc-arm-none-eabi-10.3-2021.10 $ export PATH=$PATH:~/gcc-arm-none-eabi-10.3-2021.10 $ ./build_release.sh Copy the resulting binaries to imx-mkimage $ cp ~/imx-atf/build/imx93/release/bl31.bin ~/imx-mkimage/iMX93 $ cp ~/uboot-imx/u-boot.bin ~/imx-mkimage/iMX93 $ cp ~/uboot-imx/spl/u-boot-spl.bin ~/imx-mkimage/iMX93 $ cp release/sdk20-app.bin ~/imx-mkimage/iMX93/m33_image.bin Copy i.MX firmware to imx-mkimage $ cd .. $ cp firmware-imx-8.26-d4c33ab/firmware/ddr/synopsys/lpddr4_imem_1d_v202201.bin ~/imx-mkimage/iMX93 $ cp firmware-imx-8.26-d4c33ab/firmware/ddr/synopsys/lpddr4_dmem_1d_v202201.bin ~/imx-mkimage/iMX93 $ cp firmware-imx-8.26-d4c33ab/firmware/ddr/synopsys/lpddr4_dmem_2d_v202201.bin ~/imx-mkimage/iMX93 $ cp firmware-imx-8.26-d4c33ab/firmware/ddr/synopsys/lpddr4_imem_2d_v202201.bin ~/imx-mkimage/iMX93 $ cp firmware-ele-imx-1.3.0-17945fc/mx93a1-ahab-container.img ~/imx-mkimage/iMX93 Build the flash.bin using mkimage, we have different target memory options for lpboot $ cd imx-mkimage eMMC/SD $ make SOC=iMX9 REV=A1 flash_lpboot eMMC/SD no AHAB $ make SOC=iMX9 REV=A1 flash_lpboot_no_ahabfw Flexspi $ make SOC=iMX9 REV=A1 flash_lpboot_flexspi Flexspi no AHAB $ make SOC=iMX9 REV=A1 flash_lpboot_flexspi_no_ahabfw Flexspi XiP $ make SOC=iMX9 REV=A1 flash_lpboot_flexspi_xip Change the binary name so we can identify and it is easier when flashing $ mv flash.bin flash_m33_lpboot.bin Also, build singleboot flashbin so we can use it to run UUU and flash the lpboot binary $ make SOC=iMX9 REV=A1 flash_singleboot $ mv flash.bin flash_UUU.bin Set SW1301 for serial download on the EVK (0011), connect debug, download and power cables and turn on the EVK. Flash the resulting binary into the EVK for the respective target (SD/eMMC/FSPI) $ uuu -b sd flash_UUU.bin flash_m33_lpboot.bin $ uuu -b emmc flash_UUU.bin flash_m33_lpboot.bin $ uuu -b qspi flash_UUU.bin lash_m33_lpboot.bin Once it is done change SW1301 to the respective bootmedia SD Low power boot (1010) eMMC Low power boot (1000) FlexSPI NOR Low power boot* (1101) *Note M.2 QSPI card is required for FlexSPI Boot option, since QSPI memory is not populated into the EVK Power on the board, and the example should be running on the Cortex-M33 terminal only. Hope everyone finds this useful! For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.

give an example for bring up the imx8mq DP/eDP board based on nxp SW

Test environment: i.MX93FRDM LF6.6.36. With Yocto training.

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.

Test environment: i.MX8ULP EVK, SDK2.16 Some customer want to use LPUART2 in DSP domain on M33. This patch is based on lpuart_polling.   Hardware test point: If you send data from uart2, you will get such log from M33 console: reg = d2000000, 94000000 LPUART_WriteBlocking get readbuf = 73 get readbuf = 73  

We are pleased to announce that Config Tools for i.MX v25.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...) • Output Paths Overrides for toolchain project is fixed. • "Filter source files" search bar with case-sensitive checkbox is removed. • TEE – Sort for Peripheral Configurations table is added. DDR tool (part of Config tools for i.MX 25.03😞 [MX91] Added 1Gb and 2Gb DRAM configurations in the GUI. [MX9x] Enhanced Diagnostic tests to display DBI lane when DBI is enabled. [MX95][FW2024.09] Optimized PLL settings. [MX95][FW2024.09] Included missing registers in the retention list. [Mscale] Added a temperature derating GUI option for devices with LP4. [8MP] Updated PMIC configuration to correctly set 1.2V for 8M-Plus. [8MN] Improved board bus configuration. Enabled maximum number of available frequencies setpoints for all supported devices. Added EVK default configuration for all supported devices.