Sometime need standalone compile device tree. Only Linux headers and device tree directory are needed.         

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. 

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

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.

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.  

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.

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:~#

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.

In some cases, such as mass production or preparing a demo. We need u-boot environment stored in demo sdcard mirror image.  Here is a way: HW:  i.MX8MP evk SW:  LF_v5.15.52-2.1.0_images_IMX8MPEVK.zip The idea is to use fw_setenv to set the sdcard mirror as the operation on a real emmc/sdcard. Add test=ABCD in u-boot-initial-env for test purpose. And use fw_printenv to check and use hexdump to double confirm it. The uboot env is already written into sdcard mirror(imx-image-multimedia-imx8mpevk.wic). All those operations are on the host x86/x64 PC. ./fw_setenv -c fw_env.config -f u-boot-initial-env Environment WRONG, copy 0 Cannot read environment, using default ./fw_printenv -c fw_env.config Environment OK, copy 0 jh_root_dtb=imx8mp-evk-root.dtb loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bsp_script}; mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi arch=arm baudrate=115200 ...... ...... ...... splashimage=0x50000000 test=ABCD usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi vendor=freescale hexdump -s 0x400000 -n 2000 -C imx-image-multimedia-imx8mpevk.wic 00400000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| hexdump -s 0x400000 -n 10000 -C imx-image-multimedia-imx8mpevk.wic 00400000 5f a4 9b 97 20 6a 68 5f 72 6f 6f 74 5f 64 74 62 |_... jh_root_dtb| 00400010 3d 69 6d 78 38 6d 70 2d 65 76 6b 2d 72 6f 6f 74 |=imx8mp-evk-root| 00400020 2e 64 74 62 00 20 6c 6f 61 64 62 6f 6f 74 73 63 |.dtb. loadbootsc| 00400030 72 69 70 74 3d 66 61 74 6c 6f 61 64 20 6d 6d 63 |ript=fatload mmc| 00400040 20 24 7b 6d 6d 63 64 65 76 7d 3a 24 7b 6d 6d 63 | ${mmcdev}:${mmc| 00400050 70 61 72 74 7d 20 24 7b 6c 6f 61 64 61 64 64 72 |part} ${loadaddr| 00400060 7d 20 24 7b 62 73 70 5f 73 63 72 69 70 74 7d 3b |} ${bsp_script};| 00400070 00 20 6d 6d 63 5f 62 6f 6f 74 3d 69 66 20 6d 6d |. mmc_boot=if mm| ...... ...... ...... 00401390 76 3d 31 00 73 6f 63 3d 69 6d 78 38 6d 00 73 70 |v=1.soc=imx8m.sp| 004013a0 6c 61 73 68 69 6d 61 67 65 3d 30 78 35 30 30 30 |lashimage=0x5000| 004013b0 30 30 30 30 00 74 65 73 74 3d 41 42 43 44 00 75 |0000.test=ABCD.u| 004013c0 73 62 5f 62 6f 6f 74 3d 75 73 62 20 73 74 61 72 |sb_boot=usb star| 004013d0 74 3b 20 69 66 20 75 73 62 20 64 65 76 20 24 7b |t; if usb dev ${| 004013e0 64 65 76 6e 75 6d 7d 3b 20 74 68 65 6e 20 64 65 |devnum}; then de| flash the sdcard mirror into i.MX8MP evk board emmc to check uuu -b emmc_all imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk imx-image-multimedia-imx8mpevk.wic  The first time boot, the enviroment is already there.  How to achieve that: a. fw_setenv/fw_printenv: https://github.com/sbabic/libubootenv.git Note: Please do not use uboot fw_setenv/fw_printenv Compile it on the host x86/x64 PC. It is used on host. b. u-boot-initial-env Under uboot, make u-boot-initial-env Note: Yocto deploys u-boot-initial-env by default c. fw_env.config  imx-image-multimedia-imx8mpevk.wic 0x400000 0x4000 0x400000 0x4000 are from uboot-imx\configs\imx8mp_evk_defconfig CONFIG_ENV_SIZE=0x4000 CONFIG_ENV_OFFSET=0x400000 Now, you can run  ./fw_setenv -c fw_env.config -f u-boot-initial-env

Hello everyone, We have recently migrated our Source code from CAF (Codeaurora) to Github, so i.MX NXP old recipes/manifest that point to Codeaurora eventually will be modified so it points correctly to Github to avoid any issues while fetching using Yocto. Also, all repo init commands for old releases should be changed from: $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b <branch name> [ -m <release manifest>] To: $ repo init -u https://github.com/nxp-imx/imx-manifest -b <branch name> [ -m <release manifest>] This will also apply to all source code that was stored in Codeaurora, the new repository for all i.MX NXP source code is: https://github.com/nxp-imx For any issues regarding this, please create a community thread and/or a support ticket. Regards, Aldo.

    OpenSSL is popular software library for applications that secure communications over computer networks against eavesdropping or need to identify the party at the other end. It is widely used in internet web servers, serving a majority of all web sites. OpenSSL contains an open-source implementation of the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols, it is a robust, commercial-grade, and full-featured toolkit for the SSL and TLS protocols. OpenSSL is also a general-purpose cryptography library. Its core library, written in the C programming language, implements basic cryptographic functions and provides various utility functions. Wrappers allowing the use of the OpenSSL library in a variety of computer languages are available. More and more embeded systems, like IoT gateway, ePOS, based on i.MX use OpenSSL for their secure communications and cryptographic operations. But it's cryptography library is pure software implementation which need to occupy lots of CPU resouce and the perfermance is very weak than dedicated hardware IP (like CAAM).    CAAM is the i.MX's cryptographic acceleration and assurance module, which serves as NXP's latest cryptographic acceleration and offloading hardware. It combines functions previously implemented in separate modules to create a modular and scalable acceleration and assurance engine. It also implements block encryption algorithms, stream cipher algorithms, hashing algorithms, public key algorithms (i.MX6UL/i.MX7D/S), and a hardware random number generator.   The official Yocto release (L4.1.15_2.0.0-ga) of the i.MX only enable cryptodev for accelerating symmetric algorithms and hashing algorithms, not support asymmetric algorithms(RSA, ECC). And its engine in OpenSSL(version 1.0.2h) also miss some features which is used to support symmetric algorithms and hashing algorithms, for example, AES ECB, SHA224/256, etc. These patches in the post will close the above gaps for i.MX Linux system. The software environments as the belows: Linux kernel: imx_4.1.15_2.0.0_ga cryptodev: 1.8 OpenSSL: 1.0.2h The patches include the following key features: 1, Add public key cryptography part in CAAM driver, through protocol commands, to implement a number of public (and private) key functions. These are DSA and ECDSA sign/verify, Diffie-Hellman (DH) and ECDH key agreement, ECC key generation, DLC key generation, RSA encryption/decryption, RSA key-generation finalization. 2, Add big number operation and elliptic curve math in CAAM driver to implement addition, subtraction, multiplication, exponentiation, reduction, inversion, greatest common divisor, prime testing and point add, point double, point multiply. 3, Add API in cryptodev to support RSA encryption/decryption, DSA/ECDSA sign/verify, DH/ECDH key agreement, ECC & DLC & RSA key generation and big number operation and elliptic curve math. 4, Add public key cryptography functions, hardware rng, and missing hash symmetric algorithms in OpenSSL crytodev engine. Note: 1, You can refer to ecdhtest.c, ecdsatest.c, dhtest.c, dsatest.c, rsa_test.c for how to use crytodev engine in your applications based on libcryto.so. You can also find their executable programs in folder openssl-1.0.2h/test after compiling. 2, If you want to call crytodev API directly to accelerate public key cryptography operations, please refer to asymmetric_cipher.c in cryptodev-linux-1.8/tests. Current Limitation: 1, CAAM driver don't support AES GCM/CCM but hardware supporting. I plan to add the feature next version. 2, ECDSA sign/verify will fail on some binary curves (sect163r1, sect163r2, sect193r1, sect193r2, sect233r1, sect283r1, sect409r1, sect571r1 and X9.62 binary curves). I will try to find the root cause and fix it.   ==================================== for  some binary curves (sect163r1, sect163r2, sect193r1, sect193r2, sect233r1, sect283r1, sect409r1, sect571r1 and X9.62 binary curves)  are rarely used, so i will try to find the root cause when i'm free.  +++++++++++++++++++++++    updating for Linux-4.14.78-1.1.10 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux -4.14.78-1.1.10. The new software environments as the belows: Linux kernel: imx_4.14.78_1.1.10 cryptodev: 1.9 OpenSSL: 1.0.2p HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini, i.MX8/8X. The patches include the following new features: 1, support  RSA key generation but defaultly use openssl build-in function (BN_generate_prime_ex) to create prime p, q for higher security. If need to use CAAM accelerating,  please comment Macro USE_BUILTIN_PRIME_GENERATION, but don't confirm its security. 2, Add Manufacturing-protection feature, and you can refer to manufacturing_protection_test function in asymmetric_cipher.c. 3, Support AES GCM in cryptodev. 4, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-4.14.78-1.1.10 and copy meta-openssl-caam to folder <Yocto 4.14.78-1.1.10 dir>/sources/ 5, Run DISTRO=fsl-imx-wayland MACHINE=imx6ulevk source fsl-setup-release.sh -b build-imx6ulevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into /build-imx6ulevk/conf/bblayers.conf 6, bitbake fsl-image-validation-imx 7, Run the below command on your i.MX6UL EVK board. modprobe cryptodev openssl genrsa -f4 -engine cryptodev 512 -elapsed openssl speed dsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 1024 -elapsed openssl speed rsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 2048 -elapsed openssl speed ecdsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 3072 -elapsed openssl speed ecdh -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 4096 -elapsed openssl speed -evp sha256 -engine cryptodev -elapsed openssl speed -evp aes-128-cbc -engine cryptodev -elapsed openssl speed -evp aes-128-ecb -engine cryptodev -elapsed openssl speed -evp aes-128-cfb -engine cryptodev -elapsed openssl speed -evp aes-128-ofb -engine cryptodev -elapsed openssl speed -evp des-ede3 -engine cryptodev -elapsed openssl speed -evp des-cbc -engine cryptodev -elapsed openssl speed -evp des-ede3-cfb -engine cryptodev -elapsed +++++++++++++++++++++++    updating for Linux-4.14.98-2.3.3 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux -4.14.98-2.3.3. The new software environments as the belows: Linux kernel: imx_4.14.98-2.3.3 cryptodev: 1.9 OpenSSL: 1.0.2p HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano, i.MX8/8X. The patches include the following new features: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-4.14.98-2.3.3 and copy meta-openssl-caam to folder <Yocto 4.14.98-2.3.3 dir>/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8mmevk source fsl-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into /build-imx8mmevk/conf/bblayers.conf 3, bitbake fsl-image-validation-imx 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl genrsa -f4 -engine cryptodev 512 -elapsed openssl speed dsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 1024 -elapsed openssl speed rsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 2048 -elapsed openssl speed ecdsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 3072 -elapsed openssl speed ecdh -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 4096 -elapsed openssl speed -evp sha256 -engine cryptodev -elapsed openssl speed -evp aes-128-cbc -engine cryptodev -elapsed openssl speed -evp aes-128-ecb -engine cryptodev -elapsed openssl speed -evp aes-128-cfb -engine cryptodev -elapsed openssl speed -evp aes-128-ofb -engine cryptodev -elapsed openssl speed -evp des-ede3 -engine cryptodev -elapsed openssl speed -evp des-cbc -engine cryptodev -elapsed openssl speed -evp des-ede3-cfb -engine cryptodev -elapsed +++++++++++++++++++++++    updating for Linux-4.19.35-1.1.2 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 4.19.35-1.1.2​​.  Software environments as the belows: Linux kernel: imx_4.19.35-1.1.2 cryptodev: 1.10 OpenSSL: 1.1.1l HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano, i.MX8/8X. How to build: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-4.19.35-1.1.2 and copy meta-openssl-caam to folder <Yocto 4.19.35-1.1.2 dir>/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into <Yocto 4.19.35-1.1.2 dir>/build-imx8mmevk/conf/bblayers.conf. 3, Run bitbake fsl-image-validation-imx. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl speed dsa openssl speed rsa openssl speed ecdsa openssl speed ecdh openssl genrsa -f4 -engine devcrypto 512 openssl genrsa -f4 -engine devcrypto 1024 openssl genrsa -f4 -engine devcrypto 2048 openssl genrsa -f4 -engine devcrypto 3072 openssl genrsa -f4 -engine devcrypto 4096 openssl speed -evp sha256 -engine devcrypto -elapsed openssl speed -evp aes-128-cbc -engine devcrypto -elapsed openssl speed -evp aes-128-ecb -engine devcrypto -elapsed openssl speed -evp aes-128-cfb -engine devcrypto -elapsed openssl speed -evp aes-128-ofb -engine devcrypto -elapsed openssl speed -evp des-ede3 -engine devcrypto -elapsed openssl speed -evp des-cbc -engine devcrypto -elapsed openssl speed -evp des-ede3-cfb -engine devcrypto -elapsed +++++++++++++++++++++++    updating for Linux-5.4.70-2.3.4 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.4.70_2.3.4​​.  Software environments as the belows: Linux kernel: imx_5.4.70_2.3.4 cryptodev: 1.10 OpenSSL: 1.1.1l HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano/8M Plus, i.MX8/8X. How to build: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-5.4.70-2.3.4  and copy meta-openssl-caam to folder <Yocto 5.4.70_2.3.4 dir>/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into <Yocto 5.4.70_2.3.4 dir>/build-imx8mmevk/conf/bblayers.conf. 3, Run bitbake imx-image-multimedia. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl speed dsa openssl speed rsa openssl speed ecdsa openssl speed ecdh openssl genrsa -f4 -engine devcrypto 512 openssl genrsa -f4 -engine devcrypto 1024 openssl genrsa -f4 -engine devcrypto 2048 openssl genrsa -f4 -engine devcrypto 3072 openssl genrsa -f4 -engine devcrypto 4096 openssl speed -evp sha256 -engine devcrypto -elapsed openssl speed -evp aes-128-cbc -engine devcrypto -elapsed openssl speed -evp aes-128-ecb -engine devcrypto -elapsed openssl speed -evp aes-128-cfb -engine devcrypto -elapsed openssl speed -evp aes-128-ofb -engine devcrypto -elapsed openssl speed -evp des-ede3 -engine devcrypto -elapsed openssl speed -evp des-cbc -engine devcrypto -elapsed openssl speed -evp des-ede3-cfb -engine devcrypto -elapsed     +++++++++++++++++++++++    updating for Linux-5.10.52-2.1.0 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.10.52_2.1.0​​.  Software environments as the belows: Linux kernel: lf-5.10.y cryptodev: 1.12 OpenSSL: 1.1.1l HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano/8M Plus, i.MX8/8X. How to build: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-5.10.52-2.1.0 and copy meta-openssl-caam 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-openssl-caam " into <Yocto 5.10.52_2.1.0 dir>/build-imx8mmevk/conf/bblayers.conf. 3, Run bitbake imx-image-multimedia. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl speed dsa openssl speed rsa openssl speed ecdsa openssl speed ecdh openssl genrsa -f4 -engine devcrypto 512 openssl genrsa -f4 -engine devcrypto 1024 openssl genrsa -f4 -engine devcrypto 2048 openssl genrsa -f4 -engine devcrypto 3072 openssl genrsa -f4 -engine devcrypto 4096 openssl speed -evp sha256 -engine devcrypto -elapsed openssl speed -evp aes-128-cbc -engine devcrypto -elapsed openssl speed -evp aes-128-ecb -engine devcrypto -elapsed openssl speed -evp aes-128-cfb -engine devcrypto -elapsed openssl speed -evp aes-128-ofb -engine devcrypto -elapsed openssl speed -evp des-ede3 -engine devcrypto -elapsed openssl speed -evp des-cbc -engine devcrypto -elapsed openssl speed -evp des-ede3-cfb -engine devcrypto -elapsed   +++++++++++++++++++++++    updating for Linux-5.15.71-2.2.0 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.15.71-2.2.0​​.  Software environments as the belows: Linux kernel: lf-5.15.71-2.2.0 cryptodev: 1.12 OpenSSL: 3.1.0 HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano/8M Plus, i.MX8/8X. How to build: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-5.15.71-2.2.0 and copy meta-openssl-caam 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-openssl-caam " into <Yocto 5.15.71_2.2.0 dir>/build-imx8mmevk/conf/bblayers.conf. 3, Run bitbake imx-image-multimedia. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl speed sm2 openssl speed dsa openssl speed rsa openssl speed ecdsa openssl speed ecdh openssl genrsa -f4 -engine devcrypto 512 openssl genrsa -f4 -engine devcrypto 1024 openssl genrsa -f4 -engine devcrypto 2048 openssl genrsa -f4 -engine devcrypto 3072 openssl genrsa -f4 -engine devcrypto 4096 openssl speed -evp sha256 -engine devcrypto -elapsed openssl speed -evp aes-128-cbc -engine devcrypto -elapsed openssl speed -evp aes-128-ecb -engine devcrypto -elapsed openssl speed -evp aes-128-cfb -engine devcrypto -elapsed openssl speed -evp aes-128-ofb -engine devcrypto -elapsed openssl speed -evp des-ede3 -engine devcrypto -elapsed openssl speed -evp des-cbc -engine devcrypto -elapsed openssl speed -evp des-ede3-cfb -engine devcrypto -elapsed    

In some cases, i.MX board connect to different module. It has very tiny changes, such as just one gpio different driver strength. We can build an entire new software to handle this requirement. Here we introduce another way, using u-boot to modify the device tree(dtb) at runtime.   Here is u-boot fdt command for  How to use gpio-hog demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-gpio-hog-demo/ta-p/1317709   run loadfdt fdt addr ${fdt_addr_r} fdt print /soc/bus/pinctrl/uart3grp fdt rm /soc/bus/pinctrl/uart3grp fdt print serial2 fdt set serial2 status disabled fdt print serial2 fdt print gpio4 fdt resize fdt mknode gpio4 gpio_hog_demo fdt set gpio4/gpio_hog_demo gpio-hog fdt set gpio4/gpio_hog_demo gpios <7 0> fdt set gpio4/gpio_hog_demo output-high fdt print gpio4 run mmcargs run loadimage booti ${loadaddr} - ${fdt_addr_r} root@imx8mmevk:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-31, parent: platform/30200000.gpio, 30200000.gpio: gpio-5 ( |PCIe DIS ) out hi gpio-13 ( |ir-receiver ) in hi IRQ ACTIVE LOW gpio-15 ( |cd ) in hi IRQ ACTIVE LOW gpiochip1: GPIOs 32-63, parent: platform/30210000.gpio, 30210000.gpio: gpio-38 ( |? ) out hi gpio-42 ( |reset ) out lo ACTIVE LOW gpio-51 ( |regulator-usdhc2 ) out lo gpiochip2: GPIOs 64-95, parent: platform/30220000.gpio, 30220000.gpio: gpio-80 ( |status ) out hi gpiochip3: GPIOs 96-127, parent: platform/30230000.gpio, 30230000.gpio: gpio-117 ( |PCIe reset ) out hi gpiochip4: GPIOs 128-159, parent: platform/30240000.gpio, 30240000.gpio: gpio-135 ( |gpio_hog_demo ) out hi gpio-141 ( |spi1 CS0 ) out hi ACTIVE LOW gpio-149 ( |wlf,mute ) out hi ACTIVE LOW root@imx8mmevk:~# [ 33.758914] VSD_3V3: disabling dtc_utils-v1.6.1-win-x86_64.zip by msys2   

We will build a remote debug environmet of Qt Creator in this user guide.   Contents 1 Change local.conf file in Yocto 2 2 Build and deploy Yocto SDK 2 2.1 Build full image SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Deploy SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 Configure QT Kit 2 3.1 Setup device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.2 Configure QT version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3 Configure gcc and g++ manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4 Configure gdb manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5 Configure Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6 Very important thing!! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Test result

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. i.MX 6/7 Family DDR Stress Test  The i.MX6/7 DDR Stress Test Tool is a PC-based software to fine-tune DDR parameters and verify the DDR performance on a non-OS, single-task environment(it is a light-weight test tool to test DDR performance). It performs write leveling, DQS gating and read/write delay calibration features. The tool described on this page cover the following i.MX 6/7 series SoCs: i.MX 6DQP (Dual/Quad Plus) i.MX 6DQ (Dual/Quad) i.MX 6DL/S (Dual Lite/Solo) i.MX 6SoloX i.MX 6SL i.MX 6SLL i.MX 6UL i.MX 6ULL/ULZ i.MX 7D/S i.MX 7ULP Note that the DDR Stress test tool supports the all of the above i.MX SoCs, however, some of the supported i.MX SoCs named in the tool support multiple i.MX SoCs as follows: MX6DQ – when selected, this supports both i.MX 6DQ and i.MX 6DQP (Plus) MX6DL – when selected, this supports both i.MX 6DL and i.MX 6S (i.MX 6DLS family) MX6ULL – when selected, this supports both i.MX 6ULL and i.MX6 ULZ MX7D – when selected, this supports both i.MX 7D and i.MX 7S The purpose of the i.MX 6/7 series DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.). This process equips the user to then proceed with the bring-up of a boot loader and an OS. Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface. The i.MX 6/7 series DDR Tools consist of: DDR Register Programming Aid (RPA): i.MX 6/7 Series DDR Tool Release DDR Stress test: Described below There are three options to run the DDR Stress test. Each of these options are provided in the attached zip files. The following is a high-level overview of each option along with the naming convention of the associated zip file: Option 1 GUI based: Run the GUI executable and connect your board to the host PC via USB Archive file: ddr_stress_tester_vX.xx.zip The tool will first need to run a DDR initialization script for the specified i.MX SoC (refer to Load Init Script in the GUI tool).  Example initialization scripts based on NXP's development boards can be found in this zip file under the script folder.  Note, these scripts may need to be modified for your custom board and memory.   Option 2 DDR Stress Tester: JTAG Interface A hardware debugger connected to the board via the JTAG interface is used to download an elf file into the i.MX SoC OCRAM (internal RAM) and then begin execution. Results are shown on the UART serial port (115200-8-n-1). Archive file: ddr_stress_tester_jtag_vX.xx.zip As with the GUI tool, the JTAG/debugger option will first need to run a DDR initialization script for the specified i.MX SoC. Refer to the GUI tool description above for the location of the example scripts (which are found in the ddr_stress_tester_vX.xx.zip file). Note that the scripts are available either in the RealView ICE format (.inc file) or the DS-5 DSTERAM format (.ds). For other debuggers, the user will have to modify the script's command syntax for their specific debugger. This is also true if converting from a RealView Ice (.inc) format to a DS-5 DSTREAM (.ds) format and vice versa. The DDR Stress Tester executable (starting with V2.20) has an auto UART detection feature. If a different UART port for the serial console has been chosen than used on the NXP development tool (EVK, SABRE) specific commands can be added to the DDR initialization script that allows you to configure for the specific UART and then load and run the elf executable. Refer to the FAQ section of this community post and the txt file found in the JTAG archive file for instructions.   Option 3 U-Boot: The boot loader u-boot is running and commands in u-boot are used to download the bin file into SoC OCRAM and begin execution. Results are shown on the UART serial port (115200-8-n-1) Archive file: ddr_stress_tester_uboot_vX.xx.zip When downloading the DDR Stress Tool by u-boot, please copy the ddr-test-uboot-jtag-mxxxx.bin to SD card and load it to IRAM using the 'fatload' u-boot command (see notes below when using newer versions of u-boot). For i.MX6, please load the binary to 0x00907000. For i.MX7D, please load the binary to 0x00910000.  It is imperative to first disable the I and D cache in u-boot as shown below as the DDR Stress Test re-configures and re-enables the cache and MMU page table. While this option allows the user to load and run the DDR stress test from u-boot, NXP highly recommends executing the GUI based version for system testing and debugging. The u-boot version is considered a “last resort” for systems in production which may not have USB or JTAG connectivity. The reasons behind this stance are: In the GUI version, the system starts “clean” and uninitialized, whereas u-boot initializes many SoC features outside the knowledge of the DDR stress test and may conflict with the stress test operation When running the u-boot version, the test will overwrite the contents of u-boot residing in DDR, hence the test will overwrite any data in DDR. Once the stress test is loaded and executed, u-boot itself will no longer be accessible. To return to the functionality of u-boot, a system re-boot is required. Newer versions on u-boot do not allow a direct loading of the DDR stress test code from the SD card (boot media) directly to the SoC internal OCRAM (aka IRAM). Hence, the procedure is updated to first load the DDR stress test code into DDR and then copy into OCRAM, as shown in the procedure below: u-boot> dcache off;icache off;fatload mmc 2:1 0x12000000 ddr-test-uboot-jtag-mx6dq.bin;cp.b 0x12000000 0x00907000 0x20000;go 0x00907000 As u-boot initializes many peripherals that may conflict with the operation of the DDR stress test, it is necessary to clock gate these peripherals prior to running the DDR stress test. Hence, it is highly recommended to augment the procedure above as follows: u-boot> dcache off;icache off;fatload mmc 2:1 0x12000000 ddr-test-uboot-jtag-mx6dq.bin;cp.b 0x12000000 0x00907000 0x20000; u-boot> mw 0x020c4068 0x00C0000F; u-boot> mw 0x020c406c 0x00000000; u-boot> mw 0x020c4074 0x3F300000; u-boot> mw 0x020c4078 0x0000F300; u-boot> mw 0x020c407c 0x0F000003; u-boot> mw 0x020c4080 0x000003FC; u-boot> go 0x00907000 Note, in the above procedure, it is recommended to write to each clock gate register in separate commands (refer to commands starting with “mw”). The SoC requires a finite amount of time to gate each clock hence performing this sequence with a new command line write ensures the SoC has time to gate the intended clocks.   Stress Test Revision Features Comments 3.00 Add i.MX 7ULP support in the GUI version Known issues: USB connection is unstable when under USB HUB or some PC environments 2.92 Minor correction with write leveling calibration code error check to avoid a corner case of flagging an error when none have occurred.    2.91 Resolved issue with write leveling calibration code where a race condition in the code may result in the calibration routine not being able to find any delay values.   Only applies to MX6 series SoCs that support DDR3.  2.90 Reserve write delay line register (MMDC_MPWRDLCTL) configuration as DDR script does when do write calibration. In previous releases, MMDC_MPWRDLCTL would be changed to 0x40404040 by default.      * Further details available in the release notes  _________________________________________________________________________________________________________________________________________    FAQ   Q. I see an error message that states "ERROR: DCD addr is out of valid range.", why is this and how do I resolve?   A. Sometimes, when using the register programming aid, there are registers writes that are not supported in the DCD range.  Try looking for the following items and comment them out from the DDR initialization script: wait = on setmem /16 0x020bc000 = 0x30 // disable watchdog (note the address for this may be different between i.MX6x devices)  Q. How do I select the "DDR Density" pull-down menu and what is the purpose of this?   A. The DDR Density pull-down menu gives the user the option of testing a DDR density smaller than what they actually have on their board.  The advantage of doing this is to speed up test time to allow the user to perform a "quick test" of their system.  IMPORTANT: it is imperative that the user not set this value higher than the supported density on their board, doing so will cause the stress test to fail and/or lock up. The DDR Density has a different meaning depending on the memory type being tested (DDR3 or LPDDR2): For DDR3, this is the density per CHIP SELECT.  So if your board has two chip selects, and each chip select has 512MB, you would simply select 512MB or lower.  The default setting will simply set this to the detected density per chip select. For LPDDR2, this is the density per CHANNEL.  This is only relevant for MX6 devices that support 2 channel LPDDR2 memories (MX6DQ, MX6DL).  For other MX6 devices that support only one LPDDR2 channel, then this is the total density (for the maximum setting) for that channel. Note that for LPDDR2, the number of chip selects (per channel) is irrelevant when selecting the density to test as the stress test combines both chip-selects into one combined density per channel.  For example, lets say you have a 2GB LPDDR2 device, which 2 channels and 2 chip-selects per channel.  That means you have 512MB per chip select, per channel.  Or, it also means you have 1GB per channel when combining both chip selects per channel.  In this case, you would choose (a maximum setting of) 1GB in the DDR Density drop down menu.  However, this is also the same setting as the default setting (which you are welcome to still choose 1GB to convince yourself that 1GB per channel is indeed being tested). Now let's assume you have only one channel (LPDDR2) and one chip select, with a density of 128MB; in this case, the maximum DDR Density you can select is 128MB. Let's assume you have one channel and two chip selects, each chip select is 128MB;  in this case, the maximum DDR Density you can select is 256MB (a combination of both chip selects).   Note, for the MX7D, an actual density needs to be entered. For the MX6x series, simply leaving this field as Default will cause the DDR stress test to ascertain the supported density from the DDR init script. As the MX7D DDR controller is different, this feature is not supported, hence it is required for the user to enter an actual density (for more details regarding MX7D usage of density and number of chip-selects, see the next FAQ on the DDR CS setting).   Q.  What is the purpose of the "DDR CS" pull-down option?   A.  The answer depends on which processor you are testing:   For the i.MX 6x series: This pull down menu gives you the option of testing one chip select (CS0) or ALL (both) chip selects *IF* you have a two-chip select configuration.  If you have a two-chip select configuration, then this allows you to test only one chip select for faster test time; else you can choose to test both chip selects.  Note that if you have a one-chip select configuration and you choose "ALL", the stress test will return an error.   For the iMX 7D: Because the MX7D DDR controller is different, the DDR stress test will need the user to supply the entire supported density found on their board. The chip select field should be left as is (0) as the test will naturally test one chip select to the next. For example, let’s assume you are using two chip selects, with each chip select being 512MB. In this case, you would enter 1GB for the DDR Density field ensuring that both chip selects will be tested. The user is allowed to enter a density less than the density found on their board (for quicker testing), but keeping in mind both chip selects may not be tested in this case.   Q. I run DDR calibration using the DDR Stress Test Tool to obtain the calibration results.  Are these calibration parameters are written to the uboot flash_header.S automatically or manually?   A. The calibration values obtained from the DDR Stress Test Tool will need to be manually updated in the flash_header.S file or any other DDR initialization script.   Q. When running the DDR stress test on MX7D and I try to perform calibration, I get an error stating that calibration is not supported, is this expected?   A. Yes, calibration is not supported or needed when using MX7.  The reason is, MX7 uses a different memory controller than the MX6 series.  The MX6 series memory controller has built-in support for calibration where the MX7 memory controller does not.   Q. When running the GUI version of the DDR stress test, on MX7 and I leave DDR Density as default, I get an error in the tool stating I must supply a density.  Why is this?   A. This is due to the fact that MX7 uses a different memory controller than the MX6 series.  In the MX6 series, it was possible to calculate the memory density from the memory controller register settings.  The MX7 memory controller is different and does not lend itself to easily calculate the supported density based on the register settings.  Instead, the user should verify the density on their board and selected this value in the DDR Density pull-down menu.    Q. I noticed that when I run write-leveling calibration I sometimes see a note that due to the write-leveling calibration value being greater than 1/8 clock cycle that WALAT must be set to 1.  What does this mean?   A. In the MMDC chapter of the reference manual for the specific i.MX 6 device, the need to set WALAT is described in the MDMISC register as follows: "The purpose of WALAT is to add time delay at the end of a burst write operation to ensure that the JEDEC time specification for Write Post Amble Delay (tWPST) is met (DQS strobe is held low at the end of a write burst for > 30% a clock cycle before it is released). If the value of any of the WL_DL_ABS_OFFSETn register fields are greater than ‘1F’, WALAT should be set to ‘1’ (cycle additional delay). WALAT should be further increased for any full-cycle delays added by the WL_CYC_DELn register fields." Therefore, if the write-leveling calibration routine detects any write-leveling delay value greater than 0x1F, it will note to the user that WALAT must be set and the user should update their DDR3 init script to ensure WALAT is set.  Sometimes, a user may find that the write-leveling delay value may fluctuate from one run to the next, which is quite normal.  If it is found that this delay is "borderline" meaning sometimes it is greater than 0x1F and sometimes it might be slightly less, then it is ok to go ahead and set WALAT permanently in your init script as there is no harm in doing so and will ensure you will stay within JEDEC's tWPST.   Q. I sometimes see that after running write-leveling calibration that delay values being reported back are zero'd out (0x00), and then at times I see a non-zero value being reported, why is this? A. It is quite normal to see slight variations in the delay value between write-leveling calibration runs.  The write-leveling calibration routine assumes a majority of users have designed their board such that the DDR3 memories are placed close to the i.MX 6 SoC. There’s a mechanism in NXP’s DDR Stress test write leveling calibration code that checks the returned write leveling value. If the write-leveling calibration routine detects that the returned delay value is greater than ¾ of a clock cycle, it will "zero out" the delay value. It does this because it assumes that such a large delay result is due to the fact that the DQS signal is already delayed relative to the SDCLK, and to align DQS with SDCLK requires the calibration routine to delay DQS even further to align it to the next SDCLK edge, something we ideally would like to avoid.  JEDEC specs that the DQS edge must be within 25% of a SDCLK cycle with respect to the SDCLK edge, so having DQS initially slightly delayed from SDCLK is actually ok, hence why the calibration routine “zero’s” this out when the returned value exceeds ¾ of a clock cycle.  In cases like this, the DQS edge and SDCLK edge are so close together that in some calibration runs, the DQS edge may slightly precede SDCLK (resulting in a very small write-leveling delay value) and other runs, it may be slightly delayed relative to the SDCLK (resulting in a very large write-leveling delay value that will try to align DQS to the next SDCLK edge, hence needs to be zero’d out).   Q. When using the JTAG version of the DDR stress test, how can I select a different UART port for my serial port?   A. Under the folder ddr_stress_tester_jtag_v2.52, there's a text file that describes how to add a different UART port by adding a few additional commands to your DDR init script.  The following is an outline of these commands: 1. Ungate UART module clocks (most NXP scripts ungate all of the peripheral clocks at the beginning of the script, so this part is already done) 2. Configure the IOMUX options for the pins you wish the UART to use (normally an IOMUX option for UART_TX and UART_RX, and a daisy chain option for the UART_RX input) 3. Enable the desired UART module via the register UCR1, bit UART_EN 4. Disable other UART modules (UCR1[UART_EN] = 0).  Normally disabling UART1 should be sufficient, but it doesn't hurt to disable all of the other un-used UART options for the purpose of the stress test.   Here's an example in the .ds file vernacular of a set up as follows: MX6DQ, UART4 on KEY_COL0 and KEY_ROW0 (assume clock is ungated to all peripherals): mem set 0x020E01F8 32 0x00000004   #// config_pad_mode(KEY_COL0, ALT4) mem set 0x020E01FC 32 0x00000004   #// config_pad_mode(KEY_ROW0, ALT4); mem set 0x020E0938 32 0x00000001   #// Pad KEY_ROW0 is involved in Daisy Chain. mem set 0x02020080 32 0x00000000   #//disable UART1 in UART1_UCR1 (Note, you can disable other UART modules as well) mem set 0x021F0080 32 0x00000001   #//enable UART4 in UART4_UCR1   Here's another example in the .inc file vernacular of a set up as follows: MX6SX, UART5 on SD4_DATA4 abd SD4_DATA5 (assume clock is ungated to all peripherals): setmem /32 0x020E0294 = 0x2 //IOMUXC_SW_MUX_CTL_PAD_SD4_DATA5, ALT2; UART5_TX_DATA setmem /32 0x020E0290 = 0x2 //IOMUXC_SW_MUX_CTL_PAD_SD4_DATA4, ALT2; UART5_RX_DATA setmem /32 0x020E0850 = 0x00000000 // IOMUXC_UART5_IPP_UART_RXD_MUX_SELECT_INPUT, daisy chain for UART5_RX input to use SD4_DATA4 setmem /32 0x021F4080 = 0x00000001 // Enable UART_EN in UCR1 of UART5 // Disable UART_EN in UCR1 of UART1, UART2, UART3, and UART4 setmem /32 0x02020080 = 0x00000000 // UART1 setmem /32 0x021F0080 = 0x00000000 // UART2 setmem /32 0x021EC080 = 0x00000000 // UART3 setmem /32 0x021E8080 = 0x00000000 // UART4     Related Resources Links: iMX 8M Mini Register Programming Aid DRAM PLL setting  i.MX 8/8X Series DDR Tool Release  i.MX 8M Family DDR Tool Release 

Hello everyone, this document will explain on how to create and run a custom script for UUU (Universal Update Utility) tool Requirements: I.MX 8M Mini EVK Linux Binary Demo Files - i.MX 8MMini EVK (L5.10.35) UUU Serial console emulator (tera term or putty) Text editor (Notepad++, nano, etc) UUU is a pretty flexible tool since it uses the Fastboot protocol through uboot to flash the desired images, this will make possible to create a custom script to add many uboot commands to customize further the boot settings. In this example I will create a custom script which will flash uboot and Linux rootfs and write a Cortex-M binary to the FAT partition of the eMMC. At the same time I’ll create and modify a set of environmental variables, this variables will have a set of uboot commands that will load to the TCM this same binary before the device starts booting into Linux.   Creating the script For this document I'll be using Notepad++ but any text editor may be used instead, since the scripts used by UUU are written in plain text. The very first line of the script must be the version number which will represent the minimum UUU version that UUU can parse this script. For this case that version is 1.2.39 After it, we will add all standard commands to flash uboot and filesystem into the eMMC. Note: This may be also copied from the uuu.auto script inside the Demo files. Please note that the UUU commands format is PROTOCOL: CMD, for this example we will be using mainly SDP and FB protocols which corresponds to the serial download protocol and Fastboot respectively. For a list of all supported UUU protocols and commands please refer to the UUU documentation here: https://github.com/NXPmicro/mfgtools/releases/download/uuu_1.4.165/UUU.pdf Now add the following commands to the script, this will download and write into eMMC FAT partition, which was created when flashing the .wic image, the Cortex-M binary.   FB: ucmd setenv fastboot_buffer ${loadaddr} FB: download -f hello_world_test.bin FB[-t 20000]: ucmd fatwrite mmc ${emmc_dev}:1 ${fastboot_buffer} hello_world_test.bin ${fastboot_bytes}   #fatwrite write file into a dos filesystem "<interface> <dev[:part]> <addr> <filename> [<bytes> [<offset>]] - write file 'filename' from the address 'addr' in RAM  to 'dev' on 'interface' Note: The Cortex-M binary was named as hello_world_test.bin, but any example name may be used. At this point, in the script we will be using only uboot commands as seen above, in this case was fatwrite. The script will look as following: If the script is run now uboot (imx-boot-imx8mmevk-sd.bin-flash_evk), rootfs (imx-image-multimedia-imx8mmevk.wic) will be flashed and the Cortex-M binary (hello_world_test.bin) written to the FAT partition of the eMMC. To add environmental variables to modify uboot boot settings, i.e. overwrite the dtb variable so the EVK will select the RPMSG dtb, this in case the Cortex-M example needs to be run at the same time as Cortex-A. FB: ucmd setenv fdtfile imx8mm-evk-rpmsg.dtb Next add to the UUU script the set of uboot commands in form of environmental variables that will load to the TCM the Cortex-M binary   FB: ucmd setenv loadm4image "fatload mmc ${emmc_dev}:1 0x48000000 hello_world_test.bin; cp.b 0x48000000 0x7e0000 0x20000" FB: ucmd setenv m4boot "run loadm4image; bootaux 0x48000000" Note: This can be changed to load it to different targets not only TCM, for example DRAM. Now for the set of environmental variable to run when uboot starts booting into Linux we may add it to the variable mmcboot. Also adding the command to save the environmental variables set so the settings persist after reboot, this by adding the following commands to the script:   FB: ucmd setenv mmcboot "run m4boot; $mmcboot" FB: ucmd saveenv The resulting script will be the following: Now just save the script and name it as you see fit, for this example the name will be custom_script.auto.   Running the script To run a UUU script is pretty simple, just make sure that the files used in the script are in the same folder as the script. Windows > .\uuu.exe  custom_script.auto Linux $ sudo ./uuu custom_script.auto   Wait till it finish, turn the board off, set it to boot from eMMC and turn it on, the EVK will boot into Linux automatically and will launch the Cortex-M core automatically. We may also, double check that the environmental variables were written correctly by stopping at uboot and using the printenv command For this test I have used the Prebuilt image which includes sample Cortex-M4 examples for the EVK   further flexibility UUU scripts can be customized even more, for example using macros, so the script can take input arguments so it may be possible to select the uboot, rootfs, Cortex-M binary and dtb to be used when booting, and to be used for other i.MX chips as well. The resulting script will be as following: Note: Here is assumed that the dtb file is already at the FAT partition, if not same procedure may be added as the Cortex-M binary. To run a script which expect to have input arguments is as follow: Windows > .\uuu.exe -b uuu_cortexM_loader.auto imx-boot-imx8mmevk-sd.bin-flash_evk imx-image-multimedia-imx8mmevk.wic hello_world_test.bin imx8mm-evk-rpmsg.dtb Linux $ sudo ./uuu -b uuu_cortexM_loader.auto imx-boot-imx8mmevk-sd.bin-flash_evk imx-image-multimedia-imx8mmevk.wic hello_world_test.bin imx8mm-evk-rpmsg.dtb Please find both UUU scripts attached and feel free to use them. Hope this helps everyone to better understand how this tool works and the capabilities it have.

 

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. i.MX 6/7 Series Family DDR Tools Overview This page contains the latest releases for the i.MX 6/7 series DDR Tools. The tools described on this page cover the following i.MX 6/7 series SoCs: i.MX 6DQP (Dual/Quad Plus) i.MX 6DQ (Dual/Quad) i.MX 6DL/S (Dual Lite/Solo) i.MX 6SoloX i.MX 6SL i.MX 6SLL i.MX 6UL i.MX 6ULL/ULZ i.MX 7D/S i.MX 7ULP The purpose of the i.MX 6/7 series DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.). This process equips the user to then proceed with the bring-up of a boot loader and an OS. Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface. The i.MX 6/7 series DDR Tools consist of: DDR Register Programming Aid (RPA) DDR Stress test _________________________________________________________ i.MX 6/7 Series DDR Stress Test The i.MX 6/7 Series DDR stress test tool is a Windows-based software tool that is used as a mechanism to verify that the DDR initialization is operational prior for use in u-boot and OS bring-up. The DDR Stress Test tool can be found here: i.MX 6/7 DDR Stress Test Tool Note that the DDR Stress test tool supports all of the above i.MX SoCs, however, some of the supported i.MX SoCs named in the tool support multiple i.MX SoCs as follows: MX6DQ – when selected, this supports both i.MX 6DQ and i.MX 6DQP (Plus) MX6DL – when selected, this supports both i.MX 6DL and i.MX 6S (i.MX 6DLS family) MX6ULL – when selected, this supports both i.MX 6ULL and i.MX6 ULZ MX7D – when selected, this supports both i.MX 7D and i.MX 7S _____________________________________________________________________________ i.MX 6/7 Series DDR Register Programming Aid (RPA) The i.MX 6/7 series DDR RPA (or simply RPA) is an Excel spreadsheet tool used to develop DDR initialization for a user’s specific DDR configuration (DDR device type, density, etc.). The RPA generates the DDR initialization script for use with the DDR Stress Test tool. For a history of the previous versions of an RPA, refer to the Revision History tab of the respective RPA. To obtain the latest RPAs, please refer to the following links: i.MX 6DQP i.MX6DQP Register Programming Aids i.MX 6DQ i.MX6DQ Register Programming Aids i.MX 6DL/S i.MX6DL Register Programming Aids i.MX 6SoloX i.MX6SX Register Programming Aids i.MX 6SL i.MX6SL Register Programming Aids  i.MX6SLL i.MX6SLL Register Programming Aids i.MX 6UL/ULL/ULZ i.MX6UL/ULL/ULZ DRAM Register Programming Aids i.MX7D i.MX7D DRAM Register Programming Aids i.MX 7ULP i.MX7ULP DRAM Register Programming Aids _____________________________________________________________________________ DRAM Register Programming Aids FAQ    

  Question: How can we generate an ARM DS5 DStream format DDR initialization script using the DRAM Register Programming Aid?  Answer: Some RPAs include a  "DStream .ds file" tab for the ARM DS5 debugger specific commands. The i.MX6UL/ULL/ULZ DRAM Register Programming Aids for example already has this supported. However, the user can easily create  the .ds format from the existing .inc format. The basic steps to convert .inc files to .ds format are as follows: 1)  Replace the one instance of setmem /16 with mem set 2)  In that same line, replace 0x020bc000 = with 0x020bc000 16 3)  Use a Replace All command to change setmem /32 with mem set 4)  Use a Replace All command to change = with 32 5)  Use a Replace All command to change // with # 6)  Save as a .ds file.   Question: When using a 528MHz DRAM Controller interface with a DDR memory of a faster speed bin, which speed bin timing options should one use? Answer: For example, let’s assume our MX6DQ design is using a DDR3 memory from a DDR3-1600 speed bin.  However, the maximum speed of the MMDC interface for the MX6DQ using DDR3 is 528MHz.  Should we use the 1600 speed bin (800MHz clock speed) or the 1066 speed bin (533MHz clock speed)?  In short, the user should use the timings rated for the maximum speed (frequency) with which you are running, in this case DDR3-1066 (533MHz).  In some cases, like when using the MX6DL, the maximum DDR frequency is 400MHz.  In this case, you would want to try and use 800 timings found in the AC timing parameters table.  However, most DDR3 devices have speed bin tables that may go only as low as 1066, in which case you would use the closest speed bin to your operational frequency (i.e. the 1066 speed bin table).     Question: Some timing parameters may specify a min and max number, which should I use? Answer: In most cases, you will want to choose the minimum timings.  Some DRAM controllers may have a tRAS_MAX timing parameter, in which case you would obviously use the maximum tRAS parameter given in the DRAM data sheet. Also, for timing parameters tAONPD and tAOFPD, we also want to use the maximum values given in the DDR3 data sheet. These represent the maximum amount of time the DDR3 device takes to turn on or off the RTT (termination), therefore, we should wait at least this amount of time before issuing any commands or accesses.   Question: Some timing parameters state things like “Greater of 3CK or 7.5ns”; which should I use? Answer: This depends on your clock speed.  Say you are running at 533MHz.  At 533MHz, 7.5ns equates to 4CKs.  In this case, 7.5ns at 533MHz is GREATER than 3CK, so we would use the 7.5ns number, or 4CKs. At 400MHz, 7.5ns equates to 3CKs.  In this case, we’d simply use 3CKs.   Question: I have a design that will throttle the DDR frequency (dynamic frequency scaling).  At full speed, I plan to run at 533MHz, and then I plan to throttle down to say 400MHz whenever possible.  Do I need to re-calculate my 400 MHz timing parameters that were initially set for 533MHz? Answer: It is not necessary to re-calculate timing parameters for 400MHz, and you can re-use the ones for 533MHz.  The timings at 533 MHz are much tighter than 400 MHz, and the key here is to NOT violate timings.  Also, it may be a bit of a hassle maintaining two sets of timing parameters, especially if later in the design, you swap DDR vendors that might require you to re-calculate some timing parameters.  It’s easier to do it once and to come up with a combined worse-case timing parameters for 533MHz, which you know will work at 400MHz.  But, if you don’t mind maintaining two sets of timing parameters, and really want to optimize timings down to the last pico-second for 400MHz, then knock yourself out.   Question: Can I use these Register programming aids for both Fly by and T- Topology ? Answer Yes The DDR register programming aid is agnostic to the DDR layout. The same spreadsheet works for both topologies. We recommend running write leveling calibration for both topologies and the values returned by the Write Leveling routine from the Freescale DDR stress test should be incorporated back to the customer specific initialization script. The DDR stress test also has a feature whereby it evaluates the write leveling values returned from calibration and increments WALAT to 1 if the values exceed a defined limit. The DDR stress test informs the user when the Write Additional latency (WALAT) exceeds the limit and should be increased by 1, and reminds the user to add it back in the customer specific initialization script if required.   WALAT - 0 00000000 WALAT: Write Additional latency. Recommend to clear these bits. Proper board design should ensure that the DDR3 devices are placed close enough to the MMDC to ensure the skew between CLK and DQS is less than 1 cycle.     Question: Can I use the DEFAULT Register programming aid values for MDOR when using an Internal OSC instead of the recommended 32.768 KHZ XTAL ? Answer No, NXP recommends reprogramming these values based on the worse case frequency (Max clock) of the internal OSC of the device to guarantee JEDEC timings are met. Please refer to Internal Oscillator Accuracy considerations for the i.MX 6 Series for more details  

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 detailed programming aids for the registers associated with DRAM initialization (LPDDR3, DDR3, and LPDDR2). The last work sheet tab in the tool formats the register settings for use with the ARM DS5 debugger. It can also be used with the windows executable for the DDR Stress Test (note the removal of debugger specific commands in this tab). These programming aids were developed for internal NXP validation boards.   This tool serves as an aid to assist with programming the DDR interface of the MX7D and is based on the DDR initialization scripts developed for NXP boards and no guarantees are made by this tool.   The following are some general notes regarding this tool: The default configuration for the tool is to enable bank interleaving. Refer to the "How To Use" tab in the tool as a starting point to use this tool. The tool can be configured for one of the three memory types supported by the MX7D.  However, three separate programming aids are provided based on the DRAM type: LPDDR3, LPDDR2, and DDR3.  Therefore, you may use the tool pre-configured for your desired memory type as a starting point. The DRAM controller IP in MX7D is different from the MX6 series MMDC controller. Results from DRAM calibration may be updated for the following registers: DDR_PHY_OFFSET_WR_CON0 (0x30790030) and DDR_PHY_OFFSET_RD_CON0 (0x30790020).  Also, the MX7D memory map DRAM starting address is fixed at 0x80000000. Some of the CCM programming at the beginning of the DRAM initialization script (in the "DStream .ds file" tab) were automatically generated and in very few cases may involve writing to reserved bits, however, these writes to reserved bits are simply ignored. Note that in the "DStream .ds file" tab there are DS5 debugger specific commands that should be commented out or removed when using the DRAM initialization for non-debugger specific applications (like when porting to bootloaders). This tool may be updated on an as-needed basis for bug fixes or future improvements.  There is no schedule for aforementioned maintenance. For questions or additional assistance using this tool, please contact your local sales or FAE.

      The i.MX6UL/LL/LZ processor supports 2 USB OTG interfaces, USB OTG1 and USB OTG2, and each USB interface can be configured as a device, host or dual role mode. On the EVK board of i.MX6UL/LL, USB OTG1 is designed as dual role mode, and USB OTG2 is designed as HOST mode. This is sufficient for most customers.       However, in actual applications, we may need 2 USB HOSTs, and at the same time, we don’t want to use MicroUSB to USB TYPE-AF cable for Host-Device mode conversion. Therefore, the design of the USB circuit needs to meet such requirements: 1. USB device mode We need a USB device to download the linux image to the flash or SD card on the board. 2. 2 USB HOSTs When the system is working normally, we need the board to support 2 USB HOST. i.MX6UL/LL/LZ has only 2 USB ports. How to design to meet this requirement without increasing the USB HUB? The following scheme is used as a reference, and I hope it will be helpful to customers with similar requirement:        The logic and application description of this Diagram:: Default—device mode In the process of debugging the software, we need to use the USB OTG interface to download the linux image, so it must work in device mode. What we need to do is: (1). Pull USB OTG ID up to 3.3V (2). The USB OTG D+/D- signal is switched to the MicroUSB connector. (3). The USB OTG VBUS is provided with 5V power from the external PC USB HOST. Usage:        -Use a jumper for Pin 1 and Pin2, USB OTG ID pin will be pulled up to High.        With the operation, SEL pin of USB Muxer is High, and USB signals are switched to port B, and USB differential signals are connected to MicroUSB connector. At the same time, MIC2026-1YM output is disabled. The USB OTG1 VBUS pin of CPU is supplied by VBUS of MicroUSB connector, that is to say, supplied by PC USB HOST.        In this mode, software engineer can use it to download images to flash on board. Normal Work—Host mode After the software debugging is completed, two HOSTs are needed on the board. At this time, we need to switch the USB OTG1 from device to HOST mode. What we need to do is: (1). Pull USB OTG1 ID down to LOW (2). The USB OTG D+/D- signal is switched to the USB Type-AF connector. (3). Board should supply 5V power for USB device connected USB Type-AF connector. Usage:        -Use a jumper for Pin 2 and Pin3, USB OTG ID pin will be pulled down to Low.        With the operation, USB OTG1 ID pin is pulled down to Low, SEL pin of USB Muxer is also LOW, USB signals are switched to Port A, and connected to USB type-AF connector. At the same time, MIC2026-1YM is enabled , OUTA will output 5V , which will supply USB device connected on USB type-AF connector.   [Note] Users need to pay attention to. When using the jumper with PIN1/2/3, the board needs to be powered off. In other words, when switching between device and host, you need to switch off the power, then power on, and restart the board. The solution can also be used for i.MX processors with USB 2.0 interface.   NXP CAS team Wedong Sun 01/15/2021