This article explains how to get started with JTAG debugging of the Linux kernel running on the A55 of iMX93EVK. We will be using Lauterbach Trace32 to debug iMX93EVK. Here is a list of pre-requisites that is expected from the readers:- 1. Basic knowledge to get started on Trace32 - Please refer Learning and Training | Lauterbach TRACE32 2. You should have Linux source code and steps to build the kernel. 3. Trace32 Software with a license to debug A55 COMPONENTS   Hardware required: -   iMX93EVK running 6.6.52 BSP Lauterbach Power Debug E40 with a Debug cable Software required: - Trace32 Linux kernel source code   Linux Kernel Modifications Step 1:- In arch/arm64/configs/imx_v8_defconfig, please make sure that:- CONFIG_DEBUG_INFO_REDUCED=n CONFIG_DEBUG_INFO = y CONFIG_KALLSYMS=y   Step-2 :- Enabling JTAG debugging in Linux On iMX93EVK LPUART5 is MUX'd with the JTAG pins   so if we want to debug the linux kernel via JTAG, we will have to disable it. Go to the device tree source file - arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts Change the status of the following node to 'disabled'     Step 2:- Build the kernel. vmlinux will be created as part of this. This has the Linux kernel along with the debug symbols required for Trace32 debugging. Step-3 At this point either you can copy the linux-imx folder to your local windows machine where Trace32 is installed, or you can simply map the linux machine as a network drive so that the same folder '/opt/samba/nxg05261/linux-imx' is accessible on windows. The motive of this exercise is to use 'vmlinux' and the linux source files present in this folder from trace32 cmm scripts that we will be executing.   Step-4 Replace the newly built kernel 'Image' - arch/arm64/boot/Image with the one present in the boot partition of imx93evk. You can simply copy this Image to iMX93EVK via scp and copy it to the folder - /run/media/boot-mmcblk0p1 Note:- Please make sure that the kernel version that is running on the box and the one you have built should be the same otherwise there will be debug symbols mismatch After copying the Image, reboot iMX93EVK. Debugging with Trace32 Step-1 Configuring Uboot bootargs Cpu idle state interferes with the JTAG debugging by impacting the clocks so we need to disable the cpu idle power management. We do this by appending "cpuidle.off=1" to the bootargs:- a. Stop at Uboot prompt. b. Execute command - setenv mmcargs "setenv bootargs ${jh_clock} ${mcore_clk} console=${console} root=${mmcroot}  cpuidle.off=1" [do not omit the inverted commas in the command] Step-2 Boot to Linux prompt   Step-3 Connect the USB cable of Lauterbach Power Debug probe to your windows machine and Open t32 - C:\T32\bin\windows64\t32start.exe   Select 'PowerView Instance' and click on 'Start'. A window like below will appear: -   Step- 4 Extract MMU translation info for the debugger For this either you can execute the below commands on the T32 in sequence: -   RESet SYStem.RESet SYStem.CPU IMX93-CA55 SYStem.JtagClock 10MHz SYStem.CONFIG.DEBUGPORTTYPE JTAG SYStem.Option EnReset OFF CORE.ASSIGN 1. 2. SYStem.Option MMUSPACES ON SYStem.Option IMASKASM ON SYStem.Mode Attach Data.LOAD.Elf <path_of_vmlinux> /NoCODE DO ~~/demo/arm/kernel/linux/board/generic-template/detect_translation.cmm OR simply edit the attached cmm script - detect_address_translation.cmm and modify the <path_of_vmlinux> as per your file location. Then execute it like this:- Do <file_path>/detect_address_translation.cmm In my case, this command was: - Do C:\Users\nxg05261\Documents\cmm_scripts\detect_address_translation.cmm Note:- <path_of_vmlinux> in my case was  C:\T32\demo\arm\bootloader\uboot\vmlinux. You can modify it as per the location where you have copied 'vmlinux' -- After executing the above commands, debugger address translation will be displayed: -    Now we will copy the above highlighted lines and paste it in the final cmm script that we will use for debugging. For readers' convenience this info has been collated into the final script - 'linux_attach_t32.cmm', attached with this blog.   Disclaimer:- The lines that are highlighted depends on the kernel version and customer design decisions, so it is strongly advised to take the output of detect_translation.cmm for your system and then paste it in the cmm script, instead of using the exact output that I have shown in the above picture. File -> Open File -> linux_attach_t32.cmm -- Click on 'Do' button to execute the script till the end. -- Set a breakpoint at start_kernel b.s start_kernel /Onchip   [Optional]Check the breakpoint via 'b.l'   -- Hit 'go' at t32 to let the cores execute the instructions, you will see 'running' state   -- Enter 'reboot' at Linux prompt and stop at Uboot command line prompt you will see trace32 at 'system down' state: - -- Execute 'system.mode.attach' at t32 to attach to the system, you will again see 'running' state -- Execute 'break' to stop the running state -- Check if the breakpoint 'start_kernel' still exist via command 'b.l' -- If you see the breakpoint is still set, Execute 'go' at t32 to take the cores to the running state. -- Then, at Uboot prompt, execute 'boot' so that it may load the linux kernel to the memory.   As soon as you do that you would see that Uboot will try to load kernel. The last print you will see on the serial console will be: - "Starting kernel …' the execution will stop and at t32 you will see that the breakpoint is hit, meaning the Program Counter is at the address of the function 'start_kernel'   Note- The Warning that you might observe[like in the above picture] means that trace32 is not able to find the source file 'main.c'. So you will not be able to see the 'C' source code at this point. To resolve this:- -- Right click on the 'List.auto' window where you see the assembly code. Click on 'Resolve Path' and navigate to the init/main.c in your kernel source code folder and click Open. You would see that the source path translation is now correct and you're able to view the disassembly as well as the source code: -     Now we will load kernel symbols and apply 2 breakpoints in the linux kernel to demonstrate kernel debugging:-   -- Load the kernel symbols Data.LOAD "C:\T32\demo\arm\bootloader\uboot\vmlinux"  H:0x0::0x0 /NoCODE /SOURCEPATH Z:\linux-imx   -- Apply breakpoints at t32 window b imx_rpmsg_init b imx_drm_bind   [Optionally] you can verify the breakpoints via 'b.l' These breakpoints are temporary as you can see in the above snapshot. That means after they are hit, they will be removed, so to make them permanent:- Right click the breakpoint -> Change -> Uncheck Temporary -> Click Ok like depicted in the following snapshots: -       Now, to reach the next breakpoint, execute 'go' on the t32 At this point linux kernel execution has reached the function imx_rpmsg_init   Again, to reach the next breakpoint, execute 'go'   So this is how you start debugging the linux kernel. Apart from this, there is a nice t32 feature called 'linux awareness' which allows you to easily debug the kernel loadable modules, user space applications amongst other things. To explore 'linux awareness', you can go about checking the 'Linux' drop down menu present at the top. Plenty of support documents are available on the web.       Feel free to drop in the comments section or DM if you have any queries. Happy debugging!!🙂🙂🙂🙂  

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:  

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    

This guide provides a step-by-step approach for beginners looking to flash a custom Kernel Image or device tree on an NXP i.MX board. Sometimes, we need to customize the Kernel Image or modify the device tree for our board. Fortunately, NXP provides the UUU (Universal Update Utility) tool, which allows us to flash and use a custom Kernel Image or update the device tree on our board.   Requirements Before proceeding, ensure you have the following: - The latest version of the UUU Tool. - An i.MX EVK board (i.MX6, i.MX7, i.MX8, i.MX9). - The power supply for the board. - Two USB cables (USB-C or Micro USB, depending on your board).   Preliminary Steps To customize the Kernel Image or device tree, refer to the following community posts: - How to Fix FRDM-IMX93 Linux Kernel BSP - How to Compile Linux Kernel Image and Device Tree Using Yocto SDK   Once you have your customized Linux Kernel Image or device tree ready, follow the steps below to deploy it to your board.   Flashing the Kernel Image or Device Tree Connect and Prepare the Board 1. Connect the USB debug cable and the OTG cable from your board to your host computer. 2. Power on your board and stop the boot process at the U-Boot stage by pressing a key in the terminal. 3. Enter fastboot mode by running the following command in the U-Boot terminal: u-boot -> fastboot 0   Flash the Custom Kernel Image or Device Tree   4. Open a terminal on your host computer and navigate to the directory containing the new Kernel Image or device tree. 5. Flash the new files using the following command: $ uuu -b fat_write <file_name> mmc <device>:<partition> <file_name_in_board> Example: $ uuu -b fat_write imx93-11x11-evk.dtb mmc 0:1 imx93-11x11-evk-custom.dtb In this example, the file imx93-11x11-evk.dtb stored on the host machine is flashed to the board's eMMC device, saving it as imx93-11x11-evk-custom.dtb.   Note: If you are using Linux, run the command with sudo. - For eMMC and SD card, the command is the same; just ensure you use the correct device number. - On the i.MX93, device 0 corresponds to eMMC, and device 1 corresponds to the SD card.   Update U-Boot Environment Variables   6. Exit fastboot mode by pressing CTRL+C. This returns you to the U-Boot terminal. 7. Set up the environment variablesto use the new files: For the Kernel Image: u-boot -> setenv image <custom_image_name> u-boot -> saveenv u-boot -> reset For the Device Tree: u-boot -> setenv fdtfile <custom_device_tree_name> u-boot -> saveenv u-boot -> reset The board should now boot using your modified Kernel Image and device tree.  

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.

  Test Environment i.MX8MP EVK L6.6.52   Backgroud The default BSP will assign SAI3 and I2C3 to M7 when we use imx8mp-evk-rpmsg.dtb. If customer want to assign SAI3 and I2C3 to A53 and test audio in Linux while running M7 sdk with remoterpoc.   Test steps   1. Delete all of audio related code in SDK in below function. BOARD_BootClockRUN  BOARD_RdcInit 2. Modify Uboot   arch/arm/dts/imx8mp-evk-u-boot.dtsi   The RDC will assign SAI3, sdma3 and i2c3 to M7 when M7 start. So we need to delete these lines.      3. Add RDC config in ATF plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c  Assign SAI3, sdma3 and i2c3 to A53.    4.Modify imx8mp-evk-rpmsg.dts Delete rpmsg audio and i2c3. diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg-lpv.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg-lpv.dts index e43c4dafdb88..4edc0cb71b1c 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg-lpv.dts +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg-lpv.dts @@ -4,8 +4,3 @@ */ #include "imx8mp-evk-rpmsg.dts" - -&rpmsg_audio { - /delete-property/ fsl,enable-lpa; - /delete-property/ fsl,rpmsg-in; -}; diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts index ddf5f76adc3b..75c9234d84b2 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts @@ -8,11 +8,6 @@ #include "imx8mp-evk.dts" / { - aliases { - i2c0 = &i2c1; - i2c1 = &i2c2; - i2c2 = &i2c_rpbus_3; - }; reserved-memory { #address-cells = <2>; @@ -45,70 +40,6 @@ rsc_table: rsc-table@550ff000 { no-map; }; - audio_reserved: audio@81000000 { - compatible = "shared-dma-pool"; - no-map; - reg = <0 0x81000000 0 0x10000000>; - }; - - micfil_reserved: mic_rpmsg@91000000 { - compatible = "shared-dma-pool"; - no-map; - reg = <0 0x91000000 0 0x100000>; - }; - }; - - sound-wm8960 { - status = "disabled"; - }; - - sound-micfil { - status = "disabled"; - }; - - rpmsg_audio: rpmsg_audio { - compatible = "fsl,imx8mp-rpmsg-audio"; - model = "wm8960-audio"; - fsl,rpmsg-channel-name = "rpmsg-audio-channel"; - fsl,enable-lpa; - fsl,rpmsg-out; - fsl,rpmsg-in; - assigned-clocks = <&clk IMX8MP_CLK_SAI3>; - assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; - assigned-clock-rates = <12288000>; - clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_IPG>, - <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>, - <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SDMA3_ROOT>, - <&clk IMX8MP_AUDIO_PLL1_OUT>, - <&clk IMX8MP_AUDIO_PLL2_OUT>; - clock-names = "ipg", "mclk", "dma", "pll8k", "pll11k"; - audio-codec = <&codec>; - memory-region = <&audio_reserved>; - power-domains = <&audiomix_pd>; - audio-routing = - "LINPUT1", "MICB", - "LINPUT3", "MICB"; - status = "okay"; - }; - - rpmsg_micfil: rpmsg_micfil { - compatible = "fsl,imx8mp-rpmsg-audio"; - model = "micfil-audio"; - fsl,rpmsg-channel-name = "rpmsg-micfil-channel"; - fsl,enable-lpa; - fsl,rpmsg-in; - assigned-clocks = <&clk IMX8MP_CLK_PDM>; - assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; - assigned-clock-rates = <196608000>; - clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_PDM_IPG>, - <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_PDM_ROOT>, - <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SDMA3_ROOT>, - <&clk IMX8MP_AUDIO_PLL1_OUT>, - <&clk IMX8MP_AUDIO_PLL2_OUT>; - clock-names = "ipg", "mclk", "dma", "pll8k", "pll11k"; - memory-region = <&micfil_reserved>; - power-domains = <&audiomix_pd>; - status = "okay"; }; imx8mp-cm7 { @@ -144,72 +75,10 @@ &flexspi { status = "disabled"; }; -/delete-node/ &i2c3; - -&i2c_rpbus_3 { - compatible = "fsl,i2c-rpbus"; - #address-cells = <1>; - #size-cells = <0>; - status = "okay"; - - pca6416: gpio@20 { - compatible = "ti,tca6416"; - reg = <0x20>; - gpio-controller; - #gpio-cells = <2>; - }; - - ov5640_1: ov5640_mipi@3c { - compatible = "ovti,ov5640"; - reg = <0x3c>; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_csi0_pwn>, <&pinctrl_csi0_rst>; - clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; - clock-names = "xclk"; - assigned-clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; - assigned-clock-parents = <&clk IMX8MP_CLK_24M>; - assigned-clock-rates = <24000000>; - csi_id = <0>; - powerdown-gpios = <&gpio4 1 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio4 0 GPIO_ACTIVE_LOW>; - mclk = <24000000>; - mclk_source = <0>; - mipi_csi; - status = "disabled"; - - port { - ov5640_mipi_1_ep: endpoint { - remote-endpoint = <&mipi_csi1_ep>; - data-lanes = <1 2>; - clock-lanes = <0>; - }; - }; - }; - - codec: wm8960@1a { - compatible = "wlf,wm8960,lpa"; - reg = <0x1a>; - wlf,shared-lrclk; - SPKVDD1-supply = <&reg_audio_pwr>; - }; -}; - &pwm4{ status = "disabled"; }; -&sai3 { - status = "disabled"; -}; - -&micfil { - status = "disabled"; -}; - -&sdma3{ - status = "disabled"; -}; - &uart3 { status = "disabled"; };   Result We can play audio on wm8960 after we load M7 firmware.

This article describe i.M93 RGMII to PHY connection, delay adding tips. i.MX93 don't support delay in both FEC and QOS port in i.MX93 side. It also provide solution on i.MX93 how to connect MAC to MAC in HW & SW. Thanks! 

1.1 Introduction PCI Endpoint Framework is a system within the Linux kernel, enabling developers to test the functionality of a PCIe end-point device. Linux kernel simulates a PCIe End-point's behaviour and interact with the PCIe bus. This helps developers to test and validate the PCIe Root Complex providing a structured way to verify the PCIe data transfers. For detailed info, please go through the official documentation - 9. PCI Endpoint Framework — The Linux Kernel documentation   This article focuses on how to enable the End-point test framework on imx95 and imx8mm. For the demonstration, iMX95 board will act as a Root Complex and imx8mm will be acting as an End-point. On the End-point[imx8mm], the framework creates endpoint controller driver, endpoint function driver, and using configfs interface to bind the function driver to the controller driver. At the RC, a user-space utility called 'pcitest' will be used to read and write data from/to Endpoint.  Enabling this on iMX EVKs is fairly straightforward so chances are less that you will encounter Issues while enabling this. Nevertheless, if you do face issues in enabling it, please feel free drop in a text so that we can answer your query.   At the end of this exercise, you will be able to send and receive PCIe data from Root Complex[imx95] to End-Point[imx8mm] with/without DMA.   Connections:-   iMX95 Torradex RC will be connected to iMX8MM EVK via M.2 PCIe bridge iMX95 Torradex board [RC] connected to iMX8MM[EP] via PCIe bridge on M.2   1.2 Changes required on imx95 and imx8mm linux configs:   Kernel configs   # # PCI Endpoint # CONFIG_PCI_ENDPOINT=y CONFIG_PCI_ENDPOINT_CONFIGFS=y CONFIG_PCI_EPF_TEST=y   1.3 How to run the PCIe end-point test framework?   Build standalone imx8mm and imx95 linux kernel after enabling the linux configs mentioned in the section 1.2 Note- you can also use yocto to build the kernel for imx95 and imx8mm after making the kernel config changes. I use standalone for quick validation and debugging. After building, you will get kernel images for both imx95 and imx8mm in the location - linux-imx/arch/arm64/boot/Image of the respective imx folders.    Flash imx8mm with an official linux factory image[latest preferred] to emmc a. Replace the kernel 'Image' of imx8mm [built with end-point configs in the step-1] with the one that comes with the default factory image.          Location of kernel Image on the imx8mm emmc partition - /run/media/boot-             mmcblk2p1/Image          Note- If you are using yocto, you can also just flash the built wic image and it will be automatically taken care of[given that the wic was correctly built with the kernel configs mentioned in 1.2]          b. Boot Linux with this dtb  -> imx8mm-evk-pcie-ep.dtb          location of the dts in the linux bsp -          linux-imx/arch/arm64/boot/dts/freescale/imx8mm-evk-pcie-ep.dts          If you closely observe this dts:-                         It is just disabling the default pcie0 node and enabling the pcie0_ep node. This is because the PCIe drivers need some type of indication from the dtb at boot up so that end-point controller can be created via EPC driver in the Linux kernel.             c. Run the following script to configure the iMX8MM as an endpoint root@imx8mmevk:~# cat conf_pci_ep   cd /sys/kernel/config/pci_ep/; mkdir functions/pci_epf_test/func1; cat functions/pci_epf_test/func1/deviceid; cat functions/pci_epf_test/func1/vendorid; echo 0x1957 > functions/pci_epf_test/func1/vendorid; echo 0x0808 > functions/pci_epf_test/func1/deviceid; echo 16 > functions/pci_epf_test/func1/msi_interrupts; echo 8 > functions/pci_epf_test/func1/msix_interrupts; ln -s functions/pci_epf_test/func1 controllers/33800000.pcie_ep/   root@imx8mmevk:~# ./conf_pci_ep 0xffff 0xffff root@imx8mmevk:~#        3. Flash the official imx95 image on the board.            Similar to imx8mm, Boot the imx95 board with the kernel 'Image' built in step-1            In the booting logs, if debugs are enabled, one can observe that the pci_endpoint_test probe will be called. On the linux prompt you can see a device will be created for it.   On lspci output of imx95, you can see the pcie endpoint entry 0808 is the device id we mentioned on the end-point imx8mm in the step-2 above.     4. Now, run the below script on imx95:-     root@imx95-19x19-lpddr5-evk:~# cat pcie_send_to_eptest.sh #!/bin/sh # SPDX-License-Identifier: GPL-2.0   echo "PCIe End-point test" pcitest -r -d -s 102400 pcitest -w -d -s 102400   root@imx95-19x19-lpddr5-evk:~#   The above script will read 102400 bytes from the EP and write 102400 bytes to the EP.   root@imx95-19x19-lpddr5-evk:~# ./pcie_send_to_eptest.sh PCIe Hot-plug test   [ 2885.375620] pci-endpoint-test 0000:01:00.0: in pci_endpoint_test_ioctl cmd:0x40085005 READ ( 102400 bytes):           OKAY   WRITE ( 102400 bytes):          OKAY That's all you need to get started with this simple end-point test framework on imx. Please feel free to ask questions if any.

This guide provides step-by-step instructions for setting up and applying necessary patches to the Linux kernel for the FRDM-IMX93 development board. The process involves cloning the required repositories, applying patches, and preparing the kernel for customization and compilation.   Prerequisites Required Software: A Linux-based operating system (Ubuntu/Debian recommended). Git installed (sudo apt install git). Yocto dependencies: $ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 python3-subunit zstd liblz4-tool file locales libacl1 ​   Hardware: FRDM-IMX93 Board Sufficient storage space   1. Downloading the Repository Start by downloading the necessary tools and repository. If the ~/bin folder does not already exist, create it: $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH   2. Compile the Yocto SDK: $: mkdir Yocto_SDK $: cd Yocto_SDK $: 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 $: MACHINE=imx93evk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b bld-xwayland $: bitbake imx-image-full -c populate_sdk   Run the generated .sh file to install the SDK: sudo ./fsl-imx-xwayland-glibc-x86_64-imx-image-full-armv8a-imx93evk-toolchain-6.6-scarthgap.sh   The final .sh file is located in: bld-xwayland/tmp/deploy/sdk/   3. Creating the Working Directory First, create a dedicated directory for the kernel setup and navigate into it: $ mkdir FRDM-IMX93-Kernel $ cd FRDM-IMX93-Kernel   4. Cloning the Kernel patches Retrieve the necessary kernel patches from the NXP repository: $ git clone https://github.com/nxp-imx-support/meta-imx-frdm.git -b lf-6.6.36-2.1.0   5. Cloning the Kernel Repository (linux-imx repository) Clone the kernel source of Yocto SDK that you built earlier: $ git clone https://github.com/nxp-imx/linux-imx.git -b lf-6.6.36-2.1.0 6. Applying Kernel Patches Apply the necessary patches to the kernel: $ cd linux-imx/ $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0001-gpio-pca953x-fix-pca953x_irq_bus_sync_unlock-race.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0002-arm64-dts-add-i.MX93-11x11-FRDM-basic-support.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0003-arm64-dts-add-imx93-11x11-frdm-mt9m114-dts.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0004-Add-DSI-Panel-for-imx93.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0005-Add-CTP-support-for-waveshare-panel.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0006-arm64-dts-add-imx93-11x11-frdm-tianma-wvga-panel-dts.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0007-arm64-dts-add-imx93-11x11-frdm-aud-hat-dts.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0008-arm64-dts-add-button-support.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0009-arm64-dts-add-imx93-11x11-frdm-ov5640-dts.patch $ cd linux-imx/ $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0010-arm64-dts-add-imx93-11x11-frdm-ld.dts-for-lpm.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0011-arm64-dts-add-pwm-function-of-the-LED.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0012-arm64-dts-add-imx93-11x11-frdm-8mic.dts.patch $ git apply ../meta-imx-frdm/meta-imx-bsp/recipes-kernel/linux/linux-imx/0013-arm64-dts-add-imx93-11x11-frdm-lpuart.dts.patch   7. Customizing the Device Tree Device trees can be modified or created based on your hardware setup.   Device Tree Locations: arch/arm64/boot/dts/freescale/   If you create a new device tree, add it to the respective Makefile: arch/arm64/boot/dts/freescale/Makefile   8. Setting Up the Cross-Compilation Environment To prepare for kernel compilation, source the environment setup script. Assuming the Yocto SDK is installed in /opt, run:   EXAMPLE: $ source /opt/fsl-imx-xwayland/6.6-scarthgap/environment-setup-armv8a-poky-linux   9. Configuring the Kernel Make configuration adjustments as needed in the file: arch/arm64/configs/imx_v8_defconfig Use the appropriate configuration command: $: make imx_v8_defconfig   10. Compiling Device Trees Only To compile only the device tree files, run: $: make dtbs   11. Compiling the Kernel Finally, compile the kernel image using: $ make -j $(nproc)   The resulting kernel image will be located in: arch/arm64/boot/   References: IMX YOCTO PROJECT USERS GUIDE IMX LINUX USERS GUIDE  IMX REFERENCE MANUAL 

In some cases, due to the limited resources allocated by imx pins, gpio has to be used as mdio/mdc. This article is a simple guide on how to use MDIO on GPIOs. The demo code is for network fec interface. 1. Add CONFIG_MDIO_GPIO=y and rebuild kernel 2. Modify fec device tree to use MDIO ON GPIO FEC test result: root@imx93evk:~# ethtool eth0 Settings for eth0:         Supported ports: [ TP    MII ]         Supported link modes:   10baseT/Half 10baseT/Full                                 100baseT/Half 100baseT/Full                                 1000baseT/Full         Supported pause frame use: Symmetric         Supports auto-negotiation: Yes         Supported FEC modes: Not reported         Advertised link modes:  10baseT/Half 10baseT/Full                                 100baseT/Half 100baseT/Full                                 1000baseT/Full         Advertised pause frame use: Symmetric         Advertised auto-negotiation: Yes         Advertised FEC modes: Not reported         Link partner advertised link modes:  10baseT/Half 10baseT/Full                                              100baseT/Half 100baseT/Full                                              1000baseT/Full         Link partner advertised pause frame use: No         Link partner advertised auto-negotiation: Yes         Link partner advertised FEC modes: Not reported         Speed: 1000Mb/s         Duplex: Full         Auto-negotiation: on         master-slave cfg: preferred slave         master-slave status: slave         Port: Twisted Pair         PHYAD: 2         Transceiver: external         MDI-X: Unknown         Supports Wake-on: g         Wake-on: d         Link detected: yes root@imx93evk:~# ifconfig eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC>  mtu 1500         inet 10.192.246.129  netmask 255.255.255.0  broadcast 10.192.246.255         inet6 fe80::885a:aeff:fea3:7dcf  prefixlen 64  scopeid 0x20<link>         ether 8a:5a:ae:a3:7d:cf  txqueuelen 1000  (Ethernet)         RX packets 13  bytes 2294 (2.2 KiB)         RX errors 0  dropped 3  overruns 0  frame 0         TX packets 25  bytes 4691 (4.5 KiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0   eth1: flags=-28669<UP,BROADCAST,MULTICAST,DYNAMIC>  mtu 1500         ether a2:5e:45:17:72:79  txqueuelen 1000   eQOS test result imx93evk login: root root@imx93evk:~# ifconfig eth0: flags=-28669<UP,BROADCAST,MULTICAST,DYNAMIC> mtu 1500 ether 00:04:9f:08:7f:d0 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500 inet 10.192.246.112 netmask 255.255.255.0 broadcast 10.192.246.255 inet6 fe80::204:9fff:fe08:7fcf prefixlen 64 scopeid 0x20<link> ether 00:04:9f:08:7f:cf txqueuelen 1000 (Ethernet) RX packets 12 bytes 3020 (2.9 KiB) RX errors 0 dropped 3 overruns 0 frame 0 TX packets 31 bytes 5355 (5.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 104 root@imx93evk:~# ethtool eth1 Settings for eth1: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on master-slave cfg: preferred slave master-slave status: slave Port: Twisted Pair PHYAD: 1 Transceiver: external MDI-X: Unknown Supports Wake-on: ug Wake-on: d Current message level: 0x0000003f (63) drv probe l

Test Environment： i.MX8MP EVK L6.6.52(weston12)   Background Current RDP only supports TLS authentication, but does not support the NLA feature or PAM password authentication. Therefore, the connection security of RDP will be very low, and you can even login remotely without the correct username and password. This article implements the NLA feature and PAM password authentication base on weston rdp backend, which supports customized user and login.   1.Patches patch weston-imx with add_rdp_pam_nla_support.patch patch meta-imx with add_pam_support_and_weston_user.patch   2.Generate keys on Ubuntu rename key as server.crt and server.key sudo apt-get install winpr-utils winpr-makecert -rdp -path ~/ copy server.crt and server.key from Ubuntu to /etc/freerdp/keys/ on i.MX board 3. Enable start-on-startup=true in weston.ini   4.Install Remmina on Ubuntu.   5.Generate SAM file on board and Ubuntu: /etc/winpr/SAM(SAM is a file, not a directory) and copy hash into /etc/winpr/SAM The username weston and passwd has been set in add_pam_support_and_weston_user.patch. username: weston passwd: weston domain: domain   $ winpr-hash -u weston -d domain -p weston -v1 -f sam weston:domain::b2ca4ec6a1dbd13c49b6ab5e1b10d5bf::: $ vi /etc/winpr/SAM   6.Access with Remmina on Ubuntu. 7.Result