i.MX Processors Knowledge Base

Discussions

[Brief description] (1)Contents The ducoment introduced how to expand Gigabit Ethernet based on i.MX6 PCI Express, and attached schematics in DSN & pdf format. (2)Binary file for EEROM I have the binary file used to debug intel82574 circuit in this schematic, If customer wants to use it to debug board based on i.MX6+Intel82574, she can submit a case for me to get the file by our Salesforece system. Best Regards, TIC Weidong Sun Email: weidong.sun@nxp.com

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

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.

Here are two patches to support BT656 and BT1120 output for i.MX6 ipuv3. With this patch, the i.MX6 can support the CVBS output on TV encoder. It is useful for a TV box. "L3.0.35_1.1.0_GA_bt656_output_patch.zip" is the patch for Freescale L3.0.35_1.1.0_GA_iMX6DQ BSP. "r13.4.1_bt656_output_patch.zip" is the patch for Freescale Android R13.4.1 BSP. 1. Features supported: 1) Support BT656(8 bits) and BT1120 (16 bits)interlaced output on display port. 2) Support both RGB and YUV frame buffer for BT656/BT1120 output. 3) Support PAL and NTSC mode. 4) Support on the fly switch between PAL and NTSC mode. 5) Support CVBS output based on adv7391 TV encoder. 2. Hardware link between iMX6 and adv7391 TV encoder chip. IPU1_DI0_DISP_CLK connected to adv7391 CLKIN pin. IPU1_DISP0_DAT_23~DISP0_DAT_16 connected to adv7391 P7~P0 pins. IPU1_DI0_PIN2 connected to adv7391 HSYNC pin. (option) IPU1_DI0_PIN4 connected to adv7391 VSYNC pin. (option) - Android R13.4.1 kernel. 3. How to use -- Copy the two patch files to kernel folder. $ git apply ./0001-Support-BT656-and-BT1120-output-for-iMX6-ipuv3.patch $ git apply ./0002-Support-adv739x-TV-encoder-for-BT656-output.patch -- Select them in kernel config and build the new kernel image: Device Drivers ---> Graphics support ---> [*] MXC BT656 and BT1120 output [*] ADV7390/7391 TV Output Encoder -- Uboot parameters for video mode Output BT656 NTSC data to display port with UVYV frame buffer mode: "video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=UYVY16" Output BT656 NTSC data to display port with RGB565 frame buffer mode: "video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=RGB565" Output BT656 PAL data to display port with RGB24 frame buffer mode: "video=mxcfb0:dev=bt656,BT656-PAL,if=BT656,fbpix=RGB24" Output CVBS NTSC signal on adv7391 with UYVY frame buffer mode: "video=mxcfb0:dev=adv739x,BT656-NTSC,if=BT656,fbpix=UYVY16" Output CVBS PAL signal on adv7391 with RGB565 frame buffer mode: "video=mxcfb0:dev=adv739x,BT656-PAL,if=BT656,fbpix=RGB565" -- Switch between PAL and NTSC $ echo D:720x480i-60 > /sys/class/graphics/fb0/mode $ echo D:720x576i-50 > /sys/class/graphics/fb0/mode 4. Note 1) For 8 bits BT656 interface, the default data pins are "DISP0_DAT_23~DISP0_DAT_16", it can also be any other continued display data pins, for example if "DISP0_DAT_7~DISP0_DAT_0" are used, the macro "BT656_IF_DI_MSB" in "kernel_imx/drivers/mxc/ipu3/ipu_disp.c" should be changed from "23" to "7". 2) For 16 bits BT1120 interface, the default data pins are "DISP0_DAT_23~DISP0_DAT_8", it can also be any other continued display data pins, the macro "BT656_IF_DI_MSB" should be modified if the hardware pins are changed. 3) When bt656 interface is the second display for each IPU,1-layer-fb (it can be checked with command "$ cat /sys/class/graphics/fbx/fsl_disp_propperty"), the frame buffer can only be YUV format. In this case, the IPU DC channel was used for BT656 display, it has no CSC function, so RGB frame buffer was not supported. 2013-08-09 updated: The new release package "L3.0.35_1.1.0_GA_bt656_output_patch_2013-08-09.zip" had fixed the BT656 dual display issue on iMX6S/DL. Removed the old release package. 2013-09-04 updated: The new release package "r13.4.1_bt656_output_patch_2013-09-04.zip" had fixed the BT656 dual display issue on iMX6S/DL. For default, the dual display was tested with HDMI + CVBS, HDMI is the main display and adv739x CVBS output is the second display. For iMX6DQ which has two IPUs, please assign dual display to two IPUs, for example adv739x is on IPU1 DI0, it is fixed, because hardware pins used for it is fixed. Then we can assign HDMI or LVDS to another IPU (IPU2). For iMX6S/DL which has only one IPU, since adv739x had used IPU1 DI0, another display should be IPU1 DI1. 2013-09-30 updated: Added patch for L3.0.35_4.1.0_GA BSP, the file is "L3.0.35_4.1.0_GA_bt656_output_patch_2013-09-30.zip". 2014-07-21 updated: Added patch for L3.10.17_1.0.0_GA BSP, the file is "L3.10.17_1.0.0_GA_bt656_output_patch_2014-07-21.zip". 2015-01-26 updated: Updated the IPU microcode for 1080i50 and 1080i60 BT1120 output, the parameters "N" for command BMA is a 8 bits parameters, so its max value is 255, but for 1080i50 and 1080i60 output, it needs more blank data in each line, the "N" will be bigger than 255, the updated IPU microcode can fix this limitation. The updated file is "IPU_Microcode_Update_for_BT1120_1080i_20150126.zip". You can update the macro "DC_MCODE_BT656_xxx" and function _ipu_dc_setup_bt656_interlaced() to the old patch if you used BT1120 mode to support 1080i display. The verified 1080i display mode is: { /* 1080I60 Interlaced output */ "BT1120-1080I60", 30, 1920, 1080, 13468, 20, 3, 20, 2, 280, 1, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, FB_VMODE_INTERLACED, FB_MODE_IS_DETAILED,}, { /* 1080I50 Interlaced output */ "BT1120-1080I50", 25, 1920, 1080, 13468, 20, 3, 20, 2, 720, 1, FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, FB_VMODE_INTERLACED, FB_MODE_IS_DETAILED,}, 2016-01-28 updated: Updated IPU microcode to align with BT656.4 specification for NTSC output. For other BSP version with NTSC format support, please reference to ipu_disp_update.c for the final microcode. File "L3.0.35_4.1.0_GA_bt656_output_patch_20160128.zip"., Details, please reference to the readme.txt file in the package. 2016-06-24 update: Added BT656 and BT1120 progressive mode support. File "L3.0.35_4.1.0_GA_bt656_output_patch_20160624.zip". Details, please reference to the readme.txt file in the package. The patch for 3.14.52 GA1.1.0 BSP will be released in next week. 2016-06-27 update: Add BT656 and BT1120 display patch for 3.14.52 BSP. File "L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27.zip", details, please reference to the readme.txt in the package. 2017-03-10 update: Fixed a hard coding DC macro issue for progressive mode. Added patch "0008-Fixed-a-hard-coding-DC-macro-issue-for-progressive-m.patch" in L3.0.35_4.1.0_GA_bt656_output_patch_2017-03-10.zip. The code in patch "L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27" is correct.

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 purpose of the document is to help customer setup development environment of android BSP, The document includes the following contents: 1.Setup environment for compiling android BSP source code 2. Setup tftp and NFS environment for android development 3. Common Steps of Porting android to customized borad ( L3.0.35 kernel) Note: (1) ubuntu version is suitable for 12.04/14.04/15.04 (2) android BSP version is 4.2.2 / 4.3 / 4.4.2 If cusotmer is using android5.1.1 / android 6.0 or above, The way of porting kernel should be focused on adjusting device tree. (3)Each andoid BSP has its own MFG tools version. User should pay attention to this, don't use wrong version of MFG Tools. NXP TIC team Weidong Sun

UPDATE: Note that this document describes eIQ Machine Learning Software for the NXP L4.14 BSP release. Beginning with the L4.19 BSP, eIQ Software is pre-integrated in the BSP release and this document is no longer necessary or being maintained. For more information on eIQ Software in these releases (L4.19, L5.4, etc), please refer to the "NXP eIQ Machine Learning" chapter in the Linux User Guide for that specific release. Original Post: eIQ Machine Learning Software for iMX Linux 4.14.y kernel series is available now. The NXP eIQ™ Machine Learning Software Development Environment enables the use of ML algorithms on NXP MCUs, i.MX RT crossover processors, and i.MX family SoCs. eIQ software includes inference engines, neural network compilers, and optimized libraries and leverages open source technologies. eIQ is fully integrated into our MCUXpresso SDK and Yocto development environments, allowing you to develop complete system-level applications with ease. Source download, build and installation Please refer to document NXP eIQ(TM) Machine Learning Enablement (UM11226.pdf) for detailed instructions on how to download, build and install eIQ software on your platform. Sample applications To help get you started right away we've posted numerous howtos and sample applications right here in the community. Please refer to eIQ Sample Apps - Overview. Supported platforms eIQ Machine learning software for i.MX Linux 4.14.y supports the L4.14.78-1.0.0 and L4.14.98-2.0.0 GA releases running on i.MX 8 Series Applications Processors. For more information on artificial intelligence, machine learning and eIQ Software please visit AI & Machine Learning | NXP.

This documents describes how to add the NFC support to i.MX8M mini evk running Yocto. Hardware setup: The i.MX8M mini evk (see i.MX 8M Mini Evaluation Kit | NXP) featuring Raspberry Pi compliant connector, the OM5578/RPI PN7150 demo kit can be used to perform this porting (see NFC Development Kits for Arduino and more|NXP). However a small modification must be done because some of the signals required by PN7150 are not mapped to i.MX8M mini expansion connector pins. OM5578 IRQ signal must be mapped to Raspberry Pi connector pin #19 and OM5578 IRQ signal must be mapped to Raspberry Pi connector pin #21. See below a picture of the modification: Then, the two boards can fit together as shown in the picture below: Quick start using demo image: The demo image including support for PN7150, is based on i.MX Linux 4.14.78_1.0.0 BSP software release (see i.MX Software | NXP). Related documentation can be downloaded from here: https://www.nxp.com/webapp/Download?colCode=L4.14.78_1.0.0_LINUX_DOCS. Just flash the demo image (downloaded from here: https://www.nxp.com/lgfiles/updates/NFC/LINUX_L4-14-78_IMAGE_MX8MMEVK.zip) following guidelines from i.MX_Linux_User's_Guide document (part of L4.14.78_1.0.0_LINUX Documentation package mentioned above). Then in a terminal you can run the demo application included in the image executing the command: # nfcDemoApp poll Approaching the NFC tag, provided as reference in the OM5578 demo kit, to the NFC Antenna will trigger such display: Adding PN7150 support to imx-linux-sumo release: Pre-condition is to have L4.14.78_1.0.0 release installed and already built as described in i.MX Yocto Project User's Guide (part of L4.14.78_1.0.0_LINUX Documentation package mentioned above) : $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-sumo -m imx-4.14.78-1.0.0_ga.xml $ repo sync $ MACHINE=imx8mmevk DISTRO=fsl-imx-xwayland source fsl-setup-release.sh -b build_dir $ bitbake fsl-image-validation-imx Then to add PN7150 support to your imx-linux-sumo environment, follow below step by step guidelines: In the sources directory, download the meta-nxp-nfc layer from https://github.com/NXPNFCLinux/meta-nxp-nfc $ git clone https://github.com/NXPNFCLinux/meta-nxp-nfc.git Define hardware connection between CPU and PN7150 in device-tree adding the following lines to file build_dir/tmp/work-shared/imx8mmevk/kernel-source/arch/arm64/boot/dts/freescale/fsl-imx8mm-evk.dts: @@ -227,6 +227,8 @@ fsl,pins = < MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL 0x400001c3 MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA 0x400001c3 + MX8MM_IOMUXC_ECSPI2_MOSI_GPIO5_IO11 0x41 + MX8MM_IOMUXC_ECSPI2_MISO_GPIO5_IO12 0x41 >; }; @@ -747,6 +749,13 @@ pinctrl-0 = <&pinctrl_i2c3>; status = "okay"; + pn54x: pn54x@28 { + compatible ="nxp,pn547"; + reg = <0x28>; + interrupt-gpios = <&gpio5 11 0>; + enable-gpios = <&gpio5 12 0>; + }; + pca6416: gpio@20 { compatible = "ti,tca6416"; reg = <0x20>; Add the meta-nxp-nfc layer to the build definition updating file build_dir/conf/bblayers.conf with: BBLAYERS += " ${BSPDIR}/sources/meta-nxp-nfc" Add the meta-nxp-nfc layer components to the image definition updating file build_dir/conf/local.conf with: IMAGE_INSTALL_append = " kernel-module-nxp-pn5xx nxp-nfc-bin " Re-build the linux kernel: $ bitbake -f -c compile linux-imx && bitbake -f -c deploy linux-imx Build meta-nxp-nfc layer: $ bitbake nxp-nfc Re-build the complete image to include the modifications: $ bitbake fsl-image-validation-imx Then you can flash the updated image to your i.MX8M mini evk and run the demo application as described in above "Quick start using demo image" chapter. Reference: This porting have been done (demo image and instructions) following guidelines provided in AN11679_PN71xx_Linux_Software_Stack_Integration_Guidelines document.

In January 2013, Adeneo Embedded launched 2 dedicated blogs. These blogs are both run by Adeneo Embedded Windows and Linux experts, multiple time MVP awarded. The goal is to provide the windows and linux communities with specific up-to-date information as well as the latest announcements concerning these two companies. Click here to visit our Windows dedicated blog Click here to visit our Linux dedicated blog Follow, comment and subscribe ! Ce document a été généré à partir de la discussion suivante : Adeneo Embedded experts launch 2 dedicated blogs !

Getting Started for i.MX53 Quick Start Board Here is a quick overview you can follow to get your very first contact with i.MX53 QSB. Introduction Out of box i.MX53 QSB video booting up Ubuntu Original Video: Out of box i.MX53 QSB video booting up Ubuntu with some demo (GPU and VPU) Original Video: How to load a pre-built image Here, you should have loaded your board with the out-of-box SD card. Next step is create your own SD card with some pre-built image. You can find pre-built image packages from Freescale for Linux look for Linux Binary Demo file Please, go to Timesys wikipage[1] and see how to load a pre-built image. You can use some Freescale image or some Timesys image. Both will work! For loading linux OS you need at least 3 images: bootloader image kernel image root file system image or tarball Bootloader For iMX53QSB the default bootloader provided by Freescale is u-boot.You can build your own image using LTIB following the same procedure from here. Kernel You can build a new uImage (kernel binary image to be loaded by u-boot) using LTIB, and you can follow the instructions from here Root File System Root file system is a set of directories and files that become the system environment. How to Built Your Own Image Take BSP package on Freescale i.MX53 QSB web site. Prepare your computer to LTIB installation, see that you need All Boards LTIB. Transfer all images to the SD Card (it will be placed under <ltib_dir>/rootfs/boot). Configure your u-boot environment variable. Boot your board. In case you want to boot via NFS, please follow the next procedure instead. Take BSP package on Freescale i.MX 53 QSB web site. Prepare your computer to LTIB installation, see that you need @all_boards_ltib Configure your computer to be able to provide NFS service: Configure your TFTP server. Configure your NFS server. Configure your u-boot environment variable. Boot your board. Be aware the kernel command line you set on u-boot variable can configure the display.

This document explains how to bring-up u-boot & Linux via JTAG This procedure has been tested on: i.MX6 Solo X Sabre SD i.MX6UL EVK Prerequistes: Get the latest BSP for your board. This procedure was tested with L4.1.15. Build the 'core-image-minimal' image to bring-up your board (Detailed steps here) Optional- Build a meta-toolchain for your device 1.- Set board to boot from Serial dowloader mode or set it to boot from the SD card and remove the sd card We basically want the board to stall in boot ROM to attach to the target. 2.- Connect JTAG probe and turn on the board The device should stall trying to establish a connection to download an image, this will allow us to attach to the target. 3.- Load Device Configuration Data In 'normal' boot sequence the boot ROM takes care of reading the DCD and configuring the device accordingly, but in this case we are skipping this sequence and we need to configure the device manually. The script used by Lauterbach to parse and configure the device is called dcd_interpreter.cmm and can be found here. Search for the package for your specific device. The DCD configuration for your board should be on your u-boot directory: yocto_build_dir/tmp/work/<your board>imx6ulevk/u-boot-imx/<u-boot_version>2016.03-r0/git under board/freescale/<name of your board>mx6ul_14x14_evk/imximage.cfg This file (imximage.cfg) contains all the data to bring up DRAM among other early configuration options. 4.- Load U-boot If an SREC file of U-boot is not present build it (meta-toolchain installed required) the SREC file contains all the information required by the probe to load it and makes this process easier. To build the SREC simply type: make <your board defconfig>mx6ul_14x14_evk_defconfig (all supported boards are found under u-boot_dir/configs) make If you cannot build an SREC or do not want to, you can use the u-boot.imx (located under yocto_build_dir/tmp/deploy/images/<your board name>/) or u-boot.bin files but you will need to figure out the start address and load address for these files, this can be done by examining the IVT on u-boot.imx (here is a useful document explaining the structure of the IVT). Let U-boot run and you should see its output on the console I will try to boot from several sources but it will fail and show you the prompt. 5.- Create RAMDisk After building the core-image-minimal you will have all the required files under yocto_build_dir/tmp/deploy/images/<your board name>/ You will need: zImage.bin - zImage--<Linux Version>--<your board>.bin Device tree blob - zImage--<Linux Version>--<your board>.dtb Root file system - core-image-minimal-<your board>.rootfs.ext4 We need to create a RAMDisk out of the root file system we now have, these are the steps to do so: Compress current Root file system using gzip: gzip core-image-minimal-<your board>.rootfs.ext4 If you want to keep the original file use: gzip -c core-image-minimal-<your board>.rootfs.ext4 > core-image-minimal-<your board>.rootfs.ext4.gz Create RAMDisk using mkimage: mkimage -A arm -O linux -T ramdisk -C gzip -n core-image-minimal -d core-image-minimal-<your board>.rootfs.ext4.gz core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot Output: Image Name: core-image-minimal Created: Tue May 23 11:28:55 2017 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 3017939 Bytes = 2947.21 kB = 2.88 MB Load Address: 00000000 Entry Point: 00000000 Here are some details on mkimage usage Usage: mkimage -l image -l ==> list image header information mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image -A ==> set architecture to 'arch' -O ==> set operating system to 'os' -T ==> set image type to 'type' -C ==> set compression type 'comp' -a ==> set load address to 'addr' (hex) -e ==> set entry point to 'ep' (hex) -n ==> set image name to 'name' -d ==> use image data from 'datafile' -x ==> set XIP (execute in place) mkimage [-D dtc_options] [-f fit-image.its|-F] fit-image -D => set options for device tree compiler -f => input filename for FIT source Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined) mkimage -V ==> print version information and exit 6.- Modify U-boot's environment variables Now we need to modify U-boot's bootargs as follows: setenv bootargs console=${console},${baudrate} root=/dev/ram rw We need to find out the addresses where u-boot will expect the zImage, the device tree and the initial RAMDisk, we can do it as follows: => printenv fdt_addr fdt_addr=0x83000000 => printenv initrd_addr initrd_addr=0x83800000 => printenv loadaddr loadaddr=0x80800000 Where: fdt_addr -> Device tree blob load address initrd_addr -> RAMDisk load address loadaddr -> zImage load address 7.- Load zImage, DTB and RAMDisk Now we know where to load our zImage, device tree blob and RAMDisk, on Lauterbach this can be achieved by running the following commands: Stop the target and execute: data.load.binary zImage.bin 0x80800000 data.load.binary Your_device.dtb 0x83000000 data.load.binary core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot 0x83800000 Let the device run again and deattach from the device in lauterbach this is achieved by: go SYStem.mode.NoDebug start the boot process on u-boot as follows: bootz ${loadaddr} ${initrd_addr} ${fdt_addr} You should now see the Linux kernel boot process on your terminal: After the kernel boots you should see its prompt on your terminal: Since we are running out of RAM there is no way for us to save u-boot's environment variables, but you can modify the source and compile u-boot with the new bootargs, by doing so you can create a Load script that loads all the binaries hits go and the boot process will continue automatically. One way to achieve this is to modify the configuration file under U-boot_dir/include/configs/<your board>.h find the mfgtool_args and modify accordingly. The images attached to this thread have been modified as mentioned.

Kernel provides mtdoops to dump kmsg to MTD device, but MMC card is not a MTD device. We can let user-space program to execute the write operation to dump kmsg into block storage. The sample code is below. kernel space -- #include <linux/kernel.h> #include <linux/module.h> #include <linux/console.h> #include <linux/vmalloc.h> #include <linux/seq_file.h> #include <linux/workqueue.h> #include <linux/sched.h> #include <linux/wait.h> #include <linux/delay.h> #include <linux/interrupt.h> #include <linux/kmsg_dump.h> #include <linux/proc_fs.h> static struct kmsg_dumper dump; static struct proc_dir_entry *my_proc; static int is_panic = 0; static int my_proc_show(struct seq_file *m, void *v) { seq_printf(m, "%d", is_panic); return 0; } static int my_proc_open(struct inode *inode, struct file *file) { return single_open(file, my_proc_show, NULL); } static const struct file_operations my_proc_ops = { .open = my_proc_open, .read = seq_read, .llseek = seq_lseek, .release = single_release, }; static void oops_do_dump(struct kmsg_dumper *dumper, enum kmsg_dump_reason reason, const char *s1, unsigned long l1, const char *s2, unsigned long l2) { int i; printk("### [%s:%d] reason = %d\n", __func__, __LINE__, reason); is_panic = 1; for (i = 0;i < 10; i++) msleep(1000); printk("### [%s:%d] should be done\n", __func__, __LINE__); } static int __init my_oops_init(void) { int err; dump.dump = oops_do_dump; err = kmsg_dump_register(&dump); if (err) { printk(KERN_ERR "oops: registering kmsg dumper failed, error %d\n", err); return -EINVAL; } my_proc = proc_create("dump_tester", 0, NULL, &my_proc_ops); return 0; } static void __exit my_oops_exit(void) { printk("### [%s:%d]\n", __func__, __LINE__); if (my_proc) remove_proc_entry( "dump_tester", NULL); kmsg_dump_unregister(&dump); } module_init(my_oops_init); module_exit(my_oops_exit); MODULE_LICENSE("GPL"); User space -- #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> #include <fcntl.h> #include <poll.h> #define BUF_LEN 40960 void main(int argc, char **argv) { char tmp = 'X'; char buf[BUF_LEN]; int fd_src, fd_trg; int fd = open("/proc/dump_tester", O_RDONLY, 0); while(1) { lseek(fd, 0, SEEK_SET); read(fd, &tmp, 1); //printf("### [%s:%d] ==> '%c'\n", __FUNCTION__, __LINE__, tmp); if (tmp == '1') { fd_src = open("/proc/kmsg", O_RDONLY, 0); fd_trg = open("/dev/block/mmcblk0p6", O_RDWR, 0); memset(buf, 0, BUF_LEN); write(fd_trg, buf, BUF_LEN); lseek(fd_trg, 0, SEEK_SET); read(fd_src, buf, BUF_LEN); write(fd_trg, buf, BUF_LEN); close(fd_src); close(fd_trg); sleep(1); printf("### dump panic log into %s\n", "/dev/block/mmcblk0p6"); break; } sleep(1); } close(fd); }

Introduction This is a brief guide showing how to integrate the driver for the WF111 module to the i.MX6 BSP Release. In this case the WF111 driver is available on a repository and it’s in accordance with the Yocto Project, which allows to easily customize a linux distribution for your board. Requirements WF111 Documentation – Silicon Labs have made a great job of documenting the steps to add the WF111 driver to a Linux distribution and have created Application Note 996 (link below), which we will use as reference. http://www.silabs.com/documents/login/application-notes/AN996.pdf WF111 Driver - We will also be using the Yocto layer included on the following repository: https://github.com/engicam-stable/meta-engicam i.MX6 3.14.52 BSP Release – In out scenario the WF111 layer that will be imported includes a driver that it’s compatible with Linux Kernel 2.6.24 up to 4.1., which it’s important to keep in mind. Installing the 3.14.52 BSP Release First, setup the 3.14.52 BSP as described on the i.MX Yocto Project User’s Guide. Adding the WF111 Driver Layer Clone the WF111 Driver Layer to your sources folder inside the BSP Release directory. Since the 3.14.52 BSP Release is based on Fido we will clone the Fido branch of the driver repository. $ cd <BSP_RELEASE_DIR>/sources $ git clone https://github.com/engicam-stable/meta-engicam -b fido‍‍ Once the layer is cloned you would need to add the new later editing the bblayers.conf file located the following path: <BSP_RELEASE_DIR>/<BUILD_DIR>/conf/bblayers.conf By adding the following line to add the new layer. BBLAYERS += " ${BSPDIR}/sources/meta-engicam "‍ This should make the wf111-driver available through bitbake since bitbake will now look into this layer for all available recipes. You can then add the driver to your image by adding the following line to the <BUILD_DIR>/conf/local.conf IMAGE_INSTALL_append += "wf111-driver"‍ Or you may create a new image recipe that includes the wf111-driver package. However, there are certain kernel options that must be enabled for the driver to work. Creating an append to configure the kernel options Before we can bake an image with the WF111 driver we would need to edit the kernel options as mentioned on Silabs AN996. The following kernel options must be enabled: CONFIG_WIRELESS_EXT CONFIG_MODULES CONFIG_FW_LOADER We would need to add the CONFIG_WIRELESS_EXT as the other two options are enabled on the BSP by default. This involves adding an addendum to the kernel recipe to change its configuration. You may either add this append to any layer. The best way to handle it would be using a new layer for all your customization. You can find how to create a new layer on the following document: https://community.nxp.com/docs/DOC-331917 We’ll use a new layer called meta-newlayer for this example. It’s important that this layer has a high priority so the changes from the bbappend are not overridden. The following alternative was suggested by Chris Hossack on the following thread: https://community.nxp.com/thread/376369 First, run the menuconfig tool on the bitbake environment: bitbake linux-imx -c menuconfig Enable the necessary options: Networking Support > Wireless > cfg80211 wireless extensions compatibility Save the configuration and exit. Then run the following bitbake command, which will create a config fragment file that contains the changed made to the default kernel options. bitbake linux-imx -c diffconfig We’ll make an append file that adds the required options. Content of the config fragment: CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_SPY=y CONFIG_WEXT_PRIV=y CONFIG_CFG80211_WEXT=y CONFIG_LIB80211=y CONFIG_LIB80211_CRYPT_WEP=y CONFIG_LIB80211_CRYPT_CCMP=y CONFIG_LIB80211_CRYPT_TKIP=y # CONFIG_LIB80211_DEBUG is not set CONFIG_HOSTAP=y # CONFIG_HOSTAP_FIRMWARE is not set‍‍‍‍‍‍‍‍‍‍‍‍‍ Since we are appending the kernel layer we need to add the addendum on the same path as that of the original kernel recipe but within our layer and create the append file there. Also add the WF111.cfg file to the linux-imx directory: We would need to copy (and you may rename it as well) to the folder where are will be creating the append recipe for the kernel. Copy: <BSP_RELEASE>/<BUILD_DIR>/tmp/work/<MACHINE>-poky-Linux-gnueabi/linux-imx/<KERNEL_VERSION>/fragment.cfg To: <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx/WF111.cfg You can do so suing the following command: cp <BSP_RELEASE>/<BUILD_DIR>/tmp/work/<MACHINE>-poky-Linux-gnueabi/linux-imx/<KERNEL_VERSION>/fragment.cfg <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx/WF111.cfg‍ (Please note that the file was renamed for ease, but you may use any name for the config fragment) We need to create the bbappend file on the following path (as it must be the same relative path as the original recipe it is appending) <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx_3.14.52.bbappend The linux-imx_3.14.52.bbappend file would contain the following: SRC_URI += "file://WF111.cfg" do_configure_append() { #this is run from #./tmp/work/<MACHINE>-poky-linux-gnueabi/linux-imx/3.14.52-r0/git cat ../*.cfg >> ${B}/.config }‍‍‍‍‍‍ After creating this recipe you should be able to bake any image from the BSP and see the driver there. I tested with the core-minimal-image and found that the files were indeed added to /lib/firmware. $ bitbake core-image-minimal ‍‍‍

On imx8qm there are two DPUs(display process unit) and one ISI(image subsystem interface), ISI has 5 inputs and two of them are from DPU0 and DPU1. This document demonstrates on how to loopback DPU1 outputs to ISI. Note that only mipi dsi0 of dpu0 and lvds1 of dpu1 can be loopbacked to isi. Platform: imx8qm b0 mek OS: yocto 4.14.78 ga hardware connection: imx8qm lvds1 ====> it6263 cable =====> hdmi display. 1st: isi has 8 pipelines which can be assigned to any of the 5 inputs, this doc takes the 5th pipeline to sink the dpu1 input. So you will need to configure the isi_4( start from 0) source in the dts and write a simple v4l2 subdev for capture testing, the default isi_4 device will be /dev/video4. 2st: configure both framegen0 of dpu1 and lvds1's link to pixellink 3. 3st: write a v4l2 userspace program to capture from /dev/video4 device, take this vulkan-capture as an example. Note that Vulkan-capture is rendered by vulkan api, you can also take opengl es for rendering. See the atttachments for details. ======================================== 2019/11/12 update patches. ======================================== 2019/12/19 add patch. Support connect real display to DC1-LVDS1 Note: for ISI loopback, it needs output of 2x GPIO (4x for HDMI-TX or combo PHY) to pixel_link_receiver_address: For iMX8QM: o LVDS: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6] o MIPI-DSI: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6] o HDMI-TX: odd_pixel_link_receiver_address[1:0] = do_gpio_dr[7:6],even_pixel_link_receiver_address[1:0] = do_gpio_dr[5:4] For iMX8QXP: o Combo MIPI-DSI / LVDS: pixel_link0_receiver_address[1:0] = do_gpio_dr[7:6], pixel_link1_receiver_address[1:0] = do_gpio_dr[5:4]

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

Q: What is latency figures for the VPU to decode Device: i.MX6Q OS: Linux Resolution: 1920x1080(HD) Frame rate: 30 FPS Function: Overlay messages. Input/Output: 8 bit / YUV 4:2:0 / NAL stream Profile level: 4.1. Constrained Baseline. I and P frames support. A: It depend on the syntax in H.264, includes num_reorder_frames,max_dec_frame_buffering,num_ref_frames,MaxDpbSize,etc. for start latency: it cover vpu driver loading, allocate buffers, init, decoding the first frame less than 100ms on iMX6/Linux. This document was generated from the following discussion: VPU Latency i.MX6

This work is the result of my daughter's idea, she finished it with my guidance. Cradle-1 Palmsize mini-HPC World's first full function heterogeneous mini-HPC, this is what it looks like: 1 Architecture Overall: CPU+GPU heterogeneous, 4 nodes, connected by a 100M Ethernet switcher; Nodes： FreeScale I.MX6 Quad core mini-pc, with 4 ARM Cortex-A9 cores and 1 Vivante GC2000 GPU 2 Software OS: Ubuntu 11.10 linaro OpenCL driver: Vivante GC2000 OpenCL driver Compiler: C/C++: gcc 4.6.1, Fortan90/95: gfortran 4.6.1, MPI Parallel Computing: MPICH2 1.4-1 NFS network file system: nfs-kernel-server 1.2.4 SSH security: openssh 1:5.8 3 Hardware The hardware of all nodes are the same, only the software configurations are slightly different. One of them was assigned as the master node, the others are slave nodes. They were TV sticks originally, with android 4.0 installed. The node's hardware specification is: CPU: 4 1.2G Cortex-A9 cores GPU: 1 Vivante GC2000 GPU RAM: 1G DDR ROM: 8G SD NIC: usb2.0 100M Ethernet Adapter (this NIC is not the TV stick's component, we added it) WIFI: 150M Display Interface: HDMI Network Switcher: 5 port 100M Ethernet Switcher 4 Network Each node has one USB2.0 NIC and one WIFI interface, the WIFI is used as the backup connection for NIC connection. Network configurations are: IP Address assignment: (baby1 - baby4 are the four computing nodes) baby1: 100M NIC 192.168.10.1 WIFI 192.168.0.111 baby2: 100M NIC 192.168.10.2 WIFI 192.168.0.112 baby3: 100M NIC 192.168.10.3 WIFI 192.168.0.113 baby4: 100M NIC 192.168.10.4 WIFI 192.168.0.114 5 Performance Cradle-1 has 16 1.2G ARM Cortex-A9 cores and 4 Vivante GC2000 GPU cores, the total computing power of these 20 computing devices is more than 100GFLOPS, more powerful than an ordinary desktop. The whole machine is only a little bigger than a palm, and the total power consumption is less than 15 watts. The overall architecture of Cradle-1 is almost the same as Chinese Tianhe-1A or the Titan in the oak ridge lab. they used the same set of software, LINUX+OPENCL+OPENMPI. Cradle-1 supports C/C++, Fortran90/95. And almost all kinds of parallel computing algorithms can run on it, the only difference is the scale. We coded a MPI parallel computing program for large matrix multiplication with 4 processes, each process had 5 threads, four threads for the four CPU cores, and one thread for GPU computing. 6 Appearance Front Back Top Left Right One node, it has three interfaces, the right is HDMI interface, upper-left is the wireless adapter for keyboard and mouse, down-left is the power connection. One node is running Ubuntu 11.10. Coded a simple OpenCL program to display OpenCL driver information On a notebook, using remote desktop access function to obtan the node baby1's desktop. This is the sign in desktop of baby1 node. Baby 1 has X11VNC server installed. sign in baby1, open a terminal Ran a MPI testing program, ensuring that all babies (baby1 - baby4) were working Any comments? please mail to audrey.tao@hotmail.com

i.MX Processors Knowledge Base

i.MX Processors Knowledge Base

Discussions

Intel82574IT For i.MX6 PCI Express(Hardware design)

Tracing GStreamer Pipelines

busybox on the i.MX6 sabre sd platform in a few commands

All Boards Qtopia on Ubuntu

Patch to Support BT656 and BT1120 Output For i.MX6 BSP

移植国密密码工具箱GmSSL到i.MX平台Enable GmSSL which supports OSCCA Algorithm Toolbox on i.MX

Summary For Android development(environment_porting_debug)

eIQ Software release: EAR1 for i.MX applications processors (5/21 Update: Now released)

PN7150 NFC Controller on i.MX8M mini evk running Yocto

Adeneo Embedded experts launch 2 dedicated blogs !

i.MX53 QSB Board Get Started

Bring up i.MX6 via JTAG

A simple way to dump kmsg into mmc storage

Adding the WF111 Driver to the i.MX6 Yocto BSP

i.MX8QM dpu loopback to isi.

移植实时Linux方案Xenomai到i.MX ARMv7平台 (Enable real-time Linux Xenomai on i.MX ARMv7 Platform)

Q&A: How is VPU Latency on i.MX6

从用户空间的GPIO Sysfs接口访问用户空间的GPIO

GStreamer gst-inspect Tool

Using i.MX6Q to Build a Palm-Sized Heterogeneous Mini-HPC