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.  

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 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.

 

The document to descript change the u-boot environment variables under the Linux rootfs.  Also provide a demo on i.MX6ull evk of sdcard mirror.  Linux fw_printenv fw_setenv to access U-Boot's environment variables.pdf  --- the document fw_printenv_fw_setenv_demo_iMX6ullevk_L4.14.98_2.0.0_ga.sdcard  --- demo sdcard mirror

    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    

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

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

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

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.

  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. 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    

    The document is about how to use WSL2 to compile yocto(android is the same process)  

Host TFTP and NFS Configuration Now configure the Trivial File Transfer Protocol (TFTP) server and Networked File System (NFS) server. U-Boot will download the Linux kernel and dtb file using tftp and then the kernel will mount (via NFS) its root file system on the computer hard drive. 1. TFTP Setup   1.1.1 Prepare the TFTP Service   Get the required software if not already set up. On host for TFTP: Install TFTP on Host $ sudo apt-get install tftpd-hpa   (Note: There are a number of examples in various forums, etc, of how to automatically start the TFTP service - but not all are successful on all Linux distro's it seems! The following may work for you.)   Start the tftpd-hpa service automatically by adding a command to /etc/rc.local. $ vi /etc/rc.local   Now, just before the exit 0 line edit below command then Save and Exit. $ service tftpd-hpa start  Now, To control the TFTP service from the command line use: $ service tftpd-hpa restart    To check the status of the TFTP service from the command line use: $ service tftpd-hpa status   1.1.1 Setup the TFTP Directories Now, we have to create the directory which will contain the kernel image and the device tree blob file. $ mkdir -p /imx-boot/imx6q-sabre/tftp Then, copy the kernel image and the device tree blob file in this directory. $ cp {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/zImage /imx-boot/imx6q-sabre/tftp $ cp {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/<dtb file> /imx-boot/imx6q-sabre/tftp   OR we can use the default directory created by yocto {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/ The tftpd-hpa service looks for requested files under /imx-boot/imx6q-sabre/tftp The default tftpd-hpa directory may vary with distribution/release, but it is specified in the configuration file: /etc/default/tfptd-hpa. We have to change this default directory with our directory   Edit default tftp directory $ vi /etc/default/tftpd-hpa   Now, change the directory defined as TFTP_DIRECTORY with your host system directory which contains kernel and device tree blob file. Using created directory TFTP_DIRECTORY=”/imx-boot/imx6q-sabre/tftp” OR Using Yocto directory path TFTP_DIRECTORY=”{YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}” Restart the TFTP service if required $ service tftpd-hpa restart   1.2 NFS Setup 1.2.1 Prepare the NFS Service Get the required software if not already set up. On host for NFS: Install NFS on Host $ sudo apt-get install nfs-kernel-server The NFS service starts automatically. To control NFS services : $ service nfs-kernel-server restart To check the status of the NFS service from the command line : $ service nfs-kernel-server status 1.2.2 Setup the NFS Directories Now, we have to create the directory which will contain the root file system. $ mkdir -p /imx-boot/imx6q-sabre/nfs   Then, copy the rootfs in this directory. $ cp -R {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs/* /imx-boot/imx6q-sabre/nfs   OR we can use the default directory created by yocto. $ {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs 1.2.3 Update NFS Export File The NFS server requires /etc/exports to be configured correctly to access NFS filesystem directory to specific hosts. $ vi /etc/exports Then, edit below line into the opened file. <”YOUR NFS DIRECTORY”> <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Ex. If you created custom directory for NFS then, /imx-boot/imx6q-sabre/nfs <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Ex: /imx-boot/imx6q-sabre/nfs 192.168.*.*(rw,sync,no_root_squash,no_subtree_check) OR /{YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check)   Now, we need to restart the NFS service. $ service nfs-kernel-server restart   2 Target Setup   We need to set up the network IP address of our target. Power On the board and hit a key to stop the U-Boot from continuing. Set the below parameters, setenv serverip 192.168.0.206       //This must be your Host IP address The path where the rootfs is placed in our host has to be indicated in the U-Boot, Ex. // if you choose default folder created by YOCTO setenv nfsroot /{YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs   OR // if you create custom directory for NFS setenv nfsroot /imx-boot/imx6q-sabre/nfs Now, we have to set kernel image name and device tree blob file name in the u-boot, setenv image < zImage name > setenv fdt_file <dtb file name on host> Now, set the bootargs for the kernel boot, setenv netargs 'setenv bootargs console=${console},${baudrate} ${smp} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp' Use printenv command and check loadaddr and fdt_addr environment variables variables for I.MX6Q SABRE, loadaddr=0x12000000 fdt_addr=0x18000000   Also, check netboot environment variable. It should be like below, netboot=echo Booting from net ...; run netargs; if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; ${get_cmd} ${image}; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if ${get_cmd} ${fdt_addr} ${fdt_file}; then bootz ${loadaddr} - ${fdt_addr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi; Now, set environment variable bootcmd to boot every time from the network, setenv bootcmd run netboot Now finally save those variable in u-boot: saveenv Reset your board; it should now boot from the network: U-Boot 2016.03-imx_v2016.03_4.1.15_2.0.0_ga+ga57b13b (Apr 17 2018 - 17:13:43 +0530)  (..) Net:   FEC [PRIME] Normal Boot Hit any key to stop autoboot:  0   Booting from net ... Using FEC device TFTP from server 192.168.0.206; our IP address is 192.168.3.101 Filename 'zImage'. Load address: 0x12000000 Loading: #################################################################         #################################################################         #################################################################         #################################################################         #################################################################         #################################################################         ###########################################################         2.1 MiB/s done Bytes transferred = 6578216 (646028 hex) Using FEC device TFTP from server 192.168.0.206; our IP address is 192.168.3.101 Filename 'imx6q-sabresd.dtb'. Load address: 0x18000000 Loading: ####         1.8 MiB/s done Bytes transferred = 45893 (b345 hex) Kernel image @ 0x12000000 [ 0x000000 - 0x646028 ] ## Flattened Device Tree blob at 18000000   Booting using the fdt blob at 0x18000000   Using Device Tree in place at 18000000, end 1800e344 switch to ldo_bypass mode!   Starting kernel ...

meta-avs-demos Yocto layer meta-avs-demos is a Yocto meta layer (complementary to the NXP BSP release for i.MX) published on CodeAurora that includes the additional required packages to support  Amazon's Alexa Voice Services SDK (AVS_SDK) applications. The build procedure is the described on the README.md of the corresponding branch. We have 2 fuctional branches now: imx-alexa-sdk: Support for Morty based i.mx releases imx7d-pico-avs-sdk_4.1.15-1.0.0: legacy support for Jethro releases The master branch is only used to collect manifest files, that used with repo init/sync commands will fetch the whole environment for the 2 special supported boards: i.MX7D Pico Pi and i.MX8M EVK. However the meta-avs-demos can be used with any i.MX board either. Recipes to include Amazon's Alexa Voice Services in your applications. The meta-avs-demos provides the required recipes to build an i.MX image with the support for running Alexa SDK. The imx-alexa-sdk branch is based on Morty and kernel 4.9.X and it supports the next builds: i.MX7D Pico Pi i.MX8M EVK Generic i.MX board For the i.MX7D Pico Pi and i.MX8M EVK there is an extended support for additional (external) Sound Cards like: TechNexion VoiceHat: 2Mic Array board with DSPConcepts SW support Synaptics Card: 2 Mic with Sensory WakeWord support The Generic i.MX is for any other regular i.MX board supported on the official NXP BSP releases. Only the default soundcard (embedded) on the board is supported. Sensory wakeword is currently only enabled for those with ARMV7 architecture. To support any external board like the VoiceHat or Synaptics is up to the user to include the additional patches/changes required. Build Instructions Follow the corresponding README file to follow the steps to build an image with Alexa SDK support README-IMX7D-PICOPI.md README-IMX8M-EVK.md README-IMX-GENERIC.md

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343576 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343372 

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

The i.MX Android N7.1.1_1.0.0 release is now available on Web Site (i.MX6 BSP Updates and Releases -> Android).   Files available: # Name Description 1 android_N7.1.1_1.0.0_docs.tar.gz i.MX Android N7.1.1_1.0.0 BSP Documentation 2 android_N7.1.1_1.0.0_source.tar.gz Source Code of Android N7.1.1_1.0.0 BSP (4.1 kernel) for i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo  i.MX 6Sololite, i.MX6SX and i.MX7D 3 android_N7.1.1_1.0.0_image_6dqpsabreauto.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE for Automotive Infotainment based on i.MX 6QuadPlus, i.MX 6Quad, and i.MX 6DualLite 4 android_N7.1.1_1.0.0_image_6dqpsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Platform and SABRE Board based on i.MX 6QuadPlus, i.MX 6Quad and i.MX 6DualLite. 5 android_N7.1.1_1.0.0_image_6slevk.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - i.MX 6Sololite evaluation kit. 6 android_N7.1.1_1.0.0_image_6sxsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Board based on i.MX 6SoloX 7 android_N7.1.1_1.0.0_image_6sxsabreauto.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE for Automotive infotainment based on i.MX 6SoloX 8 android_N7.1.1_1.0.0_image_7dsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Board based on i.MX 7Dual 9 android_N7.1.1_1.0.0_tools.tar.gz Manufacturing Toolkit and VivanteVTK for N7.1.1_1.0.0   Supported Hardware SoC/Boards: MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-SD board and platform MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-AI board and platform MX 6SoloLite EVK platform MX 6SoloX SABRE-SD board and platforms MX 6SoloX SABRE-AI board and platforms MX 7Dual SABRE-SD board and platform   Changes: Compared to the M6.0.1_2.1.0 release, this release has the following major changes: Upgraded the Android platform version to Android 7.1. Upgraded the U-Boot and Linux Kernel Code base from the L4.1.15_1.0.0 release to the L4.1.15_1.2.0-ga release. Added support for the i.MX 7Dual SABRE-SD board. Upgraded the GPU driver from 5.0.11p8 to 6.2.0.p2.   Feature: For features please consult the release notes.   Known issues For known issues and more details please consult the Release Notes.