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!  

Overview   This document intends to provide one reference how to emulate i.MX8QM 1.3GHz part running on i.MX8QM MEK with 1.6GHz part based on i.MX Linux BSP release.   You can find i.MX8QM/QP processors datasheet on NXP web: i.MX 8QuadMax 1.3GHz Automotive and Infotainment Applications Processors; i.MX 8QuadPlus 1.3GHz Automotive and Infotainment Applications Processors; i.MX 8QuadPlus Industrial Applications Processors Data Sheet; i.MX 8QuadMax Industrial Applications Processors Data Sheet;   Key differences between 1.3GHz part and 1.6GHz part is as follows: Key Differences 1.6GHz part 1.3GHz part 8QM/8QP A72 core max frequency 1600MHz 1296MHz 8QM GPU max frequency core 800MHz  shader 1000MHz core 650MHz shader 700MHz 8QM VDD_GPU mode Overdrive mode Remove overdrive mode, only nominal 8QM VDD_GPU nominal operation range Min 0.95V Typ 1.0 V Max 1.1V Min 0.98V Typ 1.03125V Max 1.14V   Software Changes   Since Linux 6.6.23_2.0.0 BSP release, i.MX8QM/8QP 1.3GHz part is supported into i.MX Linux release by identifying the fuse of 1.3GHz part and configuring frequency and voltage automatically. If you have i.MX8QM MEK board with 1.6GHz part, before revision E, you can apply software changes to emulate 1.3GHz part configurations explicitly. The following software reference patches are built based on Linux 6.6.52-2.2.0 release: Component Patch Name Description Linux Kernel 0001-arm64-dts-imx8qm-remove-A72-core-1.6GHz-operating-po.patch Used to remove Cortex-A72 core 1.6GHz operating-points 0002-arm64-dts-imx8qm-set-GPU-operating-points-at-nominal.patch Used to remove GPU overdrive operating-points and set GPU core frequency as 650MHz, GPU shader frequency as 700MHz. SCFW 0001-Increase-VDD-of-GPU.patch Used to increase GPU voltage ATF 0001-plat-imx8-make-ATF-kick-off-A72-core-freq-at-1.3GHz.patch Used to kickoff A72 core and set its frequency as 1.3GHz in ATF   Validation Test Apply patch into Linux kernel, SCFW porting kit, ATF, follow 6.6.52_2.2.0 release document(www.nxp.com/design/design-center/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX) to build and deploy image.     After Linux OS boot up,  run below command to check A72 and GPU frequency,  for example: #cat /sys/kernel/debug/gc/clk gpu0 mc clock: 647981058 HZ. gpu0 sh clock: 695997687 HZ. gpu1 mc clock: 647990370 HZ. gpu1 sh clock: 695987994 HZ   #cat /sys/devices/system/cpu/cpu4/cpufreq/cpuinfo_max_freq 1296000   Measure VDD_GPU voltage from i.MX8QM MEK board TP53 and TP42

Quickly develop and deploy IoT applications with Clea on your NXP device. This guide walks you through setting up Clea, managing devices remotely, and leveraging AI-powered telemetry for industrial applications.

The doc gives an introduction about how to get and run the watch-face APK on i.MX.8ULP watch board based on Android 14.0.0_1.0.0. 1. Get source code Get the shell script and related patches from the attachment at the end of the article. Run Watchface_setup.sh. Watchface_setup.sh will download all the needed gits codes. combine with them and apply patches automatically. You need to clone the gits manually if network access is not good. 2. Build the project The project is in the sub-directory named "KWART_Kid_Launcher". Then you can build it either in Android studio or Android SDK. Android studio Open the project in Android studio and build it like regular. Android SDK Copy KWART_Kid_Launcher/ into vendor/nxp-opensource/fsl_imx_demo/ Add the following into the end of device/nxp/imx8ulp/watch_8ulp/watch_8ulp.mk. PRODUCT_PACKAGES += \ KWARTLauncher Rebuild the SDK. Please refer to Android User's Guide for more details about SDK building. make -j4 2>&1 | tee make.log 3. Install the APK Install the APK Android studio Run the app like regular. Android SDK Reflash the SDK images and the app will occur after boot finishes. Then you will find the following APP.  

This sharing introduces how to porting the deepseek to the #i.MX8MP i.MX93EVK  with the Yocto BSP by llama.cpp The main test model used in this document is the Qwen model that is distilled and quantized based on the deepseek model. For other versions of the deepseek model, you can refer to the steps in the document to download different models for testing. 1. Set up the demo ON PC a. Prepare the cross-compiling. See the i.MX Yocto Project User's Guide for detailed information how to generate Yocto SDK environment for cross-compiling. Get the User's Guide. To activate this Yocto SDK environment on your host machine, use this command:   :$ source <Yocto_SDK_install_folder>/environment-setup-cortexa53-crypto-poky-linux   b. Cross-compile the llama.cpp eg: i.MX93   :$ git clone https://github.com/ggerganov/llama.cpp :$ mkdir build_93 :$ cd build_93 :build_93$ cmake .. -DCMAKE_SYSTEM_NAME=Linux -DCMAKE_SYSTEM_PROCESSOR=aarch64 -DCMAKE_C_COMPILER=aarch64-poky-linux-gcc -DCMAKE_CXX_COMPILER=aarch64-poky-linux-g++ :build_93$ make -j8 :build_93$ scp bin/llama-cli root@<your i.MX93 board IP>:~/ :build_93$ scp bin/*.so root@<your i.MX93 board IP>:/usr/lib/   c. Get the DeepSeek model on the huggingface eg: Dowload the DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M.gguf model Download the required Deepseek model in the huggingface. ON Board a.Test the Deepseek on the i.MX93 board   :~/# ./llama-cli --model DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M.gguf     b. Results shown below:   2. Results Analysis The effects of different models on different boards were tested. It should be noted that the biggest obstacle limiting the running of the model on the board is memory.The test results including CPU and memory usage are as follows: a. i.MX8mp + DeepSeek-R1-Distill-Qwen-7B-IQ4_XS b. i.MX93 + DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M   After testing, the speed at which i.MX8MP runs DeepSeek-R1-Distill-Qwen-7B-IQ4_XS to generate tokens is about 1 token per second. The speed at which i.MX93 runs DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M to generate tokens is about 1.6 token per second.  The above test results for the generation speed are only rough test results and are for reference only. The above icons show the CPU and memory usage of i.MX during the DeepSeek model running. It should be pointed out that the CPU efficiency affects the speed of model token generation. The memory size of the board limits whether the model can run in the corresponding development board. This is a balance between running speed and required memory size. Higher accuracy, such as using a 7B model, will result in a decrease in running speed.

Introduction. i.MX8ULP boot partition is handled by imx-boot image as the 8M family processors and i.MX 9 series processors, keeping the usage of imx-mkimage and UUU tools for updating the firmware to the boot media. The difference is that this processor is focus on working over Cortex-M, starting from boot which is handled by uPower ROM, it can boot Application Domain or Real Time Domain firmware images meanwhile other processors boot is less flexible, focusing on Cortex-A. This guide will explore this flexibility and it's intended for board users that test prebuilt images, want to get started with imx-boot customization, want to run SDK/Standalone examples on Cortex-M or need to perform recovery to their boards. 1. Hardware Setup. Retrieve your silicon revision from the TOP marking; BUILD A1 in this case. Identify your board in the base board silkscreen, you can work with MCIMX8ULP-EVK or MCIMX8ULP-EVK9. Connect 5V power source to P1. Connect USB type-A to type-C to USB0 J15. Connect USB type-A to type-micro-B to DEBUG J17.   2. Firmware Images Gathering. $ cd ~/Projects/ $ git clone https://github.com/nxp-imx/imx-mkimage.git Make sure that you use all images from the same release, this document uses first release for IMX8ULP; LF6.1.22. Download Sentinel Firmware retrieving the version from Release Notes. After installation copy the firmware for the silicon revision owned, mx8ulpa1 is used for REV A1. $ cd ~/Projects/ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-sentinel-0.10.bin $ chmod a+x firmware-sentinel-0.10.bin $ ./firmware-sentinel-0.10.bin $ cp firmware-sentinel-0.10/mx8ulpa1-ahab-container.img ~/Projects/imx-mkimage/iMX8ULP/ Remaining firmware will be obtained from a Yocto build, is the method that requires less steps. Make sure that the MACHINE variable matches your board. $ mkdir ~/Projects/Yocto-BSP-i.MX $ cd ~/Projects/Yocto-BSP-i.MX/ $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.22-2.0.0.xml $ repo sync $ MACHINE=imx8ulp-lpddr4-evk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b i.MX8ULPEVK $ bitbake core-image-minimal $ cd tmp/deploy/images/imx8ulp-lpddr4-evk/ $ cp bl31-imx8ulp.bin ~/Projects/imx-mkimage/iMX8ULP/bl31.bin $ cp u-boot-imx8ulp-lpddr4-evk.bin-sd ~/Projects/imx-mkimage/iMX8ULP/u-boot.bin $ cp u-boot-spl.bin-imx8ulp-lpddr4-evk-sd ~/Projects/imx-mkimage/iMX8ULP/u-boot-spl.bin $ cp imx-boot-tools/upower.bin ~/Projects/imx-mkimage/iMX8ULP/upower.bin Cortex-M firmware can be built with VS Code in Windows or by Standalone build in Linux, make sure that you have the GNU toolchain installed. Build the Power Mode Switch demo, is easier to work with it later in this document we will explore other type of demos. $ cd ~/Projects/ $ cp ~/Public/EVK-MIMX8ULP-power_mode_switch.zip . $ unzip EVK-MIMX8ULP-power_mode_switch.zip # Rename directory for this example, you can skip and use the default name. $ mv power_mode_switch/ Standalone-IMX8ULP-Power-Switch $ cd Standalone-IMX8ULP-Power-Switch/ $ ls $ chmod a+x *.sh $ ./clean.sh $ export ARMGCC_DIR=/opt/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-eabi/ # Adding a custom line (607) to print a custom message. # freq = CLOCK_GetFreq(kCLOCK_Cm33CorePlatClk); # PRINTF("\r\n#################### Standalone Built 02/21 ####################\n\r\n"); # PRINTF("\r\n#################### Power Mode Switch Task ####################\n\r\n"); $ nano source/power_mode_switch.c $ ./build_release.sh $ cp release/sdk20-app.bin ~/Projects/imx-mkimage/iMX8ULP/m33_image.bin $ ./clean.sh 3. Build and flash imx-boot firmware for Singleboot M33. This test will use Single boot – eMMC 1000_0000 pin config mode. Singleboot_M33 image stores AP FW and RT FW in eMMC, at boot time both cores work. $ cd ~/Projects/imx-mkimage/ $ make clean $ make SOC=iMX8ULP REV=A1 flash_singleboot_m33 $ cp iMX8ULP/flash.bin ~/Public/imx-boot.bin-flash_singleboot_m33 Set boot pins to 0100_0000 – Serial Download and power up the board. Flash the image using a Windows or Linux host through UUU tool. > uuu -b emmc .\imx-boot.bin-flash_singleboot_m33 Wait for UUU to print 'done' message for the command issued. 4. Test new imx-boot firmware. Set the boot pins to the config you build for and power up the board. Cortex-A output is sent through 3rd COM port and Cortex-M output through 4th. 5. Board running freertos_swtimer_cm33 and hello_world_cm33 demos. To run these demos build them through VS Code or Standalone build and copy them to imx-mkimage directory. $ cp <path to binary>/sdk20-app.bin ~/Projects/imx-mkimage/iMX8ULP/m33_image.bin $ cd ~/Projects/imx-mkimage/ $ make clean $ make SOC=iMX8ULP REV=A1 flash_singleboot_m33 $ cp iMX8ULP/flash.bin ~/Public/imx-boot.bin-flash_singleboot_m33 When this demos are running, they don't allow Cortex-A to get to U-boot, this is an issue when trying to flash new or recovery images, the board just reboots with the new FW but it's not written to eMMC, you can identify this situation when UUU prompts 100%, the command appears to hang and 'done' is not displayed. To flash a new firmware, IMX8ULP needs to boot from Serial Download pin config. Then run the script attached and go to step 4. > uuu .\uuu.auto 6. Running Dualboot demos for asynchronous operation. Dualboot are two images, AP FW which must be stored in eMMC and RT FW stored at FlexSPI0 NOR, at boot time both cores work. Boot is asynchronous and needs both images at the same time, this requires to flash two images at the same time, U-boot fastboot mode facilitates writing to eMMC while being able to use its console. Issue the following command at U-boot. => fastboot 0 Build the firmware images for A35-eMMC M33-NOR – 1000_0010* pin config. * You can also boot from LP mode – 1000_0001 pin config, this allows only M33 code to boot initially. $ make SOC=iMX8ULP REV=A1 flash_dualboot $ cp iMX8ULP/flash.bin ~/Public/imx-boot.bin-flash_dualboot $ make SOC=iMX8ULP REV=A1 flash_dualboot_m33 $ cp iMX8ULP/flash.bin ~/Public/imx-boot.bin-flash_dualboot_m33 > uuu -b emmc .\imx-boot.bin-flash_dualboot > uuu -b fat_write .\imx-boot.bin-flash_dualboot_m33 mmc 0:1 spi.bin => Ctrl + c => fatload mmc 0:1 ${loadaddr} spi.bin; setenv erase_unit 1000; setexpr erase_size ${filesize} + ${erase_unit}; setexpr erase_size ${erase_size} / ${erase_unit}; setexpr erase_size ${erase_size} * ${erase_unit}; sf probe 0:0; sf erase 0 ${erase_size} => sf write ${loadaddr} 0 ${filesize} Then go to step 4. Conclusion. This document explore all the boot configurations that feature the A35 storing its firmware in eMMC and M33 running its demo binary. Can help users that are looking to run demos on Cortex-M with their out-of-the-box board, continuing with them through the trial of different demos and boot modes to understand what are different outcomes, adapt the project in that way and develop the application over a template.