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:
Debian is a free to use and redistribute Linux distribution that is widely used by the community for industrial and desktop applications.  This distribution started in 1993 as Debian Project with Ian Murdock inviting developers to contribute in one of the first Linux distributions.  Debian takes an important role in Linux world with a clear idea about be a full featured and free distribution with over than 59,000 packages provided as a free to use and distribute that supports a wide range of functionalities.  Currently, Debian 12 supports 9 architectures which makes it in a universal operating system that can be implemented in embedded systems, desktops or servers.  Finally, Debian has been an inspiration for well-known Linux distributions such as Kali and Ubuntu.  In this guide we will check the installation process of Debian 12 for NXP microprocessors i.MX family, specifically for i.MX8M Mini, i.MX8M Nano, i.MX8M Plus and i.MX93.  For this purpose, we divided the document in the following topics: Hardware Requirements Software Requirements Host Preparation SD Card Preparation Copying Bootloader  Copying Kernel and DTB files Debian Installation Configure Base System Boot your target References   Hardware Requirements Linux Host computer (Ubuntu 20.04 or later) USB Card reader or Micro SD to SD adapter SD Card Evaluation Kit Board for the i.MX8M Nano, i.MX8M Mini, i.MX8M Plus or i.MX93   Software Requirements Linux Ubuntu (20.04 and 24.04 tested) or Debian for host BSP version 6.1.55 for your specific target (Embedded Linux for i.MX Applications Processors | NXP Semiconductors)   Host Preparation For Debian installation we will require some specific packages for host.  You can download the packages using the following command: $ sudo apt install debian-archive-keyring debootstrap qemu-user-static We must validate the key to verify the archive using the command: $ sudo apt-key add /usr/share/keyrings/debian-archive-keyring.gpg If running an older release you need to get the unstable keyring package (because the version in your release is probably too old to have the current key) $ wget http://ftp.debian.org/debian/pool/main/d/debian-archive-keyring/debian-archive-keyring_2023.4_all.deb $ sudo dpkg -i debian-archive-keyring_2023.4_all.deb   SD Card Preparation The Linux kernel running on the Linux host assigns a device node to the SD/MMC card reader. The kernel might decide the device node name or udev rules might be used. In the following instructions, it is assumed that udev is not used. To identify the device node assigned to the SD/MMC card, carry out the following command: $ cat /proc/partitions   Partitioning the SD card On most Linux host operating systems, the SD card is mounted automatically upon insertion. Therefore, before running fdisk, make sure that the SD card is unmounted if it was previously mounted (through sudo umount /dev/sdx). Start by running fdisk with root permissions. Use the instructions above to determine the card ID. We are using sdx as an example. $ sudo fdisk /dev/sdx  Type the following parameters (each followed by <ENTER>): $fdisk: p # lists the current partitions $fdisk: d # to delete existing partitions. Repeat this until no unnecessary partitions $fdisk: n # create a new partition $fdisk: p # create a primary partition - use for both partitions $fdisk: 1 # the first partition $fdisk: 20480 # starting at offset sector $fdisk: 1024000 # ending position of the first partition to be used for the boot Images $fdisk: p # to check the partitions $fdisk: n # create a new partition $fdisk: p # create a primary partition $fdisk: 2 # the second partition $fdisk: 1228800 # starting at offset sector, which leaves enough space for the kernel, the bootloader and its configuration data $fdisk: <enter> # using the default value will create a partition that extends to the last sector of the media $fdisk: p # to check the partitions $fdisk: w # this writes the partition table to the media and fdisk exits   Copying Bootloader and Kernel In this section we will copy the bootloader and kernel image to SD card.  First, we can create a new directory to unzip the BSP downloaded from the NXP site.  $ mkdir debian-imx $ cd debian-imx $ unzip ~/Downloads/LF_v6.1.55-2.2.0_images_<board>.zip Where board is: IMX8MPEVK IMX8MNEVK IMX8MMEVK IMX93EVK Then, copy the U-Boot image. $ sudo dd if=<U-Boot_image> of=/dev/sdx bs=1k seek=<offset> conv=fsync Where offset is: 33 - for i.MX 8M Mini 32 - for i.MX 8M Nano, i.MX 8M Plus, and i.MX 9 The sectors of SD/eMMC before the “offset” KB are reserved. It may include the partition table.   Copying Kernel image and DTB files This section describes how to load the kernel image and DTB. The pre-built SD card image uses the VFAT partition for storing kernel image and DTB, which requires a VFAT partition that is mounted as a Linux drive, and the files are copied into it. This is the preferred method. Default: VFAT partition Format partition 1 on the card as VFAT with this command: $ sudo mkfs.vfat /dev/sdx1 Mount the formatted partition with this command: $ mkdir mountpoint $ sudo mount /dev/sdx1 mountpoint Copy the zImage and *.dtb files to the mountpoint by using cp. The device tree names should match $ sudo cp *.dtb mountpoint/ $sudo cp Image-<board_name>.bin mountpoint/Image Where board_name is: imx8mpevk imx8mnevk imx8mmevk imx93evk the one used by the variable specified by U-Boot. Unmount the partition with this command: $ sudo umount mountpoint   Debian Installation For Debian installation we will use the official tool debootstrap. This tool allows us to install Debian without a disk and run the system using qemu in a different architecture.  Before using debootstrap tool we need to format and mount the second partition of the SD card with the commands below: $ sudo mkfs.ext4 /dev/sdx2 $ sudo mount /dev/sdx2 mountpoint/ debootstrap can download the needed files directly from the archive when you run it. You can substitute any Debian archive mirror for http.us.debian.org/debian in the command below, preferably a mirror close to you network-wise. Mirrors are listed at http://www.debian.org/mirror/list $ sudo debootstrap --arch arm64 --foreign bookworm mountpoint/ http://ftp.debian.org/debian This step takes a while and depends on the resources of your host machine.   Configure Base System Now you’ve got a real Debian system, though rather lean, on disk. chroot into it: $ sudo cp /usr/bin/qemu-aarch64-static mountpoint/usr/bin $ sudo LANG=C.UTF-8 chroot mountpoint/ qemu-aarch64-static /bin/bash After chrooting you may need to set the terminal definition to be compatible with the Debian base system, for example: $ export TERM=xterm-color we need to finish the multi-stage boot strap $ /debootstrap/debootstrap --second-stage At this point /dev/ only contains very basic device files. For the next steps of the installation, additional device files may be needed. There are different ways to go about this and which method you should use depends on the host system you are using for the installation, whether you intend to use a modular kernel or not, and whether you want to use dynamic (e.g. using udev) or static device files for the new system. A few of the available options are: install the makedev package, and create a default set of static device files using (after chrooting) $ apt install makedev $ mount none /proc -t proc $ cd /dev $ MAKEDEV generic With these next steps we will be setting up the Debian system:   Setting fstab FSTAB is a configuration table designed to ease the burden of mounting and unmounting file systems to a machine. $ nano /etc/fstab # stock fstab - you probably want to override this with a machine specific one /dev/root / auto defaults 1 1 proc /proc proc defaults 0 0 devpts /dev/pts devpts mode=0620,ptmxmode=0666,gid=5 0 0 tmpfs /run tmpfs mode=0755,nodev,nosuid,strictatime 0 0 tmpfs /var/volatile tmpfs defaults 0 0 # uncomment this if your device has a SD/MMC/Transflash slot #/dev/mmcblk0p1 /media/card auto defaults,sync,noauto 0 0   Setting Timezone The following command allows you to choose your timezone. $ dpkg-reconfigure tzdata   Configure apt Debootstrap will have created a very basic /etc/apt/sources.list that will allow installing additional packages. However, you may want to add some additional sources, for example for source packages and security updates: $ nano /etc/apt/sources.list deb http://deb.debian.org/debian bookworm main non-free-firmware deb-src http://deb.debian.org/debian bookworm main non-free-firmware deb http://deb.debian.org/debian-security/ bookworm-security main non-free-firmware deb-src http://deb.debian.org/debian-security/ bookworm-security main non-free-firmware deb http://deb.debian.org/debian bookworm-updates main non-free-firmware deb-src http://deb.debian.org/debian bookworm-updates main non-free-firmware Make sure to run the apt update after you have made changes to the sources list   Configure locales and keyboard To configure your locale settings to use a language other than English, install the locales support package and configure it. Currently, the use of UTF-8 locales is recommended. $ apt install locales $ dpkg-reconfigure locales To configure your keyboard (if needed): $ apt install console-setup $ dpkg-reconfigure keyboard-configuration Note that the keyboard cannot be set while in the chroot, but will be configured for the next reboot   Adding Users $ apt install sudo $ adduser imx $ usermod -aG sudo imx $ nano /etc/sudoers imx ALL=(ALL:ALL) ALL   Tasksel Installation As mentioned earlier, the installed system will be very basic. If you would like to make the system a bit more mature, there is an easy method to install all packages with “standard” priority: $ tasksel install standard $ apt clean $ exit $ sudo umount mountpoint/ $sync   Boot your target Now, you can boot your target from your SD Card. (Review your specific target documentation)   Configure Networking (after booting target) Based on Debian official documentation for new systems the common names for network interfaces such as eth0 or wlan0 are not used. Therefore, we will need to list the interfaces using: $ ls /sys/class/net To have ethernet connection we will need to create a file in the path etc/network/. $ sudo nano etc/network/interfaces Type the following commands on the file: auto lo iface lo inet loopback auto end0 iface end0 inet dhcp   Install Neofetch (Optional) $ apt install neofetch   Outputs  Debian 12 running on i.MX8MP Debian 12 running on i.MX93   References Chapter 1. Definitions and overview. (2021, January). Retrieved May 30, 2024, from https://www.debian.org/doc/manuals/debian-faq/basic-defs.en.html Debian GNU/Linux Installation Guide. (2024). https://www.debian.org/releases/stable/i386/install.en.pdf Arm64Port. (n.d.). https://wiki.debian.org/Arm64Port i.MX Linux User's Guide (nxp.com)
View full article
The document will cover three parts, which include: A brief introduction to RSA algorithm How to compile boot image including OP-TEE-OS for Boot media - QSPI The steps to sign and verification The SoC for this experiment is based on i.MX8MP-EVK
View full article
The HSM Coding-Signing is new. When we follow the instructions in Code-Signing Tool User’s Guide , still has something to overcome, most of them are related to the OS. Actually, Code-Signing Tool User’s Guide  can not give detail every “obvious” step. The purpose of this document is to share the experiences on my system. Hope those experience can give you some clues on your system.
View full article
Hello, on this post I will explain how to record separated audio channels using an 8MIC-RPI-MX8 Board. As background about how to setup the board to record and play audio using i.MX boards, I suggest you take a look on the next post: How to configure, record and play audio using an 8MIC-RPI-MX8 Board. Requirements: I.MX 8M Mini EVK. Linux Binary Demo Files - i.MX 8MMini EVK. 8MIC-RPI-MX8 Board. Serial console emulator (Tera Term, Putty, etc.). Headphones/speakers. Waveform Audio Format WAV, known for WAVE (Waveform Audio File Format), is a subset of Microsoft’s Resource Interchange File Format (RIFF) specification for storing digital audio files. This format does not apply compression to the information and stores the audio with different sampling rates and bitrates. WAV files are larger in size compared to other formats such as MP3 which uses compression to reduce the file size while maintaining a good audio quality but, there is always some lose on quality since audio information is too random to be compressed with conventional methods, the main advantage of this format is provide an audio file without losses that is also widely used on studio. This files starts with a file header with data chunks. A WAV file consists of two sub-chunks: fmt chunk: data format. data chunk: sample data. So, is structured by a metadata that is called WAV file header and the actual audio information. The header of a WAV (RIFF) file is 44 bytes long and has the following format: How to separate the channels? To separate each audio channel from the recording we need to use the next command that will record raw data of each channel. arecord -D plughw:<audio device> -c<number of chanels> -f <format> -r <sample rate> -d <duration of the recording> --separate-channels <output file name>.wav arecord -D plughw:2,0 -c8 -f s16_le -r 48000 -d 10 --separate-channels sample.wav This command will output raw data of recorded channels as is showed below. This raw data cannot be used as a “normal” .wav file because the header information is missing. It is possible to confirm it if import raw data to a DAW and play recorded samples: So, to use this information we need to create the header for each file using WAVE library on python. Here the script that I used: import wave import os name = input("Enter the name of the audio file: ") os.system("arecord -D plughw:2,0 -c8 -f s16_le -r 48000 -d 10 --separate-channels " + name + ".wav") for i in range (0,8): with open(name + ".wav." + str(i), "rb") as in_file: data = in_file.read() with wave.open(name + "_channel_" + str(i) +".wav", "wb") as out_file: out_file.setnchannels(1) out_file.setsampwidth(2) out_file.setframerate(48000) out_file.writeframesraw(data) os.system("mkdir output_files") os.system("mv " + name + "_channel_" + "* " + "output_files") os.system("rm " + name + ".wav.*") If we run the script, will generate a directory with the eight audio channels in .wav format. Now, we will be able to play each channel individually using an audio player. References IBM, Microsoft Corporation. (1991). Multimedia Programming Interface and Data Specifications 1.0. Microsoft Corporation. (1994). New Multimedia Data Types and Data Techniques. Standford University. (2024, January 30). Retrieved from WAVE PCM sound file format: http://hummer.stanford.edu/sig/doc/classes/SoundHeader/WaveFormat/
View full article
  Introduction   MATTER chip-tool android APK is a very useful tool for commission, control the MATTER network by smart phone. Vendor can add various features into the APK. It supports build by Android Studio and command line. The official build steps can be found here: https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/android_building.md But the official guide does not cover how to build in a non-GUI linux distribution (without Android Studio installed). This article describes how to build under Ubuntu server. Install Android SDK  Install SDK command line from: https://developer.android.com/studio, And follow the steps: https://developer.android.com/tools/sdkmanager to install.  Install the Android-26 SDK and 23 NDK: $./sdkmanager "platforms;android-26" "ndk;23.2.8568313"  Export env  $export ANDROID_HOME=<SDK path>  $export ANDROID_NDK_HOME=<SDK path>/ndk/23.2.8568313/   Install kotlin (1.8.0)  $curl -s https://get.sdkman.io | bash  $sdk install kotlin 1.8.0  $whereis kotlin  $export PATH=$PATH:<patch of bin of kotlin>    Configure proxy for gradle  $ cat ~/.gradle/gradle.properties  # Set the socket timeout to 5 minutes (good for proxies)  org.gradle.internal.http.socketTimeout=300000  # the number of retries (initial included) (default 3)  org.gradle.internal.repository.max.retries=10  # the initial time before retrying, in milliseconds (default 125)  org.gradle.internal.repository.initial.backoff=500  systemProp.http.proxyHost=apac.nics.nxp.com  systemProp.http.proxyPort=8080  systemProp.http.nonProxyHosts=localhost|*.nxp.com  systemProp.https.proxyHost=apac.nics.nxp.com  systemProp.https.proxyPort=8080  systemProp.https.nonProxyHosts=localhost|*.nxp.com    Configure proxy  Configure proxy for download packages during build export FTP_PROXY="http://apac.nics.nxp.com:8080"  export HTTPS_PROXY="http://apac.nics.nxp.com:8080"  export HTTP_PROXY="http://apac.nics.nxp.com:8080"  export NO_PROXY="localhost,*.nxp.com"  export ftp_proxy="http://apac.nics.nxp.com:8080"  export http_proxy="http://apac.nics.nxp.com:8080"  export https_proxy="http://apac.nics.nxp.com:8080"  export no_proxy="localhost,*.nxp.com"    Patch for gradle java option  This step can be skipped if using OpenJDK16.  Otherwise if you're using OpenJDK 17 (Java 61), you have to upgrade the gradle from 7.1.1 to 7.3, and add java.io open to ALL-UNNAMED:  diff --git a/examples/android/CHIPTool/gradle.properties b/examples/android/CHIPTool/gradle.properties  index 71f72db8c8..5bce4b4528 100644  --- a/examples/android/CHIPTool/gradle.properties  +++ b/examples/android/CHIPTool/gradle.properties  @@ -6,7 +6,8 @@  # http://www.gradle.org/docs/current/userguide/build_environment.html  # Specifies the JVM arguments used for the daemon process.  # The setting is particularly useful for tweaking memory settings.  -org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8  +#org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8  +org.gradle.jvmargs=-Xmx4096m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8  --add-opens=java.base/java.io=ALL-UNNAMED  # When configured, Gradle will run in incubating parallel mode.  # This option should only be used with decoupled projects. More details, visit  # http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects  diff --git a/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties b/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties  index 05679dc3c1..e750102e09 100644  --- a/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties  +++ b/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties  @@ -1,5 +1,5 @@  distributionBase=GRADLE_USER_HOME  distributionPath=wrapper/dists  -distributionUrl=https\://services.gradle.org/distributions/gradle-7.1.1-bin.zip  +distributionUrl=https\://services.gradle.org/distributions/gradle-7.3-bin.zip  zipStoreBase=GRADLE_USER_HOME  zipStorePath=wrapper/dists    Build & Install Clone all the modules from github: $git clone --single-branch --recurse-submodules https://github.com/project-chip/connectedhomeip.git Enviroment setup: $source scripts/bootstrap.sh Build: ./scripts/build/build_examples.py --target android-arm64-chip-tool build Install built apk into phone: $adb install out/android-arm64-chip-tool/outputs/apk/debug/app-debug.apk  
View full article
Hello everyone! In this document you'll find an example on how to setup your own recipe for Yocto Project to add your own custom changes, such as custom device tree, patches, custom drivers, etc. Linux kernel used in this guide 6.1.36_2.1.0 At least 120(250)GB HDD in the host PC Ubuntu 20.04 or later host PC ##Host Setup $ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev python3-subunit mesa-common-dev zstd liblz4-tool file locales -y $ sudo locale-gen en_US.UTF-8 ##Setup Repo utility $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH ##Git Setup $ git config --global user.name "Your Name" $ git config --global user.email "Your Email" $ git config --list ##Yocto Setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.36-2.1.0.xml $ repo sync $ DISTRO=fsl-imx-wayland MACHINE=imx8mp-lpddr4-evk source imx-setup-release.sh -b buildwayland ##Create the new layer $ cd ../sources $ bitbake-layers create-layer meta-newlayer ##Add the new layer to the bblayers.conf in the build directory $ bitbake-layers add-layer meta-newlayer ##Check that it has been added correctly $ tree -L 4 ./meta-newlayer ##Edit the new layer and delete the samples created by yocto $ cd meta-newlayer $ rm -r recipes-example $ rm conf/layer.conf ##Use any text editor to create the layer configuration $ nano conf/layer.conf ##Add the following to the layer configuration file BBPATH .= ":${LAYERDIR}" BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \             ${LAYERDIR}/recipes-*/*/*.bbappend" BBFILE_COLLECTIONS += "meta-newlayer" BBFILE_PATTERN_meta-newlayer := "^${LAYERDIR}/" BBFILE_PRIORITY_meta-newlayer = "8" LAYERSERIES_COMPAT_meta-newlayer = "mickledore" ##Prepare bbappend files so the patches get applied $ mkdir -p recipes-kernel/linux $ cd recipes-kernel/linux $ nano linux-imx_%.bbappend ##Add the following to the .bbappend file FILESEXTRAPATHS:prepend := "${THISDIR}/files:" SRC_URI += "file://001-add-imx8mp-dts-test.patch" PACKAGE_ARCH = "${MACHINE_ARCH}" KERNEL_DEVICETREE:append = " freescale/imx8mp-evk-test.dtb" ##Copy the patches to the layer file path, for this example I have created a simple patch to just rename the default device tree. $ mkdir files $ cp ~/patches/001-add-imx8mp-dts-test.patch files ##Make sure that the layers is created correctly $ bitbake-layers show-layers  ##Finally we bitbake our image $ cd ~/imx-yocto-bsp/buildwayland $ bitbake imx-image-multimedia #All the images built should appear at  <build directory>/tmp/deploy/images/<machine> Hope everyone finds this useful! For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.  
View full article
The user interface has limited the use of the tool GUI Guider. Getting an interaction only through a mouse or touchscreen can be enough for some use cases. However, sometimes the use case requires to go beyond its limitations. This video/appnote explores the possibility of integrating voice by creating a bridge between a speech recognition technology, such as VIT, and the interface creator GUI Guider. It uses a universal way to link all the voice recognition commands and a wakeword to any interaction created by GUI Guider. The following video shows the steps necessary to create that connection by creating the voice recognition using VIT voice commands and wakewords, create an interface of GUI Guider using a template, how to connect between them using the board i.MX 93 evk and testing it. For more information consult the following links AppNote HTML: https://docs.nxp.com/bundle/AN14270/page/topics/abstract.html?_gl=1*1glzg9k*_ga*NDczMzk4MDYuMTcxNjkyMDI0OA..*_ga_WM5LE0KMSH*MTcxNjkyMDI0OC4xLjEuMTcxNjkyMDcyMy4wLjAuMA AppNote PDF: https://www.nxp.com/docs/en/application-note/AN14270.pdf Associated File: AN14270SW  
View full article
-- DTS for gpio wakeup   // SPDX-License-Identifier: (GPL-2.0+ OR MIT) /*  * Copyright 2022 NXP  */   #include "imx93-11x11-evk.dts"   / {         gpio-keys {                 compatible = "gpio-keys";                 pinctrl-names = "default";                 pinctrl-0 = <&pinctrl_gpio_keys>;                   power {                   label = "GPIO Key Power";                   linux,code = <KEY_POWER>;                   gpios = <&gpio2 7 GPIO_ACTIVE_LOW>;                   wakeup-source;                   debounce-interval = <20>;                   interrupt-parent = <&gpio2>;                   interrupts = <7 IRQ_TYPE_LEVEL_LOW>;                 };         }; };   &iomuxc {         pinctrl_gpio_keys: gpio_keys_grp {                 fsl,pins = <                         MX93_PAD_GPIO_IO07__GPIO2_IO07  0x31e                 >;         }; }; -- testing the switch GPIO  First check if your gpio dts configuration to make it act as a switch works or not After executing the command - 'evtest /dev/input/event1' Trigger an interrupt by connecting GPIO2 7 to GND, as soon as you do that, you will receive Event logs such as below:- This shows that your dts configuration for GPIO works.     -- Verify the interrupt         -- Go to sleep and then connect the GPIO to GND to trigger a wakeup, in the logs we see that kernel exits the suspend mode    
View full article
The purpose of this document is to provide a guide on how to export new symbols using the Bazel Android server instead of the build_abi.sh script. For a better reference how to build Android i.MX image please look at the next chapter 3 Building the Android Platform for i.MX in the Android User's Guide 1. Compile full AOSP or only kernel Build full AOSP: $ source build/envsetup.sh $ lunch evk_8mp-eng $ ./imx-make.sh -j8  Only build the kernel: $ ./imx-make.sh kernel -j8 2. Generic Kernel Image GKI Development Download GKI outside of android_build (MY_ANDROID). # Make sure MY_ANDROID is set to the android_build folder. $ export MY_ANDROID=`pwd` # mkdir gki && cd gki (Make sure folder gki is not inside of ${MY_ANDROID}) $ repo init -u https://android.googlesource.com/kernel/manifest -b common android14-6.1 $ repo sync $ cd common 3. Export New Symbols Switch the kernel in this common folder from AOSP to its device, and apply the patches required for your project. In this case Android $ cd common $ git remote add device https://github.com/nxp-imx/linux-imx.git $ git remote update $ git fetch device --tags $ git checkout android-14.0.0_1.2.0 $ cd .. $ ln -s ${MY_ANDROID}/vendor/nxp-opensource/verisilicon_sw_isp_vvcam verisilicon_sw_isp_vvcam $ ln -s ${MY_ANDROID}/vendor/nxp-opensource/nxp-mwifiex nxp-mwifiex $ BUILD_FOR_GKI=yes BUILD_CONFIG=common/build.config.imx $ EXT_MODULES_MAKEFILE="verisilicon_sw_isp_vvcam/vvcam/v4l2/Kbuild" $ EXT_MODULES="nxp-mwifiex/mxm_wifiex/wlan_src" Note: Be sure that your Symbolic Link is pointing to the correct folder Open the Makefile in the following path ../gki/nxp-mwifiex/mxm_wifiex/wlan_src/ and erase some ifreq lines that will generate a No such file or directory error. #Automatically determine Android version from build information to streamline diff --git a/mxm_wifiex/wlan_src/Makefile b/mxm_wifiex/wlan_src/Makefile index 3ec5308..7b6ca47 100644 --- a/mxm_wifiex/wlan_src/Makefile +++ b/mxm_wifiex/wlan_src/Makefile @@ -139,20 +139,7 @@ CONFIG_ANDROID_KERNEL=y ifeq ($(ANDROID_PRODUCT_OUT),1) ccflags-y += -DANDROID_SDK_VERSION=$(ANDROID_SDK_VERSION) else -include $(ANDROID_BUILD_TOP)/build/make/core/build_id.mk -ifeq ($(shell echo "$(BUILD_ID)" | cut -c1),R) - ccflags-y += -DANDROID_SDK_VERSION=30 -else ifeq ($(shell echo "$(BUILD_ID)" | cut -c1),S) - ccflags-y += -DANDROID_SDK_VERSION=31 -else ifeq ($(shell echo "$(BUILD_ID)" | cut -c1),T) - ccflags-y += -DANDROID_SDK_VERSION=33 -else ifeq ($(shell echo "$(BUILD_ID)" | cut -c1),U) - ccflags-y += -DANDROID_SDK_VERSION=34 -else - # Default optimization or actions - ANDROID_SDK_VERSION := 0 - ccflags-y += -DANDROID_SDK_VERSION -endif +ccflags-y += -DANDROID_SDK_VERSION=34 endif endif endif -- Then you could update the symbol list by typing the following command. $ tools/bazel run //common:imx_abi_update_symbol_list After the build process is successful, you should get an output like the image below. Then the common/android/abi_gki_aarch64_imx will be generated. $ cp common/android/abi_gki_aarch64_imx /tmp/abi_gki_aarch64_imx $ cd .. Build GKI locally. $ tools/bazel run //common:kernel_aarch64_dist  You could follow the next chapters to update the GKI image to your boot image.
View full article
The purpose of this document is to provide supportive information for selection of suitable LPDDR4, DDR4 and DDR3L devices that are supported by i.MX 8M family of processors to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products.  It is strongly recommended to consult with NXP and the memory vendor the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. Please note that some of the LPDDR4 devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low speed operation is planned in the use case, please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs available on NXP.com For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket.  LPDDR4 - maximum supported densities Please note that the SoCs only support memory devices that support either the LPDDR4 mode or support both LPDDR4 and LPDDR4X modes. Memory devices that support only the LPDDR4X mode are not supported. SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB dual rank, dual-channel  device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8M Mini  32-bit 64Gb/8GB dual rank, dual-channel  device with 17-row addresses (R0-R16) 1, 2 i.MX 8M Nano  16-bit 32Gb/4GB dual rank, single-channel  device with 17-row addresses (R0-R16) 1, 2, 3, 12 i.MX 8M Plus  32-bit 64Gb/8GB dual rank, dual-channel  device with 17-row addresses (R0-R16)  1, 2   LPDDR4 - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Validated part number (vendor) Notes i.MX 8M Quad  24Gb/3GB MT53B768M32D4NQ-062 WT:B (Micron) 15 32Gb/4GB MT53D1024M32D4DT-046 AAT:D (Micron) 14 4Gb/512MB IS43LQ16256B-062BLI (ISSI) 5, 14 i.MX 8M Mini 16Gb/2GB MT53D512M32D2DS-053 WT:D (Micron) 15 16Gb/2GB M56Z16G32512A (ESMT) 5, 14 32Gb/4GB MT53E1G32D2FW-046 WT:A (Micron) 5, 14 64Gb/8GB MT53E2G32D4DT-046 AIT:A (Micron) 5, 14 i.MX 8M Nano  16Gb/2GB C1612PC2WDGTKR-U (Kingston) 15 32Gb/4GB MT53E2G32D4DT-046 AIT:A (Micron) 5, 13, 15 8Gb/1GB MT53D512M32D2DS-053 WT:D (Micron) 13, 15 i.MX 8M Plus 48Gb/6GB MT53E1536M32D4DT-046 WT:A (Micron) 15 64Gb/8GB MT53E2G32D4DE-046 AUT:C (Micron) 5, 14   LPDDR4 - list of incompatible devices Given the limitations mentioned in this document, the following memory devices were identified as incompatible with the particular SoCs as detailed in the following table:   Memory vendor Part Number Density Incompatible SoCs Incompatibility reason Samsung K4FHE3S4HA-KU(H/F)CL 24Gb/3Gb i.MX 8M Quad  The memory device requires 17th row address bit to function. Samsung K4UHE3S4AA-KU(H/F)CL 24Gb/3Gb i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus The memory device only supports the LPDDR4X mode. Samsung K4UJE3D4AA-KU(H/F)CL 48Gb/6GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus The memory device only supports the LPDDR4X mode. Samsung K4FCE3Q4HB-KU(H/F)CL 64Gb/8GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus A byte mode memory device. Samsung K4UCE3Q4AB-KU(H/F)CL 64Gb/8GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus A byte mode memory device. The memory device only supports the LPDDR4X mode.    DDR4 - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad  32-bit 32Gb/4GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 6 i.MX 8M Mini  32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7 i.MX 8M Nano  16-bit 64Gb/8GB x8, 16Gb device with 2 bank group addresses, 17-row addresses and 10 column addresses 1, 8 i.MX 8M Plus  32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7   DDR4 - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Validated part number (vendor) Notes i.MX 8M Quad 32Gb/4GB 4x MT40A512M16JY-083EAAT (Micron) 15 i.MX 8M Mini  16Gb/2GB 2x MT40A512M16LY-075:E (Micron) 15 i.MX 8M Nano 16Gb/2GB 1x MT40A1G16RC-062E:B (Micron) 15 i.MX 8M Plus 64Gb/8GB 4x MT40A1G16RC-062E:B (Micron) 15 16Gb/2GB NT5AD512M16C4-JRI (Nanya) 14   DDR3L - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad  32-bit 32Gb/4GB x16, 8Gb device with 16-row addresses and 10 column addresses 1, 9 i.MX 8M Mini  32-bit 64Gb/8GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 10 i.MX 8M Nano  16-bit 32Gb/4GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 11 i.MX 8M Plus  i.MX 8M Plus  does not support DDR3L   DDR3L - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Validated part number (vendor) Notes i.MX 8M Quad  16Gb/2GB 4x MT41K256M16TW-107 AAT (Micron) 14 i.MX 8M Mini  16Gb/2GB 4x MT41K256M16TW-107 AAT (Micron) 14   Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standards JESD209-4/JESD209-4A (LPDDR4), JESD279-4/JESD279-4A (DDR4), and JESD79-3E/JESD79-3F/JESD79-3-1A (DDR3/DDR3L). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory vendors often do not offer so many variants of single-channel memory devices. As an alternative, a dual-channel device with only one channel connected may be used. For example: A dual-rank, single-channel device with 16-row address bits has a density of 16Gb. If such a device is not available at the chosen supplier, a dual-rank, dual-channel device with 16-row address bits can be used instead. This device has a density of 32 Gb however since only one channel can be connected to the SoC, only half of the density is available (16 Gb). Usage of more than one discrete memory chips to overcome market constraints is not supported since only point-to-point connections are assumed for LPDDR4. Note 4: Devices with 17-row addresses (R0-R16) are not supported by the DDR Controller Note 5: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 6: The density can be achieved by connecting 2 single-rank discrete devices with one 16Gb die each. Since the SoC supports x8 devices and also has connectivity for a second rank, usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Two x16 16Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (only two discrete devices used), and bandwidth aspects (full data bus width used). Note 7: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 64Gb/8GB of address space dedicated for the DDR. Four x16 16Gb devices giving 64Gb/8GB in total is the optimal choice that balances the maximum density aspects, the signal integrity aspects (only four discrete devices used), and the bandwidth aspects (full data bus width used). Note 8: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select.  Note 9: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select, or by connecting 2 dual rank discrete devices with two 8Gb dies each. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Four x16 8Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (four discrete devices used), and bandwidth aspects (full data bus width used). Note 10: The density can be achieved by connecting 8 single rank discrete devices with one 8Gb die each, 4 devices connected to each chip select or by connecting 4 dual rank discrete devices with two 8Gb dies each. Note that the first option significantly exceeds the number of devices used on the validation board (4 discrete devices) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis. Practically, it is not recommended to use more than 4 discrete DDR3L devices. This corresponds to the maximum density of 32Gb/4GB in the case of the single rank devices containing one 8Gb die or 64Gb/8GB in case of the dual-rank devices, each containing two 8Gb dies. Note 11: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select or by connecting 2 dual rank discrete devices with two 8Gb dies each. Note 12: For single-channel (x16) memory devices, the current maximum available density in the market is 16Gb/2GB (Q1 2022). Note 13: Only one channel of the device (and hence, half of its density) was utilized due to the reduced data bus width (x16) of the SoC. Note 14: Part is active. Reviewed May 16th 2024 Note 15: Part is obsolete. Additional Links https://community.nxp.com/t5/iMX-and-Vybrid-Support/i-MX-8-8X-8XL-maximum-supported-LPDDR4-and-DDR3L-densities/ta-p/1152715          
View full article
The purpose of this document is to provide supportive information for selection of suitable LPDDR4 and DDR3L devices that are supported by i.MX 8/8X/8XLite family of processors to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products.  It is strongly recommended to consult with NXP and the respective memory vendor, the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. Please note that some of the LPDDR4 devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low speed operation is planned in the use case, please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the respective NXP i.MX 8 Hardware Developer's Guide available on NXP.com The i.MX8/8X/8XL Reference manuals declare that there are 16GB allocated for the DDR. Please note that this is only the address space, which is reserved for the DDR memory in the memory map. This specification does not guarantee that the entire region can be utilized as the maximum achievable densities listed below in the tables are restricted mainly by the addressing capabilities of the DDR controller, width of the data bus and other implementation-specific parameters as well as availability of supported devices on the market. For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket.    LPDDR4 - maximum supported densities Please note that the SoCs only support memory devices that support either the LPDDR4 mode or support both LPDDR4 and LPDDR4X modes. Memory devices that support only the LPDDR4X mode are not supported. SoC Package Max data bus width Maximum density Assumed memory organization Notes i.MX 8QM/8QP 29x29 mm 32-bit (per controller) 32Gb/4GB (per controller) dual rank, dual-channel  device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8QXP/8DXP 21x21 mm 32-bit 32Gb/4GB dual rank, dual-channel  device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8QXP/8DXP 17x17 mm 16-bit 16Gb/2GB dual rank, single-channel  device with 16-row addresses (R0-R15) 1, 2, 3, 4, 9 i.MX 8XLite 15x15 mm 16-bit 32Gb/4GB dual rank, single channel  device with 17-row addresses (R0-R16) 1, 2, 3, 9   LPDDR4 - list of validated memories The validation process is an ongoing effort - updates of the table are expected. SoC Package Maximum validated density Validated part number (vendor) Notes i.MX 8QM/8QP 29x29 mm 24Gb/3GB (per controller) MT53B768M32D4NQ-062 AIT:B (Micron)  12 32Gb/4GB (per controller) K4FBE3D4HB-KHCL (Samsung) 10,11 32Gb/4GB (per controller) MT53E1G32D2FW-046 AUT:B (Micron, Z42M) 10, 11 32Gb/4GB (per controller) MT53D1024M32D4DT-046 AAT:D (Micron)  12 16Gb/2GB (per controller) MT53D512M32D2DS-046 WT:D (Micron) 10, 12 16Gb/2GB (per controller) NT6AN512T32AC-J1J (Nanya) 10, 11 16Gb/2GB (per controller) NT6AN512T32AC-J1H (Nanya) 10, 11 32Gb/4GB (per controller) NT6AN1024F32AC-J2J (Nanya) 10, 11 32Gb/4GB (per controller) NT6AN1024F32AC-J2H (Nanya) 10, 11 i.MX 8QXP/8DXP 21x21 mm 24Gb/3GB MT53B768M32D4NQ-062 AIT:B (Micron)  12 32Gb/4GB NT6AN1024F32AC-J2J (Nanya) 10, 11 32Gb/4GB NT6AN1024F32AC-J2H (Nanya) 10, 11 16Gb/2GB NT6AN512T32AC-J2J (Nanya) 10, 11 16Gb/2GB NT6AN512T32AC-J2H (Nanya) 10, 11 32Gb/4GB MT53D1024M32D4DT-046 AAT:D (Micron)  11 i.MX 8XLite 15x15 mm 8Gb/1GB MT53D512M16D1DS 046 AAT ES:D & Z9XGG (Micron)  12 4Gb/0.5GB K4F4E164HD-THCL (Samsung) 10, 11 8Gb/1GB NT6AN512M16AV-J1I (Nanya) 10, 11   LPDDR4 - list of incompatible devices Given the limitations mentioned in this document, the following memory devices were identified as incompatible with the particular SoCs as detailed in the following table:   Memory vendor Part Number Density Incompatible SoCs Incompatibility reason Samsung K4FHE3S4HA-KU(H/F)CL 24Gb/3Gb i.MX8QM/8QP, i.MX8QXP/8DXP The memory device requires 17th row address bit to function. Samsung K4UHE3S4AA-KU(H/F)CL 24Gb/3Gb i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL The memory device only supports the LPDDR4X mode. Samsung K4UJE3D4AA-KU(H/F)CL 48Gb/6GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL The memory device only supports the LPDDR4X mode. Samsung K4FCE3Q4HB-KU(H/F)CL 64Gb/8GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL A byte mode memory device. Samsung K4UCE3Q4AB-KU(H/F)CL 64Gb/8GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL A byte mode memory device. The device only supports the LPDDR4X mode.    DDR3L - maximum supported densities SoC Package Max data bus width Maximum density Assumed memory organization Notes i.MX 8QXP/8DXP 21x21 mm 32-bit 64Gb/8GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 6 i.MX 8QXP/8DXP 17x17 mm 16-bit 32Gb/4GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 7 i.MX 8XLite 15x15 mm 16-bit 16Gb/2GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 8   DDR3L - list of validated memories The validation process is an ongoing effort -  updates of the table are expected. SoC Package Density Validated part number (vendor) Notes i.MX 8QXP/8DXP 21x21 mm 8Gb/1GB 2x MT41K256M16TW-093 IT:P (Micron) 12 i.MX 8XLite 15x15 mm           4Gb/512MB MT41K256M16TW-093 IT:P (Micron) 12   Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standard JESD209-4A. Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that a DRAM with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory vendors often do not offer so many variants of single-channel memory devices. As an alternative, a dual-channel device with only one channel connected may be used. For example: A dual-rank, single-channel device with 16-row address bits has a density of 16Gb. If such a device is not available at the chosen supplier, a dual-rank, dual-channel device with 16-row address bits can be used instead. This device has a density of 32 Gb however since only one channel can be connected to the SoC, only half of the density is available (16 Gb). Usage of more than one discrete memory chip to overcome market constraints is not supported since only point-to-point connections are assumed for LPDDR4. Note 4: Devices with 17-row addresses (R0-R16) are not supported by the SoCs.  Note 5: The numbers are based purely on the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standard JESD79-3E/JESD79-3F. Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that a DRAM with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 6: The density can be achieved by connecting 8 single rank discrete devices with one 8Gb die each, 4 devices connected to each chip select, or by connecting 4 dual rank discrete devices with two 8Gb dies each. Note that this number of discrete devices significantly exceeds the number of devices used on the validation board (2 discrete devices, not taking into account the device used for ECC) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis hence practically, it is not recommended to use more than 2 discrete DDR3L devices. This corresponds to the maximum density of 16Gb/2GB in the case of the single rank devices containing one 8Gb die or 32Gb/4GB in the case of the dual-rank devices containing two 8Gb dies (x16 8Gb devices with 16-row addresses and 10 column addresses assumed instead of x8 devices in such case). Note 7: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select, or by connecting 2 dual rank discrete devices with two 8Gb dies each. Note that the first option exceeds the number of devices used on the validation board (2 discrete devices) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis, hence practically, it is not recommended to use more than 2 discrete DDR3L devices. This corresponds to the maximum density of 16Gb/2GB in the case of the single rank devices containing one 8Gb die or 32Gb/4GB in the case of the dual-rank devices containing two 8Gb dies. Note 8: The density can be achieved by connecting 2 single rank discrete devices with one 8Gb die each to the i.MX. 8XLite supports only one chip select for DDR3L therefore, dual-rank systems are not supported. Note 9: For single-channel (x16) memory devices, the current maximum available density in the market is 16Gb/2GB (Q2 2022). Note 10: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 11: Part is active. Reviewed May 16th 2024 Note 12: Part is obsolete. Additional Links i.MX 8M Quad/8M Mini/8M Nano/8M Plus - LPDDR4, DDR4 and DDR3L memory compatibility guide 
View full article
  Test environment   i.MX8MP EVK LVDS0 LVDS-HDMI  bridge(it6263) L5.15.5_1.0.0 Background   Some customers need show logo using LVDS panel. Current BSP doesn't support LVDS driver in Uboot. This patch provides i.MX8MPlus LVDS driver support in Uboot. If you want to connect it to LVDS panel , you need port your lvds panel driver like  simple-panel.c   Update [2022.9.19] Verify on L5.15.32_2.0.0  0001-L5.15.32-Add-i.MX8MP-LVDS-driver-in-uboot 'probe device is failed, ret -2, probe video device failed, ret -19' is caused by below code. It has been merged in attachment. // /* Only handle devices that have a valid ofnode */ // if (dev_has_ofnode(dev) && !(dev->driver->flags & DM_FLAG_IGNORE_DEFAULT_CLKS)) { // /* // * Process 'assigned-{clocks/clock-parents/clock-rates}' // * properties // */ // ret = clk_set_defaults(dev, CLK_DEFAULTS_PRE); // if (ret) // goto fail; // }   [2023.3.14] Verify on L5.15.71 0001-L5.15.71-Add-i.MX8MP-LVDS-support-in-uboot   [2023.9.12] For some panel with low DE, you need uncomment CTRL_INV_DE line and set this bit to 1. #include <linux/string.h> @@ -110,9 +111,8 @@ static void lcdifv3_set_mode(struct lcdifv3_priv *priv, writel(CTRL_INV_HS, (ulong)(priv->reg_base + LCDIFV3_CTRL_SET)); /* SEC MIPI DSI specific */ - writel(CTRL_INV_PXCK, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); - writel(CTRL_INV_DE, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); - + //writel(CTRL_INV_PXCK, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); + //writel(CTRL_INV_DE, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); }       [2024.5.15] If you are uing simple-panel.c, need use below patch to set display timing from panel to lcdif controller. diff --git a/drivers/video/simple_panel.c b/drivers/video/simple_panel.c index f9281d5e83..692c96dcaa 100644 --- a/drivers/video/simple_panel.c +++ b/drivers/video/simple_panel.c @@ -18,12 +18,27 @@ struct simple_panel_priv { struct gpio_desc enable; }; +/* define your panel timing here and + * copy it in simple_panel_get_display_timing */ +static const struct display_timing boe_ev121wxm_n10_1850_timing = { + .pixelclock.typ = 71143000, + .hactive.typ = 1280, + .hfront_porch.typ = 32, + .hback_porch.typ = 80, + .hsync_len.typ = 48, + .vactive.typ = 800, + .vfront_porch.typ = 6, + .vback_porch.typ = 14, + .vsync_len.typ = 3, +}; + @@ -100,10 +121,18 @@ static int simple_panel_probe(struct udevice *dev) return 0; } +static int simple_panel_get_display_timing(struct udevice *dev, + struct display_timing *timings) +{ + memcpy(timings, &boe_ev121wxm_n10_1850_timing, sizeof(*timings)); + + return 0; +} static const struct panel_ops simple_panel_ops = { .enable_backlight = simple_panel_enable_backlight, .set_backlight = simple_panel_set_backlight, + .get_display_timing = simple_panel_get_display_timing, }; static const struct udevice_id simple_panel_ids[] = { @@ -115,6 +144,7 @@ static const struct udevice_id simple_panel_ids[] = { { .compatible = "lg,lb070wv8" }, { .compatible = "sharp,lq123p1jx31" }, { .compatible = "boe,nv101wxmn51" }, + { .compatible = "boe,ev121wxm-n10-1850" }, { } };  
View full article
For more information about the i.MX 8QM/QP revision, please see the attached PDF slide deck at the bottom of this page. It includes frequently asked questions and is the official source of information regarding this revision. ------------------------------------------------------------------------------------------------------------------------------------- The i.MX 8QM and i.MX 8QP has been revised with lower clock speeds and higher core voltages to help improve instability issues found with the part. Old parts that have not been derated have an "FF" moniker in the part number, whereas new parts, releasing in June 2024, have an "FE" moniker. An example can be found below. SCFW (System Controller Firmware) 1.16.0, which will be released with the Q2 Linux Factory BSP (LF6.6.y_2.0.0), will make the necessary changes to increase core voltage for CPU and GPU cores in the 8QM/8QP, as well as reduce clock speeds. It may not be immediately apparent what changes must be made to derate these processors before the new parts and new SCFW version is released. To assist with these issues, we are providing the changes below as a workaround until SCFW 1.16.0 is released.     Recommended Changes until SCFW 1.16.0 is released 1. Increase voltages in pmic_init(). This function is found inside the respective board.c file within the SCFW porting kit. This is assuming that the customer has routed their VDD_A72 to PMIC_0 on SW3 and SW4, and routed their VDD_GPU0 and VDD_GPU1 to PMIC_1 on SW1 through SW4. +/* Set VDD_A72 to 1.1375V (1138mV) */ +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_0_ADDR, PF8100_SW3, 1138, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_0_ADDR, PF8100_SW4, 1138, REG_RUN_MODE)) +/* Set VDD_GPU0 and VDD_GPU1 to 1.03125V (1032mV) */ +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW1, 1032, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW2, 1032, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW3, 1032, REG_RUN_MODE)) +BRD_ERR(PMIC_SET_VOLTAGE(PMIC_1_ADDR, PF8100_SW4, 1032, REG_RUN_MODE))   2. Add +37.5mV offset for VDD_A72, +31.25mV offset for VDD_GPU0/VDD_GPU1. This is done in the function board_set_voltage, found in board.c of the respective processor in the SCFW porting kit. This ensures that voltages are set correctly if a frequency change occurs (like going from overdrive to nominal mode on GPU). /*--------------------------------------------------------------------------*/ /* Set the voltage for the given SS. */ /*--------------------------------------------------------------------------*/ sc_err_t board_set_voltage(sc_sub_t ss, uint32_t new_volt, uint32_t old_volt) { sc_err_t err = SC_ERR_NONE; pmic_id_t pmic_id[2] = {0U, 0U}; uint32_t pmic_reg[2] = {0U, 0U}; uint8_t num_regs = 0U; +// A72 cores are running on 1.1375V instead of 1.10V +if ((ss == SC_SUBSYS_A72) && (new_volt == 1100)) { +board_print(3, "Changing voltage from 1100 to 1138"); +new_volt = 1138; +} +// GPU is running on 1.03125V instead of 1.00V +if ((ss == SC_SUBSYS_GPU_0 || SC_SUBSYS_GPU_1) && (new_volt == 1000)) { +board_print(3, "Changing voltage from 1000 to 1032"); +new_volt = 1032; +} board_print(3, "board_set_voltage(%s, %u, %u)\n", snames[ss], new_volt, old_volt); board_get_pmic_info(ss, pmic_id, pmic_reg, &num_regs);   3. Remove 1.6GHz from Linux DTS OPP Table for A72 core. This is found in the device tree of the board. These are typically found in /arch/arm64/boot/dts/freescale/. /* opp-1596000000 { opp-hz = /bits/ 64 <1596000000>; opp-microvolt = <1100000>; clock-latency-ns = <150000>; opp-suspend; }; */ 4. Disable GPU overdrive mode - set to nominal mode using sysfs in Linux userland echo "nominal" > /sys/bus/platform/drivers/galcore/gpu_govern
View full article
We are pleased to announce that Config Tools for i.MX v15.1 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...)   Version 15.1 • On MacOS aarch64, the missing Overview is fixed. • TEE – Pin tables now only contain items for specific configuration (mask/security/interrupts).
View full article
P3T1755DP is a ±0.5°C accurate temperature-to-digital converter with a -40 °C to +125 °C range. It uses an on-chip band gap temperature sensor and an A-to-D conversion technique with overtemperature detection. The temperature register always stores a 12-bit two's complement data, giving a temperature resolution of 0.0625 °C P3T1755DP which can be configured for different operation conditions: continuous conversion, one-shot mode, or shutdown mode.   The device has very good features but, unfortunately, is not supported by Linux yet!   The P31755 works very similarly to LM75, pct2075, and other compatibles.   We can add support to P3T1755 in the LM75.c program due to the process to communicate with the device is the same as LM75 and equivalents.   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.55-2.2.0/drivers/hwmon/lm75.c route: drivers/hwmon/lm75.c   The modifications that we have to do are the next:    1. We have to add the configurations to the kernel on the imx_v8_defconfig file CONFIG_SENSORS_ARM_SCMI=y CONFIG_SENSORS_ARM_SCPI=y CONFIG_SENSORS_FP9931=y +CONFIG_SENSORS_LM75=m +CONFIG_HWMON=y +CONFIG_I2C=y +CONFIG_REGMAP_I2C=y CONFIG_SENSORS_LM90=m CONFIG_SENSORS_PWM_FAN=m CONFIG_SENSORS_SL28CPLD=m    2. Add the part on the list of parts compatible with the driver LM75.c enum lm75_type { /* keep sorted in alphabetical order */ max6626, max31725, mcp980x, + p3t1755, pct2075, stds75, stlm75,   3. Add the configuration in the structure lm75_params device_params[]. .default_resolution = 9, .default_sample_time = MSEC_PER_SEC / 18, }, + [p3t1755] = { + .default_resolution = 12, + .default_sample_time = MSEC_PER_SEC / 10, + }, [pct2075] = { .default_resolution = 11, .default_sample_time = MSEC_PER_SEC / 10,   Notes: You can change the configuration of the device using .set_mask and .clear_mask, see more details on LM75.c lines 57 to 78   4. Add the ID to the list in the structure i2c_device_id lm75_ids and of_device_id __maybe_unused lm75_of_match    { "max31725", max31725, }, { "max31726", max31725, }, { "mcp980x", mcp980x, }, + { "p3t1755", p3t1755, }, { "pct2075", pct2075, }, { "stds75", stds75, }, { "stlm75", stlm75, },   + { + .compatible = "nxp,p3t1755", + .data = (void *)p3t1755 + },   5. In addition to all modifications, I modify the device tree of my iMX8MP-EVK to connect the Sensor in I2C3 of the board.  https://github.com/nxp-imx/linux-imx/blob/lf-6.1.55-2.2.0/arch/arm64/boot/dts/freescale/imx8mp-evk.dts   }; }; + + p3t1755: p3t1755@48 { + compatible = "nxp,p3t1755"; + reg = <0x48>; + }; + };   Connections: We will use the expansion connector of the iMX8MP-EVK and J9 of the P3T1755DP-ARD board.   P3T1755DP-ARD board   iMX8MP-EVK   P3T1755DP-ARD ----> iMX8MP-EVK J9              ---------->            J21 +3v3 (Pin 9) ---> +3v3 (Pin 1) GND(Pin 7) ---> GND (PIN 9) SCL (Pin 4) ---> SCL (Pin 5) SDA (Pin 3) ---> SDA (Pin 3)     Reading the Sensor We can read the sensor using the next commands:   Read Temperature: $ cat /sys/class/hwmon/hwmon1/temp1_input Reading maximum temperature: $ cat /sys/class/hwmon/hwmon1/temp1_max Reading hysteresis: $ cat /sys/class/hwmon/hwmon1/temp1_max_hyst   https://www.nxp.com/design/design-center/development-boards-and-designs/analog-toolbox/arduino-shields-solutions/p3t1755dp-arduino-shield-evaluation-board:P3T1755DP-ARD    
View full article
    The meta layer is designed for those guys who want to use i.MX8M series SOC and Yocto system to develop AGV and Robot.    The platform includes some key components: 1, ROS1 (kinetic, melodic) and ROS2(dashing, eloquent, foxy) 2, Real-time Linux solution : Xenomai 3.1 with ipipe 5.4.47 patch 3, Industrial protocol : libmodbus, linuxptp, ros-canopen, EtherCAT(TBD) 4, Security: Enhanced OpenSSL, Enhanced GmSSL, Enhanced eCryptfs, secure key store, secure boot(TBD), SE-Linux(TBD),  Dm-verity(TBD) The first release bases on i.MX Yocto release L5.4.47 2.2.0 and You need download Linux 5.4.47_2.2.0 according to​​ https://www.nxp.com/docs/en/user-guide/IMX_YOCTO_PROJECT_USERS_GUIDE.pdf  firstly. And then you can follow the below guide to build and test ROS and Xenomai. A, clone meta-robot-platform from gitee.com git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v0.1-L5.4.47-2.2.0 B, Adding the meta-robot-platform layer to your build 1,  copy meta-robot-platform into <i.MX Yocto folder>/source 2, You should create a symbol link: setup-imx-robot.sh -> sources/meta-robot-platform/imx/meta-robot/tools/setup-imx-robot.sh C, How to build Robot image (example for i.MX8MQ EVK board) $ DISTRO=imx-robot-xwayland MACHINE=imx8mqevk source setup-imx-robot.sh -r kinetic -b imx8mqevk-robot-kinetic [or DISTRO=imx-robot-xwayland MACHINE=imx8mqevk source setup-imx-robot.sh -r melodic -b imx8mqevk-robot-melodic ] [or DISTRO=imx-robot-xwayland MACHINE=imx8mqevk source setup-imx-robot.sh -r dashing -b imx8mqevk-robot-dashing ] [or DISTRO=imx-robot-xwayland MACHINE=imx8mqevk source setup-imx-robot.sh -r eloquent -b imx8mqevk-robot-eloquent ] [or DISTRO=imx-robot-xwayland MACHINE=imx8mqevk source setup-imx-robot.sh -r foxy -b imx8mqevk-robot-foxy ] $ bitbake imx-robot-core [or bitbake imx-robot-system ] [or bitbake imx-robot-sdk ] And if you add XENOMAI_KERNEL_MODE = "cobalt" or XENOMAI_KERNEL_MODE = "mercury" in local.conf, you also can build real-time image with Xenomai by the below command: $ bitbake imx-robot-core-rt [or bitbake imx-robot-system-rt ] D, Robot image sanity testing //ROS1 Sanity Test #source /opt/ros/kinetic/setup.sh [or # source /opt/ros/melodic/setup.sh ] #echo $LD_LIBRARY_PATH #roscore & #rosnode list #rostopic list #only kinetic #rosmsg list #rosnode info /rosout //ROS2 Sanity Test #source ros_setup.sh #echo $LD_LIBRARY_PATH #ros2 topic list #ros2 msg list #only dashing #ros2 interface list #(sleep 5; ros2 topic pub /chatter std_msgs/String "data: Hello world") & #ros2 topic echo /chatter E, Xenomai sanity testing #/usr/xenomai/demo/cyclictest -p 50 -t 5 -m -n -i 1000 F, vSLAM demo You can find orb-slam2 demo under <i.MX Yocto folder>/sources/meta-robot-platform/imx/meta-robot/recipes-demo/orb-slam2. You should choose DISTRO=imx-robot-xwayland due to it depends on OpenCV with gtk+.   //////////////////////////////////////// update for Yocto L5.4.70 2.3.0  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v0.2-L5.4.70-2.3.0 for Yocto release L5.4.70 2.3.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP) and i.MX8QM/QXP.  git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v0.2-L5.4.70-2.3.0 Updating: 1, Support i.MX8QM and i.MX8QXP 2, Add ROS driver of RPLIDAR and Orbbec 3D cameras in ROS1 3, Upgrade OpenCV to 3.4.13. 4, Add imx-robot-agv image with orb-slam2 demo 5, Fix the issue which failed to create image when adding orb-slam2 6, Fix the issue which failed to create imx-robot sdk image when add package ISP and ML Note: Currently, orb-slam2 demo don't run on i.MX8MM platform due to its GPU don't support OpenGL ES3. imx-robot-sdk image is just for building ROS package on i.MX board, not  for cross-compile. You can try "bitbake imx-robot-system -c populate_sdk" to create cross-compile sdk without gmssl-bin. diff --git a/imx/meta-robot/recipes-core/images/imx-robot-system.bb b/imx/meta-robot/recipes-core/images/imx-robot-system.bb index 1991ab10..68f9ad31 100644 --- a/imx/meta-robot/recipes-core/images/imx-robot-system.bb +++ b/imx/meta-robot/recipes-core/images/imx-robot-system.bb @@ -35,7 +35,7 @@ CORE_IMAGE_EXTRA_INSTALL += " \ ${@bb.utils.contains('DISTRO_FEATURES', 'x11 wayland', 'weston-xwayland xterm', '', d)} \ ${ISP_PKGS} \ " -IMAGE_INSTALL += " clblast openblas libeigen opencv gmssl-bin" +IMAGE_INSTALL += " clblast openblas libeigen opencv" IMAGE_INSTALL += " \ ${ML_PKGS} \   //////////////////////////////////////// Update for Yocto L5.4.70 2.3.2  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v0.3-L5.4.70-2.3.2 for Yocto release L5.4.70 2.3.2 .  git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v0.3-L5.4.70-2.3.2 Updated: 1, Upgrade to L5.4.70-2.3.2 2, Enable xenomai rtdm driver 3, Add NXP Software Content Register and BSP patches of i.MX8M Plus AI Robot board. Note: How to build for AI Robot board 1, DISTRO=imx-robot-wayland MACHINE=imx8mp-ddr4-ipc source setup-imx-robot.sh -r melodic -b imx8mp-ddr4-ipc-robot-melodic 2, Add BBLAYERS += " ${BSPDIR}/sources/meta-robot-platform/imx/meta-imx8mp-ai-robot " in bblayers.conf 3, bitbake imx-robot-sdk or bitbake imx-robot-agv   //////////////////////////////////////// Update for v1.0-L5.4.70-2.3.2  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v1.0-L5.4.70-2.3.2 .  git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v1.0-L5.4.70-2.3.2 Updated: 1, Upgrade ROS1 Kinetic Kame to Release 2021-05-11 which is final sync. 2, Add IgH EtherCAT Master for Linux in i.MX Robot platform. //////////////////////////////////////// Update for v1.1-L5.4.70-2.3.2  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v1.1-L5.4.70-2.3.2 .  git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v1.1-L5.4.70-2.3.2 Updated: 1, Add more packages passed building in ROS1 Kinetic Kame. 2, Change the board name (From IPC to AI-Robot) in Uboot and kernel for i.MX8M Plus AI Robot board. You can use the below setup command to build ROS image for AI Robot board: DISTRO=imx-robot-xwayland MACHINE=imx8mp-ai-robot source setup-imx-robot.sh -r kinetic -b imx8mp-ai-robot-robot-kinetic DISTRO=imx-robot-xwayland MACHINE=imx8mp-ai-robot source setup-imx-robot.sh -r melodic -b imx8mp-ai-robot-robot-melodic DISTRO=imx-robot-xwayland MACHINE=imx8mp-ai-robot source setup-imx-robot.sh -r dashing -b imx8mp-ai-robot-robot-dashing DISTRO=imx-robot-xwayland MACHINE=imx8mp-ai-robot source setup-imx-robot.sh -r eloquent -b imx8mp-ai-robot-robot-eloquent DISTRO=imx-robot-xwayland MACHINE=imx8mp-ai-robot source setup-imx-robot.sh -r foxy -b imx8mp-ai-robot-robot-foxy BTW, you should add BBLAYERS += " ${BSPDIR}/sources/meta-robot-platform/imx/meta-imx8mp-ai-robot " in conf/bblayers.conf.   //////////////////////////////////////// Update for v1.2-L5.4.70-2.3.3  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v1.2-L5.4.70-2.3.3 .  git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v1.2-L5.4.70-2.3.3 Updated: 1, Update to Yocto release L5.4.70-2.3.3 2, Enable RTNet FEC driver, test on i.MX8M Mini EVK and i.MX8M Plus EVK. For the detailed information,  Please refer to the community post 移植实时Linux方案Xenomai到i.MX ARM64平台 (Enable Xenomai on i.MX ARM64 Platform)    //////////////////////////////////////// Update for v2.1-L5.10.52-2.1.0  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v2.1-L5.10.52-2.1.0 .  git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v2.1.1-L5.10.52-2.1.0 Updated: 1, Update to Yocto release L5.10.52-2.1.0 2, Add ROS1 noetic, ROS2 galactic and rolling 3, Upgrade Xenomai to v3.2 4, Add vSLAM demo orb-slam3 5, Upgrade OpenCV to 3.4.15 for ROS1 A, Adding the meta-robot-platform layer to your build 1,  copy meta-robot-platform into <i.MX Yocto folder>/source 2, You should create a symbol link: setup-imx-robot.sh -> sources/meta-robot-platform/imx/meta-robot/tools/setup-imx-robot.sh B, How to build Robot image (example for i.MX8M Plus EVK board) $ DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r kinetic -b imx8mpevk-robot-kinetic [or DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r melodic -b imx8mpevk-robot-melodic ] [or DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r noetic-b imx8mpevk-robot-noetic] [or DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r dashing -b imx8mpevk-robot-dashing ] [or DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r eloquent -b imx8mpevk-robot-eloquent ] [or DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r foxy -b imx8mpevk-robot-foxy ] [or DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r galactic -b imx8mpevk-robot-galactic ] [or DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r rolling -b imx8mpevk-robot-rolling ] $ bitbake imx-robot-agv [or bitbake imx-robot-core ] [or bitbake imx-robot-system ] [or bitbake imx-robot-sdk ]   //////////////////////////////////////// Update for v2.2-L5.10.72-2.2.0  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v2.2-L5.10.72-2.2.0 .  git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v2.2.0-L5.10.72-2.2.0 Updated: 1, Update to Yocto release L5.10.72-2.2.0   //////////////////////////////////////// Update for v2.2.3-L5.10.72-2.2.3  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v2.2.3-L5.10.72-2.2.3.  repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-hardknott -m imx-5.10.72-2.2.3.xml git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v2.2.3-L5.10.72-2.2.3 1,  copy meta-robot-platform into <i.MX Yocto folder>/source 2, You should create a symbol link: setup-imx-robot.sh -> sources/meta-robot-platform/imx/meta-robot/tools/setup-imx-robot.sh Updated: 1, Update to Yocto release L5.10.72-2.2.3 2, Update ISP SDK (isp-imx) patch for Github changing.   //////////////////////////////////////// Update for v3.1-L5.15.71-2.2.0  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v3.1-L5.15.71-2.2.0.  repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-kirkstone -m imx-5.15.71-2.2.0.xml git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v3.1-L5.15.71-2.2.0 1,  copy meta-robot-platform into <i.MX Yocto folder>/source 2, You should create a symbol link: setup-imx-robot.sh -> sources/meta-robot-platform/imx/meta-robot/tools/setup-imx-robot.sh Updated: 1, Update to Yocto release L5.15.71-2.2.0 and ROS1 Noetic and ROS2 Foxy to last version 2, Add ROS2 Humble and remove EOL distributions (ROS1 Kinetic, Melodic and ROS2 Dashing, Eloquent and Galactic). How to build Robot image (example for i.MX8M Plus EVK board) $DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r noetic-b imx8mpevk-robot-noetic [or DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r foxy -b imx8mpevk-robot-foxy ] [or DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r humble -b imx8mpevk-robot-humble ] $ bitbake imx-robot-sdk [or bitbake imx-robot-core ] [or bitbake imx-robot-system ] [or bitbake imx-robot-agv ]   //////////////////////////////////////// Update for v3.3-L5.15.71-2.2.0  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v3.3-L5.15.71-2.2.0.  repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-kirkstone -m imx-5.15.71-2.2.0.xml git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout v3.3-L5.15.71-2.2.0 1,  copy meta-robot-platform into <i.MX Yocto folder>/source 2, You should create a symbol link: setup-imx-robot.sh -> sources/meta-robot-platform/imx/meta-robot/tools/setup-imx-robot.sh Updated: 1, Add vSLAM ROS demo based on i.MX vSLAM SDK and i.MX AIBot. The demo video is here: Autonomous Navigation with vSLAM, Based on the i.MX 8M Plus Applications Processor   2, Enable DDS Security and SROS2 for ROS 2’s security features. How to build Robot image (example for i.MX8M Plus EVK board) $DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r noetic-b imx8mpevk-robot-noetic [or DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r foxy -b imx8mpevk-robot-foxy ] [or DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r humble -b imx8mpevk-robot-humble ] $ bitbake imx-robot-sdk [or bitbake imx-robot-agv ] [or bitbake imx-robot-system ] [or bitbake imx-robot-core ]   //////////////////////////////////////// Update for v4.0-L6.1.55-2.2.0  /////////////////////////////////////////////////////////// New release package meta-robot-platform-v4.0-L6.1.55-2.2.0.  repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.55-2.2.0.xml git clone https://gitee.com/zxd2021-imx/meta-robot-platform.git git checkout mickledore-6.1.55 1,  copy meta-robot-platform into <i.MX Yocto folder>/source 2, You should create a symbol link: setup-imx-robot.sh -> sources/meta-robot-platform/imx/meta-robot/tools/setup-imx-robot.sh Updated: 1, Migrate i.MX Robot platform to Yocto mickledore with L6.1.55. 2, Add ROS2 iron. How to build Robot image (example for i.MX8M Plus EVK board) $DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r humble -b imx8mpevk-robot-humble [or DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r iron -b imx8mpevk-robot-iron ] [or DISTRO=imx-robot-xwayland MACHINE=imx8mpevk source setup-imx-robot.sh -r noetic-b imx8mpevk-robot-noetic] $ bitbake -k imx-robot-sdk [or bitbake imx-robot-agv ] [or bitbake imx-robot-system ] [or bitbake imx-robot-core ]  
View full article
What is LGVL? LVGL is a graphics library to run on devices with limited resources. LVGL is fully open-source and has no external dependencies, works with any modern MCU or MPU, and can be used with any (RT)OS or bare metal setup. https://lvgl.io/   What is Framebuffer? The Linux framebuffer (fbdev) is a Linux subsystem used to show graphics on a display, typically manipulated on the system console   How to write on the frame buffer? The device is listed on de device list typically "fb0" on iMX.   1. Stop the window manager (Weston in our BSP) $ systemctl stop weston   2. Write random data on the frame buffer with the next command: $ cat /dev/urandom > /dev/fb0   You should see colored pixels on the screen   3. Restart the window manager. $ systemctl start weston     Cross-compiling the application   1. On the host computer we will clone the LGVL repo: $ git clone https://github.com/lvgl/lv_port_linux_frame_buffer.git -b release/v8.2 $ cd lv_port_linux_frame_buffer $ git submodule update --init --recursive 2. Configure the screen resolution, rotation, and the touch input.       2.1 The resolution is configured in lines 33 and 34 of the main.c disp_drv.hor_res = 1080; disp_drv.ver_res = 1920;           2.2 Rotation configured is on lines 32 and 57 of main.c. disp_drv.sw_rotate = 3; lv_disp_set_rotation(NULL, LV_DISP_ROT_270);     2.3 The touch input is configured on line 450 of lv_drv_conf.h # define EVDEV_NAME "/dev/input/event2"   Note: In my case is on /dev/input/event2 to check the inputs use the command "evtest"   3. Compile the application using the command "make"   Note: To compile the application on your host computer you have to set the environment.   4. Share the file called "demo" with your board and execute it on the board with the command $ ./demo   Note: You have to stop the weston service to run the application.     Notes: Tested on iMX8MN EVK with BSP 6.1.36 Works on Multimedia and Full image.
View full article
Sometime need standalone compile device tree. Only Linux headers and device tree directory are needed.         
View full article
This article is rather short that only mentions the script that is needed to make an iMX93EVK act as a USB mass storage device so that whenever you connect your iMX device to a windows/linux system via USB, it should get enumerated something like a usb drive.  The storage that is used in this example is mmc so the expectation is that you have inserted a mmc card in the slot. Below is the script:- #!/bin/sh   # This composite gadget include function: # - MASS STORAGE     # # Exit status is 0 for PASS, nonzero for FAIL # STATUS=0   # Check if there is udc available, if not, return fail UDC_DIR=/sys/class/udc if test "$(ls -A "$UDC_DIR")"; then echo "The available udc:" for entry in "$UDC_DIR"/* do echo "$entry" done else STATUS=1 echo "No udc available!" exit $STATUS; fi   id=1; udc_name=ci_hdrc.0 #back_file=/dev/mmcblk1 back_file=/tmp/lun0.img   mkdir /sys/kernel/config/usb_gadget/g$id cd /sys/kernel/config/usb_gadget/g$id   # Use NXP VID, i.MX8QXP PID echo 0x1fc9 > idVendor echo 0x12cf > idProduct   mkdir strings/0x409 echo 123456ABCDEF > strings/0x409/serialnumber echo NXP > strings/0x409/manufacturer echo "NXP iMX USB Composite Gadget" > strings/0x409/product   mkdir configs/c.1 mkdir configs/c.1/strings/0x409   echo 5 > configs/c.1/MaxPower echo 0xc0 > configs/c.1/bmAttributes   mkdir functions/mass_storage.1 echo $back_file > functions/mass_storage.1/lun.0/file ln -s functions/mass_storage.1 configs/c.1/   echo $udc_name > UDC First execute the script. After that insert the g_mass_storage module in the kernel by executing :- modprobe g_mass_storage file=/dev/mmcblk1 removable=1 In the dmesg output, you will see something like below:-   After that you can connect a C type USB cable to the USB1 port of imx93evk and the other end to any USB ports of a laptop. The moment it is connected, you would be able to see a USB drive similar to what you get when we connect a pen-drive. 
View full article
This article introduces the overall functionality of i.MX8X security. Simulate the process of i.MX8X signature through OpenSSL provides readers with a deeper understanding of this process.   Because lots of limitation for attachments. Have to do following.  1. download                       T4549-i.MX8X security overview and AHAB deep dive.zip.001.zip                      T4549-i.MX8X security overview and AHAB deep dive.zip.002.zip                      T4549-i.MX8X security overview and AHAB deep dive.zip.003.zip 2. decompress                T4549-i.MX8X security overview and AHAB deep dive.zip.001.zip                T4549-i.MX8X security overview and AHAB deep dive.zip.002.zip                T4549-i.MX8X security overview and AHAB deep dive.zip.003.zip 3. Put together and decompress         T4549-i.MX8X security overview and AHAB deep dive.zip.001    T4549-i.MX8X security overview and AHAB deep dive.zip.002    T4549-i.MX8X security overview and AHAB deep dive.zip.003  
View full article