i.MX Processors Knowledge Base

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

i.MX Processors Knowledge Base

Discussions

Sort by:
Symptoms   Trying to initialize a repo, for example:  $repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.36-2.1.0.xml we have the below log: File "/home/username/bin/repo", line 51 def print(self, *args, **kwargs): ^ SyntaxError: invalid syntax   Workaround (1)   The first workaround consist in change the python alternatives (caused when you have installed two or more python versions). NOTE: in my case, the python version that i want to change as first priority is python3.8 $sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.8 1   Then we run: $sudo update-alternatives --config python    To verify if your python priority was changed successfully try: $python --version   You should see the version configured as priority number 1.     Workaround (2)   The workaround is very simple, only we need modify the repo file $ nano ~/bin/repo   and we will change the python interpreter in the first line (from python to python3): ORIGINAL FILE   EDITED FILE   After to do this change, repo will works fine again.     I hope this can helps to you!   Best regards.
View full article
What is a device tree? The device tree is a data structure that is passed to the Linux kernel to describe the physical devices in a system. Before device trees came into use, the bootloader (for example, U-Boot) had to tell the kernel what machine type it was booting. Moreover, it had to pass other information such as memory size and location, kernel command line, etc. Sometimes, the device tree is confused with the Linux Kernel configuration, but the device tree specifies what devices are available and how they are accessed, not whether the hardware is used. The device tree is a structure composed of nodes and properties: Nodes: The node name is a label used to identify the node. Properties: A node may contain multiple properties arranged with a name and a value. Phandle: Property in one node that contains a pointer to another node. Aliases: The aliases node is an index of other nodes. A device tree is defined in a human-readable device tree syntax text file such as .dts or .dtsi. The machine has one or several .dts files that correspond to different hardware configurations. With these .dts files we can compile them into a device tree binary (.dtb) blobs that can either be attached to the kernel binary (for legacy compatibility) or, as is more commonly done, passed to the kernel by a bootloader like U-Boot. What is Devshell? The Devshell is a terminal shell that runs in the same context as the BitBake task engine. It is possible to run Devshell directly or it may spawn automatically. The advantage of this tool is that is automatically included when you configure and build a platform project so, you can start using it by installing the packages and following the setup of i.MX Yocto Project User's Guide on section 3 “Host Setup”. Steps: Now, let’s see how to compile your device tree files of i.MX devices using Devshell. On host machine. Modify or make your device tree on the next path: - 64 bits. ~/imx-yocto-bsp/<build directory>/tmp/work-shared/<machine>/kernel-source/arch/arm64/boot/dts/freescale - 32 bits. ~/imx-yocto-bsp/<build directory>/tmp/work-shared/<machine>/kernel-source/arch/arm/boot/dts To compile, it is needed to prepare the environment as is mentioned on i.MX Yocto Project User's Guide on section 5.1 “Build Configurations”. $ cd ~/imx-yocto-bsp $ DISTRO=fsl-imx-xwayland MACHINE=<machine> source imx-setup-release.sh -b <build directory> $ bitbake -c devshell virtual/kernel (it will open a new window) On Devshell window. $ make dtbs (after finished, close the Devshell window) On host machine. $ bitbake -c compile -f virtual/kernel $ bitbake -c deploy -f virtual/kernel This process will compile all the device tree files linked to the machine declared on setup environment and your device tree files will be deployed on the next path: ~/imx-yocto-bsp/<build directory>/tmp/deploy/images/<machine> I hope this article will be helpful. Best regards. Jorge.
View full article
Hello everyone, We have recently migrated our Source code from CAF (Codeaurora) to Github, so i.MX NXP old recipes/manifest that point to Codeaurora eventually will be modified so it points correctly to Github to avoid any issues while fetching using Yocto. Also, all repo init commands for old releases should be changed from: $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b <branch name> [ -m <release manifest>] To: $ repo init -u https://github.com/nxp-imx/imx-manifest -b <branch name> [ -m <release manifest>] This will also apply to all source code that was stored in Codeaurora, the new repository for all i.MX NXP source code is: https://github.com/nxp-imx For any issues regarding this, please create a community thread and/or a support ticket. Regards, Aldo.
View full article
This is a quick article focused on how to add the support of SFTP on the i.MX devices using Yocto to add that packages.   Refer to the pdf attached.
View full article
This is a quick article focused on how to add the support of the ssh on the i.MX devices using Yocto to add that packages.   Refer to the pdf attached.
View full article
This note show how to use the open source gstreamer1.0-rtsp-server package on i.MX6QDS and i.MX8x to stream video files and camera using RTP protocol.  The i.MX 6ULL and i.MX 7 doesn't have Video Processing Unit (VPU). Real Time protocol is a very common network protocol for delivering media over IP networks. On the board, you will need a GStreamer pipeline that encodes the raw video, adds the RTP payload, and sends over a network sink. A generic pipeline would look as follows: video source ! video encoder ! RTP payload ! network sink Video source: often it is a camera, but it can be a video from a file or a test pattern, for example. Video encoder: a video encoder as H.264, H.265, VP8, JPEG and others. RTP payload: an RTP payload that matches the video encoder. Network sink: a video sync that streams over the network, often via UDP.   Prerequisites: MX6x o MX8x board with the L5.10.35 BSP installed. A host PC with either Gstreamer or VLC player installed. Receiving h.264/h.265 Encoded RTP Video Stream on a Host Machine Using GStreamer GStreamer is a low-latency method for receiving RTP video. On your host machine, install Gstreamer and send the following command: $ gst-launch-1.0 -v udpsrc port=5000 caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay ! decodebin ! videoconvert ! autovideosink sync=false   Using Host PC: VLC Player Optionally, you can use VLC player to receive RTP video on a PC. First, in your PC, create a sdp file with the following content:  stream.sdpv=0m=video 5000 RTP/AVP 96c=IN IP4 127.0.0.1a=rtpmap:96 H264/90000 After this, with the GStreamer pipepline on the device running, open this .sdp file with VLC Player on the host PC. Sending h.264 and h.265 Encoded RTP Video Stream GStreamer provides an h.264 encoding element by software named x264enc. Use this plugin if your board does not support h.264 encoding by hardware or if you want to use the same pipeline on different modules. Note that the video performance will be lower compared with the plugins with encoding accelerated by hardware. # gst-launch-1.0 videotestsrc ! videoconvert ! x264enc ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000 Note: Replace <host-machine-ip> by the IP of the host machine. In all examples you can replace videotestsrc by v4l2src element to collect a stream from a camera   i.MX8X # gst-launch-1.0 videotestsrc ! videoconvert ! v4l2h264enc ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000   i.MX 8M Mini Quad/ 8M Plus # gst-launch-1.0 videotestsrc ! videoconvert ! vpuenc_h264 ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000 i.MX6X The i.MX6QDS does not support h.265 so the h.264 can work: # gst-launch-1.0 videotestsrc ! videoconvert ! vpuenc_h264 ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000   Using Other Video Encoders While examples of streaming video with other encoders are not provided, you may try it yourself. Use the gst-inspect tool to find available encoders and RTP payloaders on the board: # gst-inspect-1.0 | grep -e "encoder"# gst-inspect-1.0 | grep -e "rtp" -e " payloader" Then browse the results and replace the elements in the original pipelines. On the receiving end, you will have to use a corresponding payload. Inspect the payloader element to find the corresponding values. For example: # gst-inspect-1.0 rtph264pay   Install rtp in your yocto different form L5.10.35 BSP, to install gstreamer1.0-rtsp-server in any Yocto Project image, please follow the steps below: Enable meta-multimedia layer: Add the following on your build/conf/bblayers.conf: BBLAYERS += "$"${BSPDIR}/sources/meta-openembedded/meta-multimedia" Include gstreamer1.0-rtsp-server into the image: Add the following on your build/conf/local.conf: IMAGE_INSTALL_append += "gstreamer1.0-rtsp-server" Run bitbake and mount your sdcard. Copy the binaries: Access the gstreamer1.0-rtsp-server examples folder: $ cd /build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0-rtsp-server/$version/build/examples/.libs Copy the test-uri and test-launch to the rootfs /usr/bin folder. $ sudo cp test-uri test-launch /media/USER/ROOTFS_PATH/usr/bin Be sure that the IPs are correctly set: SERVER: => ifconfig eth0 $SERVERIP CLIENT: => ifconfig eth0 $CLIENTIP Video file example SERVER: => test-uri file:///home/root/video_file.mp4 CLIENT: => gst-launch-1.0 playbin uri=rtsp://$SERVERIP:8554/test You can try to improve the framerate performance using manual pipelines in the CLIENT with the rtspsrc plugin instead of playbin. Follow an example: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test caps = 'application/x-rtp'  ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! queue max-size-buffers=0 ! imxv4l2sink sync=false   Camera example SERVER: => test-launch "( imxv4l2src device=/dev/video0 ! capsfilter caps='video/x-raw, width=1280, height=720, framerate=30/1, mapping=/test' ! vpuenc_h264 ! rtph264pay name=pay0 pt=96 )" CLIENT: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test ! decodebin ! autovideosink sync=false The rtspsrc has two properties very useful for RTSP streaming: Latency: Useful for low-latency RTSP stream playback (default 200 ms); Buffer-mode: Used to control buffer mode. The slave mode is recommended for low-latency communications. Using these properties, the example below gets 29 FPS without a sync=false property in the sink plugin. The key achievement here is the fact that there is no dropped frame: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test latency=100 buffer-mode=slave ! queue max-size-buffers=0 ! rtph264depay ! vpudec ! imxv4l2sink      
View full article
Wayland:   Wayland is a display SERVER and COMPOSITION protocol. It is relatively new, as its first release was in 2012. The protocol enables applications to allocate their own off-screen buffers and render their window contents directly, using hardware accelerated libraries like OpenGL ES, or high quality software implementations like Cairo. Wayland is ONLY a display server protocol, not a display server itself. Weston is the reference Wayland protocol implementation.   YOCTO Setup . $ mkdir ~/bin $ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH $ git config --global user.name "Your Name" $ git config --global user.email "Your Email" $ git config –list $ mkdir fsl-release-bsp $ cd fsl-release-bsp $ repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-3.14.52-1.1.0_ga $ repo sync     you will be able to build Yocto and also have all the recipes to do so, we need to add WAYLAND, then execute the following steps: $ DISTRO=fsl-imx-wayland MACHINE=imx6qsabresd source fsl-setup-release.sh -b build-wayland $ bitbake fsl-image-gui After these steps, you will have a wayland based i.MX6Q image where you will be able to play with all the knowledge we provided here.   Once your image has been properly generated, you will find the Weston source codes in: <YOUR YOCTODIR>/build-wayland/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/weston/1.9.0-r0/weston-1.9.0     Wayland application for extended desktop: This functionality is only supported using the GAL2D blitter, in order to enable a multiple desktop approach, you need to pass the following parameters to your weston command: /etc/init.d/weston stop echo 0 > /sys/class/graphics/fb4/blank weston --tty=1 --use-gal2d=1 --use-gl=0 --device=/dev/fb0,/dev/fb4 &     Xwayland: Wayland is a complete window system in itself, but even so, if we're migrating away from X, it makes sense to have a good backwards compatibility story. With a few changes, the Xorg server can be modified to use wayland input devices for input and forward either the root window or individual top-level windows as wayland surfaces.   DISTRO=fsl-imx-xwayland MACHINE=imx6qsabresd source ./fsl-setup-release.sh -b build-xwayland bitbake fsl-image-gui Once you have the image your Wayland/Weston image will be able to run X11 applications   Excepting X11 applications that use EGL, we don’t support that, if you plan to use EGL apps, please use the Wayland provided functions to create the buffer.   Application for rotation: Weston allows rotating windows with super-key + middle mouse button. As this works for Wayland clients only, you can run Xwayland in weston, run your X application on Xwayland, and rotate the Xwayland display. For another option: Create a file ~/.config/weston.ini with this content: [core] modules=xwayland.so shell=desktop-shell.so idle-time=0 [shell] background-color=0xff002244 locking=false # panel-location=none    [launcher] icon=/usr/share/icons/gnome/24x24/apps/utilities-terminal.png path=/usr/bin/weston-terminal [launcher] icon=/usr/share/icons/hicolor/48x48/apps/firefox.png path=/usr/bin/firefox [output] name=X1 mode=640x800 transform=90 # wanna get mad? use: transform=flipped-270 scale=1 This weston.ini enables a rootless xwayland.so in weston. The [output] section with name=X1 defines weston's appearance as X client. transform=90 rotates the weston display.   the [launcher] sections can be used to create custom panel starters for your X applications. See  /usr/share/doc/weston/examples/weston.ini for more detailed information for further cases, I will attach in the future.
View full article
    OpenSSL is popular software library for applications that secure communications over computer networks against eavesdropping or need to identify the party at the other end. It is widely used in internet web servers, serving a majority of all web sites. OpenSSL contains an open-source implementation of the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols, it is a robust, commercial-grade, and full-featured toolkit for the SSL and TLS protocols. OpenSSL is also a general-purpose cryptography library. Its core library, written in the C programming language, implements basic cryptographic functions and provides various utility functions. Wrappers allowing the use of the OpenSSL library in a variety of computer languages are available. More and more embeded systems, like IoT gateway, ePOS, based on i.MX use OpenSSL for their secure communications and cryptographic operations. But it's cryptography library is pure software implementation which need to occupy lots of CPU resouce and the perfermance is very weak than dedicated hardware IP (like CAAM).    CAAM is the i.MX's cryptographic acceleration and assurance module, which serves as NXP's latest cryptographic acceleration and offloading hardware. It combines functions previously implemented in separate modules to create a modular and scalable acceleration and assurance engine. It also implements block encryption algorithms, stream cipher algorithms, hashing algorithms, public key algorithms (i.MX6UL/i.MX7D/S), and a hardware random number generator.   The official Yocto release (L4.1.15_2.0.0-ga) of the i.MX only enable cryptodev for accelerating symmetric algorithms and hashing algorithms, not support asymmetric algorithms(RSA, ECC). And its engine in OpenSSL(version 1.0.2h) also miss some features which is used to support symmetric algorithms and hashing algorithms, for example, AES ECB, SHA224/256, etc. These patches in the post will close the above gaps for i.MX Linux system. The software environments as the belows: Linux kernel: imx_4.1.15_2.0.0_ga cryptodev: 1.8 OpenSSL: 1.0.2h The patches include the following key features: 1, Add public key cryptography part in CAAM driver, through protocol commands, to implement a number of public (and private) key functions. These are DSA and ECDSA sign/verify, Diffie-Hellman (DH) and ECDH key agreement, ECC key generation, DLC key generation, RSA encryption/decryption, RSA key-generation finalization. 2, Add big number operation and elliptic curve math in CAAM driver to implement addition, subtraction, multiplication, exponentiation, reduction, inversion, greatest common divisor, prime testing and point add, point double, point multiply. 3, Add API in cryptodev to support RSA encryption/decryption, DSA/ECDSA sign/verify, DH/ECDH key agreement, ECC & DLC & RSA key generation and big number operation and elliptic curve math. 4, Add public key cryptography functions, hardware rng, and missing hash symmetric algorithms in OpenSSL crytodev engine. Note: 1, You can refer to ecdhtest.c, ecdsatest.c, dhtest.c, dsatest.c, rsa_test.c for how to use crytodev engine in your applications based on libcryto.so. You can also find their executable programs in folder openssl-1.0.2h/test after compiling. 2, If you want to call crytodev API directly to accelerate public key cryptography operations, please refer to asymmetric_cipher.c in cryptodev-linux-1.8/tests. Current Limitation: 1, CAAM driver don't support AES GCM/CCM but hardware supporting. I plan to add the feature next version. 2, ECDSA sign/verify will fail on some binary curves (sect163r1, sect163r2, sect193r1, sect193r2, sect233r1, sect283r1, sect409r1, sect571r1 and X9.62 binary curves). I will try to find the root cause and fix it.   ==================================== for  some binary curves (sect163r1, sect163r2, sect193r1, sect193r2, sect233r1, sect283r1, sect409r1, sect571r1 and X9.62 binary curves)  are rarely used, so i will try to find the root cause when i'm free.  +++++++++++++++++++++++    updating for Linux-4.14.78-1.1.10 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux -4.14.78-1.1.10. The new software environments as the belows: Linux kernel: imx_4.14.78_1.1.10 cryptodev: 1.9 OpenSSL: 1.0.2p HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini, i.MX8/8X. The patches include the following new features: 1, support  RSA key generation but defaultly use openssl build-in function (BN_generate_prime_ex) to create prime p, q for higher security. If need to use CAAM accelerating,  please comment Macro USE_BUILTIN_PRIME_GENERATION, but don't confirm its security. 2, Add Manufacturing-protection feature, and you can refer to manufacturing_protection_test function in asymmetric_cipher.c. 3, Support AES GCM in cryptodev. 4, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-4.14.78-1.1.10 and copy meta-openssl-caam to folder <Yocto 4.14.78-1.1.10 dir>/sources/ 5, Run DISTRO=fsl-imx-wayland MACHINE=imx6ulevk source fsl-setup-release.sh -b build-imx6ulevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into /build-imx6ulevk/conf/bblayers.conf 6, bitbake fsl-image-validation-imx 7, Run the below command on your i.MX6UL EVK board. modprobe cryptodev openssl genrsa -f4 -engine cryptodev 512 -elapsed openssl speed dsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 1024 -elapsed openssl speed rsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 2048 -elapsed openssl speed ecdsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 3072 -elapsed openssl speed ecdh -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 4096 -elapsed openssl speed -evp sha256 -engine cryptodev -elapsed openssl speed -evp aes-128-cbc -engine cryptodev -elapsed openssl speed -evp aes-128-ecb -engine cryptodev -elapsed openssl speed -evp aes-128-cfb -engine cryptodev -elapsed openssl speed -evp aes-128-ofb -engine cryptodev -elapsed openssl speed -evp des-ede3 -engine cryptodev -elapsed openssl speed -evp des-cbc -engine cryptodev -elapsed openssl speed -evp des-ede3-cfb -engine cryptodev -elapsed +++++++++++++++++++++++    updating for Linux-4.14.98-2.3.3 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux -4.14.98-2.3.3. The new software environments as the belows: Linux kernel: imx_4.14.98-2.3.3 cryptodev: 1.9 OpenSSL: 1.0.2p HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano, i.MX8/8X. The patches include the following new features: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-4.14.98-2.3.3 and copy meta-openssl-caam to folder <Yocto 4.14.98-2.3.3 dir>/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8mmevk source fsl-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into /build-imx8mmevk/conf/bblayers.conf 3, bitbake fsl-image-validation-imx 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl genrsa -f4 -engine cryptodev 512 -elapsed openssl speed dsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 1024 -elapsed openssl speed rsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 2048 -elapsed openssl speed ecdsa -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 3072 -elapsed openssl speed ecdh -engine cryptodev -elapsed openssl genrsa -f4 -engine cryptodev 4096 -elapsed openssl speed -evp sha256 -engine cryptodev -elapsed openssl speed -evp aes-128-cbc -engine cryptodev -elapsed openssl speed -evp aes-128-ecb -engine cryptodev -elapsed openssl speed -evp aes-128-cfb -engine cryptodev -elapsed openssl speed -evp aes-128-ofb -engine cryptodev -elapsed openssl speed -evp des-ede3 -engine cryptodev -elapsed openssl speed -evp des-cbc -engine cryptodev -elapsed openssl speed -evp des-ede3-cfb -engine cryptodev -elapsed +++++++++++++++++++++++    updating for Linux-4.19.35-1.1.2 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 4.19.35-1.1.2​​.  Software environments as the belows: Linux kernel: imx_4.19.35-1.1.2 cryptodev: 1.10 OpenSSL: 1.1.1l HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano, i.MX8/8X. How to build: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-4.19.35-1.1.2 and copy meta-openssl-caam to folder <Yocto 4.19.35-1.1.2 dir>/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into <Yocto 4.19.35-1.1.2 dir>/build-imx8mmevk/conf/bblayers.conf. 3, Run bitbake fsl-image-validation-imx. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl speed dsa openssl speed rsa openssl speed ecdsa openssl speed ecdh openssl genrsa -f4 -engine devcrypto 512 openssl genrsa -f4 -engine devcrypto 1024 openssl genrsa -f4 -engine devcrypto 2048 openssl genrsa -f4 -engine devcrypto 3072 openssl genrsa -f4 -engine devcrypto 4096 openssl speed -evp sha256 -engine devcrypto -elapsed openssl speed -evp aes-128-cbc -engine devcrypto -elapsed openssl speed -evp aes-128-ecb -engine devcrypto -elapsed openssl speed -evp aes-128-cfb -engine devcrypto -elapsed openssl speed -evp aes-128-ofb -engine devcrypto -elapsed openssl speed -evp des-ede3 -engine devcrypto -elapsed openssl speed -evp des-cbc -engine devcrypto -elapsed openssl speed -evp des-ede3-cfb -engine devcrypto -elapsed +++++++++++++++++++++++    updating for Linux-5.4.70-2.3.4 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.4.70_2.3.4​​.  Software environments as the belows: Linux kernel: imx_5.4.70_2.3.4 cryptodev: 1.10 OpenSSL: 1.1.1l HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano/8M Plus, i.MX8/8X. How to build: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-5.4.70-2.3.4  and copy meta-openssl-caam to folder <Yocto 5.4.70_2.3.4 dir>/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into <Yocto 5.4.70_2.3.4 dir>/build-imx8mmevk/conf/bblayers.conf. 3, Run bitbake imx-image-multimedia. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl speed dsa openssl speed rsa openssl speed ecdsa openssl speed ecdh openssl genrsa -f4 -engine devcrypto 512 openssl genrsa -f4 -engine devcrypto 1024 openssl genrsa -f4 -engine devcrypto 2048 openssl genrsa -f4 -engine devcrypto 3072 openssl genrsa -f4 -engine devcrypto 4096 openssl speed -evp sha256 -engine devcrypto -elapsed openssl speed -evp aes-128-cbc -engine devcrypto -elapsed openssl speed -evp aes-128-ecb -engine devcrypto -elapsed openssl speed -evp aes-128-cfb -engine devcrypto -elapsed openssl speed -evp aes-128-ofb -engine devcrypto -elapsed openssl speed -evp des-ede3 -engine devcrypto -elapsed openssl speed -evp des-cbc -engine devcrypto -elapsed openssl speed -evp des-ede3-cfb -engine devcrypto -elapsed     +++++++++++++++++++++++    updating for Linux-5.10.52-2.1.0 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.10.52_2.1.0​​.  Software environments as the belows: Linux kernel: lf-5.10.y cryptodev: 1.12 OpenSSL: 1.1.1l HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano/8M Plus, i.MX8/8X. How to build: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-5.10.52-2.1.0 and copy meta-openssl-caam to folder <Yocto 5.10.52_2.1.0 dir>/sources/ 2, Run DISTRO=fsl-imx-xwayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into <Yocto 5.10.52_2.1.0 dir>/build-imx8mmevk/conf/bblayers.conf. 3, Run bitbake imx-image-multimedia. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl speed dsa openssl speed rsa openssl speed ecdsa openssl speed ecdh openssl genrsa -f4 -engine devcrypto 512 openssl genrsa -f4 -engine devcrypto 1024 openssl genrsa -f4 -engine devcrypto 2048 openssl genrsa -f4 -engine devcrypto 3072 openssl genrsa -f4 -engine devcrypto 4096 openssl speed -evp sha256 -engine devcrypto -elapsed openssl speed -evp aes-128-cbc -engine devcrypto -elapsed openssl speed -evp aes-128-ecb -engine devcrypto -elapsed openssl speed -evp aes-128-cfb -engine devcrypto -elapsed openssl speed -evp aes-128-ofb -engine devcrypto -elapsed openssl speed -evp des-ede3 -engine devcrypto -elapsed openssl speed -evp des-cbc -engine devcrypto -elapsed openssl speed -evp des-ede3-cfb -engine devcrypto -elapsed   +++++++++++++++++++++++    updating for Linux-5.15.71-2.2.0 ++++++++++++++++++++++++++++ This updating is for Yocto release of Linux 5.15.71-2.2.0​​.  Software environments as the belows: Linux kernel: lf-5.15.71-2.2.0 cryptodev: 1.12 OpenSSL: 3.1.0 HW platform: i.MX6UL, i.MX7D/S, i.MX8M/8M Mini/8M Nano/8M Plus, i.MX8/8X. How to build: 1, git clone https://gitee.com/zxd2021-imx/meta-openssl-caam.git, git checkout Linux-5.15.71-2.2.0 and copy meta-openssl-caam to folder <Yocto 5.15.71_2.2.0 dir>/sources/ 2, Run DISTRO=fsl-imx-xwayland MACHINE=imx8mmevk source imx-setup-release.sh -b build-imx8mmevk and add BBLAYERS += " ${BSPDIR}/sources/meta-openssl-caam " into <Yocto 5.15.71_2.2.0 dir>/build-imx8mmevk/conf/bblayers.conf. 3, Run bitbake imx-image-multimedia. 4, Run the below command on your i.MX8M Mini EVK board. modprobe cryptodev openssl speed sm2 openssl speed dsa openssl speed rsa openssl speed ecdsa openssl speed ecdh openssl genrsa -f4 -engine devcrypto 512 openssl genrsa -f4 -engine devcrypto 1024 openssl genrsa -f4 -engine devcrypto 2048 openssl genrsa -f4 -engine devcrypto 3072 openssl genrsa -f4 -engine devcrypto 4096 openssl speed -evp sha256 -engine devcrypto -elapsed openssl speed -evp aes-128-cbc -engine devcrypto -elapsed openssl speed -evp aes-128-ecb -engine devcrypto -elapsed openssl speed -evp aes-128-cfb -engine devcrypto -elapsed openssl speed -evp aes-128-ofb -engine devcrypto -elapsed openssl speed -evp des-ede3 -engine devcrypto -elapsed openssl speed -evp des-cbc -engine devcrypto -elapsed openssl speed -evp des-ede3-cfb -engine devcrypto -elapsed    
View full article
Hello there. Here is a good way to use U-boot in an efficient way with custom scripts. The bootscript is an script that is automatically executed when the boot loader starts, and before the OS auto boot process. The bootscript allows the user to execute a set of predefined U-Boot commands automatically before proceeding with normal OS boot. This is especially useful for production environments and targets which don’t have an available serial port for showing the U-Boot monitor. This information can be find in U-Boot Reference Manual.   I will take the example load a binary file in CORTEX M4 of IMX8MM-EVK. In my case, I have the binary file in MMC 2:1 called gpio.bin and I will skip those steps because that is not the goal.   First, you need the u-boot-tools installed in your Linux machine: sudo apt install u-boot-tools   That package provide to us the tool mkimage to convert a text file (.src, .txt) file to a bootscript file for U-Boot.   Now, create your custom script, in this case a simple script for load binary file in Cortex M4: nano mycustomscript.scr  and write your U-Boot commands: fatload mmc 2:1 0x80000000 gpio.bin cp.b 0x80000000 0x7e0000 0x10000 bootaux 0x7e0000   Now we can convert the text file to bootscript with mkimage. Syntax: mkimage -T script -n "Bootscript" -C none -d <input_file> <output_file> mkimage -T script -n "Bootscript" -C none -d mycustomscript.scr LCM4-bootscript   This will create a file called LCM4-bootscript (Or as your called it).   A way to load this bootscript file to U-Boot is using the UUU tool, in U-Boot set the device in fastboot with command: u-boot=> fastboot 0 Then in linux with the board connected through USB to PC run the command: sudo uuu -b fat_write LCM4-bootscript mmc 2:1 LCM4-bootscript   Now we have our bootscript in U-Boot in MMC 2:1.   Finally, we can run the bootscript in U-Boot: u-boot=> load mmc 2:1 ${loadaddr} LCM4-bootscript 158 bytes read in 2 ms (77.1 KiB/s) u-boot=> source ${loadaddr} ## Executing script at 40400000 6656 bytes read in 5 ms (1.3 MiB/s) ## No elf image at address 0x007e0000 ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE02CD...   And the Cortex M4 booted successfully:    I hope this can helps to you.   Best regards.   Salas.  
View full article
In some cases, such as mass production or preparing a demo. We need u-boot environment stored in demo sdcard mirror image.  Here is a way: HW:  i.MX8MP evk SW:  LF_v5.15.52-2.1.0_images_IMX8MPEVK.zip The idea is to use fw_setenv to set the sdcard mirror as the operation on a real emmc/sdcard. Add test=ABCD in u-boot-initial-env for test purpose. And use fw_printenv to check and use hexdump to double confirm it. The uboot env is already written into sdcard mirror(imx-image-multimedia-imx8mpevk.wic). All those operations are on the host x86/x64 PC. ./fw_setenv -c fw_env.config -f u-boot-initial-env Environment WRONG, copy 0 Cannot read environment, using default ./fw_printenv -c fw_env.config Environment OK, copy 0 jh_root_dtb=imx8mp-evk-root.dtb loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bsp_script}; mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi arch=arm baudrate=115200 ...... ...... ...... splashimage=0x50000000 test=ABCD usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi vendor=freescale hexdump -s 0x400000 -n 2000 -C imx-image-multimedia-imx8mpevk.wic 00400000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| hexdump -s 0x400000 -n 10000 -C imx-image-multimedia-imx8mpevk.wic 00400000 5f a4 9b 97 20 6a 68 5f 72 6f 6f 74 5f 64 74 62 |_... jh_root_dtb| 00400010 3d 69 6d 78 38 6d 70 2d 65 76 6b 2d 72 6f 6f 74 |=imx8mp-evk-root| 00400020 2e 64 74 62 00 20 6c 6f 61 64 62 6f 6f 74 73 63 |.dtb. loadbootsc| 00400030 72 69 70 74 3d 66 61 74 6c 6f 61 64 20 6d 6d 63 |ript=fatload mmc| 00400040 20 24 7b 6d 6d 63 64 65 76 7d 3a 24 7b 6d 6d 63 | ${mmcdev}:${mmc| 00400050 70 61 72 74 7d 20 24 7b 6c 6f 61 64 61 64 64 72 |part} ${loadaddr| 00400060 7d 20 24 7b 62 73 70 5f 73 63 72 69 70 74 7d 3b |} ${bsp_script};| 00400070 00 20 6d 6d 63 5f 62 6f 6f 74 3d 69 66 20 6d 6d |. mmc_boot=if mm| ...... ...... ...... 00401390 76 3d 31 00 73 6f 63 3d 69 6d 78 38 6d 00 73 70 |v=1.soc=imx8m.sp| 004013a0 6c 61 73 68 69 6d 61 67 65 3d 30 78 35 30 30 30 |lashimage=0x5000| 004013b0 30 30 30 30 00 74 65 73 74 3d 41 42 43 44 00 75 |0000.test=ABCD.u| 004013c0 73 62 5f 62 6f 6f 74 3d 75 73 62 20 73 74 61 72 |sb_boot=usb star| 004013d0 74 3b 20 69 66 20 75 73 62 20 64 65 76 20 24 7b |t; if usb dev ${| 004013e0 64 65 76 6e 75 6d 7d 3b 20 74 68 65 6e 20 64 65 |devnum}; then de| flash the sdcard mirror into i.MX8MP evk board emmc to check uuu -b emmc_all imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk imx-image-multimedia-imx8mpevk.wic  The first time boot, the enviroment is already there.  How to achieve that: a. fw_setenv/fw_printenv: https://github.com/sbabic/libubootenv.git Note: Please do not use uboot fw_setenv/fw_printenv Compile it on the host x86/x64 PC. It is used on host. b. u-boot-initial-env Under uboot, make u-boot-initial-env Note: Yocto deploys u-boot-initial-env by default c. fw_env.config  imx-image-multimedia-imx8mpevk.wic 0x400000 0x4000 0x400000 0x4000 are from uboot-imx\configs\imx8mp_evk_defconfig CONFIG_ENV_SIZE=0x4000 CONFIG_ENV_OFFSET=0x400000 Now, you can run  ./fw_setenv -c fw_env.config -f u-boot-initial-env
View full article
We will build a remote debug environmet of Qt Creator in this user guide.   Contents 1 Change local.conf file in Yocto 2 2 Build and deploy Yocto SDK 2 2.1 Build full image SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Deploy SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 Configure QT Kit 2 3.1 Setup device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.2 Configure QT version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3 Configure gcc and g++ manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4 Configure gdb manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5 Configure Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6 Very important thing!! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Test result
View full article
This is based on L5.10.35 BSP where you have to install QT static build: Qt 5.15 static build: Assuming your sysroot is at "/sysroot-cross" and your toolchain is at "/Toolchain" your qt-source is at /Qt-5.15 PATH=/sysroot-cross/bin:/sysroot-cross/sbin:/Toolchain/bin mkdir /Qt-5.15/mkspecs/qws/linux-imx6-g++ create in this dir the textfile "qmake.conf" with this content: ####################### snip qmake.conf ############################## include(../../common/linux.conf) include(../../common/qws.conf) # modifications to g++.conf QMAKE_CC                = arm-linux-gnueabi-gcc QMAKE_CFLAGS            = -pipe -isystem /sysroot-cross/include -isystem /sysroot-cross/usr/include QMAKE_CXX               = arm-linux-gnueabi-g++ QMAKE_CXXFLAGS          = -pipe -isystem /sysroot-cross/include -isystem /sysroot-cross/usr/include QMAKE_INCDIR            = /sysroot-cross/include /sysroot-cross/usr/include QMAKE_LIBDIR            = /sysroot-cross/lib /sysroot-cross/usr/lib QMAKE_LINK              = arm-linux-gnueabi-g++ QMAKE_LINK_SHLIB        = arm-linux-gnueabi-g++ QMAKE_LFLAGS            = -L/sysroot-cross/lib -L/sysroot-cross/usr/lib -Wl,-rpath-link -Wl,/sysroot-cross/lib QMAKE_LFLAGS           += -Wl,-rpath-link -Wl,/sysroot-cross/usr/lib #Opengl QMAKE_INCDIR_OPENGL = /Vivante/include QMAKE_INCDIR_OPENGL += /Vivante/include/GL QMAKE_INCDIR_OPENGL += /Vivante/include/EGL QMAKE_INCDIR_OPENGL += /Vivante/include/GLES2 QMAKE_LIBDIR_OPENGL = /Vivante/lib QMAKE_INCDIR_OPENGL_ES1 = $$QMAKE_INCDIR_OPENGL QMAKE_LIBDIR_OPENGL_ES1 = $$QMAKE_LIBDIR_OPENGL QMAKE_INCDIR_OPENGL_ES1CL = $$QMAKE_INCDIR_OPENGL QMAKE_LIBDIR_OPENGL_ES1CL = $$QMAKE_LIBDIR_OPENGL QMAKE_INCDIR_OPENGL_ES2 = /Vivante/include QMAKE_INCDIR_OPENGL_ES2 += /Vivante/include/EGL QMAKE_INCDIR_OPENGL_ES2 += /Vivante/include/GLES2 QMAKE_LIBDIR_OPENGL_ES2 = $$QMAKE_LIBDIR_OPENGL QMAKE_INCDIR_EGL = $$QMAKE_INCDIR_OPENGL_ES2 QMAKE_LIBDIR_EGL = $$QMAKE_LIBDIR_OPENGL QMAKE_LIBS_EGL = -lEGL -lGAL -lGLESv2 -lGLES_CM QMAKE_LIBS_OPENGL_ES2 = -lEGL -lGAL -lGLESv2 -lGLES_CM QMAKE_LIBS_OPENGL = -lEGL -lGAL -lGLESv2 -lGLES_CM QMAKE_LIBS_OPENGL_QT = -lEGL -lGAL -lGLESv2 -lGLES_CM QMAKE_LIBS_OPENGL_ES1 = QMAKE_LIBS_OPENGL_ES1CL = # modifications to linux.conf QMAKE_AR                = arm-linux-gnueabi-ar cqs QMAKE_OBJCOPY           = arm-linux-gnueabi-objcopy QMAKE_STRIP             = arm-linux-gnueabi-strip QMAKE_CFLAGS_RELEASE   = -pipe -isystem /sysroot-cross/include -isystem /sysroot-cross/usr/include load(qt_config) ####################### snip qmake.conf ############################## create in the same dir the text file "qplatformdefs.h" ####################### snip qplatformdefs.h ############################## #include "../../linux-g++/qplatformdefs.h" ####################### snip qplatformdefs.h ############################## now goto dir /Qt-5.15 cd /Qt-5.15 call configure with ./configure -opensource -confirm-license -release -no-rpath -no-fast \     -no-sql-ibase -no-sql-mysql -no-sql-odbc -no-sql-psql -no-sql-sqlite2 \     -no-qt3support -no-mmx -no-3dnow -no-sse -no-sse2 -no-sse3 -no-ssse3 \     -no-sse4.1 -no-sse4.2 -no-avx -no-optimized-qmake -no-nis -no-cups -pch \     -reduce-relocations -force-pkg-config -prefix /usr -no-armfpa -make libs \     -nomake docs -little-endian -embedded armv6 -qt-decoration-styled \     -depths all -xplatform qws/linux-imx6-g++ -iconv -largefile -qt-gfx-linuxfb \     -qt-gfx-multiscreen -qt-mouse-pc -qt-mouse-linuxinput -qt-libpng \     -plugin-gfx-directfb -system-zlib -no-accessibility -no-gfx-transformed \     -no-gfx-qvfb -no-gfx-vnc -no-kbd-tty -no-kbd-linuxinput -no-kbd-qvfb \     -no-mouse-linuxtp -no-mouse-tslib -no-mouse-qvfb -no-libmng -no-libtiff \     -no-gif -no-libjpeg -no-freetype -no-stl -no-glib -no-openssl -no-egl \     -no-xmlpatterns -no-exceptions -no-multimedia -no-audio-backend -no-phonon \     -no-phonon-backend -no-webkit -no-script -no-scripttools -no-svg -no-script \     -no-declarative -no-sql-sqlite -no-qdbus -no-opengl -static -nomake tools \     -nomake examples -nomake demos when configuring is finished call make after a looong time, when everything goes right, we have a staticly compiled Qt. DO NOT call "make install". We will install manually: copy from /Qt-5.15/bin the files moc, uic, rcc and qmake to somewhere in PATH, eg. /sysroot-cross/bin copy the contents of dir /Qt-5.15/mkspecs to /sysroot-cross/usr/mkspec copy the contents of dir /Qt-5.15/plugins to /sysroot-cross/usr/plugins copy the contents of dir /Qt-5.15/include to /sysroot-cross/usr/include copy the contents of dir /Qt-5.15/lib to /sysroot-cross/usr/lib Test application camtest: if you don't have/want directfb plugin remove from camtest.pro the lines LIBS += -L/sysroot-cross/usr/plugins/gfxdrivers QTPLUGIN += QDirectFBScreen and the lines from main.cpp #include <QtPlugin> Q_IMPORT_PLUGIN(qdirectfbscreen) generate makefile by typing /sysroot-cross/bin/qmake -spec /sysroot-cross/usr/mkspecs/qws/linux-imx6-g++ camtest.pro then make you should set and activate your framebuffers with this script ################# snip ################################ fbset -fb /dev/fb0 -g 1024 768 1024 2304 16 echo -n 0 > /sys/class/graphics/fb0/blank fbset -fb /dev/fb1 -g 1024 768 1024 1536 32 echo -n 0 > /sys/class/graphics/fb1/blank modprobe galcore modprobe uvcvideo modprobe mxc_v4l2_capture ################# snip ################################ if you use directfb then your /etc/directfbrc file should look like this: ######################## snip /etc/directfbrc ############# system=fbdev fbdev=/dev/fb1 mode=1024x768 depth=32 pixelformat=ARGB no-cursor window-surface-policy=systemonly ######################## snip /etc/directfbrc ############# to start the application with directfb: ./camtest -qws -display directfb without directfb using linuxfb: ./camtest -qws -display linuxfb:/dev/fb1 Notes about application: 1. The application shows 2 webcams in background-framebuffer (BG-FB). The foreground-framebuffer (FG-FB) shows the qt-gui. FG-FB is configured to be fully opaque and uses color-keying. On the BG-FB one cam is overlayed on the other cam using IPU. Optimization possibilities: the app copies the frames from the cams with memcpy. This wouldn't be necessary, when the kernel usb-webcam interface (uvc) would support V4L2_MEMORY_USERPTR method. through this way, you could pass the mapped IPU mmapped inbufs directly to v4l2 output buffers. If you get errors like NOSPC (-28) from uvc, this is a limitation of USB. My board is a MX6QSabre, where the two webcams are connected to the same usb-controller. With both webcams I had to limit the frame size to 320x250 and 160x120 at 25Hz. You might try higher res if you have other type of webcams (not usb). Have fun  
View full article
  Question: How can we generate an ARM DS5 DStream format DDR initialization script using the DRAM Register Programming Aid?  Answer: Some RPAs include a  "DStream .ds file" tab for the ARM DS5 debugger specific commands. The i.MX6UL/ULL/ULZ DRAM Register Programming Aids for example already has this supported. However, the user can easily create  the .ds format from the existing .inc format. The basic steps to convert .inc files to .ds format are as follows: 1)  Replace the one instance of setmem /16 with mem set 2)  In that same line, replace 0x020bc000 = with 0x020bc000 16 3)  Use a Replace All command to change setmem /32 with mem set 4)  Use a Replace All command to change = with 32 5)  Use a Replace All command to change // with # 6)  Save as a .ds file.   Question: When using a 528MHz DRAM Controller interface with a DDR memory of a faster speed bin, which speed bin timing options should one use? Answer: For example, let’s assume our MX6DQ design is using a DDR3 memory from a DDR3-1600 speed bin.  However, the maximum speed of the MMDC interface for the MX6DQ using DDR3 is 528MHz.  Should we use the 1600 speed bin (800MHz clock speed) or the 1066 speed bin (533MHz clock speed)?  In short, the user should use the timings rated for the maximum speed (frequency) with which you are running, in this case DDR3-1066 (533MHz).  In some cases, like when using the MX6DL, the maximum DDR frequency is 400MHz.  In this case, you would want to try and use 800 timings found in the AC timing parameters table.  However, most DDR3 devices have speed bin tables that may go only as low as 1066, in which case you would use the closest speed bin to your operational frequency (i.e. the 1066 speed bin table).     Question: Some timing parameters may specify a min and max number, which should I use? Answer: In most cases, you will want to choose the minimum timings.  Some DRAM controllers may have a tRAS_MAX timing parameter, in which case you would obviously use the maximum tRAS parameter given in the DRAM data sheet. Also, for timing parameters tAONPD and tAOFPD, we also want to use the maximum values given in the DDR3 data sheet. These represent the maximum amount of time the DDR3 device takes to turn on or off the RTT (termination), therefore, we should wait at least this amount of time before issuing any commands or accesses.   Question: Some timing parameters state things like “Greater of 3CK or 7.5ns”; which should I use? Answer: This depends on your clock speed.  Say you are running at 533MHz.  At 533MHz, 7.5ns equates to 4CKs.  In this case, 7.5ns at 533MHz is GREATER than 3CK, so we would use the 7.5ns number, or 4CKs. At 400MHz, 7.5ns equates to 3CKs.  In this case, we’d simply use 3CKs.   Question: I have a design that will throttle the DDR frequency (dynamic frequency scaling).  At full speed, I plan to run at 533MHz, and then I plan to throttle down to say 400MHz whenever possible.  Do I need to re-calculate my 400 MHz timing parameters that were initially set for 533MHz? Answer: It is not necessary to re-calculate timing parameters for 400MHz, and you can re-use the ones for 533MHz.  The timings at 533 MHz are much tighter than 400 MHz, and the key here is to NOT violate timings.  Also, it may be a bit of a hassle maintaining two sets of timing parameters, especially if later in the design, you swap DDR vendors that might require you to re-calculate some timing parameters.  It’s easier to do it once and to come up with a combined worse-case timing parameters for 533MHz, which you know will work at 400MHz.  But, if you don’t mind maintaining two sets of timing parameters, and really want to optimize timings down to the last pico-second for 400MHz, then knock yourself out.   Question: Can I use these Register programming aids for both Fly by and T- Topology ? Answer Yes The DDR register programming aid is agnostic to the DDR layout. The same spreadsheet works for both topologies. We recommend running write leveling calibration for both topologies and the values returned by the Write Leveling routine from the Freescale DDR stress test should be incorporated back to the customer specific initialization script. The DDR stress test also has a feature whereby it evaluates the write leveling values returned from calibration and increments WALAT to 1 if the values exceed a defined limit. The DDR stress test informs the user when the Write Additional latency (WALAT) exceeds the limit and should be increased by 1, and reminds the user to add it back in the customer specific initialization script if required.   WALAT - 0 00000000 WALAT: Write Additional latency. Recommend to clear these bits. Proper board design should ensure that the DDR3 devices are placed close enough to the MMDC to ensure the skew between CLK and DQS is less than 1 cycle.     Question: Can I use the DEFAULT Register programming aid values for MDOR when using an Internal OSC instead of the recommended 32.768 KHZ XTAL ? Answer No, NXP recommends reprogramming these values based on the worse case frequency (Max clock) of the internal OSC of the device to guarantee JEDEC timings are met. Please refer to Internal Oscillator Accuracy considerations for the i.MX 6 Series for more details  
View full article
Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. i.MX 6/7 Series Family DDR Tools Overview This page contains the latest releases for the i.MX 6/7 series DDR Tools. The tools described on this page cover the following i.MX 6/7 series SoCs: i.MX 6DQP (Dual/Quad Plus) i.MX 6DQ (Dual/Quad) i.MX 6DL/S (Dual Lite/Solo) i.MX 6SoloX i.MX 6SL i.MX 6SLL i.MX 6UL i.MX 6ULL/ULZ i.MX 7D/S i.MX 7ULP The purpose of the i.MX 6/7 series DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.). This process equips the user to then proceed with the bring-up of a boot loader and an OS. Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface. The i.MX 6/7 series DDR Tools consist of: DDR Register Programming Aid (RPA) DDR Stress test _________________________________________________________ i.MX 6/7 Series DDR Stress Test The i.MX 6/7 Series DDR stress test tool is a Windows-based software tool that is used as a mechanism to verify that the DDR initialization is operational prior for use in u-boot and OS bring-up. The DDR Stress Test tool can be found here: i.MX 6/7 DDR Stress Test Tool Note that the DDR Stress test tool supports all of the above i.MX SoCs, however, some of the supported i.MX SoCs named in the tool support multiple i.MX SoCs as follows: MX6DQ – when selected, this supports both i.MX 6DQ and i.MX 6DQP (Plus) MX6DL – when selected, this supports both i.MX 6DL and i.MX 6S (i.MX 6DLS family) MX6ULL – when selected, this supports both i.MX 6ULL and i.MX6 ULZ MX7D – when selected, this supports both i.MX 7D and i.MX 7S _____________________________________________________________________________ i.MX 6/7 Series DDR Register Programming Aid (RPA) The i.MX 6/7 series DDR RPA (or simply RPA) is an Excel spreadsheet tool used to develop DDR initialization for a user’s specific DDR configuration (DDR device type, density, etc.). The RPA generates the DDR initialization script for use with the DDR Stress Test tool. For a history of the previous versions of an RPA, refer to the Revision History tab of the respective RPA. To obtain the latest RPAs, please refer to the following links: i.MX 6DQP i.MX6DQP Register Programming Aids i.MX 6DQ i.MX6DQ Register Programming Aids i.MX 6DL/S i.MX6DL Register Programming Aids i.MX 6SoloX i.MX6SX Register Programming Aids i.MX 6SL i.MX6SL Register Programming Aids  i.MX6SLL i.MX6SLL Register Programming Aids i.MX 6UL/ULL/ULZ i.MX6UL/ULL/ULZ DRAM Register Programming Aids i.MX7D i.MX7D DRAM Register Programming Aids i.MX 7ULP i.MX7ULP DRAM Register Programming Aids _____________________________________________________________________________ DRAM Register Programming Aids FAQ    
View full article
      The i.MX6UL/LL/LZ processor supports 2 USB OTG interfaces, USB OTG1 and USB OTG2, and each USB interface can be configured as a device, host or dual role mode. On the EVK board of i.MX6UL/LL, USB OTG1 is designed as dual role mode, and USB OTG2 is designed as HOST mode. This is sufficient for most customers.       However, in actual applications, we may need 2 USB HOSTs, and at the same time, we don’t want to use MicroUSB to USB TYPE-AF cable for Host-Device mode conversion. Therefore, the design of the USB circuit needs to meet such requirements: 1. USB device mode We need a USB device to download the linux image to the flash or SD card on the board. 2. 2 USB HOSTs When the system is working normally, we need the board to support 2 USB HOST. i.MX6UL/LL/LZ has only 2 USB ports. How to design to meet this requirement without increasing the USB HUB? The following scheme is used as a reference, and I hope it will be helpful to customers with similar requirement:        The logic and application description of this Diagram:: Default—device mode In the process of debugging the software, we need to use the USB OTG interface to download the linux image, so it must work in device mode. What we need to do is: (1). Pull USB OTG ID up to 3.3V (2). The USB OTG D+/D- signal is switched to the MicroUSB connector. (3). The USB OTG VBUS is provided with 5V power from the external PC USB HOST. Usage:        -Use a jumper for Pin 1 and Pin2, USB OTG ID pin will be pulled up to High.        With the operation, SEL pin of USB Muxer is High, and USB signals are switched to port B, and USB differential signals are connected to MicroUSB connector. At the same time, MIC2026-1YM output is disabled. The USB OTG1 VBUS pin of CPU is supplied by VBUS of MicroUSB connector, that is to say, supplied by PC USB HOST.        In this mode, software engineer can use it to download images to flash on board. Normal Work—Host mode After the software debugging is completed, two HOSTs are needed on the board. At this time, we need to switch the USB OTG1 from device to HOST mode. What we need to do is: (1). Pull USB OTG1 ID down to LOW (2). The USB OTG D+/D- signal is switched to the USB Type-AF connector. (3). Board should supply 5V power for USB device connected USB Type-AF connector. Usage:        -Use a jumper for Pin 2 and Pin3, USB OTG ID pin will be pulled down to Low.        With the operation, USB OTG1 ID pin is pulled down to Low, SEL pin of USB Muxer is also LOW, USB signals are switched to Port A, and connected to USB type-AF connector. At the same time, MIC2026-1YM is enabled , OUTA will output 5V , which will supply USB device connected on USB type-AF connector.   [Note] Users need to pay attention to. When using the jumper with PIN1/2/3, the board needs to be powered off. In other words, when switching between device and host, you need to switch off the power, then power on, and restart the board. The solution can also be used for i.MX processors with USB 2.0 interface.   NXP CAS team Wedong Sun 01/15/2021
View full article
Recently, some customers are using i.MX processor, they want to add raid & LVM function support to the kernel, but they have encountered the problem that the compilation cannot pass. Tested it in L4.14.98, L4.19.35 & L5.4.x, Only L4.14.98 bsp exists the problem. Here are the experimental steps I have done, including the same problems I encountered with the customer, and how to modify the kernel to ensure that the compilation passes. 1. Exporting cross compilation tool chain from yocto BSP (1) Downloading Yocto BSP and compiling it. Following steps in i.MX_Yocto_Project_User's_Guide.pdf, download Yocto BSP and compile it successfully. (2) Exporting cross compilation tool chain Following methods described in i.MX_Linux_User's_Guide.pdf, export cross compilation tool chain from yocto BSP. See Chapter 4.5.12 of the document, please! Then cross compilation tool chain will be like below: (3) Copying linux BSP source code to a new directory # cd ~ # mkdir L4.14.98-2.0.0 # cd L4.14.98-2.0.0 # cp -r ~/imx-yocto-bsp/build-fb/tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/4.14.98- r0/git ./ Then all linux source code has been copied to L4.14.98-2.0.0, which is the top directory of linux kernel source code, I will compile kernel image here. 2. Compiling linux kernel # cd ~/L4.14.98-2.0.0 # source /opt/fsl-imx-fb/4.14-sumo/environment-setup-cortexa9hf-neon-poky-linux-gnueabi # export ARCH=arm # make imx_v7_defconfig # make menuconfig Then we will add RAID and LVM modules to linux kernel. In order to reproduce errors, I added all related modules to kernel. See below, please! Device drivers---->Multiple devices driver support (RAID and LVM) After save and exit, began to compile kernel. # make (make –j4) The following errors will occur: ------------------------------------------------------------------------------------------- drivers/md/dm-rq.c: In function ‘dm_old_init_request_queue’: drivers/md/dm-rq.c:716:2: error: implicit declaration of function ‘elv_register_queue’; did you mean ‘blk_register_queue’? [-Werror=implicit-function-declaration] elv_register_queue(md->queue); ^~~~~~~~~~~~~~~~~~ blk_register_queue cc1: some warnings being treated as errors scripts/Makefile.build:326: recipe for target 'drivers/md/dm-rq.o' failed make[2]: *** [drivers/md/dm-rq.o] Error 1 scripts/Makefile.build:585: recipe for target 'drivers/md' failed make[1]: *** [drivers/md] Error 2 Makefile:1039: recipe for target 'drivers' failed make: *** [drivers] Error 2 ------------------------------------------------------------------------------------------- 3. Finding out root cause and solving it (1) elv_register_queue( ) function The function is loaded in dm-rq.c : int dm_old_init_request_queue(struct mapped_device *md, struct dm_table *t) { … … elv_register_queue(md->queue); … … } BUT compiler didn’t find it’s declaration and entity. Searching source code, and found it declared in linux_top/block/blk.h: … … int elv_register_queue(struct request_queue *q); … … It’s entity is in linux_top/block/elevator.c: int elv_register_queue(struct request_queue *q) { … … } (2) Adding declaration and exporting the function --- Declaration Add the line below to dm-rq.c: … … extern int elv_register_queue(struct request_queue *q); … … --- Exporting the function(elevator.c) Add EXPORT_SYMBOL(elv_register_queue); to the end of function, see below. int elv_register_queue(struct request_queue *q) { … … } EXPORT_SYMBOL(elv_register_queue); 4. Re-compiling Linux Kernel The above error will not occur and the compilation will complete successfully.   NXP CAS team Weidong Sun
View full article
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 the detailed programming aids for the registers associated with MMDC DDR3 and LPDDR2 initialization for the MX6DQ SoC. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP boards.  
View full article
Attached is the Kernel image needed to construct the Linux Image i.MX 6Dual/6Quad Power Consumption Measurement Linux Image
View full article
Host TFTP and NFS Configuration Now configure the Trivial File Transfer Protocol (TFTP) server and Networked File System (NFS) server. U-Boot will download the Linux kernel and dtb file using tftp and then the kernel will mount (via NFS) its root file system on the computer hard drive. 1. TFTP Setup   1.1.1 Prepare the TFTP Service   Get the required software if not already set up. On host for TFTP: Install TFTP on Host $ sudo apt-get install tftpd-hpa   (Note: There are a number of examples in various forums, etc, of how to automatically start the TFTP service - but not all are successful on all Linux distro's it seems! The following may work for you.)   Start the tftpd-hpa service automatically by adding a command to /etc/rc.local. $ vi /etc/rc.local   Now, just before the exit 0 line edit below command then Save and Exit. $ service tftpd-hpa start  Now, To control the TFTP service from the command line use: $ service tftpd-hpa restart    To check the status of the TFTP service from the command line use: $ service tftpd-hpa status   1.1.1 Setup the TFTP Directories Now, we have to create the directory which will contain the kernel image and the device tree blob file. $ mkdir -p /imx-boot/imx6q-sabre/tftp Then, copy the kernel image and the device tree blob file in this directory. $ cp {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/zImage /imx-boot/imx6q-sabre/tftp $ cp {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/<dtb file> /imx-boot/imx6q-sabre/tftp   OR we can use the default directory created by yocto {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/ The tftpd-hpa service looks for requested files under /imx-boot/imx6q-sabre/tftp The default tftpd-hpa directory may vary with distribution/release, but it is specified in the configuration file: /etc/default/tfptd-hpa. We have to change this default directory with our directory   Edit default tftp directory $ vi /etc/default/tftpd-hpa   Now, change the directory defined as TFTP_DIRECTORY with your host system directory which contains kernel and device tree blob file. Using created directory TFTP_DIRECTORY=”/imx-boot/imx6q-sabre/tftp” OR Using Yocto directory path TFTP_DIRECTORY=”{YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}” Restart the TFTP service if required $ service tftpd-hpa restart   1.2 NFS Setup 1.2.1 Prepare the NFS Service Get the required software if not already set up. On host for NFS: Install NFS on Host $ sudo apt-get install nfs-kernel-server The NFS service starts automatically. To control NFS services : $ service nfs-kernel-server restart To check the status of the NFS service from the command line : $ service nfs-kernel-server status 1.2.2 Setup the NFS Directories Now, we have to create the directory which will contain the root file system. $ mkdir -p /imx-boot/imx6q-sabre/nfs   Then, copy the rootfs in this directory. $ cp -R {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs/* /imx-boot/imx6q-sabre/nfs   OR we can use the default directory created by yocto. $ {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs 1.2.3 Update NFS Export File The NFS server requires /etc/exports to be configured correctly to access NFS filesystem directory to specific hosts. $ vi /etc/exports Then, edit below line into the opened file. <”YOUR NFS DIRECTORY”> <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Ex. If you created custom directory for NFS then, /imx-boot/imx6q-sabre/nfs <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Ex: /imx-boot/imx6q-sabre/nfs 192.168.*.*(rw,sync,no_root_squash,no_subtree_check) OR /{YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check)   Now, we need to restart the NFS service. $ service nfs-kernel-server restart   2 Target Setup   We need to set up the network IP address of our target. Power On the board and hit a key to stop the U-Boot from continuing. Set the below parameters, setenv serverip 192.168.0.206       //This must be your Host IP address The path where the rootfs is placed in our host has to be indicated in the U-Boot, Ex. // if you choose default folder created by YOCTO setenv nfsroot /{YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs   OR // if you create custom directory for NFS setenv nfsroot /imx-boot/imx6q-sabre/nfs Now, we have to set kernel image name and device tree blob file name in the u-boot, setenv image < zImage name > setenv fdt_file <dtb file name on host> Now, set the bootargs for the kernel boot, setenv netargs 'setenv bootargs console=${console},${baudrate} ${smp} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp' Use printenv command and check loadaddr and fdt_addr environment variables variables for I.MX6Q SABRE, loadaddr=0x12000000 fdt_addr=0x18000000   Also, check netboot environment variable. It should be like below, netboot=echo Booting from net ...; run netargs; if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; ${get_cmd} ${image}; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if ${get_cmd} ${fdt_addr} ${fdt_file}; then bootz ${loadaddr} - ${fdt_addr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi; Now, set environment variable bootcmd to boot every time from the network, setenv bootcmd run netboot Now finally save those variable in u-boot: saveenv Reset your board; it should now boot from the network: U-Boot 2016.03-imx_v2016.03_4.1.15_2.0.0_ga+ga57b13b (Apr 17 2018 - 17:13:43 +0530)  (..) Net:   FEC [PRIME] Normal Boot Hit any key to stop autoboot:  0   Booting from net ... Using FEC device TFTP from server 192.168.0.206; our IP address is 192.168.3.101 Filename 'zImage'. Load address: 0x12000000 Loading: #################################################################         #################################################################         #################################################################         #################################################################         #################################################################         #################################################################         ###########################################################         2.1 MiB/s done Bytes transferred = 6578216 (646028 hex) Using FEC device TFTP from server 192.168.0.206; our IP address is 192.168.3.101 Filename 'imx6q-sabresd.dtb'. Load address: 0x18000000 Loading: ####         1.8 MiB/s done Bytes transferred = 45893 (b345 hex) Kernel image @ 0x12000000 [ 0x000000 - 0x646028 ] ## Flattened Device Tree blob at 18000000   Booting using the fdt blob at 0x18000000   Using Device Tree in place at 18000000, end 1800e344 switch to ldo_bypass mode!   Starting kernel ...
View full article