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.    

Hello, this post describes how you can add Japanese Language to the Yocto BSP. There are just a few steps to achieve. It was tested on the i.MX93-FRDM board, i.MX93-EVK and i.MX8M (Family). And Linux kernel 6.6.36.   The first step before to start your board building according to the Yocto Project User's Guide, is adding the below lines to the local.conf file: GLIBC_GENERATE_LOCALES = "en_US.UTF-8 ja_JP.UTF-8" IMAGE_LINGUAS = "en-us ja-jp" IMAGE_INSTALL:append = " \ glibc-gconv-euc-jp \ glibc-gconv-sjis \ glibc-gconv-utf-16 \ glibc-utils \ fontconfig \ ttf-bitstream-vera \ ttf-dejavu-sans \ "   Where:  glibc-gconv-*: Adds Japanese encoding conversions.   After building, flash the Image to the board and boot it. You can check if the Japanese font was installed successfully with: root@imx93frdm:~# locale -a C POSIX en_US en_US.utf8 ja_JP ja_JP.utf8   We can see it was installed successfully: ja_JP ja_JP.utf8   Then, we can change the Language at Runtime with: root@imx93frdm:~# export LANG=ja_JP.UTF-8 root@imx93frdm:~# export LC_ALL=ja_JP.UTF-8   Finally, probe with a command that supports Japanese outputs like "date": root@imx93frdm:~# date 2024年 2月 27日 火曜日 17:29:11 UTC     I hope this information can helps to you.   Best regards, Salas.

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        

We are pleased to announce that Config Tools for i.MX v25.06 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...) • DDR – Support for i.MX 91 is added. – Synchronized with BSP Q2 release – Support for the i.MX 91 FRDM board is added. – Support for the i.MX 93 FRDM board is added. – Spectrum support for i.MX 95 and i.MX 943 is spread. – The Address mirroring option in the UI for all mscale devices with DDR3L and DDR4 is exposed. – DDR3L support for i.MX 8M and i.MX 8MM is added. – Linux support for code generation (beta) is added. • SerDes tool – i.MX 943 support (Beta) is added. • Clocks – Support for read-only element settings is added. – Filtering all settings of Initialization modules in the Details view is supported. • Peripherals – A wizard to export the Registers view data in the CSV format is supported. – Performance of the tool is improved. • An ability to export/import Expansion Boards and Expansion Headers is added.

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.

Hello everyone, in this post we will control one (or more) WS2812 LEDs from a Linux UserSpace application, communicating with Cortex M33 through RPMSG.  Required materials: FRDM-IMX93 WS2812 LED/Strip Attached wsled.c (userspace application) Attached ws2812_m33_project (Source code of firmware for M33)   Environment: Linux Kernel 6.6 arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi SDK 24.12.00   This is the block diagram of the application:        CORTEX M33 SIDE.  From WS2812  LED datasheet, we can see the timing must be precise, that is the reason we will use the Cortex M33 (Real time applications):    As we can see, the timing just accept tolerance of 150ns, that is the reason is preferred to use the Cortex M33 instead of control with Linux that is in charge of other tasks.    The function that we will implement to send Zero and One is:  void WS2812B_send_bit(uint8_t bit) { if (bit) { // Send "1" RGPIO_PinWrite(WS2812B_LED_RGPIO, WS2812B_LED_RGPIO_PIN, 1); for (int i = 0; i < HIGH_ONE_CYCLES; i++) __asm__("NOP"); RGPIO_PinWrite(WS2812B_LED_RGPIO, WS2812B_LED_RGPIO_PIN, 0); for (int i = 0; i < LOW_ONE_CYCLES; i++) __asm__("NOP"); } else { // Send "0" RGPIO_PinWrite(WS2812B_LED_RGPIO, WS2812B_LED_RGPIO_PIN, 1); for (int i = 0; i < HIGH_ZERO_CYCLES; i++) __asm__("NOP"); RGPIO_PinWrite(WS2812B_LED_RGPIO, WS2812B_LED_RGPIO_PIN, 0); for (int i = 0; i < LOW_ZERO_CYCLES; i++) __asm__("NOP"); } }     Testing and measuring the toggle timing with the RGPIO driver of Cortex M33, we could find the best number of NOP instructions to adjust with the required timing according to datasheet, and the results with core running at 200MHz are:    Parameter  Number of NOP times  HIGH_ONE_CYCLES  22  (T1H: 700 ns)  LOW_ONE_CYCLES  12  (T1L: 600 ns)  LOW_ZERO_CYCLES  20  (T0L: 800 ns)  HIGH_ZERO_CYCLES  6    (T0H: 350 ns)      Zero:   One:   Taking in mind this information, we can start to develop our application. From Cortex M33, we created a little protocol, that will wait for instructions to do.    For example, the expected string to fill the RPMSG buffer is:    Index  Purpose  Example  app_buf[0]  Command ('c' or 't')  'c' = store color in buffer  't' = show colors on LEDs  app_buf[1]  Red component (0–255)  0xFF  app_buf[2]  Green component (0–255)  0x00  app_buf[3]  Blue component (0–255)  0x80  app_buf[4]  LED index (target LED position)  e.g. 0, 1, 2    Commands:    'c'  "Color store"  This command stores the RGB color value into a local buffer, targeting a specific LED (app_buf[4]).  It doesn't update the LED strip immediately, it just prepares the data.  Example of RPMSG received buffer from Cortex A (Linux):   app_buf = { 'c', 0xFF, 0x00, 0x00, 2 };  // Store red color for LED 2     't'  "Transfer"  This command sends the full color buffer to the WS2812 strip, updating the LED colors.  The RGB values in the buffer are ignored, it simply triggers an update based on previously stored data.  Example of RPMSG received buffer from Cortex A (Linux):  app_buf = { 't', 0, 0, 0, 0 };  // Transfer the buffered colors to the LED strip     You can modify the code to add your custom commands like change number of LEDs on the strip, or change the GPIO, etc. Currently, the number of WS2812 LEDs supported is defined in software by NUM_RGB_LEDS. As default is 8 LEDs.    I will attach the full code for Cortex M33 firmware, it was tested with arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi and SDK 2_15, SDK 2_16 and SDK 24.    In this example, the EXP_GPIO_IO24 of FRDM-IMX93 was used to control the LED Strip.   CORTEX A55 SIDE.  For Cortex A55 (Linux side), we developed an userspace application, that will create the structure for the buffer to send to the Cortex M33 and send through RPMSG using the imx_rpmsg_tty included on the NXP BSP. You can find the userspace application attached.    As we know, the imx_rpmsg_tty creates the tty channel called ttyRPMSG31 under /dev. So, this userspace application communicates directly with the device /dev/ttyRPMSG31 to send the buffer with the required structure for Cortex M33.    EXAMPLE OF USAGE.    STEP 1. Compile firmware for Cortex M33 and store in FRDM-IMX93 under /lib/firmware to use with remoteproc:   STEP 2.  Compile or cross-compile the userspace application (attached.)  To compile on the platform:  root@imx93evk:~# gcc wsled.c -o wsled root@imx93evk:~# ls wsled wsled.c Also, we can copy the wsled under /bin to practicity. root@imx93evk:~# wsled Error: -c <red> <green> <blue> is required. WS2812 Usage: wsled -c <red> <green> <blue> [-n <led_position>] Load the color of exact LED to the buffer wsled -t Shows the colors to the LEDs   STEP 3. To run the entire example: boot the board and load the firmware for cortex M33 with remoteproc: root@imx93evk:~# cd /sys/class/remoteproc/remoteproc0 root@imx93evk:/sys/class/remoteproc/remoteproc0# echo ws2812_m33.elf > firmware root@imx93evk:/sys/class/remoteproc/remoteproc0# echo start > state  Then, we will receive this from Cortex M33 terminal: RPMSG String Communication Channel FreeRTOS RTOS M33 clock is at: 200000000 Hz Nameservice sent, ready for incoming messages from Cortex-A55! WSLED   Load the imx_rpmsg_tty module in Linux to initialize RPMSG: root@imx93evk:~# modprobe imx_rpmsg_tty   Then, we will have the hello world message from Cortex A (Linux side), but with our buffer format in Cortex M33 console: CMD: h [1]:0x65 [2]:0x6c [3]:0x6c [4]: 111 LEN = 12   Finally, we are ready change colors of the LEDs: Load the buffer (LED 1 = RED, LED 2 = Green, LED 3 = Blue). root@imx93evk:~# wsled -c 0x55 0x00 0x00 -n 1 root@imx93evk:~# wsled -c 0x00 0x55 0x00 -n 2 root@imx93evk:~# wsled -c 0x00 0x00 0x55 -n 3   Show colors on LEDs. root@imx93evk:~# wsled -t    

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.

This guide walks you through the required steps to prepare your development environment and hardware for debugging the M core on the FRDM-IMX93 board using the MCU-LINK Pro. You’ll install the necessary firmware, perform minor hardware modifications, compile and flash a binary, and finally, initiate a debug session using MCUXpresso for VS Code. Requirements: FRDM-IMX93 Board MCU-LINK Pro Debug Probe Soldering Station (for minor rework) PC Host with MCUXpresso for VS Code installed Adapter Cables   Install Segger Firmware on MCU-LINK Pro By default, the MCU-LINK Pro does not support i.MX processors. Installing the Segger firmware is essential for proper debugging. Follow the firmware update guide to update your MCU-LINK Pro.   Rework the FRDM-IMX93 Board The FRDM-IMX93 uses UART5 (shared with the BT module) for debug pins, which causes conflicts. To enable reliable debugging, remove the following resistors: R3017 R3018 Note: After this modification, the Bluetooth module will no longer function under Linux. Schematic: FRDM BOARD:   Note: After this rework we can't use the Bluetooth module in Linux   Compile the Binary for the M Core Ensure MCUXpresso for VS Code is properly installed.   Import the iMX93-EVK SDK   Import "hello world" example Ensure that we are compiling a debug binary   Build Project   Flash the Binary using UUU Tool Connect the FRDM Board to your Host PC via USB   Enter Fastboot Mode in U-Boot Terminal => fastboot 0   On your Host PC, navigate to the binary location and flash it using the next commands: $ cd <project_location>/armgcc/debug/ $ uuu -b fat_write sdk20-app.bin mmc X:1 hello_world.bin Note: replace the X with 0 if you are booting from eMMC or 1 if you are booting from SD Card   Connect MCU-LINK Pro to the Target To set up debugging, connect the FRDM-IMX93 board to your host computer using the MCU-LINK Pro and the J-LINK Adapter for Cortex-M. FRDM-IMX93 Debug connector:   Required Connections Use the following pin mapping between the J-LINK Adapter and the FRDM-IMX93 debug connector:   J-LINK ADAPTER        -->         FRMD-IMX93  V REF        -->      3.3v(RPI Connector pin 1 )  SWDIO        -->      SWDIO (P14 pin 2)  SWCLK        -->      SWCLK (P14 pin 1)  GND        -->      GND (P14 pin 3)   Make sure all connections are secure before powering on the board.   Launch the M Core from U-Boot Terminal Use the following commands in the U-Boot terminal: => fatload mmc X:1 80000000 hello_world.bin; cp.b 0x80000000 0x201e0000 0x10000; => bootaux 0x1ffe0000 0 Note: replace the X with 0 if you are booting from eMMC or 1 if you are booting from SD Card   Start the Debug Session Once the M core is launched, you can start your debug session in VS Code using MCUXpresso:        With the MCU-LINK Pro configured, the FRDM-IMX93 reworked, and the binary successfully flashed and executed, you are now ready to debug applications on the M core using MCUXpresso and VS Code. This setup enables a reliable development workflow for i.MX93-based projects.

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.

What we need?  USB cable Windows Host PC MCU-LINK PRO What Do You Gain? With this firmware upgrade, you will be able to debug the M core of i.MX processors (such as i.MX8 and i.MX9). Also, the cost advantage due to the MCU-LINK PRO is currently the most affordable debugger available for i.MX processors.   Firmware Upgrade Steps   Install Required Tools Install the MCUXpresso IDE, or use the MCUXpresso Installer for VS Code to install the necessary software tools.     Download Firmware Get the latest firmware from the Segger web page   Save Firmware Save the downloaded firmware in the following directory: C:\nxp\LinkServer_1.6.133\MCU-LINK_installer\probe_firmware   Backup Old Firmware Rename the existing firmware file to keep a backup.   Example: Rename firmware.s19 to old_firmware.s19   Set Jumper and Connect Place a jumper on J4 and connect the MCU-LINK PRO to the host PC via USB.   Open LinkServer CLI Launch the LinkServer CLI. If it's not installed, download it from NXP web page.   Run the Update Script Execute the following commands in the terminal: $ cd MCU-LINK_installer $ scripts\program_JLINK.cmd   Start Firmware Flash Once the MCU-LINK PRO is detected, press any key to flash the Segger firmware.     Finalize Update After a successful update, remove the jumper from J4, disconnect and reconnect the MCU-LINK PRO   Verify Installation You can confirm that the debug probe is recognized using MCUXpresso IDE, or MCUXpresso for VS Code     References: MCU-Link installation   

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