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.

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.

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.

Attached package includes BSP patch for AI Robot Platform Based on i.MX 8M Plus  Version 6.1.55 : Rel_imx_6.1.55-2.2.0_8mp_airobot.tar.gz

This tutorial outlines the steps required to set up and build a Yocto image for the FRDM-IMX93 board, including integrating the meta-imx-frdm recipes and applying a patch to enable UART3 support. Required Materials A computer running Linux (Ubuntu 22.04) FRDM-IMX93 board Network cable or WiFi configured on the board USB C cables   Installing the repo Utility $ mkdir ~/bin $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=${PATH}:~/bin Downloading i.MX Linux Yocto Release $ mkdir ${MY_YOCTO} # This directory will be the top-level directory $ cd ${MY_YOCTO} $ 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 If errors occur during repo init, remove the .repo directory and run repo init again.   Integrating meta-imx-frdm Recipes into Yocto $ cd ./sources $ git clone https://github.com/nxp-imx-support/meta-imx-frdm.git $ cd meta-imx-frdm $ git checkout imx-frdm-1.0   Applying the Patch $ mv /home/<user_name>/Downloads/FRDM-IMX93-LPUART3-SUPPORT.patch . $ git apply FRDM-IMX93-LPUART3-SUPPORT.patch Setting Up the Build Environment $ cd ../../ $ MACHINE=imx93frdm DISTRO=fsl-imx-xwayland source sources/meta-imx-frdm/tools/imx-frdm-setup.sh -b frdm-imx93 Compiling the Kernel $ bitbake -c deploy virtual/kernel Once the compilation is complete, the new device tree will be located at: tmp/deploy/images/imx93frdm/imx93-11x11-frdm.dtb Flashing the Modified Device Tree You can flash the modified device tree using the uuu tool with the method described in this community post   To flash the device tree using network method, boot the board and connect it to the network using a cable or WiFi. Then, use scp to transfer the file. #For eMMC Boot $ cd tmp/deploy/images/imx93frdm/ $ scp imx93-11x11-frdm.dtb root@<frdm_ip>:/run/media/boot-mmcblk0p1/ $ reboot #For SD Boot $ cd tmp/deploy/images/imx93frdm/ $ scp imx93-11x11-frdm.dtb root@<frdm_ip>:/run/media/boot-mmcblkp1/ $ reboot   Using UART3 After rebooting, UART3 will be available on GPIO14 and GPIO15 of the RPi connector on the board.     Results:  

GUI Guider version:  1.9.x LVGL version: v8.x.x , v9.x.x Host software requirements: Ubuntu 20.04, Ubuntu 22.04 or Debian 12 Hardware requirements: FRDM i.MX 93 Development Board i.MX 93 Evaluation Kit   Steps: 1. Export your project from the folder GUI-Guider-Projects to your Linux PC.            2. Build an image for iMX93 using The Yocto Project.    a. Based on iMX Yocto Porject Users Guide set directories and download the repo $ mkdir imx-bsp-6.6 $ cd imx-bsp-6.6 $: repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.52-2.2.0.xml $ repo sync Use distro fsl-imx-xwayland and select machine imx93evk and use this commnad with a build folder name: $ MACHINE=imx93evk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh - b bld-imx93evk b. Use bitbake command to start the build process. Also, add the -c populate_sdk to get the toolchain. $ bitbake imx-image-full -c populate_sdk  c. Install the Yocto toolchain located on <build-folder>/tmp/deploy/sdk/.  $ sudo sh ./fsl-imx-xwayland-glibc-x86_64-imx-image-full-armv8a-imx93evk-toolchain-6.6-scarthgap.sh d. Install ninja utility on the build host $ sudo apt update $ sudo apt upgrade -y $ sudo apt install ninja-build e. Unzip the gui guider and lvgl sources $ cd meta-gui-guider/recipes-graphics/gui-guider/gui-guider/ $ unzip gui-guider.zip $ cd ../../lvgl/lvgl/ $ unzip lvgl.zip $ cd ../../gui-guider/gui-guider/ $ mv ../../lvgl/lvgl/ . $ cd ports/linux/ f. Change the interpreter on build.sh from #!/bin/sh to #!/bin/bash. $ nano build.sh -- #!/bin/sh ++ #!/bin/bash g. use the following commands to make build.sh executable $ dos2unix build.sh $ chmod +x build.sh h. Execute the build.sh $ ./build.sh i. Copy the binary to the iMX93 using a USB or SCP.    RESULTS:     I hope this article will be helpful

Platform: i.MX8MP EVK L6.6.52 , SDK2.16 The rpmsg_lite_pingpong_rtos demo in SDK will complete 100 times ping-pong and then destory the rpmsg connection and related resources. For Linux kernel, there is no such rpmsg api to finish similiar thing,  which will case imx-rproc imx8mp-cm7: imx_rproc_kick: failed (0, err:-62) , this error indicates that the remoteproc is still try to kick up M7 after rpmsg_lite_pingpong_rtos destory the rpmsg resources.   Here is a simple workaround for this error. 1. drivers/rpmsg/imx_rpmsg_pingpong.c Destory ept when saying goodbye. 2.drivers/rpmsg/virtio_rpmsg_bus.c Disable virtuequeue callback(->imx_rproc_kick) in _rpmsg_destory_ept.   Result: No imx-rproc imx8mp-cm7: imx_rproc_kick: failed (0, err:-62) after 100 times ping-pong    

Introduction There are some cases where it is needed to flash the image from a removable boot source (e.g. an SD card) to another boot source (e.g. eMMC), according to our documentation this can be done via dd but this does not work in the case you would like to do all the process in the board caused by the eMMC partition structure. 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 (64GB memory used in this test). Personal computer. The default partition configuration for an eMMC device is as follows: Where: - Boot areas are used for bootloader and environment configurations. - Replay-protected memory-block area (RPMB) is used to store secure data. - User area used for application data such as file system, usually divided in two or more partitions. In the case of an image, the eMMC is organized according to the next diagram: - Boot area 1 is used to store SPL and U-boot with no file system in a fixed offset according to each processor as mentioned in i.MX Linux User's Guide section 4.3 Preparing an SD/MMC card to boot. - User area partition 1 uses a FAT format where Kernel and Device Tree files are stored. - User area partition 2 is used for root file system with Ext3/Ext4 format. Exception Our documentation has a method to flash .wic image which contains all the mentioned above or each part manually using an SD card connected to a host Linux machine via dd command: sudo dd if=<image name>.wic of=/dev/sdx bs=1M && sync Or set up the partitions manually such as bootloader: sudo dd if=<U-Boot image> of=/dev/sdx bs=1k seek=<offset> conv=fsync Also, copying the kernel image and DTB file and the root file system as mentioned in i.MX Linux User's Guide. This method works for SD card since the data is stored in user area and the offset changes to burn the bootloader. This fails when we try to flash the image from SD card to eMMC. How to reproduce the issue? First, we need to erase the eMMC, here a post to achieve this task. Format boot partition of eMMC from U-boot - NXP Community How to flash image from SD card to eMMC? With the eMMC erased, we need a boot source to store and flash the image, in this case the SD card. Once the image is flashed into the Micro SD, we need to copy the necessary files such as bootloader and image. By default, our BSP has a User Area space of <>GB and we need to increase it to save the bootloader and the image, here the steps: Verify the device and partition numeration: lsblk The command to increase the size of the partition is the next: parted /dev/<storage unit> unit MiB resizepart <partition> <size in bytes> And the command to apply the changes is: resize2fs /dev/<storage and partition unit>  In this case, the device and partition we need to change is mmcblk0p2 so, the command is as follows: parted /dev/mmcblk0 unit MiB resizepart 2 10000 I increased the partition size by 10000 MB; this will be enough to store the required files. And now, we need to apply the changes: resize2fs /dev/mmcblk0p2 In the board will look like this: Now, let's copy the bootloader and root file system in SD. In this post we will use SCP: Now, we need to boot from SD card and run the next commands: As is mentioned in Linux User's guide, we need to flash the .wic image. This contains all the necessary data to flash the entire image but when flashing from SD card to eMMC we need to follow additional steps to unlock the partition used to store the bootloader: sudo dd if=<image name>.wic of=/dev/sdx bs=1M && sync Disable write protection: echo 0 > /sys/block/<storage and partition unit>/force_ro And flash the bootloader: dd if=<bootloader> of=/dev/<storage and partition unit> bs=1K seek=0 In the board will look like this: With this process now it is needed to reboot the board, change boot mode switches to boot from eMMC, and the board will boot normally, the user can perform an image flashing to simplify development workflow and also an alternative to update OS without external host dependencies.      

This document mainly introduces how to use gpio usb id. This can provide more options to avoid pin conflicts.   iMX93 11x11 evk uses a peripheral circuit built with a typeC chip to perform USB role switch. However, in many cases, the hardware design does not have the same typeC circuit as the evk, and the USB ID is needed to do switch. The two USB IDs of the current iMX93 are muxed with the eQOS pins. The probability of this conflict is very high. So we need to use an alternative solution “gpio usb id”  to avoid this pin allocation conflict. MX93_PAD_ENET1_MDC__HSIOMIX_OTG_ID1 MX93_PAD_ENET1_MDC__ENET_QOS_MDC MX93_PAD_ENET1_TD3__HSIOMIX_OTG_ID2 MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3   Based on lf-6.6.52-2.2.0  

Hey everyone! With the iMX8MM EVK, you also get an IR receiver LED interfaced with one of the GPIOs. Through this article today, I will demonstrate how to enable Infrared Receiver on the iMX8MM EVK so that data sent from the IR transmitter LEDs can be received and decoded on the iMX8MM EVK. Hardware used : iMX8MM EVK - i.MX 8M Mini Evaluation Kit | NXP Semiconductors Arduino Uno board IR TX module Arduino interfaced with IR TX will send IR messages to iMX8MM interfaced with IR RX LED Hardware connections: IR TX Module         <---->          Arduino Uno GND                          -                     GND 3.3V                          -                     3.3V DAT                           -                     D3 IR transmitter LED connected to Arduino Uno -- Kernel configurations needed: Linux Kernel Configurations Copy the kernel 'Image' built with the above changes and the IR decoder modules for the protocol you want to decode. All the ko modules are present i.e ir-rc5-decoder.ko for rc5 IR decoding in this folder after building: LIRC drivers Boot linux with the default dtb[imx8mm-evk.dtb] and the newly copied kernel 'Image' that you uploaded on the board.   At boot-up rc_register_device is called from drivers/media/rc/rc-main.c. A /dev/lirc0 node will also be created as a result of in-built driver loading. You can verify this by executing: lirc device node   On iM8MM, The IR receiver is connected to GPIO1_13. drivers/media/rc/gpio-ir-recv.c is responsible to configure this GPIO using the dts entry present in  arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi   Device tree changes gpio_ir_recv_probe will be called from drivers/media/rc/gpio-ir-recv.c.   At linux prompt, you can verify the gpio configuration using sysfs: IR GPIO Now insert the NEC and RC5 decoder modules. This gives the kernel ability to be able to decode the   NEC and RC5 IR protocols. LIRC Decoder Next, we need a program that utilizes the decoder driver to start decoding the IR signals coming onto the IR Receiver of iMX8MM EVK.   Some example invocations of the user-space binary we have built for the above purpose: RC5 Decoder RC6 Decoder NEC Decoder   ir_recv accepts 2 arguments:- 1st argument - protocol to enable 2nd argument - the remote-control device created in the /sys/class/rc example - /sys/class/rc/rc0 Note - Not to be confused with the protocols rc5 or rc6. The 2nd argument is not the name of the protocol ir_recv utility that we have built will open the /dev/lirc0 device and make an ioctl call LIRC_SET_REC_MODE to set the LIRC driver in Recording mode. These ioctls are handled in drivers/media/rc/lirc_dev.c in the kernel source code. So that whenever you run the ir_recv binary, it polls for the IR protocol scan code and prints it if successfully decoded. Attaching the ir_recv executable and the source code with this article for you to test and tweak. Please let me know if you have any follow-up questions. I would be happy to indulge. That's all I have for today. Thank you for your time!