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

Tested on Android 10 (android_Q10.0.0_1.0.0) After your the first BSP build the kernel sources are at: ${MY_ANDROID}/vendor/nxp-opensource/kernel_imx/ For the i.MX8M Mini, You can check the defconfig files being used on: ${MY_ANDROID}/device/fsl/imx8m/evk_8mm/UbootKernelBoardConfig.mk # imx8mm kernel defconfig TARGET_KERNEL_DEFCONFIG := android_defconfig TARGET_KERNEL_ADDITION_DEFCONF := android_addition_defconfig You could change one of them to add the desired configuration. - android_defconfig - is ${MY_ANDROID}/vendor/nxp-opensource/kernel_imx/arch/arm64/configs/android_defconfig - android_addition_defconfig - is on the same folder ${MY_ANDROID}/device/fsl/imx8m/evk_8mm/ "merge_config.sh" is called to generate the final defconfig file prior to building the kernel Check out: https://source.android.com/devices/architecture/kernel/config For example, I want to add DEVMEM support on my build: 1. Change the defconfig I add the line below to android_addition_defconfig CONFIG_DEVMEM=y (Or could have added it android_defconfig) 2. Build the kernel ./imx-make.sh kernel -c -j8 3. Verify your change After compiling, you can confirm your change by reading: ${MY_ANDROID}/out/target/product/evk_8mm/obj/KERNEL_OBJ/.config Then rebuild boot.img and reprogram the target.

Inside IPU there are two block where color space conversion can be made: IC (Image Converter) and DP (Display processor). On Linux, the CSC parameters are located at IPU (IC and DP) drivers, linux/drivers/mxc/ipu3 folder. All negative coefficients are represented using two's complement. Linux Image Converter driver: The parameters are set on function _init_csc: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/mxc/ipu3/ipu_ic.c?h=imx_3.14.28_1.0.0_ga static void _init_csc(struct ipu_soc *ipu, uint8_t ic_task, ipu_color_space_t in_format, ipu_color_space_t out_format, int csc_index) { /* * Y = 0.257 * R + 0.504 * G + 0.098 * B + 16; * U = -0.148 * R - 0.291 * G + 0.439 * B + 128; * V = 0.439 * R - 0.368 * G - 0.071 * B + 128; */ static const uint32_t rgb2ycbcr_coeff[4][3] = { {0x0042, 0x0081, 0x0019}, {0x01DA, 0x01B6, 0x0070}, {0x0070, 0x01A2, 0x01EE}, {0x0040, 0x0200, 0x0200}, /* A0, A1, A2 */ }; /* transparent RGB->RGB matrix for combining */ static const uint32_t rgb2rgb_coeff[4][3] = { {0x0080, 0x0000, 0x0000}, {0x0000, 0x0080, 0x0000}, {0x0000, 0x0000, 0x0080}, {0x0000, 0x0000, 0x0000}, /* A0, A1, A2 */ }; /* R = (1.164 * (Y - 16)) + (1.596 * (Cr - 128));   G = (1.164 * (Y - 16)) - (0.392 * (Cb - 128)) - (0.813 * (Cr - 128));   B = (1.164 * (Y - 16)) + (2.017 * (Cb - 128); */ static const uint32_t ycbcr2rgb_coeff[4][3] = { {149, 0, 204}, {149, 462, 408}, {149, 255, 0}, {8192 - 446, 266, 8192 - 554}, /* A0, A1, A2 */ }; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Linux Display Processor driver: The parameters are set on constants (rgb2ycbcr_coeff and ycbcr2rgb_coeff): http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/mxc/ipu3/ipu_disp.c?h=imx_3.14.28_1.0.0_ga /* Y = R * 1.200 + G * 2.343 + B * .453 + 0.250;   U = R * -.672 + G * -1.328 + B * 2.000 + 512.250.;   V = R * 2.000 + G * -1.672 + B * -.328 + 512.250.;*/ static const int rgb2ycbcr_coeff[5][3] = { {0x4D, 0x96, 0x1D}, {-0x2B, -0x55, 0x80}, {0x80, -0x6B, -0x15}, {0x0000, 0x0200, 0x0200}, /* B0, B1, B2 */ {0x2, 0x2, 0x2}, /* S0, S1, S2 */ }; /* R = (1.164 * (Y - 16)) + (1.596 * (Cr - 128));   G = (1.164 * (Y - 16)) - (0.392 * (Cb - 128)) - (0.813 * (Cr - 128));   B = (1.164 * (Y - 16)) + (2.017 * (Cb - 128); */ static const int ycbcr2rgb_coeff[5][3] = { {0x095, 0x000, 0x0CC}, {0x095, 0x3CE, 0x398}, {0x095, 0x0FF, 0x000}, {0x3E42, 0x010A, 0x3DD6}, /*B0,B1,B2 */ {0x1, 0x1, 0x1}, /*S0,S1,S2 */ };‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

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.

The purpose of this document is to provide extended guidance for the selection of compatible LPDDR4/4X memory devices that are supported by the i.MX 93 series of processors. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs. The i.MX 93 series of processors supports different packages, and each have their own maximum supported LPDDR4/4x data rates. Please refer to the respective datasheets. Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. NOTE: Some of the LPDDR4/4X devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low-speed operation is planned in the use case, please consult with the memory vendor about the configuration aspects and possible customization of the memory device so correct functionality is ensured. LPDDR4/4X - Maximum Supported Densities SoC Max Data bus width Maximum density Assumed memory organization Notes i.MX 93 (i.MX 93xx) 16-bit 16 Gb / (2 GB) single rank, single channel device with 17-row addresses (R0 - R16) 1, 2, 3   LPDDR4/4X - List of Validated Memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Memory Vendor Validated Memory Part# Notes i.MX 93 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G16D1FW-046 AAT:A  (Z32N) MT53E1G16D1ZW-046 AAT:C (Z42N) 7   4, 8 8 Gb/ (1 GB) Micron LPDDR4/4x: MT53D512M16D1DS-046 AAT (Z11M) 4, 10 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G32D2FW-046 AUT:B (Z42M) 4, 5, 10 8 Gb/ (1 GB) Nanya LPDDR4: NT6AN512M16AV-J1I LPDDR4x: NT6AP512M16BV-J1I 4, 8 4 Gb/ (512 MB) Nanya LPDDR4x: NT6AP256M16AV  4, 8 16 Gb/ (2 GB) Kingston LPDDR4: D1611PM3BDGUI-U 4, 8 16 Gb/ (2 GB) Kingston LPDDR4: C1612PC2WDGTKR-U  7, 9 4 Gb/ (512 MB) ISSI LPDDR4: IS43LQ16256B-062BLI 4, 8 2Gb / (256 MB) ISSI LPDDR4: IS43LQ16128A-062BSLI 4, 6, 8   8 Gb/ (1 GB) CXMT LPDDR4/4x: CXDB4CBAM-EA-M 4, 9 16 Gb/ (2 GB) JSC LPDDR4x: JSL4BAG167ZAMF  4, 8 8 Gb/ (1 GB) JSC LPDDR4x: JSL4B8G168ZAMF-05x  4, 8 4 Gb/ (512 MB) JSC LPDDR4x: JSL4A4G168ZAMF-05 4, 8 2Gb / (256 MB) Winbond  LPDDR4x: W66BQ6NBHAGJ 4, 6, 8 8Gb / (1 GB) IM (Intelligent Memory) LPDDR4x: IM8G16L4JCB-046I 4, 11 16Gb / (2 GB) IM (Intelligent Memory) LPDDR4/4x: IMAG16L4KBBG 4, 8 4Gb / (512 MB) Samsung LPDDR4: K4F4E164HD-THCL 4, 8 8 Gb / (1 GB) AM (Alliance Memory) LPDDR4X: AS4C512M16MD4V-053BIN 4, 8 4 Gb / (512 MB) ISSI LPDDR4/4X: IS43LQ16256B-053BLI 4, 8 8 Gb / (1 GB) ISSI LPDDR4/4X: IS46LQ16512B-046BLA2 4, 8 32 Gb / (4GB) 16 Gb / (2Gb) usable by i.MX93 ISSI LPDDR4/4X: IS46LQ32K01B-046BLI 4, 8   Note 1: The numbers are based purely on the IP documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, SoC reference manual and on the JEDEC standards JESD209-4B/JESD209-4-1 (LPDDR4/4X). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4/4X devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The SoC also supports dual rank single channel devices therefore, 16Gb/2GB density can be also achieved by using a dual rank single channel device with 16-row addresses (R0 - R15). Note 4: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 5: This is a dual channel x32 device. Since i.MX93 only supports 16-bit LPDDR4/X data bus, it can only interface with one of the channels and therefore, utilize only half of the device's density. As indicated in the table - the device has 32Gb/4GB density however, only 16Gb/2GB can be used. There is no functional problem with using only one channel of a dual channel device as the channels are independent in LPDDR4/4X.  Note 6: This is a new JEDEC 100 ball package, half the size of the standard 200 ball package. This 100 ball package has the same performance and functionality as the 200 ball package, and has the added advantage of being smaller and cheaper than the standard package. Note 7: This device has been EoLed by the manufacturer and has been updated by a new memory part number  Note 8: Part is active. Reviewed Nov 2025 Note 9: Part is obsolete. Note 10: This device will be EoLed in Q2 24 by the manufacturer and will not be updated by a new memory part number Note 11: DQ eye marginalities were identified during TSA analysis. vTSA and stability testing did not identify any issues.

It is based on L3.0.35_GA4.1.0 BSP.   In default Linux BSP, there are 3 kinds of de-interlace mode, motion =0,1,2 mode, motion mode 0 and 1 will use three fields for de-interlace, and motion mode 2 wil use one field for de-interlace, so the whole fps is 30. In this mode, for motion mode 0 and 1, field 1,2,3 was used for first VDI output frame of display; and field 3,4,5 was used for second VDI output frame of display; field 5,6,7 was used for third VDI output frame of display. One field data (such as 2,4,6) was used only once, so there is data lost.   After applied these patches, the VDI de-interlace output will be 60fps: for motion mode 0 and 1, field 0,1,2 was used for first VDI output frame of display; and field 1,2,3 was used for second VDI output frame of display; field 2,3,4 was used for third VDI output frame of display. So all field data will be used twice, there is no video data lost, the VDI quality was improved.   Kernel patches: 0001-Add-MEM-to-VDI-to-MEM-support-for-IPU.patch 0002-Add-IPU-IC-memcpy-support.patch 0003-IPU-VDI-support-switch-odd-and-even-field-in-motion-.patch 0004-IPU-VDI-correct-vdi-top-field-setting.patch   mxc_v4l2_tvin_imx6_vdi_60fps.zip: this is the test application sample code.   Test commands, parameter "-vd" means double fps VDI: ./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 720 -oh 480 -m 0 -vd  

Here we show how to generate a minimal root filesystem fairly quickly with BusyBox, for the i.MX6 sabre sd platform. This document assumes you are able to boot a Linux kernel on your platform already. See this post for details on how to do it. This implies you already have a "working" Linux development environment with some ARM cross-compilers at hand (e.g. Debian + Emdebian). busybox is so small that we will go for a ramdisk as our main root filesystem. Get busybox sources We will use git to fetch busybox sources:   $ git clone git://git.busybox.net/busybox This should create a busybox directory with all the latest sources. Note that for more stability you might want to checkout a release instead of the latest version; to do so, list the available release tags with e.g. git tag -l, and git checkout <the-desired-tag>. Compile Assuming your cross compiler is called e.g. arm-linux-gnueabihf-gcc, you can compile by doing:   $ cd busybox   $ export ARCH=arm   $ export CROSS_COMPILE=arm-linux-gnueabihf-   $ make defconfig   $ sed -i.orig 's/^#.*CONFIG_STATIC.*/CONFIG_STATIC=y/' .config   $ make   $ make install This should create an _install folder hierarchy containing binaries and links. Note that we force the build of a static binary with the sed command. Configure the root filesystem We need to add some more configuration into the _install folder before we can call it a minimal filesystem. Create some folders We need to create some mountpoints and folders:   $ mkdir _install/dev   $ mkdir _install/proc   $ mkdir _install/sys   $ mkdir -p _install/etc/init.d Add some configuration files and scripts We need to prepare the main init configuration file, _install/etc/inittab, with this contents:   ::sysinit:/etc/init.d/rcS   ::askfirst:/bin/sh   ::ctrlaltdel:/sbin/reboot   ::shutdown:/sbin/swapoff -a   ::shutdown:/bin/umount -a -r   ::restart:/sbin/init This is very close to the default behavior busybox init has with no inittab file. It just suppresses some warnings about missing tty. We need to add some more configuration to mount a few filesystems at boot for convenience. This is done with an _install/etc/fstab file containing:   proc     /proc proc     defaults 0 0   sysfs    /sys  sysfs    defaults 0 0   devtmpfs /dev  devtmpfs defaults 0 0 We also need to actually trigger the mount in the _install/etc/init.d/rcS script, which is called from the inittab. It should contain:   #!/bin/sh   mount -a And we need to make it executable:   $ chmod +x _install/etc/init.d/rcS Generate the ramdisk contents Now that we have adapted the root filesystem contents, we can generate a busybox ramdisk image for u-boot with the following commands:   $ (cd _install ; find |cpio -o -H newc |gzip -c > ../initramfs.cpio.gz)   $ mkimage -A arm -T ramdisk -d initramfs.cpio.gz uInitrd This results in a uInitrd file, suitable for u-boot. Prepare a boot script The default u-boot commands are not sufficient to boot our system, so we need to edit a boot.txt file with the following contents:   run loaduimage   run loadfdt   setenv rdaddr 0x13000000   fatload mmc ${mmcdev}:$mmcpart $rdaddr uInitrd   setenv bootargs console=${console},${baudrate} rdinit=/sbin/init   bootm $loadaddr $rdaddr $fdt_addr Then we generate a boot.scr script, which can be loaded by u-boot with:   $ mkimage -A arm -T script -d boot.txt boot.scr Put on SD card Assuming you have prepared your SD card with u-boot and Linux as explained in this post, you have a single FAT partition on your card with your kernel and dtb. Our boot script and ramdisk image should be copied alongside:   $ mount /dev/<your-sd-card-first-partition> /mnt   $ cp uInitrd boot.scr /mnt/   $ umount /mnt Your SD card first partition is typically something in /dev/sd<X>1 or /dev/mmcblk<X>p1. Note that you need write permissions on the SD card for the command to succeed, so you might need to su - as root, or use sudo, or do achmod a+w as root on the SD card device node to grant permissions to users. Boot! Your SD card is ready for booting. Insert it in the SD card slot of your i.MX6 sabre sd platform, connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data and power up the platform. Your busybox system should boot to a prompt:   ...   Freeing unused kernel memory: 292K (806d5000 - 8071e000)   Please press Enter to activate this console. After pressing enter you should have a functional busybox shell on the target. Enjoy! See also... For a more featured root filesystem you might want to try a Debian filesystem in a second SD card partition, as explained in this post, or generate your filesystem with Buildroot. If you plan to compile busybox often, you might want to use a C compiler cache; see this post.

Debian is a free to use and redistribute Linux distribution that is widely used by the community for industrial and desktop applications.  This distribution started in 1993 as Debian Project with Ian Murdock inviting developers to contribute in one of the first Linux distributions.  Debian takes an important role in Linux world with a clear idea about be a full featured and free distribution with over than 59,000 packages provided as a free to use and distribute that supports a wide range of functionalities.  Currently, Debian 12 supports 9 architectures which makes it in a universal operating system that can be implemented in embedded systems, desktops or servers.  Finally, Debian has been an inspiration for well-known Linux distributions such as Kali and Ubuntu.  In this guide we will check the installation process of Debian 12 for NXP microprocessors i.MX family, specifically for i.MX8M Mini, i.MX8M Nano, i.MX8M Plus and i.MX93.  For this purpose, we divided the document in the following topics: Hardware Requirements Software Requirements Host Preparation SD Card Preparation Copying Bootloader  Copying Kernel and DTB files Debian Installation Configure Base System Boot your target References   Hardware Requirements Linux Host computer (Ubuntu 20.04 or later) USB Card reader or Micro SD to SD adapter SD Card Evaluation Kit Board for the i.MX8M Nano, i.MX8M Mini, i.MX8M Plus or i.MX93   Software Requirements Linux Ubuntu (20.04 and 24.04 tested) or Debian for host BSP version 6.1.55 for your specific target (Embedded Linux for i.MX Applications Processors | NXP Semiconductors)   Host Preparation For Debian installation we will require some specific packages for host.  You can download the packages using the following command: $ sudo apt install debian-archive-keyring debootstrap qemu-user-static We must validate the key to verify the archive using the command: $ sudo apt-key add /usr/share/keyrings/debian-archive-keyring.gpg If running an older release you need to get the unstable keyring package (because the version in your release is probably too old to have the current key) $ wget http://ftp.debian.org/debian/pool/main/d/debian-archive-keyring/debian-archive-keyring_2023.4_all.deb $ sudo dpkg -i debian-archive-keyring_2023.4_all.deb   SD Card Preparation The Linux kernel running on the Linux host assigns a device node to the SD/MMC card reader. The kernel might decide the device node name or udev rules might be used. In the following instructions, it is assumed that udev is not used. To identify the device node assigned to the SD/MMC card, carry out the following command: $ cat /proc/partitions   Partitioning the SD card On most Linux host operating systems, the SD card is mounted automatically upon insertion. Therefore, before running fdisk, make sure that the SD card is unmounted if it was previously mounted (through sudo umount /dev/sdx). Start by running fdisk with root permissions. Use the instructions above to determine the card ID. We are using sdx as an example. $ sudo fdisk /dev/sdx  Type the following parameters (each followed by <ENTER>): $fdisk: p # lists the current partitions $fdisk: d # to delete existing partitions. Repeat this until no unnecessary partitions $fdisk: n # create a new partition $fdisk: p # create a primary partition - use for both partitions $fdisk: 1 # the first partition $fdisk: 20480 # starting at offset sector $fdisk: 1024000 # ending position of the first partition to be used for the boot Images $fdisk: p # to check the partitions $fdisk: n # create a new partition $fdisk: p # create a primary partition $fdisk: 2 # the second partition $fdisk: 1228800 # starting at offset sector, which leaves enough space for the kernel, the bootloader and its configuration data $fdisk: <enter> # using the default value will create a partition that extends to the last sector of the media $fdisk: p # to check the partitions $fdisk: w # this writes the partition table to the media and fdisk exits   Copying Bootloader and Kernel In this section we will copy the bootloader and kernel image to SD card.  First, we can create a new directory to unzip the BSP downloaded from the NXP site.  $ mkdir debian-imx $ cd debian-imx $ unzip ~/Downloads/LF_v6.1.55-2.2.0_images_<board>.zip Where board is: IMX8MPEVK IMX8MNEVK IMX8MMEVK IMX93EVK Then, copy the U-Boot image. $ sudo dd if=<U-Boot_image> of=/dev/sdx bs=1k seek=<offset> conv=fsync Where offset is: 33 - for i.MX 8M Mini 32 - for i.MX 8M Nano, i.MX 8M Plus, and i.MX 9 The sectors of SD/eMMC before the “offset” KB are reserved. It may include the partition table.   Copying Kernel image and DTB files This section describes how to load the kernel image and DTB. The pre-built SD card image uses the VFAT partition for storing kernel image and DTB, which requires a VFAT partition that is mounted as a Linux drive, and the files are copied into it. This is the preferred method. Default: VFAT partition Format partition 1 on the card as VFAT with this command: $ sudo mkfs.vfat /dev/sdx1 Mount the formatted partition with this command: $ mkdir mountpoint $ sudo mount /dev/sdx1 mountpoint Copy the zImage and *.dtb files to the mountpoint by using cp. The device tree names should match $ sudo cp *.dtb mountpoint/ $sudo cp Image-<board_name>.bin mountpoint/Image Where board_name is: imx8mpevk imx8mnevk imx8mmevk imx93evk the one used by the variable specified by U-Boot. Unmount the partition with this command: $ sudo umount mountpoint   Debian Installation For Debian installation we will use the official tool debootstrap. This tool allows us to install Debian without a disk and run the system using qemu in a different architecture.  Before using debootstrap tool we need to format and mount the second partition of the SD card with the commands below: $ sudo mkfs.ext4 /dev/sdx2 $ sudo mount /dev/sdx2 mountpoint/ debootstrap can download the needed files directly from the archive when you run it. You can substitute any Debian archive mirror for http.us.debian.org/debian in the command below, preferably a mirror close to you network-wise. Mirrors are listed at http://www.debian.org/mirror/list $ sudo debootstrap --arch arm64 --foreign bookworm mountpoint/ http://ftp.debian.org/debian This step takes a while and depends on the resources of your host machine.   Configure Base System Now you’ve got a real Debian system, though rather lean, on disk. chroot into it: $ sudo cp /usr/bin/qemu-aarch64-static mountpoint/usr/bin $ sudo LANG=C.UTF-8 chroot mountpoint/ qemu-aarch64-static /bin/bash After chrooting you may need to set the terminal definition to be compatible with the Debian base system, for example: $ export TERM=xterm-color we need to finish the multi-stage boot strap $ /debootstrap/debootstrap --second-stage At this point /dev/ only contains very basic device files. For the next steps of the installation, additional device files may be needed. There are different ways to go about this and which method you should use depends on the host system you are using for the installation, whether you intend to use a modular kernel or not, and whether you want to use dynamic (e.g. using udev) or static device files for the new system. A few of the available options are: install the makedev package, and create a default set of static device files using (after chrooting) $ apt install makedev $ mount none /proc -t proc $ cd /dev $ MAKEDEV generic With these next steps we will be setting up the Debian system:   Setting fstab FSTAB is a configuration table designed to ease the burden of mounting and unmounting file systems to a machine. $ nano /etc/fstab # stock fstab - you probably want to override this with a machine specific one /dev/root / auto defaults 1 1 proc /proc proc defaults 0 0 devpts /dev/pts devpts mode=0620,ptmxmode=0666,gid=5 0 0 tmpfs /run tmpfs mode=0755,nodev,nosuid,strictatime 0 0 tmpfs /var/volatile tmpfs defaults 0 0 # uncomment this if your device has a SD/MMC/Transflash slot #/dev/mmcblk0p1 /media/card auto defaults,sync,noauto 0 0   Setting Timezone The following command allows you to choose your timezone. $ dpkg-reconfigure tzdata   Configure apt Debootstrap will have created a very basic /etc/apt/sources.list that will allow installing additional packages. However, you may want to add some additional sources, for example for source packages and security updates: $ nano /etc/apt/sources.list deb http://deb.debian.org/debian bookworm main non-free-firmware deb-src http://deb.debian.org/debian bookworm main non-free-firmware deb http://deb.debian.org/debian-security/ bookworm-security main non-free-firmware deb-src http://deb.debian.org/debian-security/ bookworm-security main non-free-firmware deb http://deb.debian.org/debian bookworm-updates main non-free-firmware deb-src http://deb.debian.org/debian bookworm-updates main non-free-firmware Make sure to run the apt update after you have made changes to the sources list   Configure locales and keyboard To configure your locale settings to use a language other than English, install the locales support package and configure it. Currently, the use of UTF-8 locales is recommended. $ apt install locales $ dpkg-reconfigure locales To configure your keyboard (if needed): $ apt install console-setup $ dpkg-reconfigure keyboard-configuration Note that the keyboard cannot be set while in the chroot, but will be configured for the next reboot   Adding Users $ apt install sudo $ adduser imx $ usermod -aG sudo imx $ nano /etc/sudoers imx ALL=(ALL:ALL) ALL   Tasksel Installation As mentioned earlier, the installed system will be very basic. If you would like to make the system a bit more mature, there is an easy method to install all packages with “standard” priority: $ tasksel install standard $ apt clean $ exit $ sudo umount mountpoint/ $sync   Boot your target Now, you can boot your target from your SD Card. (Review your specific target documentation)   Configure Networking (after booting target) Based on Debian official documentation for new systems the common names for network interfaces such as eth0 or wlan0 are not used. Therefore, we will need to list the interfaces using: $ ls /sys/class/net To have ethernet connection we will need to create a file in the path etc/network/. $ sudo nano etc/network/interfaces Type the following commands on the file: auto lo iface lo inet loopback auto end0 iface end0 inet dhcp   Install Neofetch (Optional) $ apt install neofetch   Outputs  Debian 12 running on i.MX8MP Debian 12 running on i.MX93   References Chapter 1. Definitions and overview. (2021, January). Retrieved May 30, 2024, from https://www.debian.org/doc/manuals/debian-faq/basic-defs.en.html Debian GNU/Linux Installation Guide. (2024). https://www.debian.org/releases/stable/i386/install.en.pdf Arm64Port. (n.d.). https://wiki.debian.org/Arm64Port i.MX Linux User's Guide (nxp.com)

This is a detailed programming aid for the registers associated with i.MX 8MNano (m815S) DDR initialization.  For more details, refer to the main mScale DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/1104467 Please note that this page is only intended to store the RPA spreadsheets. For questions, please create a new community thread.

GStreamer has a simple feature to enable tracing, allowing the developer to do basic debugging. These can be done in two ways: Adding the parameter --gst-debug=LIST to the pipeline (a pipeline is a executed gst-launch command) Prepending the environment variable GST_DEBUG=LIST' LIST is a a comma-separated argument, indicating the GStreamer elements to trace. For example, if one needs to trace the sink element      $ GST_DEBUG=*sink*:5 gst-launch playbin2 uri=file:///sample.avi or      $ gst-launch playbin2 uri=file:///sample.avi --gst-debug=*sink*:5 Both commands produces the same log. In case want to trace for than one element, so can simple add the <element>:5, for example      $ GST_DEBUG=mfw_v4lsink:5,vpudec:5 gst-launch playbin2 uri=file:///sample.avi The number 5 indicates the log category, where 5 is the highest (the most verbose log you can get) and 0 produces no output (5=LOG, 4=DEBUG, 3=INFO, 2=WARN, 1=ERROR). Log can be huge in each pipeline run. One way to filter it is using the grep command. Before grepping, one needs to redirect the standard error to the standard output (GStreamer log goes always to stderr), so      $ GST_DEBUG=mfw_v4lsink:5,vpudec:5 gst-launch playbin2 uri=file:///sample.avi 2>&1 | grep <filter string> In case the log needs to be shared, it is important to remove the 'color' of the log, again, one just needs to add the parameter --gst-debug-no-color or prepend the env variable GST_DEBUG_NO_COLOR=1 ----- More shell variables that GStreamer react, can be found here https://developer.gnome.org/gstreamer/0.10/gst-running.html

In this article, some experiments are done to verify the capability of i.MX6DQ on video playback under different VPU clocks. 1. Preparation Board: i.MX6DQ SD Bitstream: 1080p sunflower with 40Mbps, it is considered as the toughest H264 clip. The original clip is copied 20 times to generate a new raw video (repeat 20 times of sun-flower clip) and then encapsulate into a mp4 container. This is to remove and minimize the influence of startup workload of gstreamer compared to vpu unit test. Kernels: Generate different kernel with different VPU clock setting: 270MHz, 298MHz, 329MHz, 352MHz, 382MHz. test setting: 1080p content decoding and display with 1080p device. (no resize) 2. Test command for VPU unit test and Gstreamer The tiled format video playback is faster than NV12 format, so in below experiment, we choose tiled format during video playback. Unit test command: (we set the frame rate -a 70, higher than 1080p 60fps HDMI refresh rate)     /unit_tests/mxc_vpu_test.out -D "-i /media/65a78bbd-1608-4d49-bca8-4e009cafac5e/sunflower_2B_2ref_WP_40Mbps.264 -f 2 -y 1 -a 70" Gstreamer command: (free run to get the highest playback speed)     gst-launch filesrc location=/media/65a78bbd-1608-4d49-bca8-4e009cafac5e/sunflower_2B_2ref_WP_40Mbps.mp4 typefind=true ! aiurdemux ! vpudec framedrop=false ! queue max-size-buffers=3 ! mfw_v4lsink sync=false 3. Video playback framerate measurement During test, we enter command "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" to make sure the CPU always work at highest frequency, so that it can respond to any interrupt quickly. For each testing point with different VPU clock, we do 5 rounds of tests. The max and min values are removed, and the remaining 3 data are averaged to get the final playback framerate. #1 #2 #3 #4 #5 Min Max Avg Dec Playback Dec Playback Dec Playback Dec Playback Dec Playback Playback Playback Playback 270M unit test 57.8 57.3 57.81 57.04 57.78 57.3 57.87 56.15 57.91 55.4 55.4 57.3 56.83 GST 53.76 54.163 54.136 54.273 53.659 53.659 54.273 54.01967 298M unit test 60.97 58.37 60.98 58.55 60.97 57.8 60.94 58.07 60.98 58.65 57.8 58.65 58.33 GST 56.755 49.144 53.271 56.159 56.665 49.144 56.755 55.365 329M unit test 63.8 59.52 63.92 52.63 63.8 58.1 63.82 58.26 63.78 59.34 52.63 59.52 58.56667 GST 57.815 55.857 56.862 58.637 56.703 55.857 58.637 57.12667 352M unit test 65.79 59.63 65.78 59.68 65.78 59.65 66.16 49.21 65.93 57.67 49.21 59.68 58.98333 GST 58.668 59.103 56.419 58.08 58.312 56.419 59.103 58.35333 382M unit test 64.34 56.58 67.8 58.73 67.75 59.68 67.81 59.36 67.77 59.76 56.58 59.76 59.25667 GST 59.753 58.893 58.972 58.273 59.238 58.273 59.753 59.03433 Note: Dec column means the vpu decoding fps, while Playback column means overall playback fps. Some explanation: Why does the Gstreamer performance data still improve while unit test is more flat? On Gstreamer, there is a vpu wrapper which is used to make the vpu api more intuitive to be called. So at first, the overall GST playback performance is constrained by vpu (vpu dec 57.8 fps). And finally, as vpu decoding performance goes to higher than 60fps when vpu clock increases, the constraint becomes the display refresh rate 60fps. The video display overhead of Gstreamer is only about 1 fps, similar to unit test. Based on the test result, we can see that for 352MHz, the overall 1080p video playback on 1080p display can reach ~60fps. Or if time sharing by two pipelines with two displays, we can do 2 x 1080p @ 30fps video playback. However, this experiment is valid for 1080p video playback on 1080p display. If for interlaced clip and display with size not same as 1080p, the overall playback performance is limited by some postprocessing like de-interlacing and resize.

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.

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.

Although you can develop your own driver to control GPIOs inside kernel space, there is a much simpler way for accessing GPIOs from user space. When timing requirements are not an issue, you are able to use GPIO-SYSFS. SYSFS is a virtual file system that exports some kernel internal framework functionalities to user space and GPIO is one of the frameworks that can have functionalities exported through SYSFS. The GPIO-SYSFS feature is available in all mainline kernels from 2.6.27 onwards. Configuring Kernel to export GPIO through SYSFS To enable GPIO in SYSFS, select the following kernel option: Device Drivers --->       --- GPIO Support             [*] /sys/class/gpio/... (sysfs interface) If you are using i.MX233 or i.MX28, after recompiling the kernel, do not forget to generate boot streams again, because this is not automatic even in ltib. Be sure that the pins you will try to use are really accessible as GPIO pins and were not requested by the kernel (gpio_request). If pin was gpio_request'ed, you will need to gpio_export the same pin inside the kernel in order to have it accessible through SYSFS. If pin is not set as GPIO by default, you will need to set IO MUX in the proper file inside <kernel>/arch/arm/mach-XXX. Accessing GPIO in user space After enabling GPIO-SYSFS feature, you can boot your device with the new kernel to make some tests. First you need to export the GPIO you want to test to the user space: echo XX > /sys/class/gpio/export XX shall be determined by the following algorithm: GPIOA_[B] is the GPIO you want to export, where "A" is the GPIO bank and "B" is the offset of the pin in the bank. if the first available GPIO bank is 0 // (iMX.28, for example)     XX = A*32 + B; else // first GPIO bank is 1     XX = (A-1)*32 + B; After exporting a GPIO pin, you shall be able to see the GPIO interface exported to: /sys/class/gpio/gpioXX Through this interface, you are now able to do things like: # Reading the pin value cat /sys/class/gpio/gpioXX/value # Changing pin direction echo in > /sys/class/gpio/gpioXX/direction echo out > /sys/class/gpio/gpioXX/direction # Toggling GPIO output level echo 0 > /sys/class/gpio/gpioXX/value echo 1 > /sys/class/gpio/gpioXX/value It is important to note that through the GPIO virtual filesystem it is only possible to deal with one GPIO pin at a time (per command).

The D-PHY PLL (in the red circle in the picture below) is the PLL that drives the MIPI Clock lane. It must be set in accordance with the video to be sent to the display.   Calculating the video bandwidth The video bandwidth is calculated with the following equation: Pixels per second = Horizontal res. x Vertical res. x Frame rate x Bits per pixel Taking as example the 1080p60 OLED display RM67191: Pixels per second = 1920 x 1080 x 60 x 24 Pixels per second = 2985984000 = 2,98Gpixels/sec Pixel clock calculation The Display pixel clock can be obtained on the display driver. In this example for RM67191, the pixel clock is 132Mpixel/sec, see file: panel-raydium-rm67191.c\panel\drm\gpu\drivers - linux-imx - i.MX Linux kernel  Line 530: .pixelclock = { 66000000, 132000000, 132000000 }, Or the number can be obtained with the following equation: pixel clock = (hactive + hfront_porch + hsync_len + hback_porch) x (vactive + vfront_porch + vsync_len + vback_porch) x frame rate pixel clock = (1080 + 20 + 2 +34) × (1920 + 10 + 2 + 4) x 60 pixel clock = 132000000 (rounded up) Bit clock calculation (clock lane) The mipi-dphy bit_clk is the output clock and is calculated on file sec-dsim.c (line 1283): sec-dsim.c\bridge\drm\gpu\drivers - linux-imx - i.MX Linux kernel  Bit clock can be calculated with the following equation: bit_clk = Pixel clock * Bits per pixel / Number of lanes In the case of 1980p60 (Raydium display), It is:   bit_clk = pixel clock * bits per pixel / number of lanes bit_clk = 132000000 * 24 / 4 bit_clk = 792000000 Other important timing parameters like 'p', 'm', 's' are obtained on the table in the following header file: sec_mipi_dphy_ln14lpp.h\imx\drm\gpu\drivers - linux-imx - i.MX Linux kernel 

All, This document will help you to understand the " YOCTO PROJECT COMMUNITY LAYERS" and the "YOCTO PROJECT FREESCALE OFFICIAL RELEASE" differences and where the layer content is coming from.   Best Regards, Luis

NXP i.MX 8 series of application processors support running ArmV8a 64-bit and ArmV7a 32-bit user space programs.  A Hello World program that prints the size of a long int is cross-compiled as 32-bit and as 64-bit from an Ubuntu host and then each is copied to MCIMX8MQ-EVK and run. Resources: Ubuntu 18.04 LTS Host i.MX 8M Evaluation Kit|NXP  MCIMX8MQ-EVK Linux Binary Demo Files - i.MX 8MQuad EVK L4.9.88_2.0.0_GA release Source Code: Create a file with contents below using your favorite editor, example name hello-sizeInt.c. #include <stdio.h> int main (int argc, char **argv) { printf ("Hello World, size of long int: %zd\n", sizeof (long int)); return 0; }‍‍‍‍‍‍‍ Ubuntu host packages: $ sudo apt-get install -y gcc-arm-linux-gnueabihf $ sudo apt-get install -y gcc-aarch64-linux-gnu‍‍‍‍ Line 1 installs the ArmV7a cross-compile tools: arm-linux-gnueabihf-gcc is used to cross compile on Ubuntu host Line 2 install the ArmV8a cross-compile tools: aarch64-linux-gnu-gcc is used to cross compile on Ubuntu host Create Linux User Space Applications Build each application and use the static option to gcc to include run time libraries. Build ArmV7a 32-bit application: $ arm-linux-gnueabihf-gcc -static hello-sizeInt.c -o hello-armv7a‍-static‍‍ Build ArmV8a 64-bit application: $ aarch64-linux-gnu-gcc -static  hello-sizeInt.c -o hello-armv8a‍-static‍‍ Copy Hello applications from Ubuntu host and run on MCIMX8MQ-EVK Using a SDCARD written with images from L4.9.88_2.0.0 Linux release (see resources for image link), power on EVK with Ethernet connected to network and Serial Console port which was connected to a windows 10 PC. Launched a terminal client (TeraTerm) to access console port. Login credentials: root and no password needed. Since Ethernet was connected a DHCP IP address was acquired, 192.168.1.241 on the EVK.  On the Ubuntu host, secure copy the hello applications to EVK: $ scp hello-armv7a-static [email protected]:~/ hello-armv7a-static                           100%  389KB   4.0MB/s   00:00    $ scp hello-armv8a-static [email protected]:~/ hello-armv8a-static                           100%  605KB   4.7MB/s   00:00 ‍‍‍‍‍‍‍‍‍‍ Run: root@imx8mqevk:~# ./hello-armv8a-static Hello World, sizeof long int: 8 root@imx8mqevk:~# ./hello-armv7a-static Hello World, sizeof long int: 4‍‍‍‍‍‍‍‍

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

Hello i.MX Community. Attached there is a guide on how to install Ubuntu trusty on i.MX7D-SD board Basically it explains all steps to install and to have running ubuntu core 14.04 on the Freescale i.Mx7D-SDB: I hope you find the document and projects useful! Regards!