This article introduces the overall functionality of i.MX8X security. Simulate the process of i.MX8X signature through OpenSSL provides readers with a deeper understanding of this process.   Because lots of limitation for attachments. Have to do following.  1. download                       T4549-i.MX8X security overview and AHAB deep dive.zip.001.zip                      T4549-i.MX8X security overview and AHAB deep dive.zip.002.zip                      T4549-i.MX8X security overview and AHAB deep dive.zip.003.zip 2. decompress                T4549-i.MX8X security overview and AHAB deep dive.zip.001.zip                T4549-i.MX8X security overview and AHAB deep dive.zip.002.zip                T4549-i.MX8X security overview and AHAB deep dive.zip.003.zip 3. Put together and decompress         T4549-i.MX8X security overview and AHAB deep dive.zip.001    T4549-i.MX8X security overview and AHAB deep dive.zip.002    T4549-i.MX8X security overview and AHAB deep dive.zip.003  

Dynamic debug is designed to allow you to dynamically at runtime  enable/disable  kernel code to obtain additional kernel information. Currently, if ``CONFIG_DYNAMIC_DEBUG`` is set, then all ``pr_debug()``/``dev_dbg()`` and ``print_hex_dump_debug()``/``print_hex_dump_bytes()`` calls can be dynamically enabled per-callsite.    

Symptoms   Trying to initialize a repo, for example:  $repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.36-2.1.0.xml we have the below log: File "/home/username/bin/repo", line 51 def print(self, *args, **kwargs): ^ SyntaxError: invalid syntax   Workaround (1)   The first workaround consist in change the python alternatives (caused when you have installed two or more python versions). NOTE: in my case, the python version that i want to change as first priority is python3.8 $sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.8 1   Then we run: $sudo update-alternatives --config python    To verify if your python priority was changed successfully try: $python --version   You should see the version configured as priority number 1.     Workaround (2)   The workaround is very simple, only we need modify the repo file $ nano ~/bin/repo   and we will change the python interpreter in the first line (from python to python3): ORIGINAL FILE   EDITED FILE   After to do this change, repo will works fine again.     I hope this can helps to you!   Best regards.

  Environment i.MX8MP EVK, SDK2.15   The default rpmsg buffer size in SDK is 512Bytes(16 Bytes header + 496Bytes payload). This knowledge base will try to change the default buffer size in rpmsg framework. Steps:   1.Modify rpmsg payload size in SDK PATH: SDK\evkmimx8mp_rpmsg_lite_str_echo_rtos_imxcm7\rpmsg_config.h     //! RL_BUFFER_PAYLOAD_SIZE //! //! Size of the buffer payload, it must be equal to (240, 496, 1008, ...) //! [2^n - 16]. Ensure the same value is defined on both sides of rpmsg //! communication. The default value is 496U. #define RL_BUFFER_PAYLOAD_SIZE (1008)     2. Modify buffer size in rpmsg linux framework and buffer pool in dts. PATH: drivers/rpmsg/virtio_rpmsg_bus.c            arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts   Test steps:   Modify the send buffer in imx_rpmsg_tty.c     #define MSG "hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world! hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world! hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!"       Modify buffer limitation in SDK PATH: evkmimx8mp_rpmsg_lite_str_echo_rtos_imxcm7\main_remote.c     /* Globals */ static char app_buf[1024]; /* Each RPMSG buffer can carry less than 512 payload */       Terminal output We can see that the MAX buffer size received in SDK is not limited to 512Bytes     Nameservice sent, ready for incoming messages... Get Message From Master Side : "hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world! hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world! hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!" [len : 674]       If we use a larger buffer like 2022 Bytes, we will see error when driver load.     [ 2673.447384] imx_rpmsg_tty virtio0.rpmsg-virtual-tty-channel-1.-1.30: message is too big (2022) [ 2673.456271] imx_rpmsg_tty virtio0.rpmsg-virtual-tty-channel-1.-1.30: rpmsg_send failed: -90 [ 2673.465556] imx_rpmsg_tty virtio0.rpmsg-virtual-tty-channel-1.-1.30: rpmsg_dev_probe: failed: -90 [ 2673.474496] imx_rpmsg_tty: probe of virtio0.rpmsg-virtual-tty-channel-1.-1.30 failed with error -90          

We are pleased to announce that Config Tools for i.MX v15.0 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...)Version 15.0 • The product is based on Eclipse 2023-06 TEE – Setting a security level for a special three-state model is improved. Pins – Validation to ensure that elements can be configured by the selected core is added. – Rows are sorted in the Peripheral Signals routing dialog. – A connected pins column in External User Signals always shows the pin's full name. – The missing scroll bar in the External User Signals view is fixed. Clocks – Support for multicore code generation is added. – Global configuration elements now support a tree structure and can be categorized. – Fractional PLL now supports a custom range and negative numerator. – Scrolling in the clock diagram by pressing the mouse wheel (drag and drop) is supported. DCD – The issue with the code generation that stopped working after the drag and drop of a group is fixed.  

i.MX6 Series - Crystal Drive Level guidance; includes calculator.  

In the IMX8MM SDK unfortunately we cannot find any example about of use a GPIO as an input with interrupt.  To use a GPIO as input with interrupt we need to keep in mind how the GPIO IRQs works in the ARM Cortex M4.   We can find in Table 7-2 (CM4 Interrupt Summary) of IMX8MMRM (IMX8MM Reference Manual) the GPIOs IRQs are divided by two parts:     Combined interrupt indication for GPIOn signal 0 throughout 15  Combined interrupt indication for GPIOn signal 16 throughout 31    This basically means, the pines of GPIOn from 0 to 15 are handled by Combined interrupt indication for GPIOn signal 0 throughout 15 and the pines from 16 to 31 are handled by Combined interrupt indication for GPIOn signal 16 throughout 31.    In SDK we can find these definitions in:  <SDK root>/devices/MIMX8MM6/MIMX8MM6_cm4.h (Remember this is for IM8MM SDK)    In this example I will use GPIO5_IO12 (ECSPI2_MISO) as Input with IRQ and GPIO5_IO11 (ECSPI_MOSI) as Output of IMX8MM-EVK. I will connect the Output to the Input and will see the behavior of the IRQ in Rising and Falling edge.    For this example I will connect ECSPI2_MOSI (GPIO5_IO11) to ECSPI_MISO (GPIO5_IO12):   See the below definitions:   #define IN_GPIO   GPIO5  This define the GPIO base of the IN pin  #define IN_GPIO_PIN  12u  This define the pin number (for in)  #define IN_IRQ  GPIO5_Combined_0_15_IRQn  This define the IRQ number (72 in this case)  #define GPIO_IRQ_HANDLER  GPIO5_Combined_0_15_IRQHandler  This is a "pointer" to function that will handle the interrupt  #define IN_NAME  "IN GPIO5_IO12"  This is only a name or description for the pin    See below definitions:    #define OUT_GPIO  GPIO5  This is the GPIO base of OUT pin  #define OUT_GPIO_PIN  11u  This define the pin number (for out)  #define OUT_NAME  "OUT GPIO5_IO11"  This is only a name or description for the pin      Now the below section is the IRQ handler (which was defined before)😞   The GPIO_ClearPinsInterruptFlags(IN_GPIO, 1u << IN_GPIO_PIN); refers to GPIOx_ISR register:      For this example, the IRQ Handler will print "IRQ detected ............" in each interrupt.    We will create two different GPIOs config, one for Output and other one for Input with IRQ Falling edge:    Then configure the GPIOs and IRQ:     EnableIRQ refers to enable the 72 IRQ.   GPIO_PortEnableInterrupts refers to GPIOx_IMR: Finally, the example put the out GPIO5_IO11 in High state and then in low state many. First the IRQ is configured as Falling edge, then as Rising edge.     I will attach the complete source file.    To compile it you can use ARMGCC toolchain directly, but I like to use VSCode with MCUXpresso integration.  Once, when you have your .bin file (in my case igpio_led_output.bin) you can load to board with UUU tool: In your Linux machine: sudo uuu -b fat_write igpio_led_output.bin mmc 2:1 gpio.bin In U-boot board: u-boot=> fastboot 0   Then, when the .bin file was loaded, you can load to the CORTEX M4 in U-boot whit: u-boot=> fatload mmc 2:1 ${loadaddr} gpio.bin 7076 bytes read in 14 ms (493.2 KiB/s) u-boot=> cp.b 0x80000000 0x7e0000 0x10000 u-boot=> bootaux 0x7e0000 ## No elf image ar address 0x007e0000 ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE02CD... u-boot=>   NOTE: You can load the binary to cortex m4 with Custom bootscripts for practicity.   Once the binary loaded in M4 core you should see in seria terminal this logs (Remember GPIO5_IO11 and GPIO5_IO12 must be connected to get the same logs):    And the logs when you disconnect the GPIO5_IO11 and GPIO5_IO12 in execution time:  🔴Disconnection (Red color) 🔵Reconnection (Blue color)   I hope this can helps.     Best regards!    Salas. 

some customers doesn't have any issue on old bsp, but have bring up issue on new 6.1 bsp, this article is about this and how to fix this

Hello there. Here is a good way to use U-boot in an efficient way with custom scripts. The bootscript is an script that is automatically executed when the boot loader starts, and before the OS auto boot process. The bootscript allows the user to execute a set of predefined U-Boot commands automatically before proceeding with normal OS boot. This is especially useful for production environments and targets which don’t have an available serial port for showing the U-Boot monitor. This information can be find in U-Boot Reference Manual.   I will take the example load a binary file in CORTEX M4 of IMX8MM-EVK. In my case, I have the binary file in MMC 2:1 called gpio.bin and I will skip those steps because that is not the goal.   First, you need the u-boot-tools installed in your Linux machine: sudo apt install u-boot-tools   That package provide to us the tool mkimage to convert a text file (.src, .txt) file to a bootscript file for U-Boot.   Now, create your custom script, in this case a simple script for load binary file in Cortex M4: nano mycustomscript.scr  and write your U-Boot commands: fatload mmc 2:1 0x80000000 gpio.bin cp.b 0x80000000 0x7e0000 0x10000 bootaux 0x7e0000   Now we can convert the text file to bootscript with mkimage. Syntax: mkimage -T script -n "Bootscript" -C none -d <input_file> <output_file> mkimage -T script -n "Bootscript" -C none -d mycustomscript.scr LCM4-bootscript   This will create a file called LCM4-bootscript (Or as your called it).   A way to load this bootscript file to U-Boot is using the UUU tool, in U-Boot set the device in fastboot with command: u-boot=> fastboot 0 Then in linux with the board connected through USB to PC run the command: sudo uuu -b fat_write LCM4-bootscript mmc 2:1 LCM4-bootscript   Now we have our bootscript in U-Boot in MMC 2:1.   Finally, we can run the bootscript in U-Boot: u-boot=> load mmc 2:1 ${loadaddr} LCM4-bootscript 158 bytes read in 2 ms (77.1 KiB/s) u-boot=> source ${loadaddr} ## Executing script at 40400000 6656 bytes read in 5 ms (1.3 MiB/s) ## No elf image at address 0x007e0000 ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE02CD...   And the Cortex M4 booted successfully:    I hope this can helps to you.   Best regards.   Salas.  

This document intends to provide an overview of the i.MX8 Boot process and walk you through the process of creating a bootable image.   Boot process Coming out of a reset state the i.MX8 ROM (firmware that is stored in non-volatile memory of the i.MX8) reads the boot mode pins to determine the boot media/device that will be used. The i.MX8 can boot out of the following boot devices: eMMC/SD card FlexSPI Flash NAND Serial Download Protocol (USB) - This is used in manufacturing mode to bring-up a board by downloading an image to RAM and then flashing the on-board boot device.   The following table indicates the available options on a i.MX8QXP, the i.MX8 reads the boot mode pads and based in the configuration selects the desired boot device.   Once the boot device has been identified, ROM configures the boot media and attempts to read the image from a predefined address in the boot device, the following table shows the addresses where the image is expected to be on different boot devices. ROM loads data from the predefined addresses above (depending on the selected boot device) to the System Controller Unit (SCU) internal memory (tightly coupled memory) and parses it to find the image container. It can also boot by downloading an image through USB.   The image container has all the information needed to load all the images to the system, the first images that get loaded are the System Controller Firmware (SCFW) and Security Controller Firmware (SECO). The SECO FW needs to be loaded to refresh the watchdog timer (kick the dog) in the device, if the SECO FW is not loaded before the watchdog expires the device will reset, this usually happens when the device fails to fetch a valid image from the boot media.   Once the SCFW is loaded, ROM jumps to it and starts executing it. The SCFW then initializes the DDR and starts loading the images for the Cortex-M4 (optional) and the Cortex-A cores (optional). Once the images are loaded to their destination memory the SCFW boots the cores and sets them in their start address.   Creating a bootable image As a recap a bootable image is comprised of as minimum the System Controller Firmware and the Security Controller Firmware, optionally it can contain images for the Cortex M4 cores (if more than one available as in the case of QM devices) and Cortex A cores. It is possible to boot an image that only contains the SCFW and SECO FW, this could be useful in the first stages of porting the SCFW to the target board. It is also possible to boot an image with only the Cortex-M4 image (baremetal, FreeRTOS, AutoSAR...), only the Cortex-A image (U-boot or any bootloader) or both Cortex-M4 and Cortex-A images.   Mkimage tool The tool in charge of merging all these images and creating a bootable image for the i.MX8 is called mkimage, and can be obtained in source form in the following repository: https://github.com/nxp-imx/imx-mkimage mkimage is only supported in Linux So the first step is to clone the mkimage repository into our machine and checkout the latest branch, at the time of writing this document the latest release is 4.14.98_02: git clone https://source.codeaurora.org/external/imx/imx-mkimage cd imx-mkimage git checkout imx_4.14.98_2.0.0_ga‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ You should now be able to see the following folders:   Getting the SCFW Now that you have the mkimage tool you need some actual images to work with, if you are using a custom board you might need to port the SCFW and DDR configuration files for it (depending on how close it follows NXP's reference board).   The following is a compendium of documents on the basics of the SCFW and how to build it from scratch you can go there if you need help getting started with the porting process: https://community.nxp.com/docs/DOC-342654   If you are trying this on one of NXP's reference board you can use a pre-built SCFW binary, this can be obtained through the building process of the Yocto project or by downloading the porting kit and following these steps: Dowload SCFW binaries for release 4.14.98_02 here. chmod a+x imx-sc-firmware-1.2.bin ./imx-sc-firmware-1.2.bin‍‍‍‍‍‍‍‍‍‍ You will prompted to accept a license agreement and after that the binaries will be extracted:   Getting the SECO FW The Security Controller Firmware is only distributed in binary form and can be obtained from the NXP website. Download SECO FW binaries for release 4.14.98_02 here. chmod a+x firmware-imx-8.1.bin ./firmware-imx-8.1.bin‍‍‍‍‍‍‍‍‍‍ You will prompted to accept a license agreement and after that the binaries will be extracted: The SECO FW is under firmware/seco mx8qm-ahab-container.img -----> SECO FW for QM devices mx8qx-ahab-container.img ------> SECO FW for QXP devices   Getting an image for the Cortex-M4 The image for the Cortex-M4 can be generated using the SDK: https://mcuxpresso.nxp.com/en/select Just select the device you are working with and click Build MCUXpresso SDK, then you will prompted to select your IDE and host. Click on Download SDK and a compressed file containing the SDK will be dowloaded to your computer. Now you only need to uncompress the file and follow the steps in the getting started document to generate the image.  The getting started document includes steps to setup the toolchain and build an image for the M4. An M4 binary for the QM and QXP MEKs is also attached in this document, the example outputs a hello world message on the M4 terminal. Getting an image for the Cortex-A  The bootloader for the Cortex-A cores can be obtained through the Yocto BSP: The steps on generating the image for the 4.14.98 release can be found here: https://www.nxp.com/webapp/Download?colCode=imx-yocto-L4.14.98_2.0.0_ga    Some more details on the Yocto BSP can be found here: https://community.nxp.com/docs/DOC-94849   All the required binaries to create a bootable image for the Cortex-A cores on the MEK platforms are attached here.   Building a bootable image Once all the required pieces have been built/obtained, the bootable image can be created. The SCFW, SECO FW and respective Cortex-M4/A images need to be copied to the folder for the target device, i.e. if you are building an image for an i.MX8QX variant copy the binaries for that variant to its folder:   Here is a list of the required files to build a bootable image: scfw_tcm.bin -------------------------------------------- System Controller Firmware binary for the target board mx8qm(qx)-ahab-container.image ---------------- Security Controller Firmware for the QM or QXP variants bl31.bin --------------------------------------------------- ARM Trusted Firmware binary (Required if using u-boot with ATF) Only needed to create Cortex-A image with u-boot u-boot.bin ------------------------------------------------ U-boot binary (optional) m4_image ----------------------------------------------- M4 binary image, the QM variant has 2 Cortex-M4s and in this case to M4 binaries might be required (optional)   Once the required binaries have been copied to the desired variant folder (QXP or QM in this example), you are ready to start building some images.   All the targets for building different images are defined on the soc.mak file contained in each folder, this file contains different examples for creating a lot of the supported bootable images.   Creating a SCFW only image The target used to create a SCFW only image is flash_b0_scfw and it is defined under the soc.mak file of each variant. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_b0_scfw‍‍‍ To invoke this target for QM from the imx-mkimage directory: make SOC=iMX8QM flash_b0_scfw‍‍‍   The target definition for flash_b0_scfw can be seen below. Definition for QXP: flash_scfw flash_b0_scfw: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin ./$(MKIMG) -soc QX -rev B0 -dcd skip -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -out flash.bin ‍‍‍‍‍‍‍‍ Definition for QM: flash_b0_scfw: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -out flash.bin‍‍‍‍‍‍   Creating a Cortex-A image only The target used to create a Cortex-A image only is called flash_b0. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_b0 ‍‍‍ To invoke this target for QM from the imx-mkimage directory: make SOC=iMX8QM flash_b0‍ ‍‍‍ The target definition for flash_b0 can be seen below. Definition for QXP:   flash flash_b0: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin u-boot-atf.bin ./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -ap u-boot-atf.bin a35 0x80000000 -out flash.bin‍‍‍‍ Definition for QM:   flash_b0: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin u-boot-atf.bin ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -ap u-boot-atf.bin a53 0x80000000 -out flash.bin‍‍‍‍   Creating a Cortex-M4 image only The target used to create a Cortex-m4 image only is called flash_b0_cm4 on QXP and QM has different targets since there are two M4s available in the system. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_b0_cm4‍‍ To invoke this target for QM from the imx-mkimage directory: // For Cortex-M4_0 only make SOC=iMX8QM flash_b0‍_cm4‍_0 // For Cortex-M4_1 only make SOC=iMX8QM flash_b0‍_cm4‍_1 // For both Cortex-M4_0 and Cortex-M4_1 make SOC=iMX8QM flash_b0‍_m4‍s_tcm ‍‍‍‍‍‍‍‍‍‍‍‍‍   The target definition for flash_b0_cm4 can be seen below. Definition for QXP: flash_cm4 flash_b0_cm4: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin m4_image.bin ./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m4_image.bin 0 0x34FE0000 -out flash.bin‍‍‍‍ Definitions for QM: flash_b0_cm4_0: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin m4_image.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m4_image.bin 0 0x34FE0000 -out flash.bin flash_b0_cm4_1: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin m4_image.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m4_image.bin 1 0x38FE0000 -out flash.bin flash_b0_m4s_tcm: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin m40_tcm.bin m41_tcm.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m40_tcm.bin 0 0x34FE0000 -m4 m41_tcm.bin 1 0x38FE0000 -out flash.bin‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   The examples above are for M4 images booting from TCM, the M4 is capable of booting and executing from DDR and it is also able to XIP (execute in place) from SPI memory, for examples on this targets please look at the soc.mak for the desired variant. Creating an image with both Cortex-A and Cortex-M4 images The target used to create an image with software for all the cores is called flash_linux_m4. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_linux_m4‍ ‍ To invoke this target for QM from the imx-mkimage directory: make SOC=iMX8QM flash_linux_m4‍ ‍ The target definition for flash_linux_m4 can be seen below. Definition for QXP: flash_linux_m4: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin u-boot-atf.bin m4_image.bin ./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap u-boot-atf.bin a35 0x80000000 -p3 -m4 m4_image.bin 0 0x34FE0000 -out flash.bin‍‍   Definition for QM: flash_linux_m4: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin u-boot-atf.bin m4_0_image.bin m4_1_image.bin ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap u-boot-atf.bin a53 0x80000000 -p3 -m4 m4_0_image.bin 0 0x34FE0000 -p4 -m4 m4_1_image.bin 1 0x38FE0000 -out flash.bin‍‍     Flash image This will create a bootable image named flash.bin, to flash this image to the SD card and boot it on your MEK simply do: sudo dd if=iMX8QX/flash.bin of=/dev/mmcblkX bs=1k seek=32‍‍‍‍‍‍‍ If the desired target is a QM variant change if=iMX8QX... to if=iMX8QM. Then match your SD card device on "of=/dev/mmcblkX" you can see how your SD card enumerates by typing lsblk on your console before and after inserting your SD card. Remember from the information above that the i.MX8 will search for the image at 32k on the SD card, that is why we are flashing it there. For more examples please look at the soc.mak file, it includes examples for different boot media (NAND/QSPI) as well as different configurations and usage.   Additional resources Reference Manual Chapter 5 System Boot SCFW API and Port document imx-mkimage README System Controller Firmware 101 

Symptoms   On i.MX8MP, when inputting a 80% duty, 0.4V-1.8V, 3KHz square wave, we observed that the system may hang. We also tested i.MX8MN and i.MX8MM and observed the same phenomenon. In i.MX8MN RM, there's a note in GPC chapter:     We believe that the issue described in this note exists not only in the iMX8MN, but also in the iMX8MP and iMX8MM. Meanwhile, there is not only a problem with power down in this issue, but also a problem with wait mode. Diagnosis   In debugging, we find that avoiding accessing LPCR_A53_AD register in imx_set_cluster_powerdown can fix the issue. So we think that due to frequently power up/down of cores, cores have chances failed to power up. When the IRQ behavior become more complex, because the IRQ is an async event, it will come in any time. if the wait mode is enabled, in some conner case, the GPC internal LPM mode state machine will run into problem, then lead to system failure. Solution   1. A workaround patch that bypass the wait mode setting during the cpuidle.. See the patch attached. 2. Will add the Note about "SCU power down should not be enabled in wait mode" to i.MX8MP and i.MX8MM RM. 3. Will try to identify this issue into errta document, ticket TKT0632147.

Hardware i.MX 93 EVK​ TFT LCD 480x272 RGB888 (NV3047E, parallel)​ Condition A55 off​ DDR self-refresh​ OCRAM for framebuffer, TCM for code/data​ LCDIF on with parallel interface​ M33 update panel content each second​ 255KB single frame buffer(RGB565) (fit in OCRAM: 0x20480000 ~ 0x204DFFFF)​ Code Bitbucket：ssh://git@bitbucket.sw.nxp.com/mpucnse/imx93-cm33-usecase.git​ Branch: imx93_sdk_2.14.1-lcd_on_ocram​ Demo code: imx93-cm33-usecase/boards/mcimx93evk/demo_apps/lcd_on_ocram​ DTS: imx93-cm33-usecase/boards/mcimx93evk/demo_apps/lcd_on_ocram/dts​ Working Flow   ​Test Flow In uboot console,​ setenv mmcargs $mmcargs clk-imx93.mcore_booted​ setenv fdtfile imx93-11x11-evk-lcd_panel.dtb​ fatload mmc 1:1 0x80000000 sdk20-app.bin;cp.b 0x80000000 0x201e0000 0x10000;bootaux 0x1ffe0000 0​ boot​ In kernel console,​ echo mem > /sys/power/state​ start the power test Power Consumption SoC power: 94.4mW​ VDD_SOC@0.8V​ CM33@100MHz​ CM33@100MHz​ A55 suspend​ DDR retention​ WAKEUPMIX off​ NICMIX and MEDIAMIX on​  ​  

This is a simple document for recording some known-how and tips for building up the Windows 10 IoT development environment for i.MX platform. It can only be used as a complement for official document in BSP package (Guide/Release Note/etc.). Applicable for: Windows 10 IoT, i.MX BSP v1.4.1 (date to Nov/2023) Please refer to the PDF attached.

Information about the transition from the NXP Demo Experience to GoPoint for i.MX Application Processors.

Board : i.MX93 EVK BSP: imx L6.1.1-1.0.0 Gui guider: 1.6.1   We have a GUI software tool called GUI Guider. It is a user-friendly graphical user interface development tool from NXP that enables the rapid development of high quality displays with the open-source LVGL graphics library. The GUI demo can run on the i.MX93EVK board. (https://www.nxp.com/design/software/development-software/gui-guider:GUI-GUIDER)   This document will show you an example how the buttons(gpio) on the EVK to interacting with the GUI. Basically, customer could use the same method to use the gpio pins to control everything.   On the i.MX93 EVK board, there are two buttons BTN1 and BTN2. They are connected to GPIO IO23 and GPIO IO24. Below is the schematic.    Buttons on the board.      SW1005 on the board   In the EVK's device tree file, need to change the pinmux for the two buttons like this: pinctrl_spdif: spdifgrp { fsl,pins = < // MX93_PAD_GPIO_IO22__SPDIF_IN 0x31e // MX93_PAD_GPIO_IO23__SPDIF_OUT 0x31e MX93_PAD_GPIO_IO23__GPIO2_IO23 0x31e MX93_PAD_GPIO_IO24__GPIO2_IO24 0x31e >; note: all the pins are defined in imx93-pinfunc.h.   For getting the input value of the buttons in user's space, I use the sysfs gpio. Build the imx-image-multimedia image first and then select the GPIO_SYSFS in kernel's menuconfig.   $ DISTRO=fsl-imx-xwayland MACHINE=imx93evk source imx-setup-release.sh -b build-xwayland $ bitbake imx-image-multimedia   After the build completed, go to the kernel's menuconfig to select the GPIO sysfs. $ bitbake linux-imx -c menuconfig [*] General setup-> Configure standard kernel features (expert users) [*] Device Drivers->GPIO Support-> /sys/class/gpio/... (sysfs interface)   Build the whole image again by "$ bitbake imx-image-multimedia".   Using the UUU to program the image to the EMMC on the EVK board. uuu -b emmc_all imx-image-multimedia-imx93evk.rootfs.wic.zst   Connect the LVDS to the board. Use the corresponding dtb to boot the board. In u-boot, set the dtb file. => setenv fdtfile imx93-11x11-evk-boe-wxga-lvds-panel.dtb => saveenv   Then restart the board. After the board boot up, it will look like below.     You need to calibrate the LVDS touch screen before it can normally use. Please use this command: $ weston-touch-calibrator LVDS-1     Now, build the GUI guider example. I use the Air Conditioner example. Download the GUI guider from the gui-guider web page: https://www.nxp.com/design/software/development-software/gui-guider:GUI-GUIDER   Follow the steps from the below web page to build the i.MX BSP and the gui example code. https://docs.nxp.com/bundle/GUIGUIDERUG-1.6.1/page/topics/yocto.html   After the gui-guider build completed, use the 'scp' command to transfer the gui_guider executable file to the board. Execute the command on your host PC like this: $ scp bld-imx93evk/tmp/work/armv8a-poky-linux/gui-guider/1.6.0-r0/image/usr/bin/gui_guider root@<Your Board IP address>:/ Note: You could use a router to connect your board and your host PC. They are on the same network so could use the 'scp' command to transfer the file to your board.   On your board, type the following commands to execute the gui. $ chmod 755 gui_guider $ ./gui_guider &   Then the GUI is running like this:   Now, let me explain how to find out the gpio number. Type the following command to show the mapping addresses of gpio. root@imx93evk:/# cat /sys/kernel/debug/gpio gpiochip3: GPIOs 0-31, parent: platform/47400080.gpio, 47400080.gpio: gpiochip0: GPIOs 32-63, parent: platform/43810080.gpio, 43810080.gpio: gpiochip1: GPIOs 64-95, parent: platform/43820080.gpio, 43820080.gpio: gpio-64 ( |cd ) in hi IRQ ACTIVE LOW gpio-71 ( |regulator-usdhc2 ) out lo gpiochip2: GPIOs 96-127, parent: platform/43830080.gpio, 43830080.gpio: gpiochip6: GPIOs 472-477, parent: i2c/0-001a, wm8962, can sleep: gpiochip5: GPIOs 478-487, parent: platform/adp5585-gpio.1.auto, adp5585-gpio, can sleep: gpio-479 ( |regulator-audio-pwr ) out hi gpio-483 ( |regulator-can2-stby ) out hi ACTIVE LOW gpio-486 ( |enable ) out hi gpiochip4: GPIOs 488-511, parent: i2c/1-0022, 1-0022, can sleep: gpio-492 ( |Headphone detection ) in lo IRQ gpio-501 ( |? ) out hi gpio-502 ( |regulator-vdd-12v ) out hi gpio-505 ( |reset ) out lo gpio-507 ( |? ) out hi gpio-508 ( |reset ) out lo ACTIVE LOW   The gpio pins of two buttons are GPIO2_IO23 and GPIO2_IO24. They are belongs to gpio2. In the imx93.dtsi, the gpio2's address is "gpio2: gpio@43810080". So, base on the information output from "/sys/kernel/debug/gpio", the gpio2 is mapping to "gpiochip0: GPIOs 32-63". So, the GPIO2_IO23 is 32+23=55, and the GPIO2_IO24 is 32+24=56.   To verify the gpio number is correct or not. We could do the following test. root@imx93evk:/# echo 55 > /sys/class/gpio/export root@imx93evk:/# echo in > /sys/class/gpio/gpio55/direction root@imx93evk:/# echo 56 > /sys/class/gpio/export root@imx93evk:/# echo in > /sys/class/gpio/gpio56/direction   Then, run these two commands to check the values. root@imx93evk:/# cat /sys/class/gpio/gpio55/value root@imx93evk:/# cat /sys/class/gpio/gpio55/value   When the button is not pressed, the value is 1. When press the button, the value is 0.  We could add the same in the GUI's custom.c. Open the GUI Guider software and add the code in the custom.c. /********************* * INCLUDES *********************/ #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> #include <fcntl.h> #include "lvgl.h" #include "custom.h" #include "ui_Aircon.h" #include "guider_customer_fonts.h" /********************** * STATIC VARIABLES **********************/ int fdbtn1,fdbtn2,fdgpio; int btn1_pressed; int btn2_pressed; char btn1_value, btn2_value; void custom_func(void) { fdbtn1 = open("/sys/class/gpio/gpio55/value", O_RDWR); fdbtn2 = open("/sys/class/gpio/gpio56/value", O_RDWR); read(fdbtn1, &btn1_value, 1); read(fdbtn2, &btn2_value, 1); if(btn1_value=='0' && btn1_pressed) { btn1_pressed=0; ui_aircon_update_temp(0, kAIRCON_TempUp); } if(btn1_value=='1') btn1_pressed=1; if(btn2_value=='0' && btn2_pressed) { btn2_pressed=0; ui_aircon_update_temp(0, kAIRCON_TempDown); } if(btn2_value=='1') btn2_pressed=1; close(fdbtn1); close(fdbtn2); } void custom_init(lv_ui *ui) { fdbtn1 = open("/sys/class/gpio/gpio55/value", O_WRONLY); if (fdbtn1 == -1) { fdgpio = open("/sys/class/gpio/export", O_WRONLY); write(fdgpio,"55",3); write(fdgpio,"56",3); close(fdgpio); fdgpio = open("/sys/class/gpio/gpio55/direction", O_WRONLY); write(fdgpio,"in",3); close(fdgpio); fdgpio = open("/sys/class/gpio/gpio56/direction", O_WRONLY); write(fdgpio,"in",3); close(fdgpio); } else close(fdbtn1); ... ... ... ...   Add the custom_func() in the custom.h. #ifndef __CUSTOM_H_ #define __CUSTOM_H_ #ifdef __cplusplus extern "C" { #endif #include "gui_guider.h" void custom_init(lv_ui *ui); + void custom_func(void);   Also, need to add the custom function() into the dead loop in main.c.   To modify the code, bld-imx93evk$ vim tmp/work/armv8a-poky-linux/gui-guider/1.6.0-r0/gui-guider-1.6.0/ports/linux/main.c   while(1) { + custom_func(); // <--- Add the custom function here. /* Periodically call the lv_task handler. * It could be done in a timer interrupt or an OS task too.*/ time_till_next = lv_wayland_timer_handler(); #if LV_USE_VIDEO video_play(&guider_ui); #endif /* Run until the last window closes */ if (!lv_wayland_window_is_open(NULL)) { break; }   Re-build the code after modified. bld-imx93evk$ bitbake gui-guider -c compile -f   Build the whole image again. bld-imx93evk$ bitbake gui-guider Then use the 'scp' command to transfer the new gui-guider file to the board.   Finally, you can use the buttons on the EVK board to set the temperature up and down.                          

How to use UART4 on iMX8M from Linux User Space   The UART4 on iMX8MM-EVK and iMX8MN-EVK are thinking of debugging the M core which is not usable on Linux user space by default on pre-compiled images.   To use the UART4 on Linux user space you have to do the next modifications on the device tree and atf to assign that peripheral to Linux User Space     https://github.com/nxp-imx/imx-atf/blob/lf_v2.6/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c     iMX8MN-EVK   imx8mn_bl31_setup.c   https://github.com/nxp-imx/imx-atf/blob/lf_v2.6/plat/imx/imx8m/imx8mn/imx8mn_bl31_setup.c   /* Master domain assignment */ RDC_MDAn(RDC_MDA_M7, DID1), /* peripherals domain permission */ - RDC_PDAPn(RDC_PDAP_UART4, D1R | D1W), + RDC_PDAPn(RDC_PDAP_UART4, D0R | D0W), RDC_PDAPn(RDC_PDAP_UART2, D0R | D0W), RDC_PDAPn(RDC_PDAP_RDC, D0R | D0W | D1R),       Device tree configurations for iMX8MN-EVK   iMX8MN-EVK.dtsi   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi   &uart3 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart3>; assigned-clocks = <&clk IMX8MN_CLK_UART3>; assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_80M>; uart-has-rtscts; status = "okay"; }; + &uart4 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uart4>; + assigned-clocks = <&clk IMX8MN_CLK_UART4>; + assigned-clock-parents = <&clk IMX8MN_SYS_PLL1_80M>; + status = "okay"; + }; ********************** pinctrl_uart3: uart3grp { fsl,pins = < MX8MN_IOMUXC_ECSPI1_SCLK_UART3_DCE_RX 0x140 MX8MN_IOMUXC_ECSPI1_MOSI_UART3_DCE_TX 0x140 MX8MN_IOMUXC_ECSPI1_SS0_UART3_DCE_RTS_B 0x140 MX8MN_IOMUXC_ECSPI1_MISO_UART3_DCE_CTS_B 0x140 >; }; + pinctrl_uart4: uart4grp { + fsl,pins = < + MX8MN_IOMUXC_UART4_RXD_UART4_DCE_RX 0x140 + MX8MN_IOMUXC_UART4_TXD_UART4_DCE_TX 0x140 + >; + };   iMX8MM-EVK   https://github.com/nxp-imx/imx-atf/blob/lf_v2.6/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c   imx8mm_bl31_setup.c   /* Master domain assignment */ RDC_MDAn(RDC_MDA_M7, DID1), /* peripherals domain permission */ - RDC_PDAPn(RDC_PDAP_UART4, D1R | D1W), + RDC_PDAPn(RDC_PDAP_UART4, D0R | D0W), RDC_PDAPn(RDC_PDAP_UART2, D0R | D0W), RDC_PDAPn(RDC_PDAP_RDC, D0R | D0W | D1R),   Device tree configurations for iMX8MM-EVK   iMX8MM-EVK.dtsi   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi   &uart3 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart3>; assigned-clocks = <&clk IMX8MM_CLK_UART3>; assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>; uart-has-rtscts; status = "okay"; }; + &uart4 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uart4>; + assigned-clocks = <&clk IMX8MM_CLK_UART4>; + assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>; + status = "okay"; + }; ********************** pinctrl_uart3: uart3grp { fsl,pins = < MX8MM_IOMUXC_ECSPI1_SCLK_UART3_DCE_RX 0x140 MX8MM_IOMUXC_ECSPI1_MOSI_UART3_DCE_TX 0x140 MX8MM_IOMUXC_ECSPI1_SS0_UART3_DCE_RTS_B 0x140 MX8MM_IOMUXC_ECSPI1_MISO_UART3_DCE_CTS_B 0x140 >; }; + pinctrl_uart4: uart4grp { + fsl,pins = < + MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX 0x140 + MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX 0x140 + >; + };   iMX8MP-EVK   https://github.com/nxp-imx/imx-atf/blob/lf_v2.6/plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c   imx8mp_bl31_setup.c   RDC_MDAn(RDC_MDA_M7, DID1), RDC_MDAn(RDC_MDA_LCDIF, DID2), RDC_MDAn(RDC_MDA_LCDIF2, DID2), RDC_MDAn(RDC_MDA_HDMI_TX, DID2), /* peripherals domain permission */ + RDC_PDAPn(RDC_PDAP_UART4, D0R | D0W), RDC_PDAPn(RDC_PDAP_UART2, D0R | D0W), RDC_PDAPn(RDC_PDAP_WDOG1, D0R | D0W), RDC_PDAPn(RDC_PDAP_RDC, D0R | D0W | D1R),   Device tree configurations for iMX8MP-EVK   iMX8MP-EVK.dts   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mp-evk.dts   &uart3 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart3>; assigned-clocks = <&clk IMX8MP_CLK_UART3>; assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>; fsl,uart-has-rtscts; status = "okay"; }; + &uart4 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uart4>; + assigned-clocks = <&clk IMX8MP_CLK_UART4>; + assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>; + status = "okay"; + }; ************************************ pinctrl_uart3: uart3grp { fsl,pins = < MX8MP_IOMUXC_ECSPI1_SCLK__UART3_DCE_RX 0x140 MX8MP_IOMUXC_ECSPI1_MOSI__UART3_DCE_TX 0x140 MX8MP_IOMUXC_ECSPI1_SS0__UART3_DCE_RTS 0x140 MX8MP_IOMUXC_ECSPI1_MISO__UART3_DCE_CTS 0x140 >; }; + pinctrl_uart4: uart4grp { + fsl,pins = < + MX8MP_IOMUXC_UART4_RXD__UART4_DCE_RX 0x140 + MX8MP_IOMUXC_UART4_TXD__UART4_DCE_TX 0x140 + >; + };     After compiling the image with the changes previously shown, we obtained this result:      

BSP: L6.1.36 Some customer need use adb under usb ffs. The adb in Yocto can greatly improves development efficiency. This is a demo for enabling adb on Yocto.   Yocto local.conf IMAGE_INSTALL:append = "android-tools android-tools-adbd" PREFERRED_PROVIDER_android-tools-conf = "android-tools-conf-configfs"   Test script for launching adbd modprobe g_ffs idVendor=0x1fc9 idProduct=0x0146 iSerialNumber="ZhimingLiu" mkdir -p /dev/usb-ffs/adb mount -t functionfs adb /dev/usb-ffs/adb -o uid=2000,gid=2000 adbd &   Test on Windows: PS C:\Users\Administrator\Desktop\platform-tools> .\adb.exe devices List of devices attached ZhimingLiu device PS C:\Users\Administrator\Desktop\platform-tools> .\adb.exe shell sh-5.2# uname -a Linux imx8mp-lpddr4-evk 6.1.36+g04b05c5527e9 #1 SMP PREEMPT Fri Nov 24 04:46:22 UTC 2023 aarch64 GNU/Linux sh-5.2# ls config ffs t.sh test2.sh sh-5.2# cd / sh-5.2# ls bin dev home lost+found mnt proc run srv tmp usr boot etc lib media opt root sbin sys unit_tests var sh-5.2#

Platform: Demo images, i.MX8MPlus EVK   Some customer need test ffs gadget function on i.MX8MPlus EVK. Here is demo for ffs test, please connect EVK and Ubuntu PC before test.   Test script: #!/bin/sh # Setup the device (configfs) modprobe libcomposite mkdir -p config mount none config -t configfs cd config/usb_gadget/ mkdir g1 cd g1 echo 0x1fc9 >idVendor echo 0x0146 >idProduct mkdir strings/0x409 echo 12345 >strings/0x409/serialnumber echo "Signal 11" >strings/0x409/manufacturer echo "Test" >strings/0x409/product mkdir configs/c.1 mkdir configs/c.1/strings/0x409 echo "Config1" >configs/c.1/strings/0x409/configuration # Setup functionfs mkdir functions/ffs.usb0 ln -s functions/ffs.usb0 configs/c.1 cd ../../../ mkdir -p ffs mount usb0 ffs -t functionfs cd ffs ffs-test 64 & # from the Linux kernel, with mods! sleep 3 cd .. # Enable the USB device echo 38100000.usb > config/usb_gadget/g1/UDC   EVK log root@imx8mpevk:~# ./test2.sh [ 17.859597] file system registered ffs-test: dbg: ep0: writing descriptors (in v2 format) ffs-test: dbg: ep0: writing strings ffs-test: dbg: ep1: starting ffs-test: dbg: ep2: starting ffs-test: dbg: ep1: starts ffs-test: dbg: ep0: starts ffs-test: dbg: ep2: starts Event BIND Event ENABLE Ubuntu PC log: lzm@lzm-GL552VW:~$ lsusb -D /dev/bus/usb/001/008 Device: ID 1fc9:0146 NXP Semiconductors Test Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1fc9 NXP Semiconductors idProduct 0x0146 bcdDevice 6.01 iManufacturer 1 Signal 11 iProduct 2 Test iSerial 3 12345 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0020 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 Config1 bmAttributes 0x80 (Bus Powered) MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 5 Source/Sink Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 0x0016 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x0000010e BESL Link Power Management (LPM) Supported BESL value 256 us SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000f Device can operate at Low Speed (1Mbps) Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 0 micro seconds bU2DevExitLat 0 micro seconds Device Status: 0x0001 Self Powered  

Traditional non-matter devices cannot directly join the matter network. But Matter Bridge solves the problem. Matter bridge can join a Matter network as a Matter device and nonmatter devices need to be mapped to Matter network as a dynamic endpoint. In this way, other Matter devices can communicate with non-matter devices through dynamic endpoints. The Guide is a Matter Zigbee Bridge implement based on i.MX93 + K32W0.     Feature List • Matter over Ethernet • Matter over Wi-Fi • Register and Remove Zigbee Deivces • Connect Zigbee devices into Matter ecosystem seamlessly • Zigbee Devices o OnOff cluster o Temperature Sensor Cluster • Matter Actions o Start Zigbee Network o Zigbee Network Permit Join o Factory Reset • No limitation if migrating to other i.MX MPU like i.MX6ULL, i.MX8MP • OTBR and Zigbee bridge can be integrated into one single device

Usually, device tree source files are not a signal pure dts file. It could include dtsi, dts or C code heads .h files. Need C compiler finish the pre-compile to a pure dts file first. It is integrated inside the like Linux build system(Makefile, etc.). This document shows the original way to compile device tree. This document will show compile device tree under windows.