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.

i.MX95 Triple Display Patches for LF-6.6.52-2.2.0 BSP. iMX95 19x19 EVK.     Patches files: 0001-iMX95-EVK-IT6263-LVDS-to-HDMI-bridge-chip-combine-it.patch Combine IT6263 with simple panel driver, no EDID is needed, 720P and 1080P display mode had been added as two examples.   0002-IT6263-Always-reported-connected-for-force-output.patch Let IT6263 always report cable connected to force output HDMI signals.   0003-iMX95-EVK-add-LVDS-clone-mode-based-on-IT6263.patch LVDS clone mode is supported on two LVDS ports, they output same content and same timing from one DPU display engine (1920*1080@60fps).   0004-iMX95-EVK-add-dual-LVDS-interleaver-mode-based-on-IT.patch LVDS interleave mode is supported on two LVDS ports, they output different content and same timing from one DPU display engine (3840*1080@60fps).   0005-iMX95-EVK-add-triple-display-support.patch Triple display is supported, 1 MIPI DSI + 2 LVDS.  imx95-19x19-evk-triple-display-lvds-clone.dtb: the two LVDS is in clone mode. imx95-19x19-evk-triple-display-lvds-interleaver.dtb: the two LVDS is in interleave mode.   For 1 MIPI DSI + 2 LVDS display clone mode: For 1 MIPI DSI + 2 LVDS Interleave mode:     Know issues:  Due to bridge numbers (3) and DPU engine/Pixel link/Pixel Interleaver number (2) is not aligned, during kernel boot up, there will be followed link error log, but there is no real function impact.   [    3.178741] imx95-ldb 4b0c0000.syscon:ldb@4: Failed to create device link (0x180) with 4b010000.syscon:bridge@8 ... [    4.209299] imx95-pixel-interleaver 4b0d0000.bridge: Failed to create device link (0x180) with 4b400000.display-controller [    4.220355] imx95-pixel-interleaver 4b0d0000.bridge: Failed to create device link (0x180) with 4b400000.display-controller ...     2025-8-19 update: Add the patch for L6.12.20_2.0.0 BSP. lf-6.12.20-2.0.0_triple_display_patches.zip  

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.

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      

This guide walks you through setting up and building the Yocto SDK, customizing a device tree (DTS), and compiling the kernel for NXP i.MX platforms. It is designed to simplify the process, from downloading tools to creating functional images for embedded devices. 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: An NXP i.MX-based development board (i.MX6, i.MX7, i.MX8, or i.MX9). 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: Create and navigate to a release directory: $: mkdir <release> $: cd <release>   Initialize and sync the repo: $: repo init -u https://github.com/nxp-imx/imx-manifest -b <branch name> [ -m <release manifest>] $: repo sync   Set up the environment and build the SDK: $: [MACHINE=<machine>] [DISTRO=fsl-imx-<backend>] source ./imx-setup-release.sh -b bld-<backend> $: bitbake <image recipe> -c populate_sdk   Example: $: mkdir Yocto_SDK $: cd Yocto_SDK $: 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 $: MACHINE=imx93evk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b bld-xwayland $: bitbake imx-image-full -c populate_sdk   Recommendation: Use the full image (imx-image-full) to include all available packages and libraries.   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. Cloning the Kernel Repository (linux-imx repository)   Clone the kernel source matching the version of the Yocto SDK you built earlier:   $: git clone https://github.com/nxp-imx/linux-imx.git -b <Kernel-version>   EXAMPLE: $: git clone https://github.com/nxp-imx/linux-imx.git -b lf-6.6.52-2.2.0   4. Customizing the Device Tree Device trees can be modified or created based on your hardware setup.   Device Tree Locations:   iMX6 and iMX7: arch/arm/boot/dts/nxp/imx/   iMX8 and iMX9: arch/arm64/boot/dts/freescale/   If you create a new device tree, add it to the respective Makefile:   iMX8 and iMX9: arch/arm64/boot/dts/freescale/Makefile   iMX6 and iMX7: arch/arm/boot/dts/nxp/imx/Makefile     5. 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   6. Configuring the Kernel Make configuration adjustments as needed:   iMX8 and iMX9: arch/arm64/configs/imx_v8_defconfig   iMX6 and iMX7: arch/arm/configs/imx_v7_defconfig   Use the appropriate configuration command:   iMX8 and iMX9: $: make imx_v8_defconfig   iMX6 and iMX7: $: make imx_v7_defconfig   7. Compiling Device Trees Only   To compile only the device tree files, run: $: make dtbs   8. Compiling the Kernel Finally, compile the kernel image using: $ make -j $(nproc)   The resulting kernel image will be located in: iMX8 and iMX9: arch/arm64/boot/   iMX6 and iMX7: arch/arm/boot/   References: IMX YOCTO PROJECT USERS GUIDE IMX LINUX USERS GUIDE  IMX REFERENCE MANUAL   

Kindly note that application note “AN12812: Using Code-Signing Tool with Hardware Security Module" has been removed from nxp.com. The AN is obsolete, the CST User’s guide describes how to use CST with an HSM using PKCS#11 interface. You can download CST package with its documentation from https://www.nxp.com/webapp/sps/download/license.jsp?colCode=IMX_CST_TOOL_NEW  

Hello everyone, this post is intended to add support to one of the most popular NFC chips on the market (PN532).  On this example I will use the I.MX93 EVK as reference board and focused in I2C communication for the PN532 Chip.    Details:   I.MX93 EVK  PN532 Module (I2C, SPI, UART)  BSP Linux 6.6.36_2.1.0 (Yocto)      STEP 1 (IMAGE COMPILATION).    At first, we need to compile our image for our board (in my case I.MX93 EVK) to add the NFC layer (Details on Yocto User's Guide😞😞 $ mkdir yocto-bsp $cd yocto-bsp $ 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 $DISTRO=fsl-imx-wayland MACHINE=imx93evk source imx-setup-release.sh -b imx93evk-build   Then, add the support for NFC in our local.conf file:  $ nano conf/local.conf   We will add the below lines: CORE_IMAGE_EXTRA_INSTALL += "libnfc" CORE_IMAGE_EXTRA_INSTALL += "libnfc-dev"   Then, we can compile the image with:  $ bitbake imx-image-full   NOTE:  libnfc is a complete coverage of low-level PN53x chipset commands written in pure and plain C for portability and speed.  libnfc-dev are the development files and headers to use in our low-level applications.    By default, the NXP BSP support the NFC pn532 driver with a tool called nfctool, but this one is very limited compared with the libnfc.      STEP 2 (DEVICE TREE MODIFICATION).    We need to add the below lines to the Device tree:  &lpi2c5 { #address-cells = <1>; #size-cells = <0>; clock-frequency = <400000>; pinctrl-names = "default", "sleep"; pinctrl-0 = <&pinctrl_lpi2c5>; pinctrl-1 = <&pinctrl_lpi2c5>; status = "okay"; nfc@24 { compatible = "nxp,nxpnfc"; //we can set the "nxp,pn533" driver but it will just work for the nfctool mentioned before reg = <0x24>; clock-frequency = <400000>; interrupt-parent = <&gpio2>; interrupts = <18 IRQ_TYPE_EDGE_FALLING>; }; };    And to the iomux section(same in device tree):  pinctrl_lpi2c5: lpi2c5grp { fsl,pins = < MX93_PAD_GPIO_IO22__LPI2C5_SDA 0x40000b9e MX93_PAD_GPIO_IO23__LPI2C5_SCL 0x40000b9e MX93_PAD_GPIO_IO18__GPIO2_IO18 0x31e >; };     STEP 3 (Connection with PN532 MODULE).     For this example, we must connect the Module with the I.MX93 RP Header as follows:    I.MX93 SIDE  PN532 SIDE  GND  GND  VCC  VCC  GPIO_IO22  SDA  GPIO_IO23  SCL  GPIO_IO18  IRQ    STEP 4 (BOOT BOARD AND CREATE libnfc.conf FILE).    Once when we have booted our board and selected our modified Device Tree, we should see our i2c-4 under /dev of our Linux OS: root@imx93evk:~# ls /dev | grep i2c i2c-0 i2c-1 i2c-2 i2c-4   And see our specific device (0x24) with the i2cdetect tool:   root@imx93evk:~# i2cdetect -y 4 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- 24 -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --     Now, we need to create a file called libnfc.conf under /etc/nfc/ (You can create that directory if does not exist).  This file must contain information about how the libnfc layer will communicate with the i2c device:    # Allow device auto-detection (default: true) # Note: if this auto-detection is disabled, user has to set manually a device # configuration using file or environment variable allow_autoscan = false # Allow intrusive auto-detection (default: false) # Warning: intrusive auto-detection can seriously disturb other devices # This option is not recommended, user should prefer to add manually his device. allow_intrusive_scan = true # Set log level (default: error) # Valid log levels are (in order of verbosity): 0 (none), 1 (error), 2 (info), 3 (debug) # Note: if you compiled with --enable-debug option, the default log level is "debug" log_level = 2 # Manually set default device (no default) # To set a default device, you must set both name and connstring for your device # Note: if autoscan is enabled, default device will be the first device available in device list. #device.name = "_PN532_SPI" #device.connstring = "pn532_spi:/dev/spidev0.0:500000" device.name = "_PN532_I2c" device.connstring = "pn532_i2c:/dev/i2c-4"   As you can see, the most important line to modify is the device.connstring, that is the charged of interaction and connection between the PN53x Module and the libnfc layer. In my case is pn532_i2c:/dev/i2c-4.    Now we can use the NFC module:  root@imx93evk:~# nfc-list nfc-list uses libnfc 1.8.0 NFC device: _PN532_I2c opened root@imx93evk:~#   And read UID of TAGs:  root@imx93evk:~# nfc-poll nfc-poll uses libnfc 1.8.0 NFC reader: _PN532_I2c opened NFC device will poll during 36000 ms (20 pollings of 300 ms for 6 modulations) ISO/IEC 14443A (106 kbps) target: ATQA (SENS_RES): 00 44 UID (NFCID1): 04 17 b5 d2 a2 11 90 SAK (SEL_RES): 00 Waiting for card removing...nfc_initiator_target_is_present: Target Released done. root@imx93evk:~#   Also, attached is a little application using the NFC headers installed with libnfc-dev. Tha application will do a poll with a 10 seconds time out. If Tag is not detected in 10 seconds, the app will close. If a tag is detected before the timeout, the app will print the UID of the NFC TAG:   OUTPUT of timeout: root@imx93evk:~# ./nfc-app NFC reader: _PN532_I2c opened Waiting for an NFC tag (timeout: 10 seconds)... No NFC tag detected within the timeout period. root@imx93evk:~#   OUTPUT when tag is detected: root@imx93evk:~# ./nfc-app NFC reader: _PN532_I2c opened Waiting for an NFC tag (timeout: 10 seconds)... Tag detected - UID: 04:16:BC:D2:A2:11:90 root@imx93evk:~#   To compile the app just copy the attached nfc-app.c file to the i.MX93 EVK and compile using this command: root@imx93evk:~# gcc nfc-app.c -o nfc-app -lnfc     I hope this thread can be helpful!   Best regards, Salas.  

This article demonstrates several simple gpio leds as system indicators, including kernel panic indicators.   HW: i.MX93 11x11 EVK SW: lf-6.6.3-1.0.0    

 

 

 

    Test envs: BOARD: i.MX 8MN EVK BSP: L6.6.36   The L6.6.y includes the feature about supporting starting Cortex-M33 from non-TCM address for i.MX93, but not for i.MX8M series.    LF-7815 remoteproc: imx_rproc: support starting Cortex-M33 from non-TCM address for i.MX93 https://github.com/nxp-imx/linux-imx/commit/680aa11c7bdaddf6bbffd74bc0a94ef67593b69b#diff-66a34e17e82d281936f559217adc3983b39abeb2e478967f3d5cef2eed5b67fcR693   For older BSP, customer can refer this full patch set https://patchew.org/linux/[email protected]/   If you want to test ELF in DDR on i.MX8M series and i.MX93 platform with L6.6.y, please use below patch set.  

Introduction LVGL is a graphics library to run on devices using a limited amount of resources. Previously, we have ran an LVGL demo from the LVGL repository, this contains a couple more demos which all of them are pieces of code included and lends us the opportunity to evaluate the library in a quick and easy way. GUI projects are developed by customers through a lot more options than bare code, there are GUI tools that translate a graphic asset into LVGL code, in this demonstration we will use a tool that's widely used in MCU GUI development and translate the GUI created into LVGL code; SquareLine. NOTE: refer to the appendix for precedent LVGL documents on i.MX series processors. HW set-up i.MX 93 EVK boot over eMMC/uSD to Linux Factory or Ubuntu. Connect power and debug receptables. Connect MX8_DSI_OLED1 to J701 (MIPI DSI) through MiniSAS cable. SquareLine set-up Download the latest version of SquareLine under the following link according to your host system. NOTE: This document is intended for demonstration of templates included within the tool, so it's recommended to download a free trial, for formal development please refer to the appendix of this document. Unzip and execute the installer, this is the windows prompt.   Demo download After setting SquareLine up go to the example section, we will demonstrate the thermostat capabilities with the Thermostat Demo. We can directly export these UI files and they would be graphically ready to be build, click on Export -> Export UI Files and select your preferred destination to save these.   LVGL setup. Option 1 Fresh Environment Clone LVGL and LV_DRIVERS repositories, this is a .gitmodules file that points to the specific branches needed. [submodule "lvgl"] path = lvgl url = https://github.com/lvgl/lvgl.git branch = release/v8.3 [submodule "lv_drivers"] path = lv_drivers url = https://github.com/lvgl/lv_drivers.git branch = release/v8.3 NOTE: If you are using other methods, you should point to these commits, lv_drivers @ 8cdabe8 and lvgl @ f2c1032. Gather the necessary files described below from the LVGL Linux Port example found here. Makefile lv_conf.h lv_drv_conf.h main.c mouse_cursor_icon.c Patch the Makefile. + include $(LVGL_DIR)/thermostat/thermostat.mk Patch the lv_drv_conf.h # define EVDEV_NAME "/dev/input/event10" /*You can use the "evtest" Linux tool to get the list of devices and test them*/ +# define EVDEV_NAME "/dev/input/event<Number>" NOTE: This changes according to the output of # evtest. Patch lv_conf.h -#define LV_FONT_MONTSERRAT_20 0 +#define LV_FONT_MONTSERRAT_20 1 Patch the main.c - disp_drv.hor_res = 800; - disp_drv.ver_res = 480; + disp_drv.hor_res = 1080; + disp_drv.ver_res = 1920; … - /*Create a Demo*/ - lv_demo_widgets(); + /*Create a Squareline Demo*/ + ui_init(); LVGL Setup. Option 2 with LVGL demos already running Gather the necessary files described below from the LVGL Linux Port example found here. Makefile lv_conf.h lv_drv_conf.h main.c mouse_cursor_icon.c Patch the lv_drv_conf.h # define EVDEV_NAME "/dev/input/event10" /*You can use the "evtest" Linux tool to get the list of devices and test them*/ +# define EVDEV_NAME "/dev/input/event<Number>" NOTE: This changes according to the output of # evtest. Patch the main.c - disp_drv.hor_res = 800; - disp_drv.ver_res = 480; + disp_drv.hor_res = 1080; + disp_drv.ver_res = 1920; … - /*Create a Demo*/ - lv_demo_widgets(); + /*Create a Squareline Demo*/ + ui_init(); Run the demo Build the demo with the following command and copy the ./demo output to the i.MX 93 EVK RootFS. # source /opt/path/to/your/toolchain # make clean # make The demo can be ran with the following commands. # systemctl stop weston # For LF $ sudo service gdm3 stop # For Ubuntu # ./demo   Conclusion SquareLine demos can run in prebuilt and basic builds of i.MX processors through FB, which can enable a quick set-up for GUI testing before moving to use a windowing stack without sacrificing any features. Appendix Document: How to run LGVL on iMX using framebuffer Official page for pricing information