Application Note AN13872  Enabling SWUpdate on i.MX 6ULL, i.MX 8M Mini, and i.MX 93 is available on www.nxp.com    SWUpdate: Embedded Systems become more and more complex. Software for Embedded Systems have new features and fixes can be updated in a reliable way. Most of time, we need OTA(Over-The-Air) to upgrade the system. Like Android has its own update system. Linux also need an update system. SWUpdate project is thought to help to update an embedded system from a storage media or from network. However, it should be mainly considered as a framework, where further protocols or installers (in SWUpdate they are called handlers) can be easily added to the application. Mongoose daemon mode: Mongoose is a daemon mode of SWUpdate that provides a web server, web interface and web application. Mongoose is running on the target board(i.MX8MM EVK/i.MX8QXP MEK).Using Web browser to access it.   Suricatta daemon mode: Suricatta regularly polls a remote server for updates, downloads, and installs them. Thereafter, it reboots the system and reports the update status to the server. The screenshot is SWUpdate scuricatta working with hawkbit server.          

  Some customer need to config different I2C bus for their PMIC in DDR test period. There is a simple method can complete this, that is NXP DDR Config Tool. The tool download link is below: https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX I'm going to use the i.MX 93 EVK board here as a demonstration. On i.MX 93 EVK board, the default PMIC I2C Bus is I2C2, I will show you how to change I2C2 to I2C1, the other i2c bus is same.  Step 1 : Rework the board and make sure the PMIC is connected to I2C1. Remove R714 R715, connnect I2C1_SCL(C20) to U701 pin 41  and I2C1_SDA(C21) tp U701 pin 42. Step 2 : Setup I2C1 PinMux: Config Tool UI:   Advance -> IOMUX config   Command:           Address                Size               Value memory   set     0x443c0170            32                   0x10 memory   set     0x443c0174            32                   0x10 memory   set     0x443c0320            32                   0x40000b9e memory   set     0x443c0324            32                   0x40000b9e Step 3 : Set PMIC VDDQ as 1.1 V Config Tool UI:   Advance -> Custom PMIC initialization enabled   #  PMIC commands        Value 0         pmic_cfg             0x0025       /*I2C bus 1,  PMIC address 0x25 */ (0 for I2C1, 1 for I2C2, 2 for I2C3, 3 for I2c4 …) 1         pmic_set             0x0C29       /* BUCKxOUT_DVS0/1, preset_buck1=0.8V, preset_buck2=0.7V, preset_buck3=0.8V PCA9451_BUCK123_DVS, 0x29 */ 2         pmic_set             0x1118      /*  BUCK1OUT_DVS0=0.9V   PCA9451_BUCK1OUT_DVS0, 0x18 */ 3         pmic_set             0x1718      /*  BUCK3OUT_DVS0=0.9V   PCA9451_BUCK3OUT_DVS0, 0x18 */ 4         pmic_set             0x1428      /*  Set VDDQ to 1.1V  PCA9451_BUCK2OUT_DVS0, 0x28  */ PS : About pmic register, The first two bytes are the register address and the next two bytes are the register setting. Step 4 : Run the DDR "Firmware init test" and see the test result. The success log is as follows: DEBUG memtool.comm.serial_channel ==================hardware_init======================= DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel Power up ddr... DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel DDRMIX power on done... DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel DDRPHY coldreset... DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel ********Found PMIC PCA945X********** DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel Set VDDQ to 1.1V for LPDDR4 DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel ==================hardware_init exit==================    

GmSSL is an open source cryptographic toolbox that supports SM2 / SM3 / SM4 / SM9 and other national secret (national commercial password) algorithm, SM2 digital certificate and SM2 certificate based on SSL / TLS secure communication protocol to support the national security hardware password device , To provide in line with the national standard programming interface and command line tools, can be used to build PKI / CA, secure communication, data encryption and other standards in line with national security applications. For more information, please access GmSSL official website http://gmssl.org/english.html.   Software environments as the belows: Linux kernel: imx_4.14.98_2.0.0_ga cryptodev: 1.9 HW platform: i.MX6UL, i.MX7D/S, i.MX8M/MM, i.MX8QM/QXP. The patches include the following features: 1, Support SM2/SM9 encryption/decryption/sign/verify/key exchange, RSA encryption/decryption, DSA/ECDSA sign/verify, DH/ECDH key agreement, ECC & DLC & RSA key generation and big number operation and elliptic curve math by CAAM hardware accelerating. 2, run "git apply 0001-Enhance-cryptodev-and-its-engine-in-GmSSL-by-CAAM-s-.patch" under folder sources/poky, and "git apply 0001-Add-public-key-cryptography-operations-in-CAAM-drive.patch" under folder sources/meta-fsl-bsp-release for patch these codes. 3, GmSSL Build command: $ tar zxvf GmSSL-master-iMX.tgz $ cd GmSSL-master-iMX (For i.MX8M/MM, i.MX8QM/QXP) $ source /opt/arm-arch64/environment-setup-aarch64-poky-linux  $ ./Configure -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DHW_ENDIAN_SWAP  --prefix=~/install64 --openssldir=/etc/gmssl --libdir=/usr/lib no-saf no-sdf no-skf no-sof no-zuc -no-ssl3 shared linux-aarch64 $ make  $ make install                            /*image and config file will be installed to folder ~/install64 */   (For i.MX6UL, i.MX7D/S) $ source /opt/arm-arch32/environment-setup-cortexa7hf-neon-poky-linux-gnueabi $ ./Configure -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS --prefix=~/install32 --openssldir=/etc/gmssl --libdir=/usr/lib no-saf no-sdf no-skf no-sof no-zuc -no-ssl3 shared linux-armv4 $ make  $ make install                            /*image and config file will be installed to folder ~/install32 */   4, How to use GmSSL: copy image gmssl to /usr/bin on i.MX board; copy gmssl libcrypto.so.1.1 and libssl.so.1.1 to /usr/lib on i.MX board; copy folder etc/gmssl to /etc/ on i.MX board. copy test examples (dhtest, dsatest, rsa_test, ecdhtest, ecdsatest, eciestest, sm3test, sms4test, sm2test, sm9test) under GmSSL-master-iMX/test  to U disk for running. You can run test examples by the following commands: #insmod /lib/modules/4.14.98-imx_4.14.98_2.0.0_ga+g5d6cbeafb80c/extra/cryptodev.ko #/run/media/sda1/dhtest #/run/media/sda1/dsatest #/run/media/sda1/rsa_test #/run/media/sda1/ecdhtest #/run/media/sda1/ecdsatest #/run/media/sda1/eciestest #/run/media/sda1/sm3test #/run/media/sda1/sms4test #/run/media/sda1/sm2test #/run/media/sda1/sm9test and speed test commands: #gmssl speed sm2 #gmssl genrsa -rand -f4 512 #gmssl speed dsa #gmssl genrsa -rand -f4 1024 #gmssl speed rsa #gmssl genrsa -rand -f4 2048 #gmssl speed ecdsa #gmssl genrsa -rand -f4 3072 #gmssl speed ecdh #gmssl genrsa -rand -f4 4096   ++++++++++++++++++++++++++++     updating at 2019-09-10   +++++++++++++++++++++++++++++++++++++++++++++ 0001-fix-the-bug-which-hash-and-cipher-key-don-t-use-DMA-.patch fix the issue which dismatching on key buffer between crytodev and caam driver. Crytodev uses stack's buffer for key storage and caam driver use it to dma map which cause flush cache failure. The patch need to apply on cryptodev-module in Yocto build.   ++++++++++++++++++  updating at 2019-10-14 +++++++++++++++++++++++++++++++++++ This updating is for China C-V2X application. The meta-gmcrypto is Yocto layer which bases on GmSSL and Cryptodev. I add HW SM2 verification by dedicated CAAM job descriptor and enhanced SW SM2 verification by precomputed multiples of generator and ARMv8 assembler language to accelerate point  operation. Software environments as the belows: Linux kernel: imx_4.14.98_2.0.0_ga cryptodev: 1.9 HW platform: i.MX8M/MM/MN, i.MX8QM/QXP. How to build: 1, You need to git clone https://gitee.com/zxd2021-imx/meta-gmcrypto.git, and git checkout Linux-4.14.98_2.0.0.  Copy meta-gmcrypto to folder (Yocto 4.14.98_2.0.0_ga dir)/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8qxpmek source fsl-setup-release.sh -b build-cv2x and add BBLAYERS += " ${BSPDIR}/sources/meta-cv2x " into (Yocto 4.14.98_2.0.0_ga dir)/build-cv2x/conf/bblayers.conf and  IMAGE_INSTALL_append += " gmssl-bin "  into local.conf 3, Run bitbake fsl-image-validation-imx. 4, You can find cv2x-verify.c under (build dir)/tmp/work/aarch64-poky-linux/cryptodev-tests/1.9-r0/git/tests. It is example for using CAAM cryptdev interface to do C-V2X verification (includes SM2 p256, NIST p256 and brainpoolP256r1).  cv2x_benchmark.c under (build dir)/tmp/work/aarch64-poky-linux/gmssl/1.0-r0/gmssl-1.0/test is the benchmark test program of C-V2X verifying. It includes HW, SW and HW+SW(one CPU) verifying for SM2 p256, NIST p256 and brainpoolP256r1. 5, Run the below command on your i.MX8QXP MEK board. modprobe cryptodev ./cv2x_benchmark Note: the udpated GmSSL also support projective coordinates and affine coordinates (CAAM only support affine coordinates). Affine coordinates is used by default. You can call EC_GROUP_set_coordinates() and EC_GROUP_restore_coordinates() to change coordinates and restore default. When you hope to use some EC APIs under expected coordinates, you need to call EC_GROUP_set_coordinates() before EC APIs and EC_GROUP_restore_coordinates() after them. Like the below example: orig_coordinate = EC_GROUP_set_coordinates(EC_PROJECTIVE_COORDINATES); group = EC_GROUP_new_by_curve_name(NID_sm2p256v1); EC_GROUP_restore_coordinates(orig_coordinate);   ++++++++++++++++++++++++++++     updating at 2020-11-09   +++++++++++++++++++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.4.47_2.2.0​​. The meta-gmcrypto is Yocto layer which also support c-v2x feature in previous release.  Software environments as the belows: Linux kernel: imx_5.4.47_2.2.0 cryptodev: 1.10 HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano/8M Plus, i.MX8/8X. How to build: 1, You need to git clone https://gitee.com/zxd2021-imx/meta-gmcrypto.git, and git checkout Linux-5.4.47-2.2.0. Copy meta-gmcrypto to folder (Yocto 5.4.47_2.2.0 dir)/sources/ 2, Run DISTRO=fsl-imx-xwayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-gmcrypto " into (Yocto 5.4.47_2.2.0 dir)/build-imx8mmevk/conf/bblayers.conf and  IMAGE_INSTALL_append += " gmssl-bin "  into local.conf 3, Run bitbake fsl-image-validation-imx. 4, You can find cv2x-verify.c under (build dir)/tmp/work/aarch64-poky-linux/cryptodev-tests/1.10caam-r0/git/tests. It is example for using CAAM cryptdev interface to do C-V2X verification (includes SM2 p256, NIST p256 and brainpoolP256r1).  cv2x_benchmark.c under (build dir)/tmp/work/aarch64-poky-linux/gmssl/1.0-r0/gmssl-1.0/test is the benchmark test program of C-V2X verifying. It includes HW, SW and HW+SW(one CPU) verifying for SM2 p256, NIST p256 and brainpoolP256r1. 5, Run the below command on your i.MX8M Mini evk board. modprobe cryptodev ./cv2x_benchmark gmssl speed sm2 gmssl speed dsa gmssl speed rsa gmssl speed ecdsa gmssl speed ecdh gmssl genrsa -rand -f4 -engine cryptodev 4096 Note: 1, the udpated GmSSL also support projective coordinates and affine coordinates (CAAM only support affine coordinates). Affine coordinates is used by default. You can call EC_GROUP_set_coordinates() and EC_GROUP_restore_coordinates() to change coordinates and restore default. When you hope to use some EC APIs under expected coordinates, you need to call EC_GROUP_set_coordinates() before EC APIs and EC_GROUP_restore_coordinates() after them. Like the below example: orig_coordinate = EC_GROUP_set_coordinates(EC_PROJECTIVE_COORDINATES); group = EC_GROUP_new_by_curve_name(NID_sm2p256v1); EC_GROUP_restore_coordinates(orig_coordinate); 2, Yocto Zeus integrates openssl 1.1.1g, so I change library name of gmssl from libcrypto to libgmcrypto and from libssl to libgmssl to avoid name confliction with openssl 1.1.1g (lib name are also libcrypto.so.1.1 and libssl.so.1.1). You should use -lgmcrypto and -lgmssl when you link gmssl library instead of -lcrypto and -lssl.   +++++++++++++++++++++++    updating at 2021-02-08  ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.4.70_2.3.0​​. The package meta-gmcrypto is Yocto layer which also support c-v2x feature in previous release. You need to git clone https://gitee.com/zxd2021-imx/meta-gmcrypto.git, and git checkout Linux-5.4.70-2.3.0.    +++++++++++++++++++++++    updating for Linux-5.10.52-2.1.0  +++++++++++++++++++++++ This updating is for Yocto release of Linux 5.10.52_2.1.0​​. The package meta-gmcrypto is Yocto layer which also support c-v2x feature in previous release.  1, You need to git clone https://gitee.com/zxd2021-imx/meta-gmcrypto.git, and git checkout Linux-5.10.52-2.1.0.  Copy meta-gmcrypto to folder (Yocto 5.10.52_2.1.0 dir)/sources/. 2, Run DISTRO=fsl-imx-xwayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-gmcrypto " into (Yocto 5.10.52_2.1.0 dir)/build-imx8mmevk/conf/bblayers.conf and  IMAGE_INSTALL_append += " gmssl-bin "  into local.conf 3, Run bitbake imx-image-multimedia. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev gmssl speed sm2 gmssl genrsa -rand -f4 -engine cryptodev 512 gmssl speed dsa gmssl genrsa -rand -f4 -engine cryptodev 1024 gmssl speed rsa gmssl genrsa -rand -f4 -engine cryptodev 2048 gmssl speed ecdsa gmssl genrsa -rand -f4 -engine cryptodev 3072 gmssl speed ecdh gmssl genrsa -rand -f4 -engine cryptodev 4096 gmssl speed -evp sha256 -engine cryptodev -elapsed gmssl speed -evp aes-128-cbc -engine cryptodev -elapsed gmssl speed -evp aes-128-ecb -engine cryptodev -elapsed gmssl speed -evp aes-128-cfb -engine cryptodev -elapsed gmssl speed -evp aes-128-ofb -engine cryptodev -elapsed gmssl speed -evp des-ede3 -engine cryptodev -elapsed gmssl speed -evp des-cbc -engine cryptodev -elapsed gmssl speed -evp des-ede3-cfb -engine cryptodev -elapsed +++++++++++++++++++++++    updating for Linux-5.15.71-2.2.0 +++++++++++++++++++++++ This updating is for Yocto release of Linux 5.15.71-2.2.0​​. The package meta-gmcrypto is Yocto layer which also support c-v2x feature in previous release.  1, You need to git clone https://gitee.com/zxd2021-imx/meta-gmcrypto.git, and git checkout Linux-5.15.71-2.2.0.  Copy meta-gmcrypto to folder (Yocto 5.15.71-2.2.0 dir)/sources/. 2, Run DISTRO=fsl-imx-xwayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-gmcrypto " into (Yocto 5.15.71-2.2.0 dir)/build-imx8mmevk/conf/bblayers.conf and  IMAGE_INSTALL:append = " gmssl-bin "  into local.conf 3, Run bitbake imx-image-multimedia. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev gmssl speed sm2 gmssl genrsa -rand -f4 -engine cryptodev 512 gmssl speed dsa gmssl genrsa -rand -f4 -engine cryptodev 1024 gmssl speed rsa gmssl genrsa -rand -f4 -engine cryptodev 2048 gmssl speed ecdsa gmssl genrsa -rand -f4 -engine cryptodev 3072 gmssl speed ecdh gmssl genrsa -rand -f4 -engine cryptodev 4096 gmssl speed -evp sha256 -engine cryptodev -elapsed gmssl speed -evp aes-128-cbc -engine cryptodev -elapsed gmssl speed -evp aes-128-ecb -engine cryptodev -elapsed gmssl speed -evp aes-128-cfb -engine cryptodev -elapsed gmssl speed -evp aes-128-ofb -engine cryptodev -elapsed gmssl speed -evp des-ede3 -engine cryptodev -elapsed gmssl speed -evp des-cbc -engine cryptodev -elapsed gmssl speed -evp des-ede3-cfb -engine cryptodev -elapsed   +++++++++++++++++++++++    Updating for Linux-6.1.55-2.2.0 +++++++++++++++++++++++ This updating is new GmSSL 3.1.1 and Yocto release of Linux 6.1.55-2.2.0. 主要特性 超轻量：GmSSL 3 大幅度降低了内存需求和二进制代码体积，不依赖动态内存，可以用于无操作系统的低功耗嵌入式环境(MCU、SOC等)，开发者也可以更容易地将国密算法和SSL协议嵌入到现有的项目中。 更合规：GmSSL 3 可以配置为仅包含国密算法和国密协议(TLCP协议)，依赖GmSSL 的密码应用更容易满足密码产品型号检测的要求，避免由于混杂非国密算法、不安全算法等导致的安全问题和合规问题。 更安全：TLS 1.3在安全性和通信延迟上相对之前的TLS协议有巨大的提升，GmSSL 3 支持TLS 1.3协议和RFC 8998的国密套件。GmSSL 3 默认支持密钥的加密保护，提升了密码算法的抗侧信道攻击能力。 跨平台：GmSSL 3 更容易跨平台，构建系统不再依赖Perl，默认的CMake构建系统可以容易地和Visual Studio、Android NDK等默认编译工具配合使用，开发者也可以手工编写Makefile在特殊环境中编译、剪裁。 More information, please refer to Readme Recipe file is the attached gmssl_3.1.1.bb.tar.gz

Design Check Lists: HW Design Checking List for i.MX6DQSDL HW Design Checking List for i.Mx53 Hardware Design Checklist for i.MX28 HW_Design_Checking_List_for_i.MX6SoloX i.MX6UL Hardware design checklist   DDR Design Tool: I.MX53 DDR3 Script Aid imx53 DDR stress tester V0.042 i.Mx6DQSDL DDR3 Script Aid MX6DQP DDR3 Script Aid i.Mx6DQSDL LPDDR2 Script Aid i.Mx6SL LPDDR2 Script Aid i.MX6SX DDR3 Script Aid I.MX6UL DDR3 Script Aid i.MX6UL_LPDDR2_Script_Aid i.MX6ULL_DDR3_Script_Aid  i.MX6ULL_LPDDR2_Script_Aid  MX6SLL_LPDDR2_Script_Aid  MX6SLL_LPDDR3_Script_Aid  i.MX6 DDR Stress Test Tool V1.0.3 i.MX6/7 DDR Stress Test Tool V3.00 i.MX8MSCALE DDR Tool Release  i.MX8M DDR3L register programming aid  i.MX 8/8X Family DDR Tools Release   Application Notes: MX_Design_Validation_Guide I.MX6 series USB Certification Guides

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with MMDC initialization. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP validation boards.

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   These are the detailed programming aids for the registers associated with MMDC DDR3 and LPDDR2 initialization for the MX6DQ SoC. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP boards.  

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   These are the detailed programming aids for the registers associated with DRAM initialization (DDR3 and LPDDR2) of the MX6DQP (also known as Rev 2 or Dual/Quad Plus), and covers the Sabre_SD boards and DDR3 based Auto Infotainment board. The last work sheet tab in the tool formats the register settings for use with the ARM RealView debugger (.inc) and the DDR Stress Test. It can be manually converted, by the user, to the DS5 .ds format or to a DCD file format used by uboot or other. The programming aids were developed based on NXP development boards and can be customized by the user for their board design. This tool serves as an aid to assist with programming the DDR interface of the MX6DQP and is based on the DDR initialization scripts developed by the R&D team and no guarantees are made by this tool. The following are some general notes regarding this tool: • Refer to the "How To Use" tab in the tool as a starting point to use this tool. • This tool may be updated on an as-needed basis for bug fixes or future improvements.  There is no schedule for aforementioned maintenance. • The MX6DQP adds a new third party IP called the NoC. The programming for these registers are automatically updated in the tool given a set of user input MMDC parameters and should not be modified manually.

In the era of digitization, concepts like smart homes and the Internet of Things (IoT) are continuously evolving. To realize these visions, a robust and efficient network infrastructure becomes crucial. OpenWRT, with its open-source nature, high customizability, and excellent stability, has become a key player in leading the future development of networks. NXP, as a global leader in semiconductor technology innovation, leverages its expertise in embedded systems and communication to introduce an intelligent network solution based on OpenWRT, empowering the flourishing smart home and IoT ecosystems. This article will explore the current status and ways to access NXP's chip support for the wireless router solution, enabling readers to build a solid foundation for the next generation of networks. 1. Unique Features of OpenWRT 1.1. Noble Value of Open Source Freedom OpenWRT stands out with its open-source nature, granting users unlimited freedom to access, modify, and share the source code, unlocking significant innovation potential. This openness not only drives continuous technological advancements but also allows users to take active control of the network direction, saving costs. 1.2. Stable and Reliable Network Foundation Built on a mature Linux kernel, OpenWRT undergoes extensive evolution and fine-tuning, ensuring outstanding system stability. This results in fewer network failures, longer device lifespans, and solid support for various network needs. OpenWRT becomes an ideal choice for building reliable home networks, alleviating concerns about network instability or crashes. 1.3. Powerful Software Package Management OpenWRT's proud software package management system provides users with great flexibility. Users can freely install, update, and uninstall various applications and services based on their needs, achieving a highly personalized network environment for a smarter networking experience. OpenWRT allows users to install various network services and applications such as VPNs and proxy servers to meet specific network requirements, providing greater freedom to create a network environment that suits individual or family needs. 1.4. Strong Community Support The vast OpenWRT community is the source of its powerful driving force. Users can exchange experiences, solve problems, and even participate in project development within the community. This collaborative spirit propels continuous innovation and progress in OpenWRT. 2. Applications of NXP wireless router Solution 2.1. Construction of Smart Home Ecosystem The seamless integration of NXP's wireless router solution with the NXP Matter solution provides an ideal platform for users to build smart home ecosystems. With its powerful customization capabilities, users can easily connect, manage, and control various smart devices, creating a highly intelligent home environment. The solution integrates NXP's Bluetooth and Wi-Fi chip drivers, such as IW612, 88W9098, 88W8997, allowing users to effortlessly build an OpenThread Border Router (OTBR) or Zigbee Bridge based on OpenWRT. 2.2. Customized Network Services The NXP wireless router solution supports the customized installation of various network services and applications. Users can create personalized network services, such as VPNs, proxy servers, home routers, or gateways, based on their individual needs, achieving a more flexible networking experience. 2.3. Transmission of High-Definition Video Streams The transmission of high-definition video streams in smart homes imposes higher demands on network performance. NXP's wireless router solution, with its excellent network performance, combined with NXP's industrial-grade IP Camera solution, ensures users can smoothly enjoy high-definition video streams, providing a superior home entertainment experience. 2.4. Construction of Smart Security Systems Security systems are an essential part of smart homes. NXP's wireless router solution, with its advanced network security features, builds a more reliable and intelligent security system for users, enhancing home security. 3. NXP's Support for OpenWRT Given the numerous advantages and wide-ranging application scenarios of wireless router, NXP early on adapted to support OpenWRT. Full support has been provided for the entire Layerscape series processors, and mainstream IMX processors are also supported. The specific supported IMX platforms and details are as follows: Processor and Board Support         ARMv8                                             ARMv7       I.MX93EVK                                •      I.MX6ULL       I.MX8MPlus       I.MX8MMini       I.MX8MNano       I.MX8MQuad OpenWrt Version  Based on OpenWrt v23.05 from mainline (tag: v23.05.0-rc1) Toolchain: ARMV8: gcc-11.3, binutils-2.37 ARMV7: gcc-12.3, binutils-2.40 U-Boot Boot Loader IMX LF release, tag: lf-5.15.71-2.2.1 v2022.04 Linux Kernel       OpenWrt kernel 5.15.114 based on IMX SDK release kernel v5.15.71_2.2.1 Firmware       firmware-imx-8.18       firmware-sentinel-0.5.1 Main Features       Squashfs rootfs support on SD card.       Supported CLI and web configuation. - U-Boot: lf-5.15.71-2.2.1. - Arm Trusted firmware (TF-A) integration. - Boot from SDHC       Linux Kernel Core - Linux kernel 5.15.114 - Cortex-A53 (AARCH64), little endian for imx8m platform - Cortex-A55 (AARCH64), little endian for imx93 platform - Cortex-A7, little endian for imx6ull platform - 64-bit effective kernel addressing [Cortex-A53/A55]       Linux Kernel Drivers - SDIO 3.0 / eMMC5.1 - USB 3.0/2.0 Dual-Role with PHY type C - 32-bit LPDDR4 - 2x Gigabit Ethernet with AVB, IEEE 1588, EEE   and 1x w/ TSN - PCIe Gen 3 + WIFI - CAN FD - Dual-ch. QuadSPI (XIP) or 1x OctalSPI(XIP) - RTC Licensing The majority of the software included in the OpenWrt release is licensed under a form of open source license (e.g. GPL, BSD). Some software is licensed under the NXP EULA license. 4. How to Start Deploying and Using wireless router? To experience the powerful features of the Layerscape series chips with wireless router, download the source code from the official OpenWRT repository: https://git.openwrt.org/openwrt/openwrt.git. The OpenWRT support code for Layerscape is already integrated into the official OpenWRT codebase. Taking IMX8MMini-EVK as an example, here are the deployment steps for wireless router on the IMX platform using Ubuntu 22.04: 4.1. Get the source code from GitHub: https://github.com/nxp-imx/imx_openwrt (Tag: imx_v23.05_v5.15.114) 4.2. Compile, Install, and Configure wireless router: $ ./scripts/feeds update -a; ./scripts/feeds install -a; cp config.default .config; make -j $ sudo dd if=/mnt/tftpboot/imx8/matter_20230908/openwrt-imx-imx8-imx8mmini-squashfs-sdcard.img of=/dev/sdX bs=1M && sync This way, an wireless router bootable disk for SD card has been generated. You can directly use an SD card to boot and experience wireless router. For more compilation assistance, please refer to the README file in the source code: target/linux/imx/README. 4.3. Configuration and Personalization Users can access the wireless router device through the web interface or SSH to begin configuring and personalizing the network environment. This includes setting network rules, installing software packages, and ensuring that the device operates according to individual needs. The following image shows the interface for installing and removing software. Isn't it simple and convenient! 4.4. What to Do If You Encounter Issues? Firstly, you can seek support in the vibrant OpenWRT community. You can not only get assistance but also share your development or usage experiences and even participate in project development. This open community provides users with more opportunities for learning and growth, collectively driving continuous progress in OpenWRT. You can also participate in the official NXP community at https://community.nxp.com/t5/i-MX-Processors/bd-p/imx-processors to ask questions and share technical insights. Professional engineers are available to help you troubleshoot and overcome challenges. NXP OpenWRT looks forward to your participation!   Disclaimer This wireless router release is an NXP's Systems Engineering Initiative and is not part of NXP's Linux base enablement strategy for its MPU platforms. NXP does not vouch for the quality of this release and any follow up releases including adding support to new platforms is at the sole discretion of the Systems Engineering team. For specific requirements or needs please reach out to NXP's systems engineering team on the following email address "andy.tang@nxp.com."

    Xenomai is real-time framework, which can run seamlessly side-by-side Linux as a co-kernel system, or natively over mainline Linux kernels (with or without PREEMPT-RT patch). The dual kernel nicknamed Cobalt, is a significant rework of the Xenomai 2.x system. Cobalt implements the RTDM specification for interfacing with real-time device drivers. The native linux version, an enhanced implementation of the experimental Xenomai/SOLO work, is called Mercury. In this environment, only a standalone implementation of the RTDM specification in a kernel module is required, for interfacing the RTDM-compliant device drivers with the native kernel. You can get more detailed information from Home · Wiki · xenomai / xenomai · GitLab       I have ported xenomai 3.1 to i.MX Yocto 4.19.35-1.1.0, and currently support ARMv7 and tested on imx6ulevk/imx6ull14x14evk/imx6qpsabresd/imx6dlsabresd/imx6sxsabresdimx6slevk boards. I also did stress test by tool stress-ng on some boards.      You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm.git, and git checkout Linux-4.19.35-1.1.0. (which inlcudes all patches and bb file) and add the following variable in conf/local.conf before build xenomai by command bitake xenomai.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" DISTRO_FEATURES_remove = "optee" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" DISTRO_FEATURES_remove = "optee" If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch. The following is test result by the command (/usr/xenomai/demo/cyclictest -p 50 -t 5 -m -n -i 1000 😞 //Mecury on 6ULL with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 128M --metrics-brief policy: fifo: loadavg: 6.08 2.17 0.81 8/101 534 T: 0 (  530) P:99 I:1000 C:  74474 Min:     23 Act:  235 Avg:   77 Max:    8278 T: 1 (  531) P:99 I:1500 C:  49482 Min:     24 Act:   32 Avg:   56 Max:    8277 T: 2 (  532) P:99 I:2000 C:  36805 Min:     24 Act:   38 Avg:   79 Max:    8170 T: 3 (  533) P:99 I:2500 C:  29333 Min:     25 Act:   41 Avg:   54 Max:    7069 T: 4 (  534) P:99 I:3000 C:  24344 Min:     24 Act:   51 Avg:   60 Max:    7193   //Cobalt on 6ULL with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 128M --metrics-brief policy: fifo: loadavg: 7.02 6.50 4.01 8/100 660 T: 0 (  652) P:50 I:1000 C: 560348 Min:      1 Act:   10 Avg:   15 Max:      71 T: 1 (  653) P:50 I:1500 C: 373556 Min:      1 Act:    9 Avg:   17 Max:      78 T: 2 (  654) P:50 I:2000 C: 280157 Min:      2 Act:   14 Avg:   20 Max:      64 T: 3 (  655) P:50 I:2500 C: 224120 Min:      1 Act:   12 Avg:   15 Max:      57 T: 4 (  656) P:50 I:3000 C: 186765 Min:      1 Act:   31 Avg:   19 Max:      53   //Cobalt on 6qp with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M --metrics-brief policy: fifo: loadavg: 8.11 7.44 4.45 8/156 1057 T: 0 (  917) P:50 I:1000 C: 686106 Min:      0 Act:    3 Avg:    5 Max:      53 T: 1 (  918) P:50 I:1500 C: 457395 Min:      0 Act:    3 Avg:    5 Max:      49 T: 2 (  919) P:50 I:2000 C: 342866 Min:      0 Act:    2 Avg:    4 Max:      43 T: 3 (  920) P:50 I:2500 C: 274425 Min:      0 Act:    3 Avg:    5 Max:      58 T: 4 (  921) P:50 I:3000 C: 228682 Min:      0 Act:    2 Avg:    6 Max:      46   //Cobalt on 6dl with stress-ng --cpu 2 --io 2 --vm 1 --vm-bytes 256M --metrics-brief policy: fifo: loadavg: 3.35 4.15 2.47 1/122 850 T: 0 (  729) P:50 I:1000 C: 608088 Min:      0 Act:    1 Avg:    3 Max:      34 T: 1 (  730) P:50 I:1500 C: 405389 Min:      0 Act:    0 Avg:    4 Max:      38 T: 2 (  731) P:50 I:2000 C: 304039 Min:      0 Act:    1 Avg:    4 Max:      45 T: 3 (  732) P:50 I:2500 C: 243225 Min:      0 Act:    0 Avg:    4 Max:      49 T: 4 (  733) P:50 I:3000 C: 202683 Min:      0 Act:    0 Avg:    5 Max:      38   //Cobalt on 6SX stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M  --metrics-brief policy: fifo: loadavg: 7.51 7.19 6.66 8/123 670 T: 0 (  598) P:50 I:1000 C:2314339 Min:      0 Act:    3 Avg:    8 Max:      60 T: 1 (  599) P:50 I:1500 C:1542873 Min:      0 Act:   15 Avg:    8 Max:      72 T: 2 (  600) P:50 I:2000 C:1157152 Min:      0 Act:    4 Avg:    9 Max:      55 T: 3 (  601) P:50 I:2500 C: 925721 Min:      0 Act:    5 Avg:    9 Max:      57 T: 4 (  602) P:50 I:3000 C: 771434 Min:      0 Act:    6 Avg:    6 Max:      41   //Cobalt on 6Solo lite stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M  --metrics-brief policy: fifo: loadavg: 7.01 7.04 6.93 8/104 598 T: 0 (  571) P:50 I:1000 C:3639967 Min:      0 Act:    9 Avg:    7 Max:      60 T: 1 (  572) P:50 I:1500 C:2426642 Min:      0 Act:    9 Avg:   11 Max:      66 T: 2 (  573) P:50 I:2000 C:1819980 Min:      0 Act:   11 Avg:   10 Max:      57 T: 3 (  574) P:50 I:2500 C:1455983 Min:      0 Act:   12 Avg:   10 Max:      56 T: 4 (  575) P:50 I:3000 C:1213316 Min:      0 Act:    7 Avg:    9 Max:      43   //Cobalt on 7d with stress-ng --cpu 2 --io 2 --vm 1 --vm-bytes 256M --metrics-brief policy: fifo: loadavg: 5.03 5.11 5.15 6/107 683 T: 0 (  626) P:50 I:1000 C:6842938 Min:      0 Act:    1 Avg:    2 Max:      63 T: 1 (  627) P:50 I:1500 C:4561953 Min:      0 Act:    4 Avg:    2 Max:      66 T: 2 (  628) P:50 I:2000 C:3421461 Min:      0 Act:    0 Avg:    2 Max:      69 T: 3 (  629) P:50 I:2500 C:2737166 Min:      0 Act:    3 Avg:    2 Max:      71 T: 4 (  630) P:50 I:3000 C:2280969 Min:      0 Act:    2 Avg:    1 Max:      33   //////////////////////////////////////// Update for Yocto L5.10.52 2.1.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.10.52 2.1.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm and git checkout xenomai-5.10.52-2.1.0. Updating: 1, Upgrade Xenomai to v3.2 2, Enable Dovetail instead of ipipe. Copy xenomai-arm to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL_append += " xenomai" Notice: If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch. //////////////////////////////////////// Update for Yocto L5.15.71 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.15.71 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm and git checkout xenomai-5.15.71-2.2.0. Updating: 1, Upgrade Xenomai to v3.2.2 Copy xenomai-arm to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai" Notice: If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch.   ///////// Later update for Later Yocto release, please refer to the following community post //////////// 移植实时Linux方案Xenomai到i.MX ARM64平台 (Enable real-time Linux Xenomai on i.MX ARM64 Platform)   

    Xenomai is real-time framework, which can run seamlessly side-by-side Linux as a co-kernel system, or natively over mainline Linux kernels (with or without PREEMPT-RT patch). The dual kernel nicknamed Cobalt, is a significant rework of the Xenomai 2.x system. Cobalt implements the RTDM specification for interfacing with real-time device drivers. The native linux version, an enhanced implementation of the experimental Xenomai/SOLO work, is called Mercury. In this environment, only a standalone implementation of the RTDM specification in a kernel module is required, for interfacing the RTDM-compliant device drivers with the native kernel. You can get more detailed information from Home · Wiki · xenomai / xenomai · GitLab       I have ported xenomai 3.1 to i.MX Yocto 4.19.35-1.1.0, and currently support ARM64 and test on i.MX8MQ EVK board. I did over night test( 5 real-time threads + GPU SDK test case) and stress test by tool stress-ng on i.MX8MQ EVK board. It looks lile pretty good. Current version (20200730) also support i.MX8MM EVK.     You need git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git, and git checkout xenomai-4.19.35-1.1.0-20200818 (which inlcudes all patches and bb file) and add the following variable in conf/local.conf before build xenomai by command bitbake xenomai.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch. The following is test result by the command (/usr/xenomai/demo/cyclictest -p 99 -t 5 -m -n -i 1000  -l 100000😞 //Over normal Linux kernel without GPU SDK test case T: 0 ( 4220) P:99 I:1000 C: 100000 Min: 7 Act: 10 Avg: 9 Max: 23 T: 1 ( 4221) P:99 I:1500 C: 66672 Min: 7 Act: 10 Avg: 10 Max: 20 T: 2 ( 4222) P:99 I:2000 C: 50001 Min: 7 Act: 12 Avg: 10 Max: 81 T: 3 ( 4223) P:99 I:2500 C: 39998 Min: 7 Act: 11 Avg: 10 Max: 29 T: 4 ( 4224) P:99 I:3000 C: 33330 Min: 7 Act: 13 Avg: 10 Max: 26 //Over normal Linux kernel with GPU SDK test case T: 0 ( 4177) P:99 I:1000 C: 100000 Min: 7 Act: 10 Avg: 11 Max: 51 T: 1 ( 4178) P:99 I:1500 C: 66673 Min: 7 Act: 12 Avg: 10 Max: 35 T: 2 ( 4179) P:99 I:2000 C: 50002 Min: 7 Act: 12 Avg: 11 Max: 38 T: 3 ( 4180) P:99 I:2500 C: 39999 Min: 7 Act: 12 Avg: 11 Max: 42 T: 4 ( 4181) P:99 I:3000 C: 33330 Min: 7 Act: 12 Avg: 11 Max: 36   //Cobalt with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M --timeout 600s --metrics-brief T: 0 ( 4259) P:50 I:1000 C:3508590 Min:      0 Act:    0 Avg:    0 Max:      42 T: 1 ( 4260) P:50 I:1500 C:2338831 Min:      0 Act:    1 Avg:    0 Max:      36 T: 2 ( 4261) P:50 I:2000 C:1754123 Min:      0 Act:    1 Avg:    1 Max:      42 T: 3 ( 4262) P:50 I:2500 C:1403298 Min:      0 Act:    1 Avg:    1 Max:      45 T: 4 ( 4263) P:50 I:3000 C:1169415 Min:      0 Act:    1 Avg:    1 Max:      22   //Cobalt without GPU SDK test case T: 0 ( 4230) P:50 I:1000 C: 100000 Min: 0 Act: 0 Avg: 0 Max: 4 T: 1 ( 4231) P:50 I:1500 C:   66676 Min: 0 Act: 1 Avg: 0 Max: 4 T: 2 ( 4232) P:50 I:2000 C:   50007 Min: 0 Act: 1 Avg: 0 Max: 8 T: 3 ( 4233) P:50 I:2500 C:   40005 Min: 0 Act: 1 Avg: 0 Max: 3 T: 4 ( 4234) P:50 I:3000 C:   33338 Min: 0 Act: 1 Avg: 0 Max: 5 //Cobalt with GPU SDK test case T: 0 ( 4184) P:99 I:1000 C:37722968 Min: 0 Act: 1 Avg: 0 Max: 24 T: 1 ( 4185) P:99 I:1500 C:25148645 Min: 0 Act: 1 Avg: 0 Max: 33 T: 2 ( 4186) P:99 I:2000 C:18861483 Min: 0 Act: 1 Avg: 0 Max: 22 T: 3 ( 4187) P:99 I:2500 C:15089187 Min: 0 Act: 1 Avg: 0 Max: 23 T: 4 ( 4188) P:99 I:3000 C:12574322 Min: 0 Act: 1 Avg: 0 Max: 29 //Mercury without GPU SDK test case T: 0 ( 4287) P:99 I:1000 C:1000000 Min: 6 Act: 7 Avg: 7 Max: 20 T: 1 ( 4288) P:99 I:1500 C:  666667 Min: 6 Act: 9 Avg: 7 Max: 17 T: 2 ( 4289) P:99 I:2000 C:  499994 Min: 6 Act: 8 Avg: 7 Max: 24 T: 3 ( 4290) P:99 I:2500 C:  399991 Min: 6 Act: 9 Avg: 7 Max: 19 T: 4 ( 4291) P:99 I:3000 C:  333322 Min: 6 Act: 8 Avg: 7 Max: 21 //Mercury with GPU SDK test case T: 0 ( 4222) P:99 I:1000 C:1236790 Min: 6 Act: 7 Avg: 7 Max: 55 T: 1 ( 4223) P:99 I:1500 C:  824518 Min: 6 Act: 7 Avg: 7 Max: 44 T: 2 ( 4224) P:99 I:2000 C:  618382 Min: 6 Act: 8 Avg: 8 Max: 88 T: 3 ( 4225) P:99 I:2500 C:  494701 Min: 6 Act: 7 Avg: 8 Max: 49 T: 4 ( 4226) P:99 I:3000 C:  412247 Min: 6 Act: 7 Avg: 8 Max: 53 //////////////////////////////////////// Update for Yocto L5.4.47 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.4.47 2.2.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP). You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git,  and git checkout xenomai-5.4.47-2.2.0. You need to add the following variable in conf/local.conf before build xenomai by command bitbake imx-image-multimedia.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "5-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "5-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" //////////////////////////////////////// Update for Yocto L5.4.70 2.3.0  /////////////////////////////////////////////////////////// New release  for Yocto release L5.4.70 2.3.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP) and i.MX8QM/QXP. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.4.70-2.3.0. Updating: 1, Support i.MX8QM and i.MX8QXP 2, Fix altency's the issue which uses legacy API to get time   //////////////////////////////////////// update for Yocto L5.4.70 2.3.2  /////////////////////////////////////////////////////////// New release for Yocto release L5.4.70 2.3.2. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git, and git checkout xenomai-5.4.70-2.3.2. Updating: 1, Enable Xenomai RTDM driver in Linux Kernel 2, Currently CAN, UART, GPIO,  SPI and Ethernet (in debug for RTNet)  are added in Xenomai. 3, Add KERNEL_DEVICETREE += " freescale/imx8mp-rt-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mpevk.conf to enable relative device in Xenomai domain, for example rt-imx8mp-flexcan.   //////////////////////////////////////// Update for Yocto L5.4.70 2.3.4  /////////////////////////////////////////////////////////// New release for Yocto release L5.4.70 2.3.4. You need to git clone  https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.4.70-2.3.4. Updating: 1, Enable RTNet FEC driver 2, Currently CAN, UART, GPIO,  SPI and Ethernet ( FEC Controller)  are added in Xenomai. 3, Add KERNEL_DEVICETREE += " freescale/imx8mp-rt-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mpevk.conf and KERNEL_DEVICETREE += " freescale/imx8mm-rt-ddr4-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mmddr4evk.conf to enable rt_fec device in Xenomai domain. Verifying the network connection by RTnet Ping Between i.MX8M Mini EVK and i.MX8M Plus EVK a, Setup test environment 1, Connect ENET1 of  i.MX8M Plus EVK (used as a master) and  ENET of i.MX8M Mini EVK (used as a slave) of  to a switch or hub 2, Modify /usr/xenomai/etc/rtnet.conf in i.MX8M Plus EVK board as the following: @@ -16,7 +16,7 @@ MODULE_EXT=".ko" # RT-NIC driver -RT_DRIVER="rt_eepro100" +RT_DRIVER="rt_fec" RT_DRIVER_OPTIONS="" # PCI addresses of RT-NICs to claim (format: 0000:00:00.0) @@ -30,8 +30,8 @@ REBIND_RT_NICS="" # The TDMA_CONFIG file overrides these parameters for masters and backup # masters. Leave blank if you do not use IP addresses or if this station is # intended to retrieve its IP from the master based on its MAC address. -IPADDR="10.0.0.1" -NETMASK="" +IPADDR="192.168.100.101" +NETMASK="255.255.255.0" # Start realtime loopback device ("yes" or "no") RT_LOOPBACK="yes" @@ -65,7 +65,7 @@ TDMA_MODE="master" # Master parameters # Simple setup: List of TDMA slaves -TDMA_SLAVES="10.0.0.2 10.0.0.3 10.0.0.4" +TDMA_SLAVES="192.168.100.102" # Simple setup: Cycle time in microsecond TDMA_CYCLE="5000" 3, Modify /usr/xenomai/etc/rtnet.conf in i.MX8M Mini EVK board as the following: @@ -16,7 +16,7 @@ MODULE_EXT=".ko" # RT-NIC driver -RT_DRIVER="rt_eepro100" +RT_DRIVER="rt_fec" RT_DRIVER_OPTIONS="" # PCI addresses of RT-NICs to claim (format: 0000:00:00.0) @@ -30,8 +30,8 @@ REBIND_RT_NICS="" # The TDMA_CONFIG file overrides these parameters for masters and backup # masters. Leave blank if you do not use IP addresses or if this station is # intended to retrieve its IP from the master based on its MAC address. -IPADDR="10.0.0.1" -NETMASK="" +IPADDR="192.168.100.102" +NETMASK="255.255.255.0" # Start realtime loopback device ("yes" or "no") RT_LOOPBACK="yes" @@ -59,13 +59,13 @@ STAGE_2_CMDS="" # TDMA mode of the station ("master" or "slave") # Start backup masters in slave mode, it will then be switched to master # mode automatically during startup. -TDMA_MODE="master" +TDMA_MODE="slave" # Master parameters # Simple setup: List of TDMA slaves -TDMA_SLAVES="10.0.0.2 10.0.0.3 10.0.0.4" +TDMA_SLAVES="192.168.100.102" # Simple setup: Cycle time in microsecond TDMA_CYCLE="5000" 4, rename imx8mm-rt-ddr4-evk.dtb to imx8mm-ddr4-evk.dtb in /run/media/mmcblk1p1,  rename imx8mp-rt-evk.dtb to imx8mp-evk.dtb in /run/media/mmcblk1p1, and reboot board. 5, Run the below command on i.MX8M Mini EVK board. cd /usr/xenomai/sbin/ ./rtnet start & 5, Run the below command on i.MX8M Plus EVK board. cd /usr/xenomai/sbin/ ./rtnet start & When you see the log (rt_fec_main 30be0000.ethernet (unnamed net_device) (uninitialized): Link is Up - 100Mbps/Full - flow control rx/tx) and you can run command "./rtroute" to check route table if the slave IP (192.168.100.102) is in route.. b, Verify the network connection using the command below: ./rtping -s 1024 192.168.100.102 //////////////////////////////////////// Update for Yocto L5.10.52 2.1.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.10.52 2.1.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.10.52-2.1.0. Updating: 1, Upgrade Xenomai to v3.2 2, Enable Dovetail instead of ipipe. Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL_append += " xenomai" Notice: If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch.  Latency testing of Xenomai3.2+Dovetail with isolating CPU 2,3 ( Xenomai 3.2 on 8MM DDR4 EVK with GPU test case (GLES2/S08_EnvironmentMappingRefraction_Wayland) + iperf3 + 2 ping 65000 size + stress-ng --cpu 2 --io 2 --vm 1 --vm-bytes 256M --metrics-brief )😞 The following is test result by the command (/usr/xenomai/demo/cyclictest -a 2,3 -p 50 -t 5 -m -n -i 1000) root@imx8mmddr4evk:~# /usr/xenomai/demo/cyclictest -a 2,3 -p 50 -t 5 -m -n -i 1000 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 5.96 6.04 6.03 7/155 1349 T: 0 ( 615) P:50 I:1000 C:63448632 Min: 0 Act: 0 Avg: 0 Max: 55 T: 1 ( 616) P:50 I:1500 C:42299087 Min: 0 Act: 0 Avg: 1 Max: 43 T: 2 ( 617) P:50 I:2000 C:31724315 Min: 0 Act: 0 Avg: 1 Max: 51 T: 3 ( 618) P:50 I:2500 C:25379452 Min: 0 Act: 0 Avg: 1 Max: 53 T: 4 ( 619) P:50 I:3000 C:21149543 Min: 0 Act: 0 Avg: 1 Max: 47 //////////////////////////////////////// Update for Yocto L5.10.72 2.2.2  /////////////////////////////////////////////////////////// New release for Yocto release L5.10.72 2.2.2. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.10.72-2.2.2. Updating: 1, Upgrade Xenomai to v3.2.1 Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL_append += " xenomai" //////////////////////////////////////// Update for Yocto L5.15.71 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.15.71 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.15.71-2.2.0. Updating: 1, Upgrade Xenomai to v3.2.2 Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai"   //////////////////////////////////////// Update for Yocto L6.1.55 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L6.1.55 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git recipes-rtlinux-xenomai -b Linux-6.1.x Updating: 1, Upgrade Xenomai to v3.2.4 and support i.MX93 2, Enable EVL (aka Xenomai 4) for i.MX93 and legacy i.MX(6/7D/8X/8M) Copy recipes-rtlinux-xenomai to <Yocto folder>/sources/meta-imx/meta-bsp/, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "evl" IMAGE_INSTALL:append += " libevl"  

Why SWPDM?   In order to process human voice, it is required to have the best audio resolution in the incoming data captured by the microphones. This mean, having a resolution of 16bits is not enough to capture all the information to properly process the voice. Voice processing requires a peripheral capable of capture data on a 32bits resolution within the range of the most common sample rates (16kHz, 44.1kHz, 48Khz, etc.). On the i.MX8M family there is a peripheral which fulfill those requirements and is called MICFIL. MICFIL is a peripheral which convert PDM (Pulse Density Modulation) data to PCM (Pulse-Code Modulation) data. The PDM format encode the analog signal in just one bit. Where 1 means the signal is increasing in amplitude while 0 means the opposite. In the other hand, the PCM format encode the data in 8, 16, or 32 bits. The advantage of PDM is that the creation of microphones is cheaper than having PCM microphones but then you will need a software or hardware which do the conversion for PDM to PCM since PDM cannot be processed. This is the reason of the MICFIL peripheral. However, not all the MICFIL's on the difference SOMs are the same. While the i.MX8MPLUS has a resolution of 32bits its smaller brothers do not. i.MX8MMINI and i.MX8MNANO have a MICFIL which only allows a resolution up to 16bits. For most of the cases it will be enough but not for voice processing. Nevertheless, not everything is lost; As mentioned previously, the PDM to PCM conversation can be done by hardware or by software. NXP also have the algorithm in software to do the conversation. Therefore, if a Mini or Nano is being used for voice processing it is fully recommended to use the ALSA SWPDM Plugin and avoid MICFIL peripheral.   Using the Plugin   In order to use the plugin, it is required to change the DTB to  imx8mm-evk-8mic-swpdm.dtb , when using the i.MX8MM or  imx8mn-evk-8mic-swpdm.dtb , when using the i.MX8MN. In order to do so follow the next steps: Please notice below example if for Mini. For Nano will be the same just changing the DTB name to imx8mn-evk-8mic-swpdm.dtb. # Stop at U-boot u-boot=> edit fdtfile edit: imx8mm-evk-8mic-swpmd.dtb u-boot=> saveenv u-boot=> boot   The change in the DTB is required to disable MICFIL so Linux can receive the raw data and sent it to the plugin. However, the plugin is not enabled by default, users need to explicit add the plugin to their ALSA pipeline. The way of doing so is by adding the following device to  /etc/asound.conf : pcm.cic { type cicFilter slave "hw:imxswpdmaudio,0" delay 100000 gain 0 OSR 48 }   Where: pcm.cic : Is an arbitrary name which allow ALSA to find the requested devices when setting the  -D  flag with  arecord  or  aplay . type cicFilter : This is the plugin type which is named with the algorithm name. slave: Name of the physical or virtual device which will be controlled by the cicFilter plugin. The recommendation is to always have the actual hardware connected to this plugin. delay : Amount of time in microsecond which the plugin won't write to the buffer, but it still does the conversion. The value could be between 100us to 1'000,000us. By removing the property from the structure, the delay will be set to 0. gain : A value between 0 and 100. OSR : Is related to the quality of the signal by increasing the PDM sample rate. With a higher valuer a best quality on the audio can be achieved. However, keep in mind than having a higher value will also require more memory to store all the new data due to the oversampling. The valid values for the OSR are: 48, 64, 96, 128, and 192. With all being said, the only thing left is to test the plugin by running the following command: $ arecord -D cic -c4 -r16000 -f s32_le --period-size=96 -d5 -v test.wav   Integration With AFE   The next and final step is integrating the plugin with AFE and VoiceSeeker. The integration of SWPDM requires to apply a patch to the SWPDM repository. The patch changes the amount of period sizes allowed on the plugin. By default, the plugin only allows certain values which are:  48 Samples = 3ch x 4bytes format x 16samples = 192 bytes. 48 Samples = 2ch x 4bytes format x 48samples = 384 bytes. 48 Samples = 4ch x 4bytes format x 48samples = 768 bytes. 96 Samples = 4ch x 4bytes format x 96samples = 1,536 bytes. Although, AFE and VoiceSeeker are extremely configurable, 48 or 96 samples for the algorithm is too small. Meaning that the SWPDM should support a bigger period size, not all the way around. By applying the attached file, the plugin can have a period size from 64 bytes (1ch and 16 samples) up to 16,384 bytes (4ch and 1024 samples). However, the number of samples can vary depending on the OSR value and the number of channels. Once the patch has been applied in must be installed on: /usr/lib/alsa-lib (if the repository is being built on a standalone environment). AFE opens a device called mic  for capture the microphones' input. This device can have anything below it. By default, have the following definition on /etc/asound.conf  (after following the steps described on the TODO.md file). # mic represents the physical source (capture) pcm.mic { type plug slave.pcm "hw:micfilaudio,0" }   The devices opens the MICFIL driver, but on this case MICFIL is disable, which means the definition of the device must change. From above cic  device the definition can be copy and paste and then tweak one parameter. The delay must be set to 0 by removing the property or setting it explicitly on the structure. If this step if forgotten this might cause some underrun issues. The device definition will be: pcm.mic { type cicFilter slave "hw:imxswpdmaudio,0" delay 0 gain 0 OSR 48 }   The last thing to do will be running AFE with VoiceSeeker as usual. $ /unit_tests/nxp-afe/voice_ui_app & $ /unit_tests/nxp-afe/afe libvoiceseekerlight &   Considerations and Restrictions With all that said, there are few things left to mention, which are the considerations and restrictions on the plugin itself. These are good things to know before adding the plugin into any application. The plugin is supported from the Linux BSP 5.15.32. Currently the plugin only supports up to 4 channels. Plugin only outputs a S32_LE format (if required another format please use MICFIL). By applying above patch, the period size must be a multiple of 16, due to a limitation on the algorithm itself, rather than the plugin. The driver only allows to have one microphone per data-line while MICFIL allows to have two microphones per data-line. The SWPDM Plugin is based on the External Plugin: I/O Plugin. This means it also have the restriction of this ALSA plugin, being the following restriction the most important one: "The I/O-type plugin is a PCM plugin to work as the input or output terminal point, i.e. as a user-space PCM driver". In other words, there can't be any device/plugin on top of it, not even a "plug" type. 

Background   Wake-on-LAN ( WoL) is an Ethernet computer networking standard that allows a computer to be turned on or awakened from sleep mode by a network message. The message is usually sent to the target computer by a program executed on a device connected to the same local area network. Ethernet connections, including home and work networks, wireless data networks, and the Internet itself, are based on frames sent between computers. WoL is implemented using a specially designed frame called a magic packet, which is sent to all computers in a network, among them the computer to be awakened. The magic packet contains the MAC address of the destination computer. This is an identifying number, built into each network interface controller (NIC)/Ethernet Controller, that enables the NIC/EnetController to be uniquely recognized and addressed on a network What is a WOL Magic packet? The magic packet is a frame that is most often sent as a broadcast and that contains anywhere within its payload 6 bytes of all 255 (FF FF FF FF FF FF in hexadecimal), followed by sixteen repetitions of the target computer's 48-bit MAC address, for a total of 102 bytes. it is typically sent as a UDP datagram to port 0 (reserved port number), 7 (Echo Protocol) or 9 (Discard Protocol) or directly over Ethernet using EtherType 0x0842   Configure iMX93EVK to wake up on an Ethernet Wake On LAN Magic Packet   Pre-requisite:- Install 'Wake on  LAN' utility on windows from the Microsoft Store. This utility uses Port 7 to send magic packet as a broadcast to the devices on the network.   Step-1 Make the dts change to enable wake-up functionality on eth1   In the following dts:- arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts   You would see the node entry for the corresponding ethernet, eth1 as eqos. Add fsl,magic-packet; to the node     After building the changes, boot with the imx93evk image.   Step-2 Enable wake on LAN By default in linux user-space the wake-on-lan is disabled, to enable the wake-on-lan run:  ethtool -s eth1 wol g     Now you are all set to wake up imx93evk via Ethernet WOL packet. Put the iMX93 to deep sleep via 'echo mem > /sys/power/state'   Step-3 Send WOL magic packet via Wake On LAN windows utility to wake up iMX93EVK   Make sure the devices are connected to the same local network like imx93evk and laptop connected to the same L2 switch. Add your imx93evk device to Wake on LAN software, you have to give iMX93EVK's MAC address of the ethernet that the RJ45 cable is connected to[you can get this from 'ifconfig -a' output].     After adding the device, it will look something like below:-     Right-click on the 'imx' device which is registered on Wake on LAN UI and click on 'Send WOL(magic packet)'. The moment you do that the WOL packet is sent to your iMX from your Laptop/PC on the same network and the iMX is woken up from deep sleep.     Hope you found it helpful. Please drop in any questions/comments just in case. 

Sometimes we need to use an SPI bus to communicate with sensors or another device. Unfortunately, by default on iMX8MN-EVK, we have the ECSPI2 disabled on our BSP.   We can use that peripheral on Linux enabling it in the device tree.   To enable the ECSPI2 on the device tree we have to add the next on imx8mn-evk.dtsi:     status = "okay"; }; +&ecspi2 { + #address-cells = <1>; + #size-cells = <0>; + fsl,spi-num-chipselects = <1>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>; + cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>; + status = "okay"; + + spidev0: spi@0 { + reg = <0>; + compatible = "rohm,dh2228fv"; + spi-max-frequency = <500000>; + }; +}; + &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_fec1>;   On iomux node:   + pinctrl_ecspi2: ecspi2grp { + fsl,pins = < + MX8MN_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK 0x82 + MX8MN_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI 0x82 + MX8MN_IOMUXC_ECSPI2_MISO_ECSPI2_MISO 0x82 + >; + }; + + pinctrl_ecspi2_cs: ecspi2cs { + fsl,pins = < + MX8MN_IOMUXC_ECSPI2_SS0_GPIO5_IO13 0x40000 + >; + }; + pinctrl_ir_recv: ir-recv { fsl,pins = < MX8MN_IOMUXC_GPIO1_IO13_GPIO1_IO13 0x4f    after modifying and compiling the device tree you can see the device active like this:     Connection:   Test: spidev_test -D /dev/spidev1.0 -v       You can use the devsheell of yocto to make the changes:   https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-Devshell-to-compile-device-tree-files/ta-p/1727428

  For some applications, we need to reduce the CPU Frequency, but if you are not familiar with our BSP or our devices probably you need some help to do some configurations.   In this post, I will share the configuration to set up lower frequencies (100MHz, 200MHz, 400Mhz, 600MHz, 800MHz, and 1000MHz) on iMX8MP, iMX8MN, and iMX8MM.   Note: Works on Kernel 6.1.xx (not tested on oldest BSP)   1- We have to modify the PLL driver to set the proper parameters to lower frequencies. The file to modify is "clk-pll14xx.c" adding the following lines:   https://github.com/nxp-imx/linux-imx/blob/770c5fe2c1d1529fae21b7043911cd50c6cf087e/drivers/clk/imx/clk-pll14xx.c#L57   static const struct imx_pll14xx_rate_table imx_pll1416x_tbl[] = { PLL_1416X_RATE(1800000000U, 225, 3, 0), PLL_1416X_RATE(1600000000U, 200, 3, 0), PLL_1416X_RATE(1500000000U, 375, 3, 1), PLL_1416X_RATE(1400000000U, 350, 3, 1), PLL_1416X_RATE(1200000000U, 300, 3, 1), PLL_1416X_RATE(1000000000U, 250, 3, 1), PLL_1416X_RATE(800000000U, 200, 3, 1), PLL_1416X_RATE(750000000U, 250, 2, 2), PLL_1416X_RATE(700000000U, 350, 3, 2), PLL_1416X_RATE(600000000U, 300, 3, 2), + PLL_1416X_RATE(400000000U, 200, 3, 2), + PLL_1416X_RATE(200000000U, 200, 3, 3), + PLL_1416X_RATE(100000000U, 200, 3, 4), };   2- Once the pll driver has been modified, only we have to add the values on the opp-table according to the device that you will use.   2.1- For iMX 8MP:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mp.dtsi         a53_opp_table: opp-table { compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; opp-1200000000 { opp-hz = /bits/ 64 <1200000000>;   2.2 For iMX8MM:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mm.dtsi     a53_opp_table: opp-table { compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; opp-1200000000 { opp-hz = /bits/ 64 <1200000000>;   2.3- For iMX8MN:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mn.dtsi   compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1200000000 { opp-hz = /bits/ 64 <1200000000>; opp-microvolt = <850000>;   After that, you should note the changes under Linux.   These commands return information about the system and the current settings.   • The kernel is pre-configured to support only certain frequencies. The list of frequencies currently supported can be obtained from: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies   • To get the available scaling governors: cat /sys/devices/system/cpu/*/cpufreq/scaling_available_governors   • To check the current CPU frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_cur_freq   The frequency is displayed depending on the governor set.   • To check the maximum frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_max_freq   • To check the minimum frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_min_freq   These commands set a constant CPU frequency:   • Use the maximum frequency: echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor   • Use the current frequency to be the constant frequency: echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor   • The following two commands set the scaling governor to a specified frequency, if that frequency is supported.   If the frequency is not supported, the closest supported frequency is used:   echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo <frequency> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed    

this is tested with MX93(A1) EVK running 6.1.55_2.2.0 pre-build image.   USB can output test patterns with either one of the setup below: 1. through device node: root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# cat role gadget root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo host > role [ 2672.864083] ci_hdrc ci_hdrc.0: EHCI Host Controller [ 2672.868996] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 [ 2672.893320] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 [ 2672.899314] hub 1-0:1.0: USB hub found [ 2672.909235] hub 1-0:1.0: 1 port detected root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# cat role host root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 4 > port_test root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 3 > port_test root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 2 > port_test root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 1 > port_test   2. use memtool to program registers for i in $(find /sys -name control | grep usb);do echo on > $i;echo "echo on > $i";done; echo host > /sys/kernel/debug/usb/ci_hdrc.0/role #Offset:184h USB_OTG1 base address: 4C10_0000h base address USB_OTG2 base address: 4C20_0000h Register address Register address：base address+offset $ /unit_tests/memtool 0x4c100184 1 # Force to output Test Packet for Eye Diagram Test $ /unit_tests/memtool 0x4c100184=0x18041215 #Force to output J_STATE $ /unit_tests/memtool 0x4c100184=0x18011215 #Force to output K_STATE $ /unit_tests/memtool 0x4c100184=0x18021215 #Force to output SE0 (host) / NAK (device) $ /unit_tests/memtool 0x4c100184=0x18031215

Hey everyone !! This piece covers how to configure the iMX93EVK board to wake up Cortex A55[ running Linux] from Cortex M33 core[running a bare metal application].    We will be using UART console on Cortex M33 to signal Cortex A55 via RPMSG to wake-up from deep sleep.   This can be done as follows:-   1. Boot iMX93EVK with RPMSG enabled DTB and load M33 binary via UBOOT   After booting to Uboot terminal, set the fdtfile variable to <rpmsg dtb> that will help us enable rpmsg in the kernel.   u-boot=> setenv fdtfile imx93-11x11-evk-rpmsg.dtb u-boot=> setenv bootargs ${jh_clk} ${mcore_clk} console=${console} root=${mmcroot}   then, load the M33 binary from the eMMC partition    u-boot=> fatload mmc 0:1 0x80000000 imx93-11x11-evk_m33_TCM_power_mode_switch.bin 18996 bytes read in 14 ms (1.3 MiB/s)   u-boot=> cp.b 0x80000000 0x201e0000 0x4a34 u-boot=> saveenv Note:-  Do not run the M33 core via bootaux at this point, instead just boot to Linux   u-boot=> boot         2. Starting the Cortex M33 core from Cortex A55[running Linux]   Once linux is up, load the elf of Cortex M33 power mode switch application.   echo ~/power_mode_switch.elf > /sys/devices/platform/imx93-cm33/remoteproc/remoteproc0/firmware   start the M33 core   echo start > /sys/devices/platform/imx93-cm33/remoteproc/remoteproc0/state   On console of Cortex M33 you will see the output as below:-   The log below shows the output of the power mode switch demo in the terminal window: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Start SRTM communication Task 1 is working now #################### Power Mode Switch Task #################### Build Time: Nov 10 2023--15:15:16 Core Clock: 200000000Hz Select the desired operation Press A to enter: Normal RUN mode Press B to enter: WAIT mode Press C to enter: STOP mode Press D to enter: SUSPEND mode Press W to wakeup A55 core Press M for switch M33 Root Clock frequency between OD/ND. Waiting for power mode select.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   M33 at this point is ready to wake up the A55 core.     3. Put A55 core to deep sleep and trigger a wakeup from M33 console   To put A55 to deep sleep   echo mem > /sys/power/state you will see something like below on linux console:-     At this point, A55 core is in deep sleep power saving mode. So the A55 console will not respond to any of the key presses. Go on, give it a try 🙂   Now to wake up this core, go to M33 serial console and type 'W'  This will wake up A55 core and you will see the logs denoting that the core has woken up:-   That's it! that's how you exercise UART wake-up functionality on imx93evk. Please feel free to drop any follow-up questions or additional thoughts on this.

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