After following instructions on how to change DRAM PLL frequency, here is a quick comparison of Stream, running on the i.MX 8MM. Normalized to LPDDR4-3000, based on 5.4.24_2.1.0​ BSP Stream LP4-3000 LP4-2400 DDR4-2400 LPDDR-1866 Copy: 1 0.810 0.735 0.497 Scale: 1 0.896 0.765 0.756 Add: 1 0.899 0.683 0.762 Triad: 1 0.902 0.680 0.767      

  For some applications, we need to reduce the CPU Frequency, but if you are not familiar with our BSP or our devices probably you need some help to do some configurations.   In this post, I will share the configuration to set up lower frequencies (100MHz, 200MHz, 400Mhz, 600MHz, 800MHz, and 1000MHz) on iMX8MP, iMX8MN, and iMX8MM.   Note: Works on Kernel 6.1.xx (not tested on oldest BSP)   1- We have to modify the PLL driver to set the proper parameters to lower frequencies. The file to modify is "clk-pll14xx.c" adding the following lines:   https://github.com/nxp-imx/linux-imx/blob/770c5fe2c1d1529fae21b7043911cd50c6cf087e/drivers/clk/imx/clk-pll14xx.c#L57   static const struct imx_pll14xx_rate_table imx_pll1416x_tbl[] = { PLL_1416X_RATE(1800000000U, 225, 3, 0), PLL_1416X_RATE(1600000000U, 200, 3, 0), PLL_1416X_RATE(1500000000U, 375, 3, 1), PLL_1416X_RATE(1400000000U, 350, 3, 1), PLL_1416X_RATE(1200000000U, 300, 3, 1), PLL_1416X_RATE(1000000000U, 250, 3, 1), PLL_1416X_RATE(800000000U, 200, 3, 1), PLL_1416X_RATE(750000000U, 250, 2, 2), PLL_1416X_RATE(700000000U, 350, 3, 2), PLL_1416X_RATE(600000000U, 300, 3, 2), + PLL_1416X_RATE(400000000U, 200, 3, 2), + PLL_1416X_RATE(200000000U, 200, 3, 3), + PLL_1416X_RATE(100000000U, 200, 3, 4), };   2- Once the pll driver has been modified, only we have to add the values on the opp-table according to the device that you will use.   2.1- For iMX 8MP:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mp.dtsi         a53_opp_table: opp-table { compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; opp-1200000000 { opp-hz = /bits/ 64 <1200000000>;   2.2 For iMX8MM:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mm.dtsi     a53_opp_table: opp-table { compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; opp-1200000000 { opp-hz = /bits/ 64 <1200000000>;   2.3- For iMX8MN:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mn.dtsi   compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1200000000 { opp-hz = /bits/ 64 <1200000000>; opp-microvolt = <850000>;   After that, you should note the changes under Linux.   These commands return information about the system and the current settings.   • The kernel is pre-configured to support only certain frequencies. The list of frequencies currently supported can be obtained from: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies   • To get the available scaling governors: cat /sys/devices/system/cpu/*/cpufreq/scaling_available_governors   • To check the current CPU frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_cur_freq   The frequency is displayed depending on the governor set.   • To check the maximum frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_max_freq   • To check the minimum frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_min_freq   These commands set a constant CPU frequency:   • Use the maximum frequency: echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor   • Use the current frequency to be the constant frequency: echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor   • The following two commands set the scaling governor to a specified frequency, if that frequency is supported.   If the frequency is not supported, the closest supported frequency is used:   echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo <frequency> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed    

Instrumenting A Board To instrument a board, the connection between the power supply and the target device needs to be broken, usually via a series resistor that's placed on the board. Sometimes the inductor needs to be lifted if no series resistor was included on the rail by the board's designer. In the ideal case, through-hole connections were also provided on the board for the connection of these off-board sensors. Here are three close-up photos that show several boards that have been instrumented: In all three cases, the sensors stand in place via the two outer current carrying wires. The middle and right used insulated wires where as the one on the left used bare wires. In all three cases, the sensor's + connection needs to go towards the power supply and the - connection goes to the target device. The outer wires here are 24-26 gauge. (The relatively heavy gauge wire is used to keep the series resistance of inserting a smart sensor to a minimum.) The ground connection is the middle hole of the smart sensor. In the left and middle photos, a 30 gauge wire connects to the middle hole ground connection on the  board. In the right photo, the ground wire was more conveniently added to a big cap just below the bottom of edge of the photo. Here are wider angle view photos of two of the boards above: The sensors on the left are free-standing since the current carrying wires are stiff enough to hold them upright. Care must be taken since too much flexing will cause a wire to break. Too much bending can also cause a short to the board (and that's why insulated wires were used on these boards). The board on the right has the sensors laying parallel to the board. They are not affixed to the board, but a wire is wrapped around the bundle of ribbon cables out of view past the right edge of the photo. For boards without the through hole connections, the smart sensors need to be immobilized to keep from pulling the SMT pads off the board. If there is room on the board or sides of connectors or large components, the sensors may be attached down with foam double-sticky tape (see photo below, sensor affixed on top i.MX7ULP): For boards where there are no convenient unpopulated areas or there are too many sensors, some other means needs to be devised to immoblize the smart sensors. In the left photo below, two inductors per sensor have been flipped and the two sensors inserted to instrument the two rails. The solder pads on the inductors would easily be broken off by any movement of the smart sensors, so a cage with clamps to hold the ribbon cables was 3D printed. On the back side, there is room for the aggregator to be zip tied to the bottom plate, so the instrumented board can be moved as a single unit with minimal flexing of the ribbon cables.

Some customer need to test ENET IEEE1588 1pps ouput signal. This article describe all i.MX8 serials test procedure, including normal ENET port and EQOS port(i.MX8MP & i.MX8DXL support EQOS).

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

i.MX evaluation board can be a simple solution to program i.MX boards in a factory for instance. i.MX evaluation board are not for industrial usage, but you can find plenty of cheap i.MX insdustrial boards on the web. Here I am using an i.MX8QXP rev B0 MEK board and I will program an i.MX6Q SABRE SD board. The first step is to generate your image. Follow the documentation steps to generate the "validation" image. You will have to customize a little bit the local.conf file (in conf/local.conf) to have git, cmake, gcc and other missing package. edit local.conf and add the following lines at the end of the file: IMAGE_INSTALL_append = " git cmake htop packagegroup-core-buildessential xz p7zip rsync"‍‍‍‍‍ I have added rsync package in local, it can replace cp (copy) but with the --progress option you can see the copy progression. P7zip replace unzip for our images archives avaialable on nxp.com as unzip as issues with big files. then rebake your image: bitbake -k fsl-image-validation-imx‍‍‍‍‍ When it is done, go in tmp/deploy/image/<your image generated> and use uuu to program your board (I use a sd card; thus I can increase the partition esily): sudo ./uuu -b sd_all imx-boot-imx8qxpmek-sd.bin-flash fsl-image-validation-imx-imx8qxpmek.sdcard.bz2/*‍‍‍‍‍ As the rootfs can be too small, use gparted under Linux for instance to increase the size of the partition. Put the SD card and start your board. Here here the dirty part... You may know archlinux|ARM websitesite (Arch Linux ARM ), you have a lots of precompiled packages. Thus on the board you can download it, and copy the file in /usr folder (you can use it to have the latest openSSL for  instance!). Plug an ethernet cable on the board and check if it is up: ifconfig -a ifconfig eth0 up‍‍‍‍‍‍‍‍‍‍ Now you should have access to the internet. On uuu webpage you can find all the packages you need (here I am using a 4.14.98_2.0.0 Linux): mkdir missinglibs cd missinglibs wget http://mirror.archlinuxarm.org/aarch64/core/bzip2-1.0.8-2-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/nettle-3.5.1-1-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/libusb-1.0.22-1-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/extra/libzip-1.5.2-2-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/zlib-1:1.2.11-3-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/extra/p7zip-16.02-5-aarch64.pkg.tar.xz cd ..‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Wait all the archives are downloaded (otherwise you'll decompress before the archive is downloaded) as wget is running in background! Now untar the archives and copy it in the rootfs (dirty): tar -xJf libzip-1.5.2-2-aarch64.pkg.tar.xz tar -xJf libusb-1.0.22-1-aarch64.pkg.tar.xz tar -xJf nettle-3.5.1-1-aarch64.pkg.tar.xz tar -xJf bzip2-1.0.8-2-aarch64.pkg.tar.xz cp zlib-1:1.2.11-3-aarch64.pkg.tar.xz zlib tar -xJf zlib tar -xJf p7zip-16.02-5-aarch64.pkg.tar.xz cd usr sudo cp -R . /usr cd ../../ ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Download and compile uuu: git clone git://github.com/NXPmicro/mfgtools.git cd mfgtools/ cmake . make‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Download an image on nxp.com for instance. I have downloaded on the i.MX6 4.14.98_2.0.0 image and put it on a usb key. then unzip it in the uuu folder: 7z e L4.14.98_2.0.0_ga_images_MX6QPDLSOLOX.zip‍‍‍‍ As mentionned before unzip cannot hadle big files... so use 7z as me plug the i.MX6Q SABRE SD to the i.MX8X and program your i.MX6 board: ./uuu uuu.auto-imx6qsabresd‍ uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.3.74-0-g64eeca1 Success 1 Failure 0 ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

In order to improve the speed of compilation, VMWare Player 14.0 is installed on local hard disk, and Ubuntu 18.04 LTS is installed on a SSD with at least 500GB size and USB3.1 specification. When installing ubuntu 18.04 LTS to SSD, it should be allocated at least 350GB of disk space, because compiling this version of android requires a larger disk space. The following are detailed compilation steps: Part l Configuring Ubuntu 18.04 LTS 1. Installing Ubuntu 18.04 on VMplayer 14.0 After installation is done, root user should be set at first. # sudo passwd root Then follow these steps to configuration ubuntu 18.04 for environment of compiliation --Changing sources of ubuntu 18.04 mirror If you are Chinese users, you can do the step, which can improve your system performance. # sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak # sudo geit /etc/apt/source.list Comment I.MX customers outside China do not need to modify Ubuntu source list, or can modify it to local mirror site of Ubuntu 18.04, which can improve the speed of software upgrade.    Delet all sources and copy following lines here, Then save it and exit Changing ubuntu source deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse # deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-proposed main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-proposed main restricted universe multiverse    Then running these 2 commands to update sources and packages    # sudo apt-get update    # sudo apt-get upgrade 2. Installing packages for compiliation Packages for compiliation # sudo apt-get install flex bison gperf build-essential zlib1g-dev lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev tofrodos python-markdown libxml2-utils xsltproc # sudo apt-get install uuid-dev:i386 liblzo2-dev:i386 gcc-multilib g++-multilib subversion openssh-server openssh-client uuid uuid-dev zlib1g-dev liblz-dev lzop liblzo2-2 liblzo2-dev git-core curl # sudo apt-get install u-boot-tools mtd-utils android-tools-fsutils openjdk-8-jdk device-tree-compiler aptitude libcurl4-openssl-dev nss-updatedb # sudo apt-get install chrpath texinfo gawk cpio diffstat gdisk m4 libz-dev libssl-dev Part 2 Compiling Android Q10.0.0_2.1.0 BSP 1. Downloading NXP source code for Android Q10.0.0_2.1.0    File name is imx-android-10.0.0_2.1.0.tar.gz.    Copy the file to ~/, and decompress it.    # cd ~/    # tar zxvf ./imx-android-10.0.0_2.1.0.tar.gz    Then “imx-android-10.0.0_2.1.0” directory is created at ~/, now run the command to download android source code. # source ./imx-android-10.0.0_2.1.0/imx_android_setup.sh Comment imx_android_setup.sh is a script file, which includes all steps needed by the environment of android Q10.0.0_2.1.0 BSP. If network environment is enough good, several hours later, it will be done. 2. Compiling Android Q10.0.0_2.1.0 Referring to steps in Android_User's_Guide.pdf, We summaries steps for compilation here: (1) Preparing cross-compile tool chain    In Android_User's_Guide.pdf, 2 kinds of tool chain are recommended for users. --- gcc-arm-8.3-2019.03-x86_64-aarch64-elf.tar.xz --- gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu.tar.xz    Users can select one of them, and then decompress it to /opt/ directory. On how to download them or more details, see Android_User's_Guide.pdf, page 3. Here we will use gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu.tar.xz as tool chain. (2) Beginning to Compile Android Q10.0.0_2.1.0 BSP    Since this version of Android BSP requires high memory capacity when compiling, if the memory configuration of the virtual machine is incorrect, it is very likely to cause the compilation to fail. The following is a list of variable tests for user reference: # cd android_build # export AARCH64_GCC_CROSS_COMPILE=/opt/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu- # source build/envsetup.sh # lunch evk_8mp-userdebug # ./imx-make.sh -j2 2>&1 | tee build-log.txt Part 3 Errors During Compilation 1. Allocating 8GB Memory For VMware Player # ./imx-make.sh -j1 2>&1 | tee build-log.txt 2. Allocating 12GB Memory For VMware Player # ./imx-make.sh -j4 2>&1 | tee build-log.txt # ./imx-make.sh -j4 2>&1 | tee build-log.txt (Run it again) # ./imx-make.sh -j4 2>&1 | tee build-log.txt (Run it again)       So if we use 4 thread to compile BSP, command for compilation will have to be run for 3 times. NXP TIC Team Weidong Sun 2020/4/30

  Platform: i.MX8MP EVK , L6.1.22-2.0.0 LT9211 is a chip that can realize the conversion of MIPI DSI signals to LVDS signals. This patch is based on this mainline driver:https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/gpu/drm/bridge/lontium-lt9211.c Keypoint Move lt9211_host_attach function to lt9211_attach to skip bridge attach error.  

Useful information about push buttons.   Physical level.            When there is a change of voltage level on P0-P7 pins, PCA9555PW will generate interrupt on INT pin. The driver (running on SoC) can read the status of P0-P7 pins via I2C (SCL/SDA pins) and generate separate interrupts for each of P0-P7 pins. This is why this driver acts as interrupt controller. Consider next configuration:        One push button changes level on P4 pin, tempting PCA9555PW to generate interrupt. Interrupt from PCA9555PW is connected to GPIO5 IP-core (inside of SoC), and it uses line #9 of that GPIO5 module to notify CPU about interrupt. So we can say that PCA9555PW is cascaded to GPIO5 controller. GPIO5 also acts as interrupt controller, and it's cascaded to GIC interrupt controller.   Device tree properties.   The meaning of properties is as follows: interrupt-controller  property defines that device generates interrupts; it will be needed further to use this node as interrupt-parent in each push button node. #interrupt-cells defines format of interrupts property; in our case it's 2 : 1 cell for line number and 1 cell for interrupt type interrupt-parent and interrupts properties are describing interrupt line connection   Interrupt handling.   CPU now is in interrupt context in GIC interrupt handler. From gic_handle_irq() it calls handle_domain_irq() , which in turn calls generic_handle_irq() . See Documentation/gpio/driver.txt for details. Now we are in SoC's GPIO controller IRQ handler. SoC's GPIO driver also calls generic_handle_irq() to run handler, which is set for each particular pin. See for example how it's done in omap_gpio_irq_handler() . Now we are in PCA9555PW IRQ handler. PCA9555PW IRQ handler calls handle_nested_irq() . Finally, gpio_keys_gpio_isr() is called.      The following steps allow you to enable rgb led's and push buttons on 8MIC-RPI-MX8 board with i.MX 8M Mini Applications Processor Evaluation Kit (EVKB). You have to use a led driver and change the device tree. On the Host. Cloning the Linux kernel repository.   Clone the i.MX Linux Kernel repo to the home directory. cd ~ git clone https://source.codeaurora.org/external/imx/linux-imx This guide will use the following commit which corresponds to Kernel 5.10.35-2.0. cd linux-imx/ git checkout -b RGB ef3f2cfc6010 Patching the device tree.   Download the "0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch" file attached to this post and copy it into linux-imx directory, then apply the patch. cp 0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch ~/linux-imx/ cd ~/linux-imx/ patch < 0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch When prompted, select the file to patch: File to patch: arch/arm64/boot/dts/freescale/imx8mm-evk-8mic-revE.dts patching file arch/arm64/boot/dts/freescale/imx8mm-evk-8mic-revE.dts Then setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate config file. make imx_v8_defconfig Compile the device tree. make freescale/imx8mm-evk-8mic-revE.dtb Copy the .dtb file to the EVK, for example with scp: scp imx8mm-evk-8mic-revE.dtb root@<EVK_IP>:/home/root Alternatively, you may copy the .dtb file directly to the FAT32 partition where the Kernel and Device Tree files are located. Compiling the Led driver.   Obtain the leds-pca995x.h file in the next site: https://github.com/TechNexion/linux-tn-imx/blob/tn-imx_5.4.70_2.3.0-stable/include/linux/platform_data/leds-pca995x.h  Copy it into the next path: cp leds-pca995x.h ~/linux-imx/include/linux Create a new directory. mkdir ~/linux-imx/PCA9955 Create a makefile. cd ~/linux-imx/PCA9955 vim Makefile   KERNEL_ROOT?=~/linux-imx obj-m += leds-pca995x.o all: make -C $(KERNEL_ROOT) M=$(PWD) modules clean: make -C $(KERNEL_ROOT) M=$(PWD) clean   Press the key "Esc" and then: :wq Obtain the leds-pca995x.c file in the next site: https://github.com/TechNexion/linux-tn-imx/blob/tn-imx_5.4.70_2.3.0-stable/drivers/leds/leds-pca995x.c Copy it into the next path: cp leds-pca995x.c ~/linux-imx/PCA9955 Obtain 0001-PCA9955BTW.patch file and copy it into the next path: cp 0001-PCA9955BTW.patch ~/linux-imx/PCA9955 Apply the patch. patch < 0001-PCA9955BTW.patch Then setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate .ko file. cd ~/linux-imx/PCA9955 make all Copy the .ko file to the EVK, for example with scp: scp leds-pca995x.ko root@192.168.100.105:/home/root NOTE: The linux version of .ko file must be the same as EVK. On the EVK. Switching the device tree.   To copy the updated device tree to the corresponding partition, first create a directory. mkdir Partition_1 Mount the partition one. mount /dev/mmcblk1p1 Partition_1/ Copy or move the device tree into partition one. cp imx8mm-evk-8mic-revE.dtb Partition_1/ Reboot the board. reboot Stop on u-boot and modify the .dtb file to use the device tree for 8mic board. u-boot=> editenv fdtfile edit: imx8mm-evk-8mic-revE.dtb u-boot=> saveenv Saving Environment to MMC... Writing to MMC(1)... OK u-boot=> boot Installing a led driver.   Execute the following command to load the led driver into the kernel. insmod leds-pca995x.ko And you will see something like: [ 249.359103] leds_pca995x: loading out-of-tree module taints kernel. [ 249.366864] ALL [ 249.368740] ALL 0 [ 249.370667] ALL 1 [ 249.372609] ALL 2 [ 249.374536] ALL 2 [ 249.376475] ALL 2 [ 249.378401] ALL 2 [ 249.380338] ALL 2 [ 249.382264] ALL 2 [ 249.384202] ALL 2 [ 249.386127] ALL 2 [ 249.388063] ALL 2 [ 249.389989] ALL 2 [ 249.391913] ALL 2 [ 249.393847] ALL 2 [ 249.395774] ALL 2 [ 249.397709] ALL 2 [ 249.399635] ALL 2 [ 249.401568] ALL 2 [ 249.403496] ALL 3 Turning on a Led.   If you changed the device tree, you can turn on a led with the following command: echo 250 > /sys/class/leds/pca995x\:blue0/brightness To turn off a led: echo 0 > /sys/class/leds/pca995x\:blue0/brightness The red, blue and green leds can be turned on at different intensities provided. Testing the push buttons.   If you changed the device tree, you can test the push buttons with the following command: evtest Select the correct number: No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: 30370000.snvs:snvs-powerkey /dev/input/event1: sw_keys /dev/input/event2: gpio_ir_recv Select the device event number [0-2]: 1 And you will see: Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sw_keys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 67 (KEY_F9) Event code 113 (KEY_MUTE) Event code 114 (KEY_VOLUMEDOWN) Event code 115 (KEY_VOLUMEUP) Properties: Testing ... (interrupt to exit) Event: time 1642457988.1642457988, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1 Event: time 1642457988.1642457988, -------------- SYN_REPORT ------------ Event: time 1642457988.1642457988, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0 Event: time 1642457988.1642457988, -------------- SYN_REPORT ------------

For the board imx8M Quad EVK running the Linux 4.14.78-1.0.0_ga version BSP, the resolutions 3840x2160,1920x1080, 1280x720, 720x480 are support in our default BSP. For the other resolutions how to make it work? This patch used to do support for a non-default resolution on i.MX 8MQ EVK. Basically, the customer needs to change the clocks accordingly to the display requirements,  it to be used as a base to the display support.

   Some of Chinese customer couldn’t normally download android source code from google site, here give a way to download android source from Mirror site of Tsinghua University. Customers in other areas can refer to the configurations of ubuntu 18.04 in the document. Updating software packages for ubuntu18.04 LTS 1、Using software updater to update software packages Press Install Now button to update software. Restart ubuntu18.04 2、Installing necessary software packages #sudo apt-get install flex # sudo apt-get install bison # sudo apt-get install gperf # sudo apt-get install build-essential # sudo apt-get install zlib1g-dev # sudo apt-get install lib32ncurses5-dev # sudo apt-get install x11proto-core-dev # sudo apt-get install libx11-dev # sudo apt-get install lib32z1-dev # sudo apt-get install libgl1-mesa-dev # sudo apt-get install tofrodos # sudo apt-get install python-markdown # sudo apt-get install libxml2-utils # sudo apt-get install xsltproc # sudo apt-get install uuid-dev:i386 liblzo2-dev:i386 # sudo apt-get install gcc-multilib g++-multilib # sudo apt-get install subversion # sudo apt-get install openssh-server openssh-client # sudo apt-get install uuid uuid-dev # sudo apt-get install zlib1g-dev liblz-dev # sudo apt-get install liblzo2-2 liblzo2-dev # sudo apt-get install lzop # sudo apt-get install git-core curl # sudo apt-get install u-boot-tools # sudo apt-get install mtd-utils # sudo apt-get install android-tools-fsutils # sudo apt-get install openjdk-8-jdk # sudo apt-get install device-tree-compiler # sudo apt-get install aptitude # sudo aptitude install libcurl4-openssl-dev nss-updatedb 3、Downloading and unpacking Android release package https://www.nxp.com/products/processors-and-microcontrollers/applications-processors/i.mx-applications-processors/android-os-for-i.mx-applications-processors:IMXANDROID?tab=Design_Tools_Tab --O8.1.0_1.3.0_ANDROID_SOURCE_8MQ_GA File name is imx-o8.1.0_1.3.0_8m.tar.gz # cd ~ # tar xzvf imx-o8.1.0_1.3.0_8m.tar.gz Downloading android8.1.0-1.3.0 source code Getting repo # cd ~ # mkdir bin # cd bin # curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo # chmod a+x ~/bin/repo # export PATH=${PATH}:~/bin   Modifying repo File Open ~/bin/repo file with 'gedit' and Change google address From REPO_URL = 'https://gerrit.googlesource.com/git-repo' To REPO_URL = 'https://mirrors.tuna.tsinghua.edu.cn/git/git-repo/' 3、Setting email address # git config --global user.email "xxxx@nxp.com" # git config --global user.name "xxxx" [ Email & Name should be yours] 4、Modifying android setup script and Running it Open ~/ imx-o8.1.0_1.3.0_8m /imx_android_setup.sh and add a line like below: ...       if [ "$rc" != 0 ]; then          echo "---------------------------------------------------"          echo "-----Repo Init failure"          echo "---------------------------------------------------"          return 1       fi find -name 'aosp-O8.1.0-1.3.0.xml'| xargs perl -pi -e 's|https://android.googlesource.com/|https://aosp.tuna.tsinghua.edu.cn/|g' fi   # Don't Delete .repo directory and hidden files #rm -rf $android_builddir/.??* ... Then save it and exit. # cd ~/ # source ~/ imx-o8.1.0_1.3.0_8m/imx_android_setup.sh Then android_build directory is created at ~/ # export MY_ANDROID=~/android_build          48 hours later: Compiling android8.1.0-1.3.0 BSP # cd ~/android_build # gedit ./prebuilts/sdk/tools/jack-admin               And find “JACK_SERVER_COMMAND” ,change it to be: JACK_SERVER_COMMAND="java -XX:MaxJavaStackTraceDepth=-1 -Djava.io.tmpdir=$TMPDIR $JACK_SERVER_VM_ARGUMENTS -Xmx4096m -cp $LAUNCHER_JAR $LAUNCHER_NAME"          Save and exit. And run: # ./prebuilts/sdk/tools/jack-admin stop-server # ./prebuilts/sdk/tools/jack-admin start-server # export ARCH=arm64 # export CROSS_COMPILE=~/android_build/prebuilts/gcc/linux-x86/aarch64/aarch64-linuxandroid-4.9/bin/aarch64-linux-android- # export LC_ALL=C # source build/envsetup.sh # lunch evk_8mq-userdebug               Begin to build android BSP for i.MX8MQ # make –j4 NXP TIC weidong sun 2018-08-15

NOTE: Always de-power the target board and the aggregator when plugging or unplugging smart sensors from the aggregator. NOTE: See this link to instrument a board with a Smart Sensor. Overview The i.MX Power Profiler system consists of one to fourteen "smart" current sensors, an aggregator shield, and a Kinetis FRDM board (the FRDM-KL25 has been used in prototyping but the FRDM-K64F and FRDM-K66F should also be fully compatible). One of the biggest improvements of this system over its preceeding dual-range measurement system is that the microcontroller on each sensor board allows near-simultaneous measurement of all instrumented rails on a board. The dual range profiler has only a single MCU for all sensors, so only one measurement can be made at a time.  It is intended to be used to instrument one to fourteen rails of a target i.MX appliation board. Ideally, the target board will have been designed with a matching/mating power sense footprint for each rail to be measured.  Each smart sensor can sense current in three ranges with three current sense amplifiers. They are "smart" because each sensor board has a Kinetis KL05Z on it to control the switching FETs and to digitize the analog signals (the sense amplifier outputs and the target's power supply rail voltage). A 1% voltage regulator on each smart sensor provides a good voltage reference right next to the KL05Z to ensure better ADC accuracy. Each smart sensor board communicates via I2C. The aggregator shield has three I2C bus extenders (PCA9518) which essentially provide a dedicated I2C bus for each of the connected smart sensors. The FRDM board's I2C is also connected to one of the bus extenders ports. Individual GPIO lines are routed to each smart sensor's connected along with a ganged reset and trigger line for all of the connected smart sensors. A boost regulator generates almost 12V from the FRDM board's 5V supply, which is used for all the switching FETs on the smart sensor boards. The FRDM board's 5V rail is also routed to each smart sensor, which is regulated down to 3.3V locally on each connected smart sensor. Here is a photo of the very first prototypes after moving to 10-pin 0.05" spaced headers and ribbon cables instead of FFC: The smart sensor is intended to mate with through-hole current sense tap points on the target i.MX application board. Three holes spaced at 0.05" each. When not instrumented with sensor, a short needs to be placed across the outer two pins so that the board will function normally. The through hole connections provide physical protection to the target board, keeping traces from getting ripped off. The ground connection in the center provides a reference for meauring the rail voltage on the target board. A partial layout example of the implementation of the current sense footprint is below, where two 0805 shorting resistors in parallel are placed on each side of the holes. The top trace connects to the regulator output and the bottom to the load, usually an i.MX power supply rail. To include the current sense footprint into a board during the design phase, it should be configured as in the following partial schematic:  Every effort should be made to place the feedback on the i.MX side of the sense points so that the regulator compensates for the additional series resistance of the smart sensor, which effectively eliminates the additional series resistance the smart sensor adds. The Feedback should be before the smart sensor if the switching supply won't tolerate the additional series resistance (i.e., output becomes unstable).

Many customer set GPIO as input or output functions. While they are confused on how to set GPIO property. This article describe on GPIO property setting tips, especially that input and out property setting are different. 

The configuration of DDR is very important. NXP provides a tool for configuring DDR for users of i.MX series products. Here are the details steps for it. Hope can do help for someone. 1\ The DDR part startup and initialization sequence of MX8MM:   The MX 8M series DDR tools include： DDR Register Programming Aid --->Configurate custom DDR initialization MSCALE DDR Tool（DDR Stress Test Tool） --->Test DDR initialization And DDR interface ---> Generate custom DDR initialization code for the u-boot SPL DDR RPA（RPA） is an Excel spreadsheet tool used to develop DDR initialization for specific DDR configurations (DDR device type, density, etc.) of users. RPA generates DDR initialization (in a separate Excel worksheet tab). Detailed explanations and introductions will be provided here. DDR stress testing tool is a software tool based Windows that initializes PHY and generates DDRC configuration Uboot source code to verify whether DDR initialization can be used for u-boot and OS startup. DDR stress testing script, this format is specifically used for DDR stress detection. First, copy the content from this worksheet tab, and then paste it into a text file, naming the document with the ". ds" file extension. Select this file when performing DDR stress testing. 2\i.MX8M series DDR tool work flow           Above is the DDR Tool flow for the i.MX8MM: DDR RPA Tool: Configure DDR parameters to generate DDR Stress Test script ". ds". DDR Sress Test Tool: Test DDR initialization and DDR interface, generate DDR initialization code for the u-boot SPL DDR driver. For the newest DDR RPA version as below：   https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MMini-m845S-DDR-Register-Programming-Aid-RPA/ta-p/1172443 In the above link, you can download the corresponding DDR configuration tools for i.MX8MM using different DDRs.   3\How to use this script to configure DDR parameters (1)Obtain the required DRAM data sheet from the DRAM supplier firstly. The DDR parameter configuration content will be completed in the "Register Configuration" worksheet tab.   (2)"Register Configuration"，Update the device information table to include DRAM information and system usage. DDR RPA tool:  Register Configuration---->Device Information table   It should be filled out based on the datasheet and relevant hardware circuit design of the selected DDR chip. Specific users can refer to the manual for selecting DDR chips and their own hardware design. Take the i.MX 8M Mini LPDDR4 EVK board as example, it selects the Micron MT53D512M32D2DS-053 WT:D, we can go the Micron website to download the DDR’s datasheet and we can see bellow:   Density per channel (Gb)= Device density (Per Channel Per CS)=8Gb Number of ROW Addresses=R[15:0]=16 Number of Channels=2 (2 Channels i.MX8MM DDR is 32bit) Number of COLUMN Addresses=C[9:0]=10 Total DRAM density(Gb) Automatic calculation：Density per channel (Gb) * Number of Channels * Number of Chip Selects used  =8Gb * 2 * 1=16Gb=2GB Bus Width=M32=32bit: i.MX8MM DDR support 32bit Cycle Freq (MHz)=1500MHZ: The DDR controller clock of the i.MX8MM is set to 1500MHZ. The information filled in is shown in the table below:   (3)Browse through various shaded cells in the spreadsheet to update using data from the DRAM table (pay special attention to the "Legend" table to determine the meaning of different shaded cells; in many cases, these cells may not need to be updated). On the parameter filling page, we can also see the following table, with different colors indicating the need to modify and maintain the original parameters and the affected parameter information. On the register configuration tab, basically only the orange part of the color represents the bit segments that usually need to be updated, and the rest do not need to be modified or configured.   (4)Go to the BoardDataBusConfig tab, fill in the i.MX8MM data bus mapping to the memory device correctly. DDR RPA tool: BoardDataBusConfig ---->Configurate data bus bit   Users should pay special attention to ensuring that this worksheet is configured correctly, otherwise the LPDDR4 system may not function properly. The memory controller of i.MX8MM allows for BYTE internal swapping. For layout convenience, BYTE internal swapping is usually performed, so the BoardDataBusConfig column needs to be configured according to the actual schematic design. We can see the tab in the BoardDataBusConfig, user fill the i.MX8MM data bit connection to associated LPDDR4, the filling in of data bits here should be consistent with the order of our hardware design wiring, which means that if there are swapped data bits, the corresponding relationship must be filled in. Take the LPDDR4 connection to the i.MX8MM as example, the highest 8 bits on the channel B of the LPDDR4   connect to the side of DRAM_DQ00~DRAM_DQ07 of CPU, and the lowest 8 bits on the channel B of the LPDDR4 DRAM_DQ08~DRAM_DQ15 of CPU side，the lowest 8 bits on the channel A of the LPDDR4 connect to the DRAM_DQ16~DRAM_DQ23 of CPU side，the highest 8 bits on the channel A of the LPDDR4 connect to the DRAM_DQ24~DRAM_DQ31 of the CPU side. The i.MX8MM memory controller allows for BYTE internal swapping. For layout convenience, BYTE internal swapping is usually performed, and this needs to be filled in according to the actual wiring in the data bus.       (5)Generate the “.ds” file DDR RPA tool: DDR stress test file ----> “.ds”   Copy the content of the DDR stress test file into a text file and name it a. ds file. For subsequent DDR stress testing purposes.   4\Do the DDR Stress test and Generate the DDR Code The following is the workflow of the DDR tool for the MX8MM series:   Preparation Board: i.MX 8M Mini LPDDR4 EVK Software download: mscale_ddr_tool_v3.31_setup.exe(Install it) PC:Window10 PC file .ds file Hardware requirements for the board: (Please note that these interfaces are necessary when using our stress testing tools) Serial download mode USB OTG port Debug UART port 4.1 Hardware connection   SW1101set 1010xxxxxx go to Serial Download mode, connect the USB-OTG and UART to PC, USB OTG is used for serial download of binary files: UART is used to communicate with users. Note: It is recommended to connect the USB OTG directly to the host PC, rather than through the USB Hub. When power on the board，we can see HID-compliant vendor-defined device and USB Input Device:   UART port are COM3 and COM4:   4.2 Open MSCALEDDR_Tool. exe in administrator mode for DDR parameter calibration and pressure testing：   Select serial port Select Search in Debug UART and you can read that the other two serial ports COM3 and COM4 have been tried. Click on the Connect button. It should be noted that we have two serial ports, one for the A core and the other for the M core. Here, COM4 must be selected to load the script normally. COM4 is used for the A core. Select Target Select the MX8M-mini，speed of CPU chosse1200MHZ, DDR LPDDR4 size 2GB. Select .ds file, Load DDR Script: Copy the generate mx8mm_micron_lpddr4_2gb_2d_1500m_200m_50m_32bit_1cs_RPAv22.ds to the path of the DDR TOOL, then press the Download button. After the download is successful, there will be a print message indicating the successful download and the startup information of the board. We can see the CPU parameters and DDR configuration.   Pres Calibration: This step mainly involves executing the DDR initialization and calibration process. If there is a failure, it is necessary to analyze the DDR problem based on the printed information. If there is no problem, the following interface will appear.   (5) If there are no problems after calibration, perform a pressure test. Only perform this operation when the calibration is passed. Run the test on all frequency set points. If the DDR pressure test passes, you can see that the test has passed successfully. If there is an error, you should search for the problem with the DDR based on the error message.   (6) Generate u-boot timing After the stress test is successfully completed, clicking the Gen Code button will generate a file lpddr4_timing. c, and then the lpddr4_timing. C file can be copied to the u boot directory.     5\ Modifying and configuring DDR frequencies that are not supported by default         The above test is for the frequency point 1500MHZ that is supported by default in our tool. RPA provides default DRAM PLL settings (DRAM frequency) based on the default settings supported in u-boot. If the customer is not using the default supported frequency, in addition to updating the new frequency in RPA, the new DRAM PLL settings should also be manually updated in the u boot SPL. (1) Firstly, in the RPA script, "Clock Cycle Freq (MHz)" is set to the frequency we need (2) Then search for 'memory set 0x30360054' in the RPA DDR stress test file worksheet tab, with a default setting of 1500MHZ.   We can see the DRAM PLL register and bit settings：   For special frequencies, we have a calculation formula here: DDR_freq = [(24MHz x pll_main_div)/(pll_pre_div x 2^pll_post_div)] x 2 1500 = [(24 x 250) / (8 x 2^1)] x 2 Bellow are some special examples of the required configurations for various frequencies:     Finishing configuration, create a. ds test DDR script in the RPA script to specify the frequency of this configuration. （3）After creating a DDR script for the DDR stress testing tool, run the calibration and perform the DDR pressure test. Generating the lpddr4_timing.c, modify the required DDR rate parameters Manually. （4）Modify the DRAM PLL，DRAM_freq = DRAM_PLL x 2 in SPL，u-boot SPL DDR driver can will not automatically change DRAM PLL based on generated code. Therefore, users will need to manually modify the dram_pll_init  for the required DDR PLL parameter.

  It is a Matter Demo setup guide to set up Matter OTBR on i.MX MPU Platfrom. i.MX 2023Q2 release is based on Matter v1.1  Current test solutions. i.MX6ULL + 88W8987(WiFi-BT combo Module) + K32W(OpenThread RCP module) i.MX8MM + 88W8987(WiFi-BT combo Module) + K32W(OpenThread RCP module) i.MX8MM + IW612-RD-EVK (WiFi-BT-Thread tri-radio single-chip module) i.MX93 + IW612 (WiFi-BT-Thread tri-radio single-chip module) Matter Zigbee Bridge  https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Matter-Zigbee-Bridge-base-on-i-MX-MPU-and-K32W/ta-p/1675962   if use imx8mm_k32w_matter.sh or imx93_matter.sh to setup OTBR, you need modify "SSID" and " WIFI_PWD" in the script.    

Before I have presentation named “i.MX6 SDCARD Secondary Boot Demo”  in following link. i.MX Development Miscellanea(i.MX 开发杂记) - NXP Community   Now I have the “i.MX8MM SDCARD Secondary Boot Demo”.   The big difference is i.MX8MM using spl. And in the “i.MX6 SDCARD Secondary Boot Demo” I manually edit the secondary image table and manually combine the images. Now, I have written done a script “imx_sd_secondary_boot_creator.sh” to do above.

Background Some customers connect their imx running Android to the cloud, so reboot-bootloader and the use of fastboot oem unlock is not acceptable. This way the system is disconnected and cannot be operated remotely using adb. This article therefore proposes to execute oem unlock before the bootloader is started when the system is first run, which can be unlocked directly.   Patch diff --git a/drivers/fastboot/fb_fsl/fb_fsl_boot.c b/drivers/fastboot/fb_fsl/fb_fsl_boot.c index 86b919775a..d60cd248ee 100644 --- a/drivers/fastboot/fb_fsl/fb_fsl_boot.c +++ b/drivers/fastboot/fb_fsl/fb_fsl_boot.c @@ -529,6 +529,42 @@ bool __weak is_power_key_pressed(void) { return false; } +static void wipe_all_userdata(void) +{ + char response[FASTBOOT_RESPONSE_LEN]; + + /* Erase all user data */ + printf("Start userdata wipe process....\n"); + /* Erase /data partition */ + fastboot_wipe_data_partition(); + +#if defined (CONFIG_ANDROID_SUPPORT) || defined (CONFIG_ANDROID_AUTO_SUPPORT) + /* Erase the misc partition. */ + process_erase_mmc(FASTBOOT_PARTITION_MISC, response); +#endif + +#ifndef CONFIG_ANDROID_AB_SUPPORT + /* Erase the cache partition for legacy imx6/7 */ + process_erase_mmc(FASTBOOT_PARTITION_CACHE, response); +#endif + +#if defined(AVB_RPMB) && !defined(CONFIG_IMX_TRUSTY_OS) + printf("Start stored_rollback_index wipe process....\n"); + rbkidx_erase(); + printf("Wipe stored_rollback_index completed.\n"); +#endif + process_erase_mmc(FASTBOOT_PARTITION_METADATA, response); + printf("Wipe userdata completed.\n"); +} +void do_unlock(void) +{ + int status; + wipe_all_userdata(); + status = fastboot_set_lock_stat(FASTBOOT_UNLOCK); + if (status < 0) + return FASTBOOT_LOCK_ERROR; + printf("Unlock device\n"); +} int do_boota(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]) { ulong addr = 0; @@ -563,6 +599,9 @@ int do_boota(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]) { fastboot_set_lock_stat(FASTBOOT_LOCK); lock_status = FASTBOOT_LOCK; } + if (lock_status == FASTBOOT_LOCK){ + do_unlock(); + } bool allow_fail = (lock_status == FASTBOOT_UNLOCK ? true : false); avb_metric = get_timer(0);      

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

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

1.Compile full aosp or only kernel Build full aosp: source build/envsetup.sh lunch evk_8mm-userdebug ./imx-make.sh -j8  Only build kernel: ./imx-make.sh kernel -j8 2.Build GKI locally Download GKI outside of android_build. mkdir gki && cd gki (Make sure folder gki is not inside of ${MY_ANDROID}) repo init -u https://android.googlesource.com/kernel/manifest -b commonandroid13-5.15 repo sync Build GKI locally. BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh 3. Export symbols After building GKI locally, you can copy linux-imx from /vendor/nxp-opensource/kernel_imx into common. cd common rm -r ./* cp ${MY_ANDROID}/vendor/nxp-opensource/kernel_imx/* ./ 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 GKI about i.MX: 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" build/build_abi.sh --update-symbol-list -j8 Then the  common/android/abi_gki_aarch64_imx will be generated. cd gki cp common/android/abi_gki_aarch64_imx /tmp/abi_gki_aarch64_imx   Update GKI kernel rm -r common/* # delete imx kernel repo sync # recover aosp kernel cp /tmp/abi_gki_aarch64_imx android/abi_gki_aarch64_imx cd .. BUILD_CONFIG=common/build.config.gki.aarch64 build/build_abi.sh LTO=thin --update -j8  Then, common/android/abi_gki_aarch64.xml is updated.