In this blog, we are going to discuss how we can configure iMX95EVK as PCIe Endpoint and test it using a RC which will be iMX8MM. Hardware Components iMX95EVK iMX8MM PCIe M.2 Key E Bridge Ethernet connectivity     Software Components Linux Factory 6.12.20 BSP linux-imx source code - https://github.com/nxp-imx/linux-imx/tree/lf-6.12.20-2.0.0 System setup Step -1 Flash the 6.12.20 BSP on the iMX95 EVK eMMC/SD card and boot with it. Step-2 Fetch linux-imx 6.12.20 source code from the github repo GitHub - nxp-imx/linux-imx at lf-6.12.20-2.0.0 Step-3 Make the following changes to arch/arm64/boot/dts/freescale/imx95-19x19-evk-pcie1-ep.dtso as per the following diff:-   diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk-pcie1-ep.dtso b/arch/arm64/boot/dts/freescale/imx95-19x19-evk-pcie1-ep.dtso index a8e3bbc53894..d082688fc1c2 100644 --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk-pcie1-ep.dtso +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk-pcie1-ep.dtso @@ -11,12 +11,12 @@ &smmu {  };     -&pcie1 { +&pcie0 {         status = "disabled";  };   -&pcie1_ep { +&pcie0_ep {         pinctrl-names = "default"; -       pinctrl-0 = <&pinctrl_pcie1>; +       pinctrl-0 = <&pinctrl_pcie0>;         status = "okay";  };     As you can see, we are trying to enable 'End-point' mode on iMX95EVK's M.2 PCIe 0. The default dtb enables it for PCIe 1. Building the kernel will build this dtb from the dtso changes. Step-4 SCP the dtb to the board and rename it to "imx95-19x19-evk-pcie0-ep.dtb" to avoid confusion. Copy it to the location - /run/media/boot-mmcblk0p1/ Step-5 Boot the board with this DTB by changing the 'fdtfile' variable at Uboot. when the kernel boots up with this dtb, you will see the following pcie dmesg logs on the console through which you can verify if the changes have worked:-   root@imx95evk:~# dmesg | grep pcie-ep [    3.142123] imx6q-pcie 4c300000.pcie-ep: iATU: unroll T, 8 ob, 8 ib, align 4K, limit 1024G [    3.151767] imx6q-pcie 4c300000.pcie-ep: eDMA: unroll T, 4 wr, 4 rd root@imx95evk:~#   0x4c300000 is the address of pcie0 controller Step-6 Execute this script on iMX95EVK - 'conf_pcie0_ep' Step-7 Boot iMX8MM board with this dtb - imx8mm-evk.dtb Step-8 Executing 'lspci' on the iMX8MM, you will see the following output:- That's the iMX95EVK Endpoint that you see on the lspci output of iMX8MM RC.   The address space translation window is configured with the help of the info mentioned in  arch/arm64/boot/dts/freescale/imx8mm.dtsi If the readers want to make sense out of the translation window info mentioned in form of 'ranges' property of PCIe node, they can go through this article in which there is a detailed explanation of what is going behind the scenes - Demystifying the PCIe and CPU address space translation in Linux - NXP Community      

LSIO_GPIO0_IO0x toggling on i.MX8QM Issue customer met: Customer met LSIO_GPIO0_IO0x not toggling on i.MX8QM, they are working through the software on their board, part of that involves getting a few GPIO pins working. They have been using several GPIO pins for a while now, we have some simple toggles and some others where we bit bang i2c, all of those have worked fine. However, They have not been able to get 3 pins to either read or set successfully at all: LSIO_GPIO0_IO00 (SIM0_CLK) LSIO_GPIO0_IO01 (SIM0_RST) LSIO_GPIO0_IO02 (SIM0_IO) 1\ Reproduce on our i.MX8QM EVK board  a. Check the hardware connection Check the LSIO_GPIO0_IO00 (SIM0_CLK), LSIO_GPIO0_IO01 (SIM0_RST) and LSIO_GPIO0_IO02 (SIM0_IO) connection in our i.MX8QM EVK board. In the default design in NXP i.MX8QM EVK board, the pins SIM0_CLK, SIM0_RST and SIM0_IO connect to the SIM CARD on the base board.         b. To make these pins work as GPIO pins In the default pins mux, default pins mux on the SIM0, to make these pins work as GPIO, need to mux them to the GPIO functions. SIM0_CLK (SIM0_CLK)     SIM0_RST (SIM0_RST)   SIM0_IO (SIM0_IO)     c. In the source code change these pins mux to GPIO configuration: Defalt setting for these pins : linux-imx/arch/arm64/boot/dts/freescale/imx8qm-mek.dts at lf-6.12.y · nxp-imx/linux-imx · GitHub   pinctrl_sim0: sim0grp {                              fsl,pins = <                                            IMX8QM_SIM0_CLK_DMA_SIM0_CLK           0xc0000021                                            IMX8QM_SIM0_IO_DMA_SIM0_IO                 0xc2000021                                            IMX8QM_SIM0_PD_DMA_SIM0_PD               0xc0000021                                           IMX8QM_SIM0_POWER_EN_DMA_SIM0_POWER_EN                         0xc0000021                                            IMX8QM_SIM0_RST_DMA_SIM0_RST            0xc0000021                              >;               }; Linux dts should set them to GPIO0 functions:               IMX8QM_SIM0_CLK_LSIO_GPIO0_IO00 0xc0000021               IMX8QM_SIM0_RST_LSIO_GPIO0_IO01 0xc2000021               IMX8QM_SIM0_IO_LSIO_GPIO0_IO02 0xc0000021 Build the source code, download the images to board, test on the SIM pins to see if these pins can work or not. Test on the J45 pins 3,5,6.   Test the SIM_CLK as an example: Test commands in Linux echo 480 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio480/direction #output high echo 1 > /sys/class/gpio/gpio480/value #measure the PINs #output low echo 0 > /sys/class/gpio/gpio480/value #measure the PINs Found these pins can not toggling well. 2\ Go next further test and consideration Foud the SCU_GPIO0_00, SCU_GPIO0_01, SCU_GPIO0_02 are also configurate as GPIO function in the SCFW,  in the default setting for the SC_P_SCU_GPIO0_00is the function GPIO0_00 , and when setting the SIM0_CLK to GPIO0_00 function then the GPIO0_00 can not work normally. So if setting the SIM0_CLK as GPIO0_00 function, then we need to set the SC_P_SCU_GPIO0_00 this PIN to others function, so that no conflict of them. Even no use the pin SC_P_SCU_GPIO0_00 in hardware, we also need to set them to others function to avoid the conflict. SCU_GPIO Pins mux: SCU_GPIO0_00 (SCU_GPIO0_00)   SCU_GPIO0_01 (SCU_GPIO0_01)   SCU_GPIO0_02 (SCU_GPIO0_02)         Tested the PINs "SIM0_CLK, SIM0_IO, SIM0_RST" on iMX8QM MEK with base board. All of them works fine.  The key points are already listed. VDD_SIM0 power should be supplied (It is 3.3V on MEK from PF8100 LDO)   Linux dts should set them to GPIO0 functions:     IMX8QM_SIM0_CLK_LSIO_GPIO0_IO00 0xc0000021     IMX8QM_SIM0_RST_LSIO_GPIO0_IO01 0xc2000021     IMX8QM_SIM0_IO_LSIO_GPIO0_IO02 0xc0000021 The default IOMUX for PINs SC_P_SCU_GPIO0_00, SC_P_SCU_GPIO0_01, SC_P_SCU_GPIO0_02 should be changed from 0 to others.  Test on MEK, we used followed codes in SCFW board_init():     else if (phase == BOOT_PHASE_FINAL_INIT)     {         /* Configure SNVS button for rising edge */         SNVS_ConfigButton(SNVS_DRV_BTN_CONFIG_RISINGEDGE, SC_TRUE);           /* Init PMIC if not already done */         pmic_init();         pad_force_mux(SC_P_SCU_GPIO0_00, 2,             SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);         pad_force_mux(SC_P_SCU_GPIO0_01, 2,             SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);         pad_force_mux(SC_P_SCU_GPIO0_02, 2,             SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);     }  Note: In SCFW, should also set SC_P_SCU_GPIO0_00, SC_P_SCU_GPIO0_01, SC_P_SCU_GPIO0_02 to other functions, because they are set to GPIO0_0x function default, if two PINs set to the same functions, such as SIM0_CLK_DMA pin and SCU_GPIO0_00 pin are set to GPIO0_00 together, the function will not work correctly.   Test commands in LInux: echo 480 > /sys/class/gpio/export echo 481 > /sys/class/gpio/export echo 482 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio480/direction echo out > /sys/class/gpio/gpio481/direction echo out > /sys/class/gpio/gpio482/direction #output high echo 1 > /sys/class/gpio/gpio480/value echo 1 > /sys/class/gpio/gpio481/value echo 1 > /sys/class/gpio/gpio482/value #measure the PINs, they are correct high  ( 3V ) #output low echo 0 > /sys/class/gpio/gpio480/value echo 0 > /sys/class/gpio/gpio481/value echo 0 > /sys/class/gpio/gpio482/value #measure the PINs, they are correct low ( 0V ) The test result is based on real measurement on iMX8QM MEK.    Note: 1\In customer's side If still not work, To confirm the issue, please suggest customer build SCFW with parameter "-m", then use followed commands to dump the IOMUX registers: md 0x41F80000 1 md 0x41F80040 1 md 0x41F80080 1 md 0x41F82140 1 md 0x41F82180 1 md 0x41F83000 1   The "md" command should run from SCFW debug UART, not linux/uboot UART. 2\Make sure the hardware in customer's side VDD_SIM0 power should be supplied .    

Some customer want to measure DSM power and do some customize in their own board. We supply the the AN13917 to customer already. But some customer also have some questions about it , so here give more details and test for it for customer will more clearly understand and use it. 1 i.MX 93 power mode overview The i.MX 93 supports the following power modes: Run mode: In this mode, the Cortex-A55 CPU is active and running. Some portions can be shut off for power saving. Low-power run mode: This mode is defined as a Low-power run mode with all external power rails on. In this mode, all unnecessary power domains (MIX) can be off. The AONMIX and internal modules, such as OSC24M/PLL, are an exception in this mode. The Cortex CPU in AONMIX handles all the computing and data processing. Cortex-A55 is powered down and DRAM can be in self-refresh/retention mode. Idle mode: This mode is defined as one that a CPU can enter automatically when no threads are engaged, and no high-speed devices are in use. CPU can be put into a power-gated state, but with L3 data retained, DRAM, and bus clocks are reduced. Most of the internal logic is clock-gated; yet is still powered. In this mode, all the external power from PMIC remains the same, and most IPs remain in their state. Therefore, the interrupt response in this mode is quick compared to the Run mode. Suspend mode: This mode is defined as the most power-saving mode since it shuts off all the clocks and all the unnecessary power supplies. In this mode, the Cortex-A55 CPU is fully power gated, all internal digital logic, and the analog circuits that can be powered down are off, and all PHYs are power gated. VDD_SOC(and related digital supply) voltage is reduced to the "Suspend mode" voltage. Compared to Idle, this mode takes a longer time to exit, but it also uses far less energy. BBSM mode: This mode is also called RTC mode. In this mode, to keep RTC and BBSM logic alive, only the power for the BBSM domain remains on. Off mode: In this mode, all power rails are off. 2 Measure the power consumption of the system in the DSM( Deep Sleep Mode) The use case is based on the Suspend mode, which implies the following: CA55 cluster is OFF • MEDIAMIX is OFF • NICMIX is OFF • WAKEUPMIX is OFF • PLL is OFF • 24 M OSC is OFF PMIC is in STBY mode Download the demo images from website: Download the AN13917SW.zip file, upzip it. Copy the uuu and imx93-11x11-evk-dsm.dtb to demo images path. Download the images to board: .\uuu.exe -b emmc_all .\ imx-boot-imx93-11x11-lpddr4x-evk-sd.bin-flash_singleboot  .\imx-image-full-imx93evk.wic To measure the power consumption of the system in the DSM, the steps are as follows: Boot the Linux image with imx93-11x11-evk-DSM.dtb. System boot up with the default dtb, when system boot up change it to the imx93-11x11-evk-DSM.dtb, using the following commends: setenv fdtfile imx93-11x11-evk-dsm.dtb saveenv boot To put the system into the Suspend (Deep sleep) mode, run the following command: echo mem > /sys/power/state Measure the power and record the results. About the BCU Tool: BCU (Board Remote Control Utilities):BCU is a software specially designed to control boards/platforms that support remote control. It provides functions such as on/off key operation, board reset, setting boot mode, controlling GPIO, and power measurement through the debug cable. ------->Remote Control function: $ sudo ./bcu reset sd [-board=xxx] version bcu_1.0.158-0-gdb0a8e5 Auto recognized the board: imx8dxlevk set reset high successfully set onoff high successfully set ft_reset high successfully ENABLE remote control set sd_pwr high successfully set sd_wp high successfully set sd_cd high successfully set boot mode successfully set bootmode_sel low successfully Set ALL sense resistances to smaller ones rebooting... reset successfully done -------->Power measurement function: $ sudo ./bcu monitor -hz=1 [-board=xxx] Here for the power measurement function support the boards have power measurement function. This is the example for the power measurement for the i.MX93 EVK board: 1\Download the BCU tool Releases · nxp-imx/bcu Download the bcu_1.1.100 to Windows 2\Connect the i.MX93 EVK board to Windows PC 3\Open the teminal in the Windows PC C:\Users \Desktop>bcu.exe monitor -board=imx93evk11b1 -hz=1 Use the bcu.exe monitor -board=imx93evk11b1 -hz=1 Make sure the board version is proper, current board is B1 version, so the board name is imx93evk11b1. 4\Run the command in the PC : For others mode test can refer to the BCU.pdf file: https://github.com/nxp-imx/bcu/releases/download/bcu_1.1.100/BCU.pdf Note: To make sure the board version are proper with the related command: bcu.exe monitor -board=imx93evk11b1 -hz=1 For the i.MX93 SOM B2 version Board can use the above command. If the board version is old, such as use the i.MX93 SOM B, here you need to use the command: bcu.exe monitor -board=imx93evk11 If using the bcu.exe monitor -board=imx93evk11b1 the test result are not for this board, here can use the ./bcu eeprom -w -board=imx93evk11 to write the eeprom for the imx93evk11. Using the bcu eeprom -r -board=imx93evk11 see the present status. If we met the problem as bellow we need to check and write to the eeprom again. Measure the power in the DSM mode on the i.MX93 board with SOMB2(board name with the i.mx93evk11b1): old EVK imx93evk11 use a 20m Ohms sensing resistor new EVK imx93evk11b1 use a 5m Ohms sensing resistor For the the i.MX93 board with SOM B Measure the power in the DSM mode on the i.MX93 board with SOMB2 result, use the small and larger range test: Measure the power in the DSM mode on the i.MX93 board with SOMB result: Using the command bcu.exe monitor -board=imx93evk11 -hz=1 3 Questions from customer a.The diff/patch between imx93-11x11-evk.dts and imx93-11x11-evk-dsm.dts If customer use the Linux kernel version: L6.1.55 version BSP, they need to use the imx93-11x11-evk-dsm.dtb we supply. And if using the newer than it and newest BSP in our website, they do not need to change the dtb to the and imx93-11x11-evk-dsm.dtb, just using the imx93-11x11-evk.dts will be OK, as for the Atf  also add the has_wakeup_irq = true;   And in the default imx93-11x11-evk.dts already support the  linux-imx/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts at lf-6.12.y · nxp-imx/linux-imx · GitHub   So customer and directly use on their products. b. NXP i.MX93 EVK DSM power measurement, the GROUP_SOC_FULL  are some difference from our AN. As different chips may show slight differences in static power consumption(SS TT FF) due to process corner variations.  

This article describes how to speed-up the Linux boot time on i.MX 6ULZ to under 2s. Software: Linux BSP 6.12.20-2.0.0 Boot device: SD card The attached imx6ulz-fast-boot.tar.gz archive contains a series of patches which reduces the boot time of the i.MX 6ULZ to ~1.9s. What you'll find in the archive: U-Boot patches: Set the BOOTDELAY to 0 in U-Boot Increase the CPU frequency from 396MHz to 792MHz Add quiet to the kernel bootargs, to suppress the kernel's output during boot Kernel patches: Trim down the kernel to create a minimal version Use LZ4 compression type for the kernel image Minimal rootfs based on BusyBox How to? 1. Prepare the Yocto environment according to Section 3, 4, 5 in i.MX Yocto Project User's Guide. Version 6.12.20-2.0.0, for other versions, you may need to make adjustments. 2. Unzip the imx6ulz-fast-boot.tar.gz archive in the sources directory of your Yocto environment just created. cd ~/imx-yocto-bsp/sources tar -xvpzf imx6ulz-fast-boot.tar.gz -C . 3. Remove additional machine features. Add the configuration below in your conf/local.conf: MACHINE_FEATURES:remove = "\ optee \ alsa \ touchscreen screen \ wifi bluetooth \ bcm4339 bcm43455 \ nxp8987-sdio nxpwifi-all-sdio \ rtc qemu-usermode"  4. Build the image. bitbake core-image-busybox The resulted core-image-busybox-imx6ulz-14x14-evk.rootfs.wic should have ~38M. 5. Write the image on an SD card, and boot. It should boot under 2s from reset to prompt. If you are connected to the serial port of the board, press any key continuously to stop in U-Boot.

As we haven't provided a guide with steps that implement the Linux OS encryption and signature for i.MX9x products so far. So, the document provides the steps for that. For details related to how to encrypt and sign a bootloader image, please have a reference to This Guide 

This article describes how to enable the GPIO support in SPL for i.MX 93 and how to use the associated library. Available GPIO banks Bank Registers' Base Address GPIO1 0x47400000 GPIO2 0x43810000 GPIO3 0x43820000 GPIO4 0x43830000   Software Tests performed using the LF6.12.20-2.0.0 BSP, but should work similarly in other versions.   Enable the GPIO support in SPL Enable the CONFIG_SPL_GPIO through menuconfig. Configure the GPIO pin Make sure the chosen GPIO pin is not used by any other peripheral, by checking U-Boot's device tree (example: imx93-11x11-evk.dts and its included files). If used, disable the conflicting peripheral in the device tree. To identify the exact macro associated to the GPIO functionality, please check the arch/arm/dts/imx93-pinfunc.h file.  Example 1: Use an available GPIO pin (e.g. GPIO2_IO05) This pin is not used by other peripheral, so there is nothing to disable.  To use the pin with the GPIO functionality, the following pin muxing must be added in the iomux node of the imx93-11x11-evk.dts file (located in dts/upstream/src/arm64/freescale/😞 😞 pinctrl_hog: hoggrp { fsl,pins = < MX93_PAD_GPIO_IO05__GPIO2_IO05 0x51e >; }; Note: 0x51e represents the value you want in the PAD register (SW_PAD_CTL_PAD_GPIO_IO05). You may configure it as you want.  Example 2: Use the XSPI1_TXC pin as GPIO (GPIO1_IO12) In our BSP, by default, this pin is used by the SAI1 peripheral. To use this pin as GPIO, SAI1 must be disabled in device tree. &sai1 { status = "disabled"; }; To use the XSPI1_TXC pin with the GPIO functionality, the following pin muxing must be added in the iomux node of the imx93-11x11-evk.dts file (located in dts/upstream/src/arm64/freescale/😞😞 pinctrl_hog: hoggrp { fsl,pins = < MX93_PAD_SAI1_TXC__GPIO1_IO12 0x51e >; }; Include the correct header files In the file you want to use the GPIO, include the following headers: #include <asm/arch-mx7ulp/gpio.h> #include <asm-generic/gpio.h> Define the GPIO To define the GPIO's handle, use the IMX_GPIO_NR(bank, index) macro. index = The pin number within the bank. bank = The GPIO bank number, mapped as follows (due to the way they are placed in memory): GPIO Bank bank value for IMX_GPIO_NR GPIO1 4 GPIO2 1 GPIO3 2 GPIO4 3 Example 1: Compute the handle for GPIO2_IO05 #define TIMED_GPIO IMX_GPIO_NR(1, 5) Example 2: Compute the handle for XSPI1_TXC (GPIO1_IO12) #define TIMED_GPIO IMX_GPIO_NR(4, 12)   Read the GPIO pin gpio_request(TIMED_GPIO, "timed_gpio"); gpio_direction_input(TIMED_GPIO); int val = gpio_get_value(TIMED_GPIO); printf("GPIO value is %d\n", val);   Write the GPIO pin gpio_request(TIMED_GPIO, "timed_gpio"); // set the pin as output and make it high gpio_direction_output(TIMED_GPIO, 1);   The driver used is drivers/gpio/gpio-uclass.c.

Background : Some customer wants to know the DRAM's MR register value. But, For now, we do not have any documentation or binary to complete this. So, this article aim to show how to read this register.   Hardware environment : i.MX8ULP EVK board Software environment : uboot-imx : lf_v2024.04   1. The related registers information are as following:   DENALI CTL 165 [READ MODEREG[24:8]] Read the specified memory mode register from specified chip when start bit set. Bits (7:0) define the memory mode register and bits (15:8) define the chip select. Set bit (16) to 1 to trigger.   DENALI CTL 166 [PERIPHERAL MRR - DATA[31:0]] Data and chip returned from memory mode register read requested by the READ MODEREG parameter. Bits (7:0) indicate the read data and bits (15:8) indicate the chip. READ-ONLY   2. Test result :         Type the below command: mrr <chip_select MR_register>  Like the below picture, when type the mrr 0 c, it means the chip select is 1 and the MR register is MR12, then the value of MR12 register can be output , is 0x1c.     Note : When read the MR register, must make sure the register has read right. Because most of MR register only have write right. you can check about it on JDEC spec document.   If you want to get the test binary file, please contact to me, i will send it to you.

i.MX8MP and i.MX95 both support USB3.0. In EVK board, USB download pin is USB3.0 with Type-C.  While in other boards, they may delete CC logic design PTN5110, or use USB2.0 signals instead. This document describes how to modify U-Boot to support a design without PTN5110 when using the uuu tool to download.

This document explains how to enable and test Bluetooth 6LoWPAN (IPv6 over Low-power Wireless Personal Area Networks) in the i.MX Linux BSP.   Environment   i.MX Linux BSP 6.6.52-2.2.0 (based on Yocto scrathgap) i.MX 93 EVK (2 units) An Embedded Artists 2EL M.2 module with the Murata LBES5PL2EL module (containing NXP IW612) is inserted into the i.MX 93 EVK's M.2 slot and connected to the onboard Wi-Fi/BT antenna. One i.MX 93 EVK will serve as the Peripheral device, while the other will act as the Central device. It should also work with i.MX 8 and 9 series evaluation kit equipped with Bluetooth LE modules.   Configurations   Although the Linux kernel includes a Bluetooth 6LoWPAN driver, it is disabled in the i.MX Linux BSP. Therefore, we will modify the kernel configuration to enable it. Add 2 settings below in kernel configuration file (imx_v8_defconfig) to build the required drivers as modules: CONFIG_6LOWPAN=m CONFIG_BT_6LOWPAN=m These settings can be found in the following section of the Linux kernel menuconfig. CONFIG_6LOWPAN: Depends on: NET [=y] && IPV6 [=y] Location: -> Networking support (NET [=y]) -> Networking options -> 6LoWPAN Support (6LOWPAN [=m]) CONFIG_6LOWPAN  CONFIG_BT_6LOWPAN: Depends on: NET [=y] && BT_LE [=y] && 6LOWPAN [=y] Location: -> Networking support (NET [=y]) -> Bluetooth subsystem support (BT [=y]) -> Bluetooth Low Energy (LE) features (BT_LE [=y]) -> Bluetooth 6LoWPAN support (BT_6LOWPAN [=m]) Rebuild the image containing the Linux kernel and make sure that the required drivers are present in the following paths. /lib/modules/6.6.52-ge0f9e2afd4cf-dirty/kernel/net/6lowpan/6lowpan.ko /lib/modules/6.6.52-ge0f9e2afd4cf-dirty/kernel/net/bluetooth/bluetooth_6lowpan.ko   Operations for Peripheral device   Boot the Peripheral device EVK and log in as the root user. NXP i.MX Release Distro 6.6-scarthgap imx93-11x11-lpddr4x-evk ttyLP0 imx93-11x11-lpddr4x-evk login: root Load the NXP Bluetooth UART driver to enable Bluetooth. # modprobe btnxpuart Start the Bluetooth hci0 interface with the hciconfig command. # hciconfig hci0 up Type hciconfig command to check the BD Address of the Bluetooth hci0 interface and confirm that its status is "UP RUNNING". # hciconfig -a hci0: Type: Primary Bus: UART BD Address: D0:17:69:12:34:56 ACL MTU: 1021:7 SCO MTU: 120:6 UP RUNNING RX bytes:862 acl:0 sco:0 events:59 errors:0 TX bytes:1085 acl:0 sco:0 commands:58 errors:0 Features: 0xbf 0xfe 0x8f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: PERIPHERAL ACCEPT Name: 'imx93-11x11-lpddr4x-evk' Class: 0x200000 Service Classes: Audio Device Class: Miscellaneous, HCI Version: 5.4 (0xd) Revision: 0x8300 LMP Version: 5.4 (0xd) Subversion: 0x1015 Manufacturer: NXP Semiconductors (formerly Philips Semiconductors) (37) Load the Bluetooth 6LoWPAN driver. # modprobe bluetooth_6lowpan Enable Bluetooth 6LoWPAN. # echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable Start Bluetooth advertising and waits for a connection request from the Central device. # bluetoothctl advertise on   Operations for Central device   Boot the Central device EVK and log in as the root user. NXP i.MX Release Distro 6.6-scarthgap imx93-11x11-lpddr4x-evk ttyLP0 imx93-11x11-lpddr4x-evk login: root Load the NXP Bluetooth UART driver to enable Bluetooth. # modprobe btnxpuart Start the Bluetooth hci0 interface with the hciconfig command. # hciconfig hci0 up Type hciconfig command to check the BD Address of the Bluetooth hci0 interface and confirm that its status is "UP RUNNING". # hciconfig -a hci0: Type: Primary Bus: UART BD Address: D0:17:69:AB:CD:EF ACL MTU: 1021:7 SCO MTU: 120:6 UP RUNNING RX bytes:862 acl:0 sco:0 events:59 errors:0 TX bytes:1085 acl:0 sco:0 commands:58 errors:0 Features: 0xbf 0xfe 0x8f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: PERIPHERAL ACCEPT Name: 'imx93-11x11-lpddr4x-evk' Class: 0x200000 Service Classes: Audio Device Class: Miscellaneous, HCI Version: 5.4 (0xd) Revision: 0x8300 LMP Version: 5.4 (0xd) Subversion: 0x1015 Manufacturer: NXP Semiconductors (formerly Philips Semiconductors) (37) Load the Bluetooth 6LoWPAN driver. # modprobe bluetooth_6lowpan Enable Bluetooth 6LoWPAN. # echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable Send a connection request to the Peripheral device. (In this example, the BD address of the Peripheral device is D0:17:69:12:34:56.) # echo "connect D0:17:69:12:34:56 1" > /sys/kernel/debug/bluetooth/6lowpan_control After waiting for a few tens of seconds, the bt0 network interface will appear. (At the same time, the bt0 network interface will appear on the Peripheral device that accepted the connection.) # ifconfig bt0 bt0: flags=4161<UP,RUNNING,MULTICAST> mtu 1280 inet6 fe80::d017:69ff:feab:cdef prefixlen 64 scopeid 0x20<link> unspec D0-17-69-AB-CD-EF-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC) RX packets 9 bytes 884 (884.0 B) RX errors 0 dropped 4 overruns 0 frame 0 TX packets 13 bytes 1069 (1.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 The Central device and Peripheral device are now connected via Bluetooth 6LoWPAN.   Testing Send a ping from the Central device to the Peripheral device. (In this example, the IPV6 address of the Peripheral device is fe80::d017:69ff:fe12:3456.) # ping6 fe80::d017:69ff:fe12:3456%bt0 PING fe80::d017:69ff:fe12:3456%bt0 (fe80::d017:69ff:fe12:3456%bt0) 56 data bytes 64 bytes from fe80::d017:69ff:fe12:3456%bt0: icmp_seq=1 ttl=64 time=181 ms 64 bytes from fe80::d017:69ff:fe12:3456%bt0: icmp_seq=2 ttl=64 time=125 ms 64 bytes from fe80::d017:69ff:fe12:3456%bt0: icmp_seq=3 ttl=64 time=67.7 ms 64 bytes from fe80::d017:69ff:fe12:3456%bt0: icmp_seq=4 ttl=64 time=56.1 ms ...   Benchmarking   Run the iperf3 server on the Peripheral device. # iperf3 -s Run the iperf3 benchmark on the Central device. For example, check the TCP connections. # iperf3 -V -c fe80::d017:69ff:fe12:3456%bt0 You can also check UDP connections. For example, the following example sends UDP 200Kbps bandwidth. # iperf3 -V -c fe80::d017:69ff:fe12:3456%bt0 -u -b 200K   Disclaimer   This document is provided as a reference for utilizing NXP products. Please refer to the official product manuals and application notes for formal specifications. Due to differences in software versions and other conditions, actual behavior may differ from the descriptions provided. This document does not verify all functions, so please be sure to conduct appropriate validation and testing to ensure suitability for your intended use.  

Streaming different use case pipelines between i.MX 95 and i.MX 8M Plus LF-6.12.20

We are pleased to announce that Config Tools for i.MX v25.09 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...) • The Release Notes format is updated from plain text to markdown. • The newly generated configuration includes the default NXP copyright notice and is licensed under the BSD-3-Clause license. • DDR tool – ODT and Driver Strength Updates for LP4/LP5 on i.MX 943 and i.MX 95 – Improved DRAM Configuration for i. MX 9x devices – Multicore support is enabled for DDR tests on i.MX 943 and i.MX 95 – Linux support for the DDR tool – Vref DQ Setting now available in the GUI – Board-agnostic SM Support for i.MX 943 and i.MX 95 – DDR part number entry is supported in the GUI – Enhanced logging from the target application – Stress test repetition option is enabled – Updated ODT shmoo scenario values on i.MX 943 and i.MX 95 – Support for SNPS FW and PHY Init 2024.09 SP2 on i.MX 943 and i.MX 95 – AHAB image update to align with BSP for CES parts on i.MX 943 and i.MX 95 – New configuration support for 15x15 on i.MX 943 – Improved bus configuration for single-channel setups – LP4/LP5 CS signal configuration now exposed in the GUI for i.MX 943 and i.MX 95 • Clocks – Supported input frequency setting • System Manager – Initial version of the tool

This article describe some bring up tips during i.MX95 board debug, including HW and SW aspects.  

based on customer's issue when use PTF pins of imx8ulp as GPIO or gpio hog

  This document shows how to use the open source gstreamer1.0-rtsp-server package on i.MX6QDS and i.MX8x to stream video files and camera using RTP protocol.  The i.MX 6ULL and i.MX 7 doesn't have Video Processing Unit (VPU). Real time protocol (RTP) is a very common network protocol for delivering media over IP networks. On the board, you will need a GStreamer pipeline that encodes the raw video, adds the RTP payload, and sends over a network sink. A generic pipeline would look as follows: video source ! video encoder ! RTP payload ! network sink Video source: often it is a camera, but it can be a video from a file or a test pattern, for example. Video encoder: a video encoder as H.264, H.265, VP8, JPEG and others. RTP payload: an RTP payload that matches the video encoder. Network sink: a video sync that streams over the network, often via UDP. Pre-Requisites: MX6x o MX8x board with the L6.6.52 BSP installed. A host PC with either Gstreamer or VLC player installed.   Receiving h264 / h.265 Encoded RTP Video Stream on a Host Using GStreamer: GStreamer is a low-latency method for receiving RTP video. On your host machine, install Gstreamer and send the following command: $ gst-launch-1.0 -v udpsrc port=5000 caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay ! decodebin ! videoconvert ! autovideosink sync=false   Using HOST PC: VLC Player Optionally, you can use VLC player to receive RTP video on a PC. First, in your PC, create a sdp file with the following content:  stream.sdpv=0m=video 5000 RTP/AVP 96c=IN IP4 127.0.0.1a=rtpmap:96 H264/90000 After this, with the GStreamer pipepline on the device running, open this .sdp file with VLC Player on the host PC.   Sending h.264 and h.265 Encoded RTP video stream GStreamer provides an h.264 encoding element by software named x264enc. Use this plugin if your board does not support h.264 encoding by hardware or if you want to use the same pipeline on different modules. Note that the video performance will be lower compared with the plugins with encoding accelerated by hardware. # gst-launch-1.0 videotestsrc ! videoconvert ! x264enc ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000 Note: Replace <host-machine-ip> by the IP of the host machine. In all examples you can replace videotestsrc by v4l2src element to collect a stream from a camera   i.MX8X # gst-launch-1.0 videotestsrc ! videoconvert ! v4l2h264enc ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000   i.MX8M Mini Quad / 8M Plus # gst-launch-1.0 videotestsrc ! videoconvert ! vpuenc_h264 ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000 i.MX6X The i.MX6QDS does not support h.265 so the h.264 can work: # gst-launch-1.0 videotestsrc ! videoconvert ! vpuenc_h264 ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000 Using other video Encoders While examples of streaming video with other encoders are not provided, you may try it yourself. Use the gst-inspect tool to find available encoders and RTP payloaders on the board: # gst-inspect-1.0 | grep -e "encoder"# gst-inspect-1.0 | grep -e "rtp" -e " payloader" Then browse the results and replace the elements in the original pipelines. On the receiving end, you will have to use a corresponding payload. Inspect the payloader element to find the corresponding values. For example: # gst-inspect-1.0 rtph264pay   Install rtp in your yocto different form L6.6.52 BSP, to install gstreamer1.0-rtsp-server in any Yocto Project image, please follow the steps below: Enable meta-multimedia layer: Add the following on your build/conf/bblayers.conf: BBLAYERS += "$"${BSPDIR}/sources/meta-openembedded/meta-multimedia" Include gstreamer1.0-rtsp-server into the image: Add the following on your build/conf/local.conf: IMAGE_INSTALL_append += "gstreamer1.0-rtsp-server" Run bitbake and mount your sdcard. Copy the binaries: Access the gstreamer1.0-rtsp-server examples folder: $ cd /build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0-rtsp-server/$version/build/examples/.libs Copy the test-uri and test-launch to the rootfs /usr/bin folder. $ sudo cp test-uri test-launch /media/USER/ROOTFS_PATH/usr/bin Be sure that the IPs are correctly set: SERVER: => ifconfig eth0 $SERVERIP CLIENT: => ifconfig eth0 $CLIENTIP Video file example SERVER: => test-uri file:///home/root/video_file.mp4 CLIENT: => gst-launch-1.0 playbin uri=rtsp://$SERVERIP:8554/test You can try to improve the framerate performance using manual pipelines in the CLIENT with the rtspsrc plugin instead of playbin. Follow an example: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test caps = 'application/x-rtp'  ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! queue max-size-buffers=0 ! imxv4l2sink sync=false   Camera example SERVER: => test-launch "( imxv4l2src device=/dev/video0 ! capsfilter caps='video/x-raw, width=1280, height=720, framerate=30/1, mapping=/test' ! vpuenc_h264 ! rtph264pay name=pay0 pt=96 )" CLIENT: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test ! decodebin ! autovideosink sync=false The rtspsrc has two properties very useful for RTSP streaming: Latency: Useful for low-latency RTSP stream playback (default 200 ms); Buffer-mode: Used to control buffer mode. The slave mode is recommended for low-latency communications. Using these properties, the example below gets 29 FPS without a sync=false property in the sink plugin. The key achievement here is the fact that there is no dropped frame: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test latency=100 buffer-mode=slave ! queue max-size-buffers=0 ! rtph264depay ! vpudec ! imxv4l2sink    

  This article shows how to use the i.MX6DL/Q to transcode and stream videos on 1080i/p @ 24fps and 720p @ 30fps. For this test, we used one i.MX6DL as server and an i.MX6DL and i.MX6Q as clients. The video is streamed by the server, playing the sound at the same time, while the clients show the video in the HDMI output, as the image below:     This test depends on some GStreamer plugins. To check that the right GStreamer plugins are installed type the following commands: $ gst-inspect-1.0 | grep h264 To return all the H.264 related plugins, or: $ gst-inspect-1.0 decodebin To check directly the command. To connect more than one board to the minicom, open it with the command: $ sudo minicom –s This way, you open the configuration menu. Enter in the “Serial port setup” option and press “A” to set or change the PORTNUMBER, in “ttyUSB$PORTNUMBER”. To set the HDMI output, run the commands below from the U-Boot prompt: => setenv mmcargs 'setenv bootargs console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 consoleblank=0' => saveenv Be sure that the IPs are correctly setted: SERVER: => ifconfig eth0 $SERVERIP CLIENTS: => ifconfig eth0 $CLIENTSIP Streaming transcoded video only SERVER: => gst-launch-1.0 filesrc location=/home/root/bbb_720p.mp4 ! decodebin ! queue max-size-buffers=0 ! vpuenc_h264 gop-size=2 bitrate=20000 ! queue max-size-buffers=0 ! rtph264pay config-interval=2 ! queue max-size-buffers=0 ! gdppay ! tcpserversink blocksize=512000 host=$SERVERIP$ port=8554 CLIENTS: => gst-launch-1.0 tcpclientsrc host=$SERVERIP$ port=8554 ! gdpdepay ! queue max-size-buffers=0 ! 'application/x-rtp, media=(string)video, clock10-rate=(int)90000, payload=(int)96' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! autovideosink sync=false Streaming transcoded video + audio SERVER: => gst-launch-1.0 filesrc location=/home/root/bbb_720p.mp4 ! decodebin name=demux demux. ! queue max-size-buffers=0 ! vpuenc_h264 gop-size=2 bitrate=20000 ! queue max-size-buffers=0 ! rtph264pay config-interval=2 ! queue max-size-buffers=0 ! gdppay ! tcpserversink blocksize=512000 host=$SERVERIP$ port=8554 demux. ! alsasink CLIENTS: => gst-launch-1.0 tcpclientsrc host=$SERVERIP$ port=8554 ! gdpdepay ! queue max-size-buffers=0 ! 'application/x-rtp, media=(string)video, clock10-rate=(int)90000, encoding-name=(string)H264' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! autovideosink sync=false   You can check the results with the 1080p@24fps.

This guide walks you through the required steps to prepare your development environment and hardware for debugging the M core on the IMX8MP-EVK board using the MCU-LINK Pro. You’ll install the necessary firmware, compile and flash a binary, and finally, initiate a debug session using MCUXpresso for VS Code. Requirements: IMX8MP-EVK Board MCU-LINK Pro Debug Probe PC Host with MCUXpresso for VS Code installed Install Segger Firmware on MCU-LINK Pro By default, the MCU-LINK Pro does not support i.MX processors. Installing the Segger firmware is essential for proper debugging. Follow the firmware update guide to update your MCU-LINK Pro.   Compile the Binary for the M Core Ensure MCUXpresso for VS Code is properly installed.   Import the iMX8MP-EVK SDK   Import "hello world" example Ensure that we are compiling a debug binary Build Project Flash the Binary using UUU Tool Connect the IMX8MP-EVK Board to your Host PC via USB   Enter Fastboot Mode in U-Boot Terminal => fastboot 0   On your Host PC, navigate to the binary location and flash it using the next commands: $ cd <project_location>/armgcc/debug/ $ uuu -b fat_write hello_world.bin mmc X:1 hello_world_debug.bin Note: replace the X with 2 if you are booting from eMMC or 1 if you are booting from SD Card   Connect MCU-LINK Pro to the Target   IMX8MP-EVK Debug connection:     Launch the M Core from U-Boot Terminal Use the following commands in the U-Boot terminal: => fatload mmc X:1 0x48000000 hello_world_debug.bin; cp.b 0x48000000 0x7e0000 0x20000; => bootaux 0x7e0000 Note: replace the X with 2 if you are booting from eMMC or 1 if you are booting from SD Card   Start the Debug Session Once the M core is launched, you can start your debug session in VS Code using MCUXpresso:          With the MCU-LINK Pro configured, the IMX8MP-EVK, and the binary successfully flashed and executed, you are now ready to debug applications on the M core using MCUXpresso and VS Code. This setup enables a reliable development workflow for i.MX8MP based projects.   References: AN14120.pdf 

The documentation is to provide steps for single secure boot for BSP Android 14.0.0_2.0.0. More details related to secure boot for Android BSP can be found from IMX ANDROID SECURE BOOT. However, the steps in this document facilitate some helps signing an Android boot image in the aspects of - First, the Android build process for signing the image, and second, the FDT signing process must be performed after the SPL/FIT of the signing process. The second one of which is crucial.   Best regards Harvey

This guide walks you through the required steps to prepare your development environment and hardware for debugging the M core on the IMX8MN-EVK board using the MCU-LINK Pro. You’ll install the necessary firmware, compile and flash a binary, and finally, initiate a debug session using MCUXpresso for VS Code. Requirements: IMX8MN-EVK Board MCU-LINK Pro Debug Probe PC Host with MCUXpresso for VS Code installed Install Segger Firmware on MCU-LINK Pro By default, the MCU-LINK Pro does not support i.MX processors. Installing the Segger firmware is essential for proper debugging. Follow the firmware update guide to update your MCU-LINK Pro.   Compile the Binary for the M Core Ensure MCUXpresso for VS Code is properly installed.   Import the iMX8MN-EVK SDK   Import "hello world" example Ensure that we are compiling a debug binary Build Project   Flash the Binary using UUU Tool Connect the IMX8MN-EVK Board to your Host PC via USB   Enter Fastboot Mode in U-Boot Terminal => fastboot 0   On your Host PC, navigate to the binary location and flash it using the next commands: $ cd <project_location>/armgcc/debug/ $ uuu -b fat_write hello_world.bin mmc X:1 hello_world_debug.bin Note: replace the X with 2 if you are booting from eMMC or 1 if you are booting from SD Card   Connect MCU-LINK Pro to the Target   IMX8MN-EVK Debug connection:   Launch the M Core from U-Boot Terminal Use the following commands in the U-Boot terminal: => fatload mmc X:1 0x48000000 hello_world_debug.bin; cp.b 0x48000000 0x7e0000 0x20000; => bootaux 0x7e0000 Note: replace the X with 2 if you are booting from eMMC or 1 if you are booting from SD Card   Start the Debug Session Once the M core is launched, you can start your debug session in VS Code using MCUXpresso:      With the MCU-LINK Pro configured, the IMX8MN-EVK, and the binary successfully flashed and executed, you are now ready to debug applications on the M core using MCUXpresso and VS Code. This setup enables a reliable development workflow for i.MX8MN based projects.   References: AN14120.pdf 

This guide walks you through the required steps to prepare your development environment and hardware for debugging the M core on the IMX8MM-EVK board using the MCU-LINK Pro. You’ll install the necessary firmware, compile and flash a binary, and finally, initiate a debug session using MCUXpresso for VS Code. Requirements: IMX8MM-EVK Board MCU-LINK Pro Debug Probe PC Host with MCUXpresso for VS Code installed Install Segger Firmware on MCU-LINK Pro By default, the MCU-LINK Pro does not support i.MX processors. Installing the Segger firmware is essential for proper debugging. Follow the firmware update guide to update your MCU-LINK Pro.   Compile the Binary for the M Core Ensure MCUXpresso for VS Code is properly installed.   Import the iMX8MM-EVK SDK   Import "hello world" example Ensure that we are compiling a debug binary Build Project   Flash the Binary using UUU Tool Connect the IMX8MM-EVK Board to your Host PC via USB   Enter Fastboot Mode in U-Boot Terminal => fastboot 0   On your Host PC, navigate to the binary location and flash it using the next commands: $ cd <project_location>/armgcc/debug/ $ uuu -b fat_write hello_world.bin mmc X:1 hello_world_debug.bin Note: replace the X with 2 if you are booting from eMMC or 1 if you are booting from SD Card Connect MCU-LINK Pro to the Target     IMX8MM-EVK Debug connection:   Launch the M Core from U-Boot Terminal Use the following commands in the U-Boot terminal: => fatload mmc X:1 0x48000000 hello_world_debug.bin; cp.b 0x48000000 0x7e0000 0x20000; => bootaux 0x7e0000 Note: replace the X with 2 if you are booting from eMMC or 1 if you are booting from SD Card     Start the Debug Session Once the M core is launched, you can start your debug session in VS Code using MCUXpresso:      With the MCU-LINK Pro configured, the IMX8MM-EVK, and the binary successfully flashed and executed, you are now ready to debug applications on the M core using MCUXpresso and VS Code. This setup enables a reliable development workflow for i.MX8MM based projects.   References: AN14120.pdf 

This guide walks you through the required steps to prepare your development environment and hardware for debugging the M core on the IMX93-EVK board using the MCU-LINK Pro. You’ll install the necessary firmware, compile and flash a binary, and finally, initiate a debug session using MCUXpresso for VS Code. Requirements: IMX93-EVK Board MCU-LINK Pro Debug Probe PC Host with MCUXpresso for VS Code installed Install Segger Firmware on MCU-LINK Pro By default, the MCU-LINK Pro does not support i.MX processors. Installing the Segger firmware is essential for proper debugging. Follow the firmware update guide to update your MCU-LINK Pro.   Compile the Binary for the M Core Ensure MCUXpresso for VS Code is properly installed.   Import the iMX93-EVK SDK     Import "hello world" example   Ensure that we are compiling a debug binary Build Project   Flash the Binary using UUU Tool Connect the IMX93-EVK Board to your Host PC via USB       Enter Fastboot Mode in U-Boot Terminal => fastboot 0   On your Host PC, navigate to the binary location and flash it using the next commands: $ cd <project_location>/armgcc/debug/ $ uuu -b fat_write sdk20-app.bin mmc X:1 hello_world.bin Note: replace the X with 0 if you are booting from eMMC or 1 if you are booting from SD Card     Connect MCU-LINK Pro to the Target     IMX93-EVK Debug connection:       Launch the M Core from U-Boot Terminal Use the following commands in the U-Boot terminal: => fatload mmc X:1 80000000 hello_world.bin; cp.b 0x80000000 0x201e0000 0x10000; => bootaux 0x1ffe0000 0 Note: replace the X with 0 if you are booting from eMMC or 1 if you are booting from SD Card     Start the Debug Session Once the M core is launched, you can start your debug session in VS Code using MCUXpresso:        With the MCU-LINK Pro configured, the IMX93-EVK, and the binary successfully flashed and executed, you are now ready to debug applications on the M core using MCUXpresso and VS Code. This setup enables a reliable development workflow for i.MX93-based projects.   References: AN14120.pdf