i.MX Processors Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Sort by:
The HSM Coding-Signing is new. When we follow the instructions in Code-Signing Tool User’s Guide , still has something to overcome, most of them are related to the OS. Actually, Code-Signing Tool User’s Guide  can not give detail every “obvious” step. The purpose of this document is to share the experiences on my system. Hope those experience can give you some clues on your system.
View full article
  Introduction   MATTER chip-tool android APK is a very useful tool for commission, control the MATTER network by smart phone. Vendor can add various features into the APK. It supports build by Android Studio and command line. The official build steps can be found here: https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/android_building.md But the official guide does not cover how to build in a non-GUI linux distribution (without Android Studio installed). This article describes how to build under Ubuntu server. Install Android SDK  Install SDK command line from: https://developer.android.com/studio, And follow the steps: https://developer.android.com/tools/sdkmanager to install.  Install the Android-26 SDK and 23 NDK: $./sdkmanager "platforms;android-26" "ndk;23.2.8568313"  Export env  $export ANDROID_HOME=<SDK path>  $export ANDROID_NDK_HOME=<SDK path>/ndk/23.2.8568313/   Install kotlin (1.8.0)  $curl -s https://get.sdkman.io | bash  $sdk install kotlin 1.8.0  $whereis kotlin  $export PATH=$PATH:<patch of bin of kotlin>    Configure proxy for gradle  $ cat ~/.gradle/gradle.properties  # Set the socket timeout to 5 minutes (good for proxies)  org.gradle.internal.http.socketTimeout=300000  # the number of retries (initial included) (default 3)  org.gradle.internal.repository.max.retries=10  # the initial time before retrying, in milliseconds (default 125)  org.gradle.internal.repository.initial.backoff=500  systemProp.http.proxyHost=apac.nics.nxp.com  systemProp.http.proxyPort=8080  systemProp.http.nonProxyHosts=localhost|*.nxp.com  systemProp.https.proxyHost=apac.nics.nxp.com  systemProp.https.proxyPort=8080  systemProp.https.nonProxyHosts=localhost|*.nxp.com    Configure proxy  Configure proxy for download packages during build export FTP_PROXY="http://apac.nics.nxp.com:8080"  export HTTPS_PROXY="http://apac.nics.nxp.com:8080"  export HTTP_PROXY="http://apac.nics.nxp.com:8080"  export NO_PROXY="localhost,*.nxp.com"  export ftp_proxy="http://apac.nics.nxp.com:8080"  export http_proxy="http://apac.nics.nxp.com:8080"  export https_proxy="http://apac.nics.nxp.com:8080"  export no_proxy="localhost,*.nxp.com"    Patch for gradle java option  This step can be skipped if using OpenJDK16.  Otherwise if you're using OpenJDK 17 (Java 61), you have to upgrade the gradle from 7.1.1 to 7.3, and add java.io open to ALL-UNNAMED:  diff --git a/examples/android/CHIPTool/gradle.properties b/examples/android/CHIPTool/gradle.properties  index 71f72db8c8..5bce4b4528 100644  --- a/examples/android/CHIPTool/gradle.properties  +++ b/examples/android/CHIPTool/gradle.properties  @@ -6,7 +6,8 @@  # http://www.gradle.org/docs/current/userguide/build_environment.html  # Specifies the JVM arguments used for the daemon process.  # The setting is particularly useful for tweaking memory settings.  -org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8  +#org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8  +org.gradle.jvmargs=-Xmx4096m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8  --add-opens=java.base/java.io=ALL-UNNAMED  # When configured, Gradle will run in incubating parallel mode.  # This option should only be used with decoupled projects. More details, visit  # http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects  diff --git a/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties b/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties  index 05679dc3c1..e750102e09 100644  --- a/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties  +++ b/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties  @@ -1,5 +1,5 @@  distributionBase=GRADLE_USER_HOME  distributionPath=wrapper/dists  -distributionUrl=https\://services.gradle.org/distributions/gradle-7.1.1-bin.zip  +distributionUrl=https\://services.gradle.org/distributions/gradle-7.3-bin.zip  zipStoreBase=GRADLE_USER_HOME  zipStorePath=wrapper/dists    Build & Install Clone all the modules from github: $git clone --single-branch --recurse-submodules https://github.com/project-chip/connectedhomeip.git Enviroment setup: $source scripts/bootstrap.sh Build: ./scripts/build/build_examples.py --target android-arm64-chip-tool build Install built apk into phone: $adb install out/android-arm64-chip-tool/outputs/apk/debug/app-debug.apk  
View full article
For more information about the i.MX 8QM/QP revision, please see the attached PDF slide deck at the bottom of this page. It includes frequently asked questions and is the official source of information regarding this revision. ------------------------------------------------------------------------------------------------------------------------------------- The i.MX 8QM and i.MX 8QP has been revised with lower clock speeds and higher core voltages to help improve instability issues found with the part. Old parts that have not been derated have an "FF" moniker in the part number, whereas new parts, releasing in June 2024, have an "FE" moniker. An example can be found below. SCFW (System Controller Firmware) 1.16.0, which will be released with the Q2 Linux Factory BSP (LF6.6.y_2.0.0), will make the necessary changes to increase core voltage for CPU and GPU cores in the 8QM/8QP, as well as reduce clock speeds. It may not be immediately apparent what changes must be made to derate these processors before the new parts and new SCFW version is released. To assist with these issues, we are providing the changes below as a workaround until SCFW 1.16.0 is released.     Recommended Changes until SCFW 1.16.0 is released 1. Increase voltages in pmic_init(). This function is found inside the respective board.c file within the SCFW porting kit. This is assuming that the customer has routed their VDD_A72 to PMIC_0 on SW3 and SW4, and routed their VDD_GPU0 and VDD_GPU1 to PMIC_1 on SW1 through SW4. +/* Set VDD_A72 to 1.1375V (1138mV) */ +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_0_ADDR, PF8100_SW3, 1138, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_0_ADDR, PF8100_SW4, 1138, REG_RUN_MODE)) +/* Set VDD_GPU0 and VDD_GPU1 to 1.03125V (1032mV) */ +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW1, 1032, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW2, 1032, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW3, 1032, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW4, 1032, REG_RUN_MODE))   2. Add +37.5mV offset for VDD_A72, +31.25mV offset for VDD_GPU0/VDD_GPU1. This is done in the function board_set_voltage, found in board.c of the respective processor in the SCFW porting kit. This ensures that voltages are set correctly if a frequency change occurs (like going from overdrive to nominal mode on GPU). /*--------------------------------------------------------------------------*/ /* Set the voltage for the given SS. */ /*--------------------------------------------------------------------------*/ sc_err_t board_set_voltage(sc_sub_t ss, uint32_t new_volt, uint32_t old_volt) { sc_err_t err = SC_ERR_NONE; pmic_id_t pmic_id[2] = {0U, 0U}; uint32_t pmic_reg[2] = {0U, 0U}; uint8_t num_regs = 0U; +// A72 cores are running on 1.1375V instead of 1.10V +if ((ss == SC_SUBSYS_A72) && (new_volt == 1100)) { +board_print(3, "Changing voltage from 1100 to 1138"); +new_volt = 1138; +} +// GPU is running on 1.03125V instead of 1.00V +if ((ss == SC_SUBSYS_GPU_0 || SC_SUBSYS_GPU_1) && (new_volt == 1000)) { +board_print(3, "Changing voltage from 1000 to 1032"); +new_volt = 1032; +} board_print(3, "board_set_voltage(%s, %u, %u)\n", snames[ss], new_volt, old_volt); board_get_pmic_info(ss, pmic_id, pmic_reg, &num_regs);   3. Remove 1.6GHz from Linux DTS OPP Table for A72 core. This is found in the device tree of the board. These are typically found in /arch/arm64/boot/dts/freescale/. /* opp-1596000000 { opp-hz = /bits/ 64 <1596000000>; opp-microvolt = <1100000>; clock-latency-ns = <150000>; opp-suspend; }; */ 4. Disable GPU overdrive mode - set to nominal mode using sysfs in Linux userland echo "nominal" > /sys/bus/platform/drivers/galcore/gpu_govern
View full article
Sometime need standalone compile device tree. Only Linux headers and device tree directory are needed.         
View full article
This article is rather short that only mentions the script that is needed to make an iMX93EVK act as a USB mass storage device so that whenever you connect your iMX device to a windows/linux system via USB, it should get enumerated something like a usb drive.  The storage that is used in this example is mmc so the expectation is that you have inserted a mmc card in the slot. Below is the script:- #!/bin/sh   # This composite gadget include function: # - MASS STORAGE     # # Exit status is 0 for PASS, nonzero for FAIL # STATUS=0   # Check if there is udc available, if not, return fail UDC_DIR=/sys/class/udc if test "$(ls -A "$UDC_DIR")"; then echo "The available udc:" for entry in "$UDC_DIR"/* do echo "$entry" done else STATUS=1 echo "No udc available!" exit $STATUS; fi   id=1; udc_name=ci_hdrc.0 #back_file=/dev/mmcblk1 back_file=/tmp/lun0.img   mkdir /sys/kernel/config/usb_gadget/g$id cd /sys/kernel/config/usb_gadget/g$id   # Use NXP VID, i.MX8QXP PID echo 0x1fc9 > idVendor echo 0x12cf > idProduct   mkdir strings/0x409 echo 123456ABCDEF > strings/0x409/serialnumber echo NXP > strings/0x409/manufacturer echo "NXP iMX USB Composite Gadget" > strings/0x409/product   mkdir configs/c.1 mkdir configs/c.1/strings/0x409   echo 5 > configs/c.1/MaxPower echo 0xc0 > configs/c.1/bmAttributes   mkdir functions/mass_storage.1 echo $back_file > functions/mass_storage.1/lun.0/file ln -s functions/mass_storage.1 configs/c.1/   echo $udc_name > UDC First execute the script. After that insert the g_mass_storage module in the kernel by executing :- modprobe g_mass_storage file=/dev/mmcblk1 removable=1 In the dmesg output, you will see something like below:-   After that you can connect a C type USB cable to the USB1 port of imx93evk and the other end to any USB ports of a laptop. The moment it is connected, you would be able to see a USB drive similar to what you get when we connect a pen-drive. 
View full article
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.          
View full article
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
View full article
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
View full article
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.    
View full article
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.
View full article
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.  
View full article
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 
View full article
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.
View full article
Information about the transition from the NXP Demo Experience to GoPoint for i.MX Application Processors.
View full article
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.    
View full article
On behalf of Gopise Yuan. This is an update for the DRM framebuffer capture tool I used to share with the team. Some enhancement added. Might be useful for debugging some display related issues.   Some special notes: Behavior of DRM subsystem is different between L4.x and L5.x. For L4.x, you can capture the RGB buffer without any problem. But, there’s no API for YUV (multi-plane) buffer. To capture YUV, need to apply “kernel_0001-drm-Add-getfb2-ioctl_L4.14.98.patch”. For L5.x, mapping/capturing the internal buffer is not allowed by default due to security reason. A simple change in “0001-drm-enable-mapping-of-internal-object-for-debugging_L5.x.patch” can disable this guard. Capture raw data only. RGB and YUV (packed/planar, 420/422) supported. Support de-tile on “Amphion tile” (VPU, NV12 only) and “Super tile” (Vivante GPU). Please use “-t” to enable this. Other tile might not be supported. This is a static linked binary. You can run it on any ARM64 based Linux/Android system in theory (prerequisites in item #1). If you need source code, come to me.   To get more details on how to use it, use “-?” option: DRM screen capture DRM based screen capture program Usage:     ./drmfbcap [OP] [ARG] [OP] OPeration (optional):     -v Show version.     -? Show help information.     -i Show information about target DRM device only (no capture).     -t Perform de-tile for tile format.     -d DRM device to open. [ARG] should contain the path to the device node. Default: '/dev/dri/card0'     -o Output folder. [ARG] should contain the path to the output folder. Default: '.'     -p Specific plane # to capture. [ARG] should contain the plane number. If no '-p' specified, capture all planes   Example:     ./drmfbcap   Capture all planes on default DRM device.     ./drmfbcap -d /dev/dri/controlD64   Capture all planes on '/dev/dri/controlD64' device.     ./drmfbcap -p 44 -t -o /sdcard   Capture plane 44, do de-tile after capture and then output to /sdcard/.   Raw buffer capture will be done for each enabled/target plane and one file for each. Captured file will be saved to './' if not specified. --- By Gopise, 2022/08   Updated_2023_10_16: continuous capture (repeat mode) support with this link: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/DRM-screen-capture-tool/ta-p/1725363
View full article
What is a device tree? The device tree is a data structure that is passed to the Linux kernel to describe the physical devices in a system. Before device trees came into use, the bootloader (for example, U-Boot) had to tell the kernel what machine type it was booting. Moreover, it had to pass other information such as memory size and location, kernel command line, etc. Sometimes, the device tree is confused with the Linux Kernel configuration, but the device tree specifies what devices are available and how they are accessed, not whether the hardware is used. The device tree is a structure composed of nodes and properties: Nodes: The node name is a label used to identify the node. Properties: A node may contain multiple properties arranged with a name and a value. Phandle: Property in one node that contains a pointer to another node. Aliases: The aliases node is an index of other nodes. A device tree is defined in a human-readable device tree syntax text file such as .dts or .dtsi. The machine has one or several .dts files that correspond to different hardware configurations. With these .dts files we can compile them into a device tree binary (.dtb) blobs that can either be attached to the kernel binary (for legacy compatibility) or, as is more commonly done, passed to the kernel by a bootloader like U-Boot. What is Devshell? The Devshell is a terminal shell that runs in the same context as the BitBake task engine. It is possible to run Devshell directly or it may spawn automatically. The advantage of this tool is that is automatically included when you configure and build a platform project so, you can start using it by installing the packages and following the setup of i.MX Yocto Project User's Guide on section 3 “Host Setup”. Steps: Now, let’s see how to compile your device tree files of i.MX devices using Devshell. On host machine. Modify or make your device tree on the next path: - 64 bits. ~/imx-yocto-bsp/<build directory>/tmp/work-shared/<machine>/kernel-source/arch/arm64/boot/dts/freescale - 32 bits. ~/imx-yocto-bsp/<build directory>/tmp/work-shared/<machine>/kernel-source/arch/arm/boot/dts To compile, it is needed to prepare the environment as is mentioned on i.MX Yocto Project User's Guide on section 5.1 “Build Configurations”. $ cd ~/imx-yocto-bsp $ DISTRO=fsl-imx-xwayland MACHINE=<machine> source imx-setup-release.sh -b <build directory> $ bitbake -c devshell virtual/kernel (it will open a new window) On Devshell window. $ make dtbs (after finished, close the Devshell window) On host machine. $ bitbake -c compile -f virtual/kernel $ bitbake -c deploy -f virtual/kernel This process will compile all the device tree files linked to the machine declared on setup environment and your device tree files will be deployed on the next path: ~/imx-yocto-bsp/<build directory>/tmp/deploy/images/<machine> I hope this article will be helpful. Best regards. Jorge.
View full article
Customer is asking high-capacity external storage(for example >64GB) support on i.MX BSP, ext4 is ok for HC storage, but it can’t be supported by Windows. Pls find NFTS and exFAT support status on Linux BSP below: Updated test result on L5.4.70.2.3.0 and L6.1.22: L5.4.70.2.3.0 1.You can enable ntfs support in kernel config as below,  ntfs can be mounted normally, but you can only modify existing file content in disk, you can’t create/delete/rename file on disk. > File systems > DOS/FAT/NT Filesystems   Log: root@imx8mpevk:~# mount -t ntfs /dev/sda1 /mnt/fat/ [  662.732869] ntfs: volume version 3.1. root@imx8mpevk:~# cp ntfs-3g /mnt/fat/ cp: cannot create regular file '/mnt/fat/ntfs-3g': Permission denied root@imx8mpevk:~# ls /mnt/fat/ 111.png  Image_org  System Volume Information  gpuinfo.sh root@imx8mpevk:~# vi /mnt/fat/gpuinfo.sh root@imx8mpevk:~# umount /mnt/fat/ root@imx8mpevk:~# ntfs file system can be accessed via ntfs-3g in user space as below //build: wget https://tuxera.com/opensource/ntfs-3g_ntfsprogs-2017.3.23.tgz tar zxvf ntfs-3g_ntfsprogs-2017.3.23.tgz cd ntfs-3g_ntfsprogs-2017.3.23/ source ../../sdk/environment-setup-aarch64-poky-linux   ./configure --host=aarch64-linux --build=aarch64-poky-linux --disable-shared --enable-static   make   ls /src/ntfs-3g   //put it into rootfs cp ntfs-3g /bin   //test log: root@imx8mpevk:/# [ 1058.724471] usb 1-1: USB disconnect, device number 4 [ 1062.058613] usb 1-1: new high-speed USB device number 5 using xhci-hcd [ 1062.214029] usb-storage 1-1:1.0: USB Mass Storage device detected [ 1062.220986] scsi host0: usb-storage 1-1:1.0 [ 1063.235871] scsi 0:0:0:0: Direct-Access     VendorCo ProductCode      2.00 PQ: 0 ANSI: 4 [ 1063.246185] sd 0:0:0:0: [sda] 15728640 512-byte logical blocks: (8.05 GB/7.50 GiB) [ 1063.254023] sd 0:0:0:0: [sda] Write Protect is off [ 1063.259164] sd 0:0:0:0: [sda] No Caching mode page found [ 1063.264540] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 1063.296946]  sda: sda1 [ 1063.300860] sd 0:0:0:0: [sda] Attached SCSI removable disk   root@imx8mpevk:/# ntfs-3g /dev/sda1 /mnt/fat/ root@imx8mpevk:/# ls /mnt/fat/ README  System Volume Information  gpu.sh  gpuinfo.sh root@imx8mpevk:/# cp /unit_tests/memtool /mnt/fat/ root@imx8mpevk:/# umount /mnt/fat/ root@imx8mpevk:/# ntfs-3g /dev/sda1 /mnt/fat/ root@imx8mpevk:/# ls /mnt/fat/ README  System Volume Information  gpu.sh  gpuinfo.sh  memtool root@imx8mpevk:/#   3.exFAT is not supported on this BSP..   L6.1.22(you can check it on L5.15 and above, should be the same) You can enable ntfs support in kernel config as below, full features can be supported. > File systems > DOS/FAT/EXFAT/NT Filesystems   Pls use ‘-t ntfs3’ during mounting, otherwise it will be mounted as ‘read-only’ Log: root@imx8ulpevk:~# mount -t ntfs3 /dev/sda1 /mnt/fat/ root@imx8ulpevk:~# ls /mnt/fat/ 111.png   Image_org  'System Volume Information' root@imx8ulpevk:~# root@imx8ulpevk:~# cp gpuinfo.sh /mnt/fat/ root@imx8ulpevk:~# umount /mnt/fat/ root@imx8ulpevk:~# root@imx8ulpevk:~# mount -t ntfs3 /dev/sda1 /mnt/fat/ root@imx8ulpevk:~# ls /mnt/fat/ 111.png   Image_org  'System Volume Information'   gpuinfo.sh root@imx8ulpevk:~#   exFAT has been supported in L6.1.22. > File systems > DOS/FAT/EXFAT/NT Filesystems   /dev/sda1 on /run/media/sda1 type exfat (rw,relatime,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro) root@imx8ulpevk:~# ls /run/media/sda1 'Certificate of Completion.pdf'             carlife.MP4 Image_org                                  example.tflite L5.4.70_2.3.0                              mx8mp_vpu.txt NXP-5G.mp4                                 sd.mp4 'System Volume Information'                 vela.ini android_p9.0.0_2.1.0-auto-ga_image_8qmek root@imx8ulpevk:~# ls Image_org  gpuinfo.sh root@imx8ulpevk:~# cp gpuinfo.sh /run/media/sda1/ root@imx8ulpevk:~# umount /run/media/sda1 root@imx8ulpevk:~#
View full article
Hello everyone! In this quick example its focused on how to customize uboot code to generate an uboot image with a silent console so its speed up the flash and boot time, this may provide helpful for customers who have a bigger images or just want to have a silent console. Note: this should not be enabled if the image is still being under test, since this will disable all communication with the debug terminal and there won't be boot messages. Requirements: I.MX 8M Nano DDR4 EVK i.MX 8M Nano EVK Prebuilt image (6.1.1-1.0.0) UUU tool First clone the code from the uboot repository: $ git clone https://github.com/nxp-imx/uboot-imx -b lf-6.1.1-1.0.0 $ cd uboot-imx After we get the code, then proceed to enable the silent console in the uboot defconfig: $ nano configs/imx8mn_ddr4_evk_defconfig CONFIG_SILENT_CONSOLE=y CONFIG_SILENT_U_BOOT_ONLY=y For this to actually work we need to create the silent environmental variable and give it a value different from "0": $ nano include/configs/imx8mn_evk.h "silent=1\0"      \ As specified in our Linux porting guide: Generate an SDK from the Yocto Project build environment with the following command. To set up the Yocto Project build environment, follow the steps in the i.MX Yocto Project User's Guide (IMXLXYOCTOUG). In the following command, set Target-Machine to the machine you are building for. See Section "Build configurations" in the i.MX Yocto Project User's Guide (IMXLXYOCTOUG) Set up the host terminal window toolchain environment: $ source/opt/fsl-imx-xwayland/6.1.1/environment-setup-aarch64-poky-linux $ export ARCH=arm64 Build uboot binary: $ make distclean $ make imx8mn_ddr4_evk_defconfig $ make Build ARM Trusted Firmware (ATF) $ cd .. $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.1.1-1.0.0 $ cd imx-atf/ $ make PLAT=imx8mn bl31 In case you get the error aarch64-poky-linux-ld.bfd: unrecognized option '-Wl,-O1' $ unset LDFLAGS Download the DDR training & HDMI binaries $ cd .. $ mkdir firmware-imx $ cd firmware-imx $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.19.bin $ chmod a+x firmware-imx-8.19.bin $ ./firmware-imx-8.19.bin Accept EULA and the firmware will be deployed. Download imx-mkimage and build the boot image $ cd .. $ git clone https://github.com/nxp-imx/imx-mkimage -b lf-6.1.1-1.0.0 $ cd imx-mkimage $ cp ../uboot-imx/spl/u-boot-spl.bin iMX8M/ $ cp ../uboot-imx/u-boot-nodtb.bin iMX8M/ $ cp ../uboot-imx/arch/arm/dts/imx8mn-ddr4-evk.dtb iMX8M/ $ cp ../imx-atf/build/imx8mn/release/bl31.bin iMX8M/ $ cp ../firmware-imx/firmware-imx-8.19/firmware/ddr/synopsys/ddr4_* iMX8M/ $ cp ../uboot-imx/tools/mkimage iMX8M/mkimage_uboot $ make SOC=iMX8MN flash_ddr4_evk After this we can download our uboot image to our board, we can either use the uboot image for boot or for flashing purpose only. We can compare the time it takes using UUU with a standard pre-built image uuu -V -b emmc_all imx-boot-imx8mn-ddr4-evk-sd.bin-flash_ddr4_evk imx-image-full-imx8mnevk.wic It takes 485.5 seconds using normal uboot with debug console enabled. uuu -V -b emmc_all flash.bin imx-image-full-imx8mnevk.wic It takes 477.5 seconds using silent uboot console. Even if the speed is not greatly improved (~8 seconds), in larger files it could help to speed up flashing, even if wants to have the console silent is a good option. Hope everyone finds this useful! For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.
View full article
  Introduction   Prior to 6.1.22_2.0.0 BSP release, Bluetooth interface are based on the tty line discipline framework, so we need to use hciattach tool to enable it in the user space. From 6.1.22_2.0.0 BSP, the nxp bluetooth driver no longer needs the help of the userspace hciattach tool, and the tty port bound by bluetooth also won't be exported to the user space, so you cannot find the corresponding tty device anymore. So, you won't see the (/dev/ttymxcX), for the Bluetooth interface. All jobs has been done in the new NXP Bluetooth driver. New Method   The new NXP Bluetooth UART Driver is based on a server driver for the NXP BT serial protocol, which can enable the built-in Bluetooth device inside an NXP BT chip. This driver has a Power Save feature that will put the chip into a sleep state whenever there is no activity for 2000ms and will be woken up when any activity is to be initiated over UART.  Device Tree support The new BT framework requires adding a "bluetooth" sub node with a device compatibility string to the attached UART node in the dts file &uart1 { bluetooth { compatibility = "nxp,88w8987-bt"; fw-init-baudrate = <3000000>; #Optional. Default is considered 115200 if this parameter not defined. }; };   Note: The parameter ‘compatibility = “nxp,88w8987-bt”’ will use for 88W8987, IW416, 88Q9098, IW612 chipsets and need to change for 88W8997 with parameter ‘compatibility = “nxp,88w8997-bt”’.   Note: ’fw-init-baudrate’ parameter depends on the module vendor. The Murata and Azuere wifi modules support in BSP release uses the default value -- 115200. We strongly recommend looking at the module vendor-specific baud rate parameter. Note: For the old 88Q9098 Murata 1XL module that uses the 3Mbps by default, please add the fw-init-baudrate = <3000000> property in dts files to make it work. Enable Guide   Use wifi interface to load combo (wifi & bt) firmware and enable BT Need to load wifi driver first, then load the BT driver, otherwise, BT driver suspend/resume test will fail. This is a HW limitation, since NXP wifi and BT module use the same power control pin(W_DISABLE1#), if we don't load the wifi driver, SDIO bus will power down the wifi chip during suspend resume, which may cause the BT chip also been powered down and cannot work after resume back. So we need to load the wifi driver to make sure SDIO bus won't power down the BT chip to make sure BT functions can work during suspend resume. modprobe moal mod_para=nxp/wifi_mod_para.conf modprobe btnxpuart or insmod mlan.ko insmod moal.ko mod_para=nxp/wifi_mod_para.conf insmod btnxpuart   Unload UART Driver modprobe moal Make sure run hciconfig hci0 up or hciconfig hci0 reset or bluetootctl power on before unload btnxpuart driver. If we don't open hci0 interface, the driver cannot send change to 115200 baud rate command to BT chip, which causes the host and BT chip baud rate mismatch, the host still uses 115200bps talk to the BT chip which now use 3Mbps, it cannot work anymore. So we need to make sure open the hci0 interface before unload btnxpuart driver.   mod_para=nxp/wifi_mod_para.conf modprobe btnxpuart sleep 3 hciconfig hci0 up #Note: Need to up hci interface before unload the BT module hcitool -i hci0 cmd 3F 23 02 00 00 modprobe -r btnxpuart modprobe -r moal sleep 3​ For better reference: Please find the I.MX 8MQ Linux getting started user guide, UM11483, Chapter "7.1 Bring-up using NXP Bluetooth UART driver"  Bluetooth Deep Sleep Feature App Note AN13920, Chapter 6 Load NXP UART driver module NOTE: Please do not run the power save feature for Murata IW612 2EL Module Regards, Mario
View full article