Host TFTP and NFS Configuration Now configure the Trivial File Transfer Protocol (TFTP) server and Networked File System (NFS) server. U-Boot will download the Linux kernel and dtb file using tftp and then the kernel will mount (via NFS) its root file system on the computer hard drive. 1. TFTP Setup   1.1.1 Prepare the TFTP Service   Get the required software if not already set up. On host for TFTP: Install TFTP on Host $ sudo apt-get install tftpd-hpa   (Note: There are a number of examples in various forums, etc, of how to automatically start the TFTP service - but not all are successful on all Linux distro's it seems! The following may work for you.)   Start the tftpd-hpa service automatically by adding a command to /etc/rc.local. $ vi /etc/rc.local   Now, just before the exit 0 line edit below command then Save and Exit. $ service tftpd-hpa start  Now, To control the TFTP service from the command line use: $ service tftpd-hpa restart    To check the status of the TFTP service from the command line use: $ service tftpd-hpa status   1.1.1 Setup the TFTP Directories Now, we have to create the directory which will contain the kernel image and the device tree blob file. $ mkdir -p /imx-boot/imx6q-sabre/tftp Then, copy the kernel image and the device tree blob file in this directory. $ cp {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/zImage /imx-boot/imx6q-sabre/tftp $ cp {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/<dtb file> /imx-boot/imx6q-sabre/tftp   OR we can use the default directory created by yocto {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/ The tftpd-hpa service looks for requested files under /imx-boot/imx6q-sabre/tftp The default tftpd-hpa directory may vary with distribution/release, but it is specified in the configuration file: /etc/default/tfptd-hpa. We have to change this default directory with our directory   Edit default tftp directory $ vi /etc/default/tftpd-hpa   Now, change the directory defined as TFTP_DIRECTORY with your host system directory which contains kernel and device tree blob file. Using created directory TFTP_DIRECTORY=”/imx-boot/imx6q-sabre/tftp” OR Using Yocto directory path TFTP_DIRECTORY=”{YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}” Restart the TFTP service if required $ service tftpd-hpa restart   1.2 NFS Setup 1.2.1 Prepare the NFS Service Get the required software if not already set up. On host for NFS: Install NFS on Host $ sudo apt-get install nfs-kernel-server The NFS service starts automatically. To control NFS services : $ service nfs-kernel-server restart To check the status of the NFS service from the command line : $ service nfs-kernel-server status 1.2.2 Setup the NFS Directories Now, we have to create the directory which will contain the root file system. $ mkdir -p /imx-boot/imx6q-sabre/nfs   Then, copy the rootfs in this directory. $ cp -R {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs/* /imx-boot/imx6q-sabre/nfs   OR we can use the default directory created by yocto. $ {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs 1.2.3 Update NFS Export File The NFS server requires /etc/exports to be configured correctly to access NFS filesystem directory to specific hosts. $ vi /etc/exports Then, edit below line into the opened file. <”YOUR NFS DIRECTORY”> <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Ex. If you created custom directory for NFS then, /imx-boot/imx6q-sabre/nfs <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Ex: /imx-boot/imx6q-sabre/nfs 192.168.*.*(rw,sync,no_root_squash,no_subtree_check) OR /{YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check)   Now, we need to restart the NFS service. $ service nfs-kernel-server restart   2 Target Setup   We need to set up the network IP address of our target. Power On the board and hit a key to stop the U-Boot from continuing. Set the below parameters, setenv serverip 192.168.0.206       //This must be your Host IP address The path where the rootfs is placed in our host has to be indicated in the U-Boot, Ex. // if you choose default folder created by YOCTO setenv nfsroot /{YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs   OR // if you create custom directory for NFS setenv nfsroot /imx-boot/imx6q-sabre/nfs Now, we have to set kernel image name and device tree blob file name in the u-boot, setenv image < zImage name > setenv fdt_file <dtb file name on host> Now, set the bootargs for the kernel boot, setenv netargs 'setenv bootargs console=${console},${baudrate} ${smp} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp' Use printenv command and check loadaddr and fdt_addr environment variables variables for I.MX6Q SABRE, loadaddr=0x12000000 fdt_addr=0x18000000   Also, check netboot environment variable. It should be like below, netboot=echo Booting from net ...; run netargs; if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; ${get_cmd} ${image}; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if ${get_cmd} ${fdt_addr} ${fdt_file}; then bootz ${loadaddr} - ${fdt_addr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi; Now, set environment variable bootcmd to boot every time from the network, setenv bootcmd run netboot Now finally save those variable in u-boot: saveenv Reset your board; it should now boot from the network: U-Boot 2016.03-imx_v2016.03_4.1.15_2.0.0_ga+ga57b13b (Apr 17 2018 - 17:13:43 +0530)  (..) Net:   FEC [PRIME] Normal Boot Hit any key to stop autoboot:  0   Booting from net ... Using FEC device TFTP from server 192.168.0.206; our IP address is 192.168.3.101 Filename 'zImage'. Load address: 0x12000000 Loading: #################################################################         #################################################################         #################################################################         #################################################################         #################################################################         #################################################################         ###########################################################         2.1 MiB/s done Bytes transferred = 6578216 (646028 hex) Using FEC device TFTP from server 192.168.0.206; our IP address is 192.168.3.101 Filename 'imx6q-sabresd.dtb'. Load address: 0x18000000 Loading: ####         1.8 MiB/s done Bytes transferred = 45893 (b345 hex) Kernel image @ 0x12000000 [ 0x000000 - 0x646028 ] ## Flattened Device Tree blob at 18000000   Booting using the fdt blob at 0x18000000   Using Device Tree in place at 18000000, end 1800e344 switch to ldo_bypass mode!   Starting kernel ...

Note: This guide is specifically for use with Segger software. For steps to use with the MCUXpresso extension for VSCode please refer to How to Use Segger J-Link Plus with i.MX 8M Process... - NXP Community This guide aims to be a technical reference to start using the SEGGER J-Link Plus debug probe on the i.MX 8M Family processors. The board used for this guide specifically is the i.MX 8M Nano EVK, but it also applies to all processors of the i.MX 8M Family. Here we will describe the process using the following structure: Hardware requirements Software requirements How to find, build, and download the i.MX SDK Host setup Build an example application Target setup Run an example application Hardware requirements Evaluation Kit for the i.MX8M Nano Applications Processor (i.MX 8M Nano Evaluation Kit | NXP Semiconductors) Quick Start Guide for i.MX8M Nano (I.MX 8M Nano EVK Quick Start Guide (nxp.com)) J-Link Plus JTAG/SWD debug probe with USB interface (SEGGER J-Link PLUS) Features Download speed up to 1MB/s Unlimited breakpoints in flash memory Supports direct download into RAM and flash memory Supported NXP Devices Supported Devices - Search results "nxp" (segger.com) 9 Pin Cortex-M Adapter (9-Pin Cortex-M Adapter (segger.com)) Description Adapts from the 20-pin 0.1'' JTAG connector to a 9-pin 0.05'' Samtec FTSH connector as defined by Arm. Software requirements Windows 10 OS (host) J-Link Software and Documentation Pack for Windows (https://www.segger.com/products/debug-probes/j-link/models/j-link-plus/) i.MX 8M Nano SDK (Welcome | MCUXpresso SDK Builder (nxp.com)) MinGW CMake GNU ARM Embedded Toolchain Terminal Emulator for serial port connection (Tera Term, PuTTY, etc.)   How to find, build, and download the i.MX 8M Nano SDK Enter Welcome | MCUXpresso SDK Builder (nxp.com) Click on "Select Development Board"  Select EVK-MIMX8MN (MIMX8MN6xxxJZ) from Boards -> i.MX -> EVK-MIMX8MN Click on the Build MCUXpresso SDK button Click on Download SDK, you'll be redirected to the MCUXpresso SDK Dashboard Look for the i.MX 8M Nano SDK and click on Download SDK Click on Download SDK archive and documentation, accept the Software Terms and Conditions and the .zip file for the SDK will be downloaded.   Host Setup J-Link Software and Documentation Pack for Windows Download J-Link Software and Documentation Pack for Windows (https://www.segger.com/products/debug-probes/j-link/models/j-link-plus/) Execute .exe file downloaded and then click on "Next" Follow the installation wizard with default parameters and click on "Finish".   MinGW Download the MinGW installer from MinGW - Minimalist GNU for Windows - Browse /Installer at SourceForge.net. Follow the installer instructions leaving all options in their default values. Click on Continue when the installer finishes. A MinGW Installation Manager window will pop up, select mingw32-base and msys-base from basic setup. Click on the Installation menu and select Apply Changes. On the next window, click on Apply and wait for the package to finish downloading. Add the appropriate item to the Windows operating system path environment variable. It can be found under Control Panel->System and Security->System->Advanced System Settings in the Environment Variables... section. The path is: \bin. Assuming the default installation path, "C:\MinGW". If the path is not set correctly, the toolchain does not work. Note: If you have C:\MinGW\msys\x.x\bin in your PATH variable (as required by KSDK 1.0.0), remove it to ensure that the new GCC build system works correctly.   CMake Download CMake Windows x64 Installer from  Download CMake. Scroll down to find the latest release for the installer: Run the installer and follow the instructions. Make sure to check the Add CMake to system PATH for all users option during the installation process. Restart your PC to apply changes. GNU ARM Embedded Toolchain Download the GNU ARM Embedded Toolchain installer from Downloads | GNU Arm Embedded Toolchain Downloads – Arm Developer, scroll down to find the latest release for the installer: Follow the installer instructions and check the Add to PATH option at the end of the process. Add a new system environment variable named ARMGCC_DIR with the GNU ARM embedded Toolchain installation path as its value ARMGCC_DIR=ARMGCC_DIR=C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10​   Build and example application Press the Windows Key and search for GCC Command Prompt and run it. Change the directory to the example application project directory (inside the armgcc folder), for example: C:\Users/<user>\Documents\8MNANO\boards\evkmimx8mn\demo_apps\hello_world\armgcc Type build_debug.bat on the command line or double click the build_debug.bat file (inside the armgcc folder of the application project) through Windows Explorer Wait for the building process to end and make sure no error messages are shown. Target Setup Connect the debug cable (USB-UART) to the board and the other end to your PC. Connect the power cable to the second USB-C port and to a wall socket. Don't turn on the board yet. Connect the JLink Plus to your PC with the USB cable. Connect the JLink Plus to the JTAG of the i.MX 8M Nano EVK board In this part we will need to identify pin number 1 from the 9 Pin Cortex-M adapter and from the i.MX 8M Nano EVK board. For the first one identify pin 7 identifiable by a "Non-connect pin". For the i.MX 8M Nano, you can identify easily with a number 1 in one corner of the connectors.    The whole setup should look similar to this: Run an example application Open a terminal application (TeraTerm, PuTTY, etc.) on your host PC and set it to the serial debug port with the lowest numbered port with the following settings: Speed: 115200 Data: 8-bit Parity: none Stop bits: 1 bit Flow Control: none Start SEGGER J-Link GDB Server. On section “Target Device” select MIMX8MN6_M7 and click “OK”. You will see the following window. Open a new instance of GCC Command Prompt. Change to the directory with the example previously compiled. Here is the path to folder that contains the files: <install_dir>/boards/<boad_name>/<example_type>/<application_name>/armgcc/debug​ Run the command: arm-none-eabi-gdb.exe <application_name>.elf.​ Example: At this point you are in the GDB Command Prompt, run the following commands: target remote localhost:2331 monitor reset monitor halt load monitor go The application will be now running and you can see the “hello world” on your terminal (PuTTY,Tera Term, etc.).  

Recently I published this i.MX Dev Blog post about the Gateworks plugin gst-variable-rtsp-server support for i.MX 6. Now, you can check how to use it on i.MX 8 SoCs as well. 1. Preparing the image In order to use gst-variable-rtsp-server plugin, prepare your machine and distro: Add the following line to conf/local.conf: IMAGE_INSTALL_append += "gstreamer1.0-rtsp-server gst-variable-rtsp-server" Download the attached patch and apply it by doing: $ cd <yocto_path>/sources/meta-fsl-bsp-release/ $ git am ~/Download/0001-Add-RTSP-support-for-i.MX-8-L4.14.78_ga1.0.0-or-olde.patch Note: This patch is not necessary for L4.14.98_ga2.0.0 BSP! Then, build the image with bitbake and deploy it to the SD card. 2. Video Test Source Example Server $ gst-variable-rtsp-server -p 9001 -u "videotestsrc ! v4l2h264enc ! rtph264pay name=pay0 pt=96" Client 2. Camera Example Server $ gst-variable-rtsp-server -p 9001 -u "v4l2src device=/dev/video0 ! video/x-raw,width=640,height=480 ! v4l2h264enc ! rtph264pay name=pay0 pt=96" Client In order to use VLC or other application as the client, just enter the URL as shown in the image below:

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.  

Hi all, I shared my test results and solutions in attachments. Best regards, Carl

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

     The following steps allow you to build a bootable image in two different ways and also how to enable and use SCFW debug monitor. There are four files needed to generate a bootable image: ├── bl31.bin ├── u-boot.bin   ├── mx8qm-ahab-container.img     └── scfw_tcm.bin There are some ways to get the four files, one way is with Yocto and other way is with stand alone build. Get the four files needed to generate a bootable image with Yocto.   To get the four files needed with Yocto, you have to build an i.MX 8QuadMax image, maybe some steps are not necessary. 1.-Host packages. sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \ build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \ xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa \ libsdl1.2-dev pylint3 xterm rsync curl 2.-Setting up the 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 3.-Yocto Project Setup. git config --global user.name "Your Name" git config --global user.email "Your Email" git config --list mkdir imx-yocto-bsp cd imx-yocto-bsp repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-hardknott -m imx-5.10.72-2.2.0.xml repo sync 4.-Build configurations. DISTRO=fsl-imx-xwayland MACHINE=imx8qmmek source imx-setup-release.sh -b imx8qmmek 5.-Building an image. bitbake imx-image-full The four files needed to generate a bootable image are in: ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools Note: With Yocto you can not enable the SCFW debug monitor. For more information see the i.MX Yocto Project User's Guide. Get the four files needed to generate a bootable image with stand alone build.   To build all required binaries from source you can use standard aarch64 Linux toolchain, on Ubuntu 20.04 LTS: sudo apt-get install gcc-aarch64-linux-gnu Get the bl31.bin file - Arm Trust Firmware.   Download source from: git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/imx-atf Build: cd imx-atf make clean PLAT=imx8qm CROSS_COMPILE=aarch64-linux-gnu- make PLAT=imx8qm CROSS_COMPILE=aarch64-linux-gnu- bl31 The compiled bl31.bin location: build/imx8qm/release/bl31.bin Get the u-boot.bin file - u-boot.   Download source from: git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/uboot-imx Build: cd uboot-imx make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- imx8qm_mek_defconfig make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- The compiled u-boot.bin location: ./u-boot.bin Get the mx8qmb0-ahab-container.img file - iMX Seco. wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-seco-3.7.4.bin chmod +x imx-seco-3.7.4.bin ./imx-seco-3.7.4.bin --auto-accept The mx8qmb0-ahab-container.img file location: imx-seco-3.7.4/firmware/seco/mx8qmb0-ahab-container.img Get the scfw_tcm.bin file - SCFW.   Download and Install a GNU Toolchain.   Look at the packages/imx-scfw-porting-kit-1.7.4/doc/pdf/ , chapter Porting Guide, sub-chapter Tool Chain to check which GNU Toolchain version corresponds to the SCFW you are building. The imx-scfw-porting-kit-1.7.4 version uses the GNU Toolchain version gcc-arm-none-eabi-8-2018-q4-major . It is recommended to install toolchain in “opt” folder: cd /opt sudo wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 sudo tar xjf gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 Download and Install a Arm GCC toolchain. It is recommended to install toolchain in “opt” folder: sudo wget https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/aarch64-linux-gnu/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz sudo tar -Jxvf gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz After installing the toolchain, set up the environment variable relevant for building. export ARCH=arm CROSS_COMPILE=/opt/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- export TOOLS=/opt Build the scfw_tcm.bin file. cd ~ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx-scfw-porting-kit-1.7.4.bin chmod +x imx-scfw-porting-kit-1.7.4.bin ./imx-scfw-porting-kit-1.7.4.bin --auto-accept cd imx-scfw-porting-kit-1.7.4/src Extract the desired scfw porting kit: tar -xvf scfw_export_mx8qm_b0.tar.gz cd scfw_export_mx8qm_b0/ Build without debug monitor: make clean make qm B=mek R=B0 Build with debug monitor: make clean make qm B=mek D=1 M=1 R=B0 DDR_CON=imx8qm_dcd_1.6GHz The scfw_tcm.bin file location: build_mx8qm_b0/scfw_tcm.bin   Generate the bootable image.   Once you have the four files needed to generate a bootable image, use imx-mkimage tool. Download source from: git clone -b lf-5.10.72-2.2.0 https://source.codeaurora.org/external/imx/imx-mkimage Copy the four binaries to iMX8QM folder. You have to rename some files. If you got the four binaries with Yocto. cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/bl31-imx8qm.bin ~/imx-mkimage/iMX8QM/bl31.bin cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/u-boot-imx8qmmek.bin-sd ~/imx-mkimage/iMX8QM/u-boot.bin cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/mx8qmb0-ahab-container.img ~/imx-mkimage/iMX8QM cp ~/imx-yocto-bsp/imx8qmmek/tmp/deploy/images/imx8qmmek/imx-boot-tools/mx8qm-mek-scfw-tcm.bin ~/imx-mkimage/iMX8QM/scfw_tcm.bin If you got the four binaries with stand alone build. cp ~/imx-atf/build/imx8qm/release/bl31.bin ~/imx-mkimage/iMX8QM cp ~/uboot-imx/u-boot.bin ~/imx-mkimage/iMX8QM cp ~/imx-seco-3.7.4/firmware/seco/mx8qmb0-ahab-container.img ~/imx-mkimage/iMX8QM cp ~/imx-scfw-porting-kit-1.7.4/src/scfw_export_mx8qm_b0/build_mx8qm_b0/scfw_tcm.bin ~/imx-mkimage/iMX8QM Build the bootable image. cd ~/imx-mkimage make SOC=iMX8QM flash The compiled file is flash.bin and its location is: iMX8QM/flash.bin   Flash the bootable image.   To flash the bootable image follow the next steps: -Copy the flash.bin and uuu.exe in a folder. -Change SW2 on the base board to 000100 (from MSB to LSB, 1-ON and 0-OFF) to boot from the Serial Downloader. -Run the following command in Command Prompt: uuu.exe -b sd flash.bin -Power on the MEK CPU board.   SCFW debug monitor.        If the SCFW is compiled using the M=1 option (default is M=0) then it will include a debug monitor. This can be used to R/W memory or registers, R/W power state, and dump some resource manager state. Production SCFW should never have the monitor enabled (M=0, the default)!      The debug monitor allows command-line interaction via the SCU UART. Inclusion of the debug monitor affects SCFW timing and therefore should never be deployed in a product! Note the terminal needs to be in a mode that sends CR or LF for a new line (not CR+LF). The following commands are supported: Command                                   Description exit                                              exit the debug monitor quit                                              exit the debug monitor reset [mode]                                request reset with mode (default = board) reboot partition [type]                  request partition reboot with type (default = cold) md.b address [count]                  display count bytes at address md.w address [count]                 display count words at address md[.l] address [count]                 display count long-words at address mm.b address value                   modify byte at address mm.w address value                  modify word at address mm[.l] address value                  modify long-word at address ai.r ss sel addr                            read analog interface (AI) register ai.w ss sel addr data                  write analog interface (AI) register fuse.r word                                 read OTP fuse word fuse.w word value                      write value to OTP fuse word dump rm                                    dump all the resource manager (RM) info dump rm part [part]                    dump all partition info for part (default = all) dump rm rsrc [part]                    dump all resource info for part (default = all) dump rm mem [part]                  dump all memory info for part (default = all) dump rm pad [part]                    dump all pad info for part (default = all) power.r [resource]                     read/get power mode of resource (default = all) power.w resource mode            write/set power mode of resource to mode (off, stby, lp, on) info                                             display SCFW/SoC info like unique ID, etc. seco lifecycle change                send SECO lifecycle update command (change) to SECO seco info                                    display SECO info like Lifecycle, SNVS state, etc. seco debug                                dump SECO debug log seco events                               dump SECO event log seco commit                              commit SRK and/or SECO FW version update pmic.r id reg                               read pmic register pmic.w id reg val                        write pmic register pmic.l id                                      list pmic info (rail voltages, etc) Resource and subsystem (ss) arguments are specified by name. All numeric arguments are decimal unless prefixed with 0x (for hex) or 0 (for octal). Testing SCFW debug monitor to display count long-words at address on Linux side and on SCU side. -Change SW2 on the base board to 001100 (from MSB to LSB, 1-ON and 0-OFF) to boot from the SD card. -Power on the MEK CPU board. -Open Tera Term and you will see: Hello from SCU (Build 5263, Commit 9b3d006e, Aug 20 2021 12:20:10) ​ DDR frequency = 1596000000  ROM boot time = 262368 usec      Boot time = 24583 usec         Banner = 10 usec           Init = 9038 usec         Config = 3232 usec            DDR = 2677 usec        SConfig = 444 usec           Prep = 5039 usec ​ *** Debug Monitor *** ​ >$ -Run the following commands: power.r power.w db on power.w dblogic on power.w mu_1a on -Example reading on Linux side: md.l 0x5d1c0000 10 -You will see: >$ md.l 0x5d1c0000 10 5d1c0000: 00000000 00000000 00000000 00000000 5d1c0010: 00010201 23c34600 d63fdb21 00000000 5d1c0020: 00f00200 18000000 -Example reading on SCU side: md.l 0x41cac080 10 -You will see: >$ md.l 0x41cac080 10 41cac080: 00000000 00000000 00000000 00000000 41cac090: 0d070201 ff0001f1 ffff8000 ffff00fb 41cac0a0: 00f00000 18000000 For more information see the System Controller Firmware Porting Guide.

This document explains the pad implementation and its relationship with the System Controller Firmware pad configuration service. There are two components to pad configuration in the SCFW, there are the modules that generate the signals that will ultimately appear on the physical pad, let's say GPIO/Ethernet/I2C/UART etc... and then there is the part that configures the muxing of the pad (what signal is going to be outputted through the specific pad), the drive strength of the pad, pull selection, etc, this is the part that the SCFW pad service configures. Introduction‌ The i.MX8 has three types of I/Os: 1.8V only I/Os 3.3V only I/Os 1.8V / 3.3V I/Os Dual Voltage I/Os Note: USB High Speed Inter-Chip (HSIC) and Ethernet interfaces have specific integration schemes with dedicated features. They are a modified versions of the above I/O types. HSIC are a special kind of I/O modified to sustain 480Mbps data rates ENET I/Os are modified versions of Dual Voltage I/Os to support 2.5V operations All of these I/Os have "common features" and "technology specific features" which depend on the type of I/O and the chip manufacturing process (FDSOI in the i.MX8QM case) I/O common features Muxing capability of up to 4 signals Each Pad can have up to 4 signals, only one signal can be present in the pad. To select the signal that will output on the pad simply look at the Pinmux spreadsheet and use the desired alternative, for instance in the following image SCU_GPIO0_00 has 3 options, SCU_GPIO (ALT0 - GPIO controlled directly by the SCU), SCU_UART0_RX (ALT1 - SCU UART receiver) or LSIO_GPIO0_IO28 (ALT3 - Low speed I/O GPIO).   Pads without GPIO functionality (i.e. without the GPIO option in the pinmux spreadsheet) are implemented for one purpose only, these pins are connected directly to the module that drives them and they feature their own physical interface. Examples are XTAL pins, DDR pins and SCU PMIC interface (shown above). Mode of operation All GPIO types support four modes of operation: Normal mode Data is being driven directly to the pad (an internal signal of 1 shows in the pad as a 1 and vice-versa) and the pad works either as an output or as an input but not both at the same time. The output buffer while on this mode looks like this: Open drain Data is being driven through an open drain configuration, the output on the pad switches between 0 and high-z. The pad works either as an output or as an input but not both at the same time, e.g. if the Output Buffer is enabled the Input Buffer is disabled. This is how the output buffer looks like on Open drain mode: Open drain and input Output buffer acts as in open drain mode but with the input buffer enabled regardless of the output buffer state (enabled/disabled), this allows to simultaneously read the signal at the pad while driving it. Output and input Output buffer acts as in normal mode but with the input buffer enabled regardless of the output buffer state (enabled/disabled), this allows to read the signal at the pad while driving it. Wake-up capability Each I/O can be configured to wake-up the device, the following configuration options are available: OFF I/O cannot wake-up the system Low detect Generate wake-up event when the pad remains in low-level High detect Generate wake-up event when the pad remains in high-level Rising edge Generate wake-up event on rising edge detection Falling edge Generate wake-up event on falling edge detection Technology specific features Some of the available features for each pad depend on two factors: Chip manufacturing process (FDSOI or LPP) I/O type (1.8V, 3.3V or Dual Voltage) The i.MX8QM is manufactured using FDSOI technology and it features all of the three available I/O types. Drive strength Drive strength options vary within I/O types and chip manufacturing options. The available options for a FDSOI chip are: 1.8V Drive strength options 3.3V Drive strength options Dual Voltage drive strength options Drive strength of 1mA Drive strength of 2mA Low drive strength (50 ohms) Drive strength of 2mA Drive strength of 4mA High drive strength (33 ohms) Drive strength of 4mA Drive strength of 8mA Drive strength of 6mA Drive strength of 12mA Drive strength of 8mA Drive strength of 10mA Drive strength of 12mA High-speed drive strength Pull Select The pull select available options are almost the same for all I/O types (1.8V being the exception) and they also depend on chip manufacturing process. The available options for a FDSOI chip are: Pull select options for FDSOI Bus-keeper (only available for 1.8V) Pull-up Pull-down No Pull (Disabled) A bus-keeper or bus-holder is used to keep the last state on the bus. In normal operation it makes no difference, but once the bus is tri-stated it keeps the last logic level in the bus to prevent the bus from floating. Compensation The compensation feature is only available on Dual Voltage I/Os. Dual Voltage I/Os have a different implementation, they require: Voltage reference generator - which provides a voltage reference to the supply detector and compensation cell Supply detector - detects automatically whether the I/O is being supplied with 1.8V or 3.3V and broadcasts this information to compensation cell and I/O  Compensation cell - adjusts drive strength of dual voltage I/Os depending on Process Voltage and Temperature (PVT) conditions. The default configuration takes care of adjusting this parameters and no further modifications are required. Pad configuration service SCFW API Mux selection The very first function that needs to be called to configure a pad is: sc_err_t sc_pad_set_mux(sc_ipc_t ipc, sc_pad_t pad, uint8_t mux, sc_pad_config_t config, sc_pad_iso_t iso);‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This function takes care of configuring the muxing alternative and setting the common features, its parameters are: ipc - The Inter Processor Communication (IPC) channel that you will use to communicate with the SCU. You need to call sc_ipc_open to obtain it. pad - The pad you want to configure, the different pad definitions are in imx8qm_pads.h, this is basically the same list that is included in the scfw_api_qm.pdf document (page 27 Chapter 5 Pad List) and it also mimics the Pinmux excel sheet. mux - The mux setting that you require, basically Alt0 -> 0, Alt1 -> 1, Alt2 -> 2 and Alt3-> 3, the pinmux spreadsheet contains the required information (take a look at I/O common features above). config - Used to select the desired mode of operation (take a look at I/O common features above), the available options are declared under sc_pad_config_t Normal mode - SC_PAD_CONFIG_NORMAL Open Drain mode - SC_PAD_CONFIG_OD Open Drain and input - SC_PAD_CONFIG_OD_IN Output and input - SC_PAD_CONFIG_OUT_IN iso - This is the low-power isolation configuration (take a look at I/O common features above). The available options are declared under sc_pad_iso_t ISO_OFF - SC_PAD_ISO_OFF ISO_EARLY - SC_PAD_ISO_EARLY ISO_LATE - SC_PAD_ISO_LATE ISO_ON - SC_PAD_ISO_ON For instance to configure M40_I2C0_SCL with its UART alternative in normal mode with low-power isolation off, the call would look like this: sc_pad_set_mux(ipc, SC_P_M40_I2C0_SCL, 1, SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);‍‍‍‍‍‍‍‍‍‍ Pad configuration To configure drive strength and pull select options the technology specific functions need to be used (FDSOI for i.MX8QM): sc_pad_set_gp is being used by our Linux team because it admits the passing of the configuration parameters as a single value and this eases the handling on the device tree, but you should aim to use the technology specific functions. sc_err_t sc_pad_set_gp_28fdsoi(sc_ipc_t ipc, sc_pad_t pad, sc_pad_28fdsoi_dse_t dse, sc_pad_28fdsoi_ps_t ps);‍‍‍‍‍‍‍‍‍‍‍ This function takes care of configuring the drive strength (DSE) and pull select settings (PS) for the specified pad, here is a break down of the parameters it uses: ipc - The Inter Processor Communication (IPC) channel that you will use to communicate with the SCU. You need to call sc_ipc_open to obtain it. pad - The pad you want to configure, the different pad definitions are in imx8qm_pads.h, this is basically the same list that is included in the scfw_api_qm.pdf document (page 27 Chapter 5 Pad List) and it also mimics the Pinmux excel sheet. dse - The desired drive strength configuration (see Technology specific features above). DSE settings depend on the I/O type being used, the available options for each I/O type are defined under sc_pad_28fdsoi_dse_t: ENET pads capable of operating at 2.5V are a subset of dual voltage I/Os, the dse options available for these pads are the same as normal dual voltage I/Os. i.e. High drive and low drive. ps - The desired pull select configuration (see Technology specific features above). The available options are defined under sc_pad_28fdsoi_ps_t: To determine whether a GPIO pad is 1.8V, 3.3V or Dual Voltage one can look at the pinmux spread sheet, the supply for the pad will indicate what implementation of the GPIO is used. For instance: pads under VDD_SIM_1P8_3P3 are Dual voltage I/Os pads under VDD_SCU_1P8 are 1.8V I/Os pads under VDD_ADC_3P3 are 3.3V I/Os taking the same example as above we could configure the M40_I2C0_SCL as follows: sc_pad_set_gp_28fdsoi(ipc, SC_P_M40_I2C0_SCL, SC_PAD_28FDSOI_DSE_DV_LOW, SC_PAD_28FDSOI_PS_NONE);‍‍‍‍‍‍‍‍‍‍‍‍‍ Configuration under Linux Linux configures pads through the device tree, the full documentation of the binding is under Documentation/devicetree/bindings/pinctrl/fsl,imx8qxp-pinctrl.txt. but here is an extract: * Freescale i.MX8QXP IOMUX Controller Required properties: - compatible: "fsl,imx8qxp-iomuxc" - fsl,pins: each entry consists of 2 integers. Its format is <pin_id pin_config>. pin_config definition: - i.MX8QXP have different pad types, please refer to below pad register definitions, the pinctrl driver will just write the pin_config into the hardware register.‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The driver uses the following API: sc_err_t sc_pad_set_gp (sc_ipc_t ipc, sc_pad_t pad, uint32_t ctrl) ‍‍‍ Instead of configuring each parameter individually as done with sc_pad_set_gp_28fdsoi it configures the pad as if writing to a register, the bitfield format is under the binding documentation but it is as follows: struct _hw_pad_iomux_bitfields0 { uint32_t GP : 19; /*!< [18:0] GP controls. */ uint32_t WAKEUP : 3; /*!< [21:19] Wakeup controls. */ uint32_t WAKEUP_ENB : 1; /*!< [22] Wakeup write enable. */ uint32_t LPCONFIG : 2; /*!< [24:23] Low-power config. */ uint32_t CONFIG : 2; /*!< [26:25] Config. */ uint32_t IFMUX : 3; /*!< [29:27] Mux. */ uint32_t GP_ENB : 1; /*!< [30] GP write enable. */ uint32_t IFMUX_ENB : 1; /*!< [31] Mux write enable. */ } B; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ All the configurations mentioned above can be configured, but they are done in a single pass, e.g. Muxing, Configuration (Norma, Open Drive, etc...), Wakeup control, and GP controls are for Pull Select Drive Strenght etc... Check the Reference Manual Chapter for IOMUXD for the register definition for each pad. References For more details refer to the sc_fw_api.pdf document: Chapter 1.3.3 Pad Configuration Service Chapter 6 Pad List Chapter 9.3 (SVC) Pad Service System Controller Firmware 101 

Introduction ARM SoC+FPGA/CPLD is widely used in some application like industry control and data acquisition system, there were many customers adopted i.MX6 EIM (a memory parallel interface) to access FPGA/CPLD, and archived good data throughput, but EIM is removed from i.MX8M and i.MX9, some customers is asking for such a compatible solution for i.MX8/8M and coming i.MX9 family.  FlexSPI is designed for connecting storage devices like NOR Flash, integrated in most of i.MXRT/i.MX8/LS products and provides flexible configuration for 4-wire/8wire working mode, this article provides a low-cost and efficiency demo to show how  to support CPLD/FPGA  via FlexSPI, as a replacement of EIM for EP i.MX8/9/LS products. key features Implement a  new kernel driver for FlexSPI to support read/write access to FPGA/CPLD. Support two type connections: Support 4-wire(QSPI) and 8-wire(HypeBUS, OctalSPI) Deliverables A new kernel driver for FlexSPI to support read/write access to FPGA/CPLD by AHB command A kernel patch to disable the QSPI Flash in kernel A test program shows how to do read/write performance test. Hardware Hardware Prepare: i.MX8MM-LPDDR4-EVK Lattice LFE5U EVK Figure1 4-wire SPI HW Block diagram Figure2 8-wire OctalSPI   Hardware Rework on i.MX8MM-EVK     1 Need to remove the SPI-Flash(U5, MT25QU256ABA) on the i.MX8MM-EVK board, and wire below signals: QSPI_DATA0 QSPI_DATA1 QSPI_DATA2 QSPI_DATA3 QSPI_SCLK QSPI_nSS0 VDD_1V8 GND Figure3 QPSI signals for FPGA/CPLD Figure4 Hardware rework on i.MX8MM-EVK board Note that, i.MX8MM-EVK QSPI power rails is 1.8v, so be careful that the FPGA/CPLD side IO should be 1.8V. Software BSP version 1 Linux BSP version: L5.10.52 Software Change  Apply 0001-FlexSPI-FPGA-need-to-disable-flexspi-for-fpga-usage.patch in Linux kernel and generate the new dtb extract the flexspi-fpga driver compile the flexspi-fpga driver with the kernel$ $make -C $(YOUR_KDIR) M=$(FlexSPI_FPGAW_DIVER_DIR) modules ARCH=arm64 CROSS_COMPILE=$(CROSS_COMPILE) Deployment  upload new generated i.mx8mm-evk.dtb to the target board(the 1st partition) upload the flex-spi driver and fpga/cpld test program to the target board   Test Test1: Set the flexspi working at 40Mhz   $insmod imx_flexspi_fpga.ko pre_div=2 post_div=5 Read/write FPGA/CPLD test .$/flexspi_fpga_test -p 0x08000000 -s 768 Test2: Set the FlexSPI working at 100MHz   $ insmod imx_flexspi_fpga.ko pre_div=1 post_div=4 Read/write FPGA/CPLD test $./flexspi_fpga_test -p 0x08000000 -s 768   Limitation FPGA and Flash devices can’t work at the same time due to just one FlexSPI controller. Due to the IO assignment conflict in i.MX8M EVK design, this demo just tested 4-wire（QSPI) mode at 50MHz and got data throughput as expected. Disclaimer: − “Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.”

File related to the following question: MX53 u-boot Splash Screen support

  Introduction   Prior to 6.1.22_2.0.0 BSP release, Bluetooth interface are based on the tty line discipline framework, so we need to use hciattach tool to enable it in the user space. From 6.1.22_2.0.0 BSP, the nxp bluetooth driver no longer needs the help of the userspace hciattach tool, and the tty port bound by bluetooth also won't be exported to the user space, so you cannot find the corresponding tty device anymore. So, you won't see the (/dev/ttymxcX), for the Bluetooth interface. All jobs has been done in the new NXP Bluetooth driver. New Method   The new NXP Bluetooth UART Driver is based on a server driver for the NXP BT serial protocol, which can enable the built-in Bluetooth device inside an NXP BT chip. This driver has a Power Save feature that will put the chip into a sleep state whenever there is no activity for 2000ms and will be woken up when any activity is to be initiated over UART.  Device Tree support The new BT framework requires adding a "bluetooth" sub node with a device compatibility string to the attached UART node in the dts file &uart1 { bluetooth { compatibility = "nxp,88w8987-bt"; fw-init-baudrate = <3000000>; #Optional. Default is considered 115200 if this parameter not defined. }; };   Note: The parameter ‘compatibility = “nxp,88w8987-bt”’ will use for 88W8987, IW416, 88Q9098, IW612 chipsets and need to change for 88W8997 with parameter ‘compatibility = “nxp,88w8997-bt”’.   Note: ’fw-init-baudrate’ parameter depends on the module vendor. The Murata and Azuere wifi modules support in BSP release uses the default value -- 115200. We strongly recommend looking at the module vendor-specific baud rate parameter. Note: For the old 88Q9098 Murata 1XL module that uses the 3Mbps by default, please add the fw-init-baudrate = <3000000> property in dts files to make it work. Enable Guide   Use wifi interface to load combo (wifi & bt) firmware and enable BT Need to load wifi driver first, then load the BT driver, otherwise, BT driver suspend/resume test will fail. This is a HW limitation, since NXP wifi and BT module use the same power control pin(W_DISABLE1#), if we don't load the wifi driver, SDIO bus will power down the wifi chip during suspend resume, which may cause the BT chip also been powered down and cannot work after resume back. So we need to load the wifi driver to make sure SDIO bus won't power down the BT chip to make sure BT functions can work during suspend resume. modprobe moal mod_para=nxp/wifi_mod_para.conf modprobe btnxpuart or insmod mlan.ko insmod moal.ko mod_para=nxp/wifi_mod_para.conf insmod btnxpuart   Unload UART Driver modprobe moal Make sure run hciconfig hci0 up or hciconfig hci0 reset or bluetootctl power on before unload btnxpuart driver. If we don't open hci0 interface, the driver cannot send change to 115200 baud rate command to BT chip, which causes the host and BT chip baud rate mismatch, the host still uses 115200bps talk to the BT chip which now use 3Mbps, it cannot work anymore. So we need to make sure open the hci0 interface before unload btnxpuart driver.   mod_para=nxp/wifi_mod_para.conf modprobe btnxpuart sleep 3 hciconfig hci0 up #Note: Need to up hci interface before unload the BT module hcitool -i hci0 cmd 3F 23 02 00 00 modprobe -r btnxpuart modprobe -r moal sleep 3​ For better reference: Please find the I.MX 8MQ Linux getting started user guide, UM11483, Chapter "7.1 Bring-up using NXP Bluetooth UART driver"  Bluetooth Deep Sleep Feature App Note AN13920, Chapter 6 Load NXP UART driver module NOTE: Please do not run the power save feature for Murata IW612 2EL Module Regards, Mario

Here is an example for i.MX28 EVK board to support SPI NOR boot in uboot, kernel and MFGTool.   Attached files are the patches to support SPI NOR flash on i.MX28 EVK bord based on L2.6.35 ER11.09.01 BSP. It was verified on Spansion s25fl256s SPI NOR. "ER11.09.01_uboot_imx28_spi_nor.patch" is the Uboot patch. "ER11.09.01_kernel_imx28_spi_nor.patch" is the kernel patch. "ucl.xml" is the updated MFGTool config file, please update it to "Mfgtools-Rel\Profiles\MX28 Linux Update\OS Firmware\ucl.xml".   The uboot boot paramters for SPI: setenv bootargs_base 'setenv bootargs console=ttyAM0,115200' setenv loadaddr 0x42000000 setenv bootargs_spi 'setenv bootargs ${bootargs} root=/dev/mtdblock2 rootfstype=jffs2 rootwait rw ip=none' setenv bootcmd_spi 'run bootargs_base bootargs_spi;sf probe 2:0; sf read ${loadaddr} 0x100000 0x300000;bootm' setenv bootcmd 'run bootcmd_spi' saveenv   To boot the board from SPI NOR s25fl256s, the 4KB page region of the NOR should be put to top, the last 128KB of the NOR address space. The uboot.sb is about 220KB, it can't be put to 4KB and 64KB combined region. The IMX28 boot ROM can only handle simple page size for boot. All 4KB page region or all 64KB page region are both OK for boot, but combined region can't boot.   For default, the s25fl256s NOR's 128KB 4KB page size region is at the bottom of the NOR, we should update the OTP to set this region to TOP, in Uboot, we run the followed command to burn the OTP: MX28 U-Boot -> sf probe 2:0 MX28 U-Boot -> sf set_config_reg 0x04   To boot the i.MX28 EVK board from SPI2 NOR flash, the BM3~0 should be 0010.   In this example, we only used the JFFS2 file system. To support the UBIFS, there is a known issue, that the UBIFS will use vmalloc to alloc memory, and if SPI driver used the DMA, kernel will halt with error "kernel BUG at arch/arm/mm/dma-mapping.c:409!".   For 11.09.01 BSP, the default MFGTool rootfs "initramfs.cpio.gz" will be bigger than 4MB, but in i.MX28 bootlets code, the BSP only set ramdisk to 4MB, so we need modify this limitation for MFGTool.   Use command "./ltib -p imx-bootlets -m prep" to get the bootlets code, modify "ltib/rpm/BUILD/imx-bootlets-src-11.09.01/linux_prep/core/setup.c", function setup_initrd_tag(), change from "params->u.initrd.size =  0x00400000;" to "params->u.initrd.size =  0x00500000;". Modify "ltib/rpm/BUILD/imx-bootlets-src-11.09.01/updater.bd" and "updater_ivt.bd", change from "load 0.b    > 0x40800000..0x40c00000;" to "load 0.b    > 0x40800000..0x40d00000;".   Now the MFGTool rootfs size can be 5MB.   2013-05-09: Updated hardware rework: On iMX28 EVK board, rework J89 as followed and mount R320,R321,R322 and C178. MX28 U49 Pin1 /CS <-> NOR Pin7 CS# MX28 U49 Pin2  D0 <-> NOR Pin8 SI/IO1 MX28 U49 Pin5 DIO <-> NOR Pin15 SI/IO0 MX28 U49 Pin6 CLK<-> NOR pin 16 SCK. MX28 U49 Pin8 VCC <-> NOR Pin2 VCC                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 MX28 U49 Pin4 GND <-> NOR Pin10 VSS MX28 U49 Pin3 /WP <-> NOR Pin9 WP MX28 U49 Pin7 /Hold <-> NOR Pin pin1 hold   Software reset issue for 32MB SPI NOR: For 32MB SPI NOR, after booted into kernel, the kernel driver will set SPI NOR to 4 bytes address mode, but for iMX28 SPI boot, it can only boot with 3 bytes address mode, if reset the iMX28 board but SPI NOR was not reset, it will fail to reboot. Hardware solution: when iMX28 was reboot, reset the SPI NOR too, the SPI NOR will work in 3 bytes address mode as default. Software solution: In kernel SPI NOR driver, always switch SPI NOR to 3 bytes address mode after each SPI NOR access, and switch to 4 bytes address mode before each access. There is no such issue if the SPI NOR size is less than 32MB.    

Starting from $52, the VAR-SOM-MX6 sets the bar for unparalleled design flexibility. The VAR-SOM-MX6 ensures scalable and simplified development, while also extending the product lifecycle. Thanks to four CPU core assembly options, customers can apply a single System on Module in a broad range of applications to achieve short time-to-market for their current innovations, while still accommodating potential R&D directions and marketing opportunities.     VAR-SOM-MX6 CPU: Freescale iMX6 Key features include: Freescale i.MX6 1.2GHz Quad / Dual / Single core Cortex-A9       2GB DDR3, 1GB SLC NAND Flash       Full HD 1080p video encoding/decoding capability       Vivante GPU providing 2D/3D acceleration       Simultaneous multiple display support       Gigabit Ethernet       TI WiLink™ 6.0 single-chip connectivity solution (Wi-Fi, Bluetooth®)       PCI-Express 2.0, S-ATA 3.0       Camera interface       USB 2.0: Host, OTG       Audio In/Out       Dual CAN Bus This versatile solution's -40 to 85°C temperature range and Dual CAN support is ideal for industrial applications, while 1080p video and graphics accelerations make it equally suitable for intensive multimedia applications. The impressive scalability of the VAR-SOM-MX6 satisfies the needs of the most demanding future application requirements whether faster processing power, enhanced algorithms or improved graphics and video performance to name just a few. The VAR-SOM-MX6 is an all-round solution with broad connectivity and sophisticated video and acceleration graphic capabilities, delivering a range of middle to high end assembly options all from the same product. For more details, please see VAR-SOM-MX6 CPU: Freescale iMX6

Materials: i.MX8M Plus EVK Rev. A USB cable type-C USB cable type-B AC Adapter EA1045CR Micro SD (Optional) 88W8997-based wireless modules Software: Yocto Project Mobaxterm Personal Edition v20.2 Build 4296 This test was done on an i.MX8M Plus EVK with Linux 5.10. Hardknott.   To achieve this, you need to identify your WI-FI module and look for the necessary drivers for that module, in my case I am using the 88W8997 module that comes with the i.MX8M Plus, but you can select any other WI-FI module you want.   In my case I build a basic image on Yocto, following the Yocto users guide, I bitbake just the core boot image that allows me to boot the i.MX8M plus. Deploy your image on an SD or eMMC. These instructions apply to SD and MMC cards although for brevity, and usually, only the SD card is listed. For a Linux image to be able to run, four separate pieces are needed: Linux OS kernel image (zImage/Image) Device tree file (*.dtb) Bootloader image Root file system (i.e., EXT4)   The Yocto Project build creates an SD card image that can be flashed directly. This is the simplest way to load everything needed onto the card with one command. A .wic image contains all four images properly configured for an SD card. The release contains a pre-built .wic image that is built specifically for the one board configuration. It runs the Wayland graphical backend. It does not run on other boards unless U-Boot, the device tree, and rootfs are changed. When more flexibility is desired, the individual components can be loaded separately, and those instructions are included here as well. An SD card can be loaded with the individual components one-by-one or the .wic image can be loaded and the individual parts can be overwritten with specific components. The rootfs on the default .wic image is limited to a bit less than 4 GB, but re-partitioning and re-loading the rootfs can increase that to the size of the card. The rootfs can also be changed to specify the graphical backend that is used. Carry out the following command to copy the SD card image to the SD/MMC card. Change sdx below to match the one used by the SD card. $ sudo dd if=<image name>.wic of=/dev/sdx bs=1M && sync The entire contents of the SD card are replaced. If the SD card is larger than 4 GB, the additional space is not accessible. As this build does not contain the driver integrated we need to add it manually on Linux user space. Follow these instructions to load the driver modules and bring up the 88W8987-based wireless module, more info can be found on the next link: https://www.nxp.com/products/wireless/wi-fi-plus-bluetooth/2-4-5-ghz-dual-band-2x2-wi-fi-5-802-11ac-plus-bluetooth-5-3-solution:88W8997?tab=Documentation_Tab   Use the nano editor included in the pre-built image to edit and verify the module parameters in the wifi_mod_para.conf configuration file.   Add the following lines to the configuration file: PCIE8997 = { cfg80211_wext=0xf wfd_name=p2p max_vir_bss=1 cal_data_cfg=none drv_mode=7 ps_mode=2 auto_ds=2 fw_name=nxp/pcieuart8997_combo_v4.bin } Load the modules in the kernel:   Verify the kernel debug messages in the command output   Verify that the module is now visible to the system:     Now that the module is ready to work, we need to enable it, in my case the Wi-Fi is named mlan0, it could vary on other Linux systems.   In the case you need to see which networks are available you can scan it and select the one you need.   Identify your network and add it to the  WPA supplicant file:     Associate the Wi-Fi with config:   Check if you have right SSID associated:   Use DHPC to get the IP   Ping any public site you know to check the network.   In the case you have a Temporary failure in name resolution you will need to change the default DNS that was assigned by DHCP:     Modify /etc/resolv.conf file and add the DNS of your preference, for my case I add the one that uses Google, as they have access to the most common web pages.   And with that should work.    

Installation, patching and building the SDK The i.MX 6 Series Platform SDK v1.1.0 does not enable neither the MMU nor L1/L2 Caches (depending on the benchmark you are running, enabling these yield much better numbers), so there is a need to patch the code to enable these. Please download the SDK from the Freescale portal and the patch attached on this document, then follow these instructions: $ tar zxvf imx6_platform_sdk_v1.1.0.tgz $ cd iMX6_Platform_SDK $ patch -p1 < 0001-add-L2-cache-enable-to-mx6-SDK-1.1.0.patch $ export PATH=$PATH:<toolchain_install_path>/bin $ ./tools/build_sdk For more help, please look at the README.pdf and documents inside the doc folder.

Installation Build the development image (fsl-image-gui-sdk) using Yocto and flash it into the board Download LMbench's tarball from LMbench - Tools for Performance Analysis Untar the file and move the created folder Run the benchmarks following these steps: lmbench $ cd src lmbench/src $ make results lmbench/src $ cd .. lmbench $ make see Benchmarks Attached are the benchmarks results from several machines. In case you run them in a different machine, please attach your results file on this document. For more robust results, rerun several times the test and create the result document following these steps: lmbench $ make results lmbench $ make rerun lmbench $ make rerun lmbench $ make rerun lmbench $ cd results lmbench/results $ make > results # results is the output file you may want to attach to this document

Hello! Here's some CODE!!! #include <iostream> #include <stdio.h> #include <assert.h> #include <string.h> #include <fcntl.h> #include <malloc.h> #include <math.h> #include <stdlib.h> //#define EGL_USE_GLES2 #include <GLES2/gl2.h> #include <EGL/egl.h> #include <GLES2/gl2ext.h> #include <EGL/eglext.h> #include <termios.h> #include <unistd.h> #include <fcntl.h> #ifdef EGL_USE_X11 #include <X11/X.h> #include <X11/Xlib.h> #endif EGLDisplay egldisplay; EGLConfig eglconfig; EGLSurface eglsurface; EGLContext eglcontext; EGLNativeWindowType eglNativeWindow; EGLNativeDisplayType eglNativeDisplayType; EGLNativeDisplayType fsl_getNativeDisplay() {   EGLNativeDisplayType eglNativeDisplayType = NULL; #if (defined EGL_USE_X11)   eglNativeDisplayType = XOpenDisplay(NULL);   assert(eglNativeDisplayType != NULL); #elif (defined EGL_API_FB)   eglNativeDisplayType = fbGetDisplayByIndex(0); //Pass the argument as required to show the framebuffer #else   display = EGL_DEFAULT_DISPLAY; #endif   return eglNativeDisplayType; } EGLNativeWindowType fsl_createwindow(EGLDisplay egldisplay, EGLNativeDisplayType eglNativeDisplayType) {   EGLNativeWindowType native_window = (EGLNativeWindowType)0; #if (defined EGL_USE_X11)   Window window, rootwindow;   int screen = DefaultScreen(eglNativeDisplayType);   rootwindow = RootWindow(eglNativeDisplayType,screen);   window = XCreateSimpleWindow(eglNativeDisplayType, rootwindow, 0, 0, 400, 533, 0, 0, WhitePixel (eglNativeDisplayType, screen));   XMapWindow(eglNativeDisplayType, window);   native_window = window; #else   const char *vendor = eglQueryString(egldisplay, EGL_VENDOR);   if (strstr(vendor, "Imagination Technologies"))   native_window = (EGLNativeWindowType)0;   else if (strstr(vendor, "AMD"))   native_window = (EGLNativeWindowType)  open("/dev/fb0", O_RDWR);   else if (strstr(vendor, "Vivante")) //NEEDS FIX - functs don't exist on other platforms   { #if (defined EGL_API_FB)   native_window = fbCreateWindow(eglNativeDisplayType, 0, 0, 0, 0); #endif   }   else   {   printf("Unknown vendor [%s]\n", vendor);   return 0;   } #endif   return native_window; } void fsl_destroywindow(EGLNativeWindowType eglNativeWindowType, EGLNativeDisplayType eglNativeDisplayType) {   (void) eglNativeWindowType; #if (defined EGL_USE_X11)   //close x display   XCloseDisplay(eglNativeDisplayType); #endif } void GLInit (void) {   static const EGLint s_configAttribs[] =   {   EGL_RED_SIZE, 5,   EGL_GREEN_SIZE, 6,   EGL_BLUE_SIZE, 5,   EGL_ALPHA_SIZE, 0,   EGL_SAMPLES, 0,   EGL_NONE   };   EGLint numconfigs;   printf("1");   eglNativeDisplayType = fsl_getNativeDisplay();   printf("2");   egldisplay = eglGetDisplay(eglNativeDisplayType);   printf("3");   eglInitialize(egldisplay, NULL, NULL);   printf("4");   assert(eglGetError() == EGL_SUCCESS);   printf("5");   eglBindAPI(EGL_OPENGL_ES_API);   printf("6");   eglChooseConfig(egldisplay, s_configAttribs, &eglconfig, 1, &numconfigs);   assert(eglGetError() == EGL_SUCCESS);   assert(numconfigs == 1);   printf("7");   eglNativeWindow = fsl_createwindow(egldisplay, eglNativeDisplayType);   assert(eglNativeWindow);   printf("8");   eglsurface = eglCreateWindowSurface(egldisplay, eglconfig, eglNativeWindow, NULL);   assert(eglGetError() == EGL_SUCCESS);   printf("9");   EGLint ContextAttribList[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE };   eglcontext = eglCreateContext( egldisplay, eglconfig, EGL_NO_CONTEXT, ContextAttribList );   assert(eglGetError() == EGL_SUCCESS);   printf("10");   eglMakeCurrent(egldisplay, eglsurface, eglsurface, eglcontext);   assert(eglGetError() == EGL_SUCCESS); } void GLEnd (void) {   printf("Cleaning up...\n");   eglMakeCurrent(egldisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);   assert(eglGetError() == EGL_SUCCESS);   eglDestroyContext(egldisplay, eglcontext);   eglDestroySurface(egldisplay, eglsurface);   fsl_destroywindow(eglNativeWindow, eglNativeDisplayType);   eglTerminate(egldisplay);   assert(eglGetError() == EGL_SUCCESS);   eglReleaseThread(); } int main (int argc, char **argv) {   GLInit();   for( int i = 0; i < 100000; ++i)   {   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);     // Clear The Screen And The Depth Buffer   glClearColor (.0f, .0f, 1.0f, 1.0f);   eglSwapBuffers (egldisplay, eglsurface);   }   GLEnd(); } Above code is stitched together from samples from GPU SDK. I've built an image using Yocto (dylan branch) and build the meta-toolchain-qt (and qte). Successfully managed to build above code ONLY FOR X11. Issues i am facing: 1) if build for X11 and run app on the board, window shows, but it stays white, when it should be BLUE...doesn't update no matter what color i glClear to. 2) when compiling with FB, fbCreateWindow and etc don't get recognized, i.e. undefined reference to `fbCreateWindow' .... WHAT header contains these functions???? 3) if even the basic samples don't work, how the hell is anybody supposed to build a GL application on this board?? --- more rhetorical than a real question, just frustrated here... what did i do wrong? 4) please show me a working tutorial or some code on how to get this EGL context initialized...i'm running at wit's end here...

This is a generic script which flashes a Linux System (U-boot, uImage and root filesystem) into a SD card. Steps:     1. Download the script into a Linux system     2. Make the script executable (chmod +x mk_mx_sd)     3. Run it with '-H' to know its usage.     4. Run the script with real parameters, specifying the paths for U-boot, uImage and the root filesystem as seen above     5. Plug the SD into your target, boot the board and change the corresponding U-boot variables $ IMAGE=/data/BSP/L2.6.35_11.09.01_ER/L2.6.35_11.09.01_ER_images_MX5X $ ./mk_mx_sd  -d /dev/sdc \                       -u $IMAGE/u-boot-mx53-loco.bin \                       -k $IMAGE/uImage \                       -r $IMAGE/rootfs     6. In case you only want to flash a single binary (like U-boot), just specify the U-boot parameter (-u)

How to connect i.MX51 and Ubuntu using USB cable: i.MX51 Side Plug in USB cable. getprop debug.adb.usb - Shows that debug.adb.usb are not set by default setprop persist.service.adb.enable 0 -> disable adb setprop debug.adb.usb 1 - adb will be through USB (for Ethernet, use setprop debug.adb.usb 0) setprop persist.service.adb.enable 1 -> enable adb Example: # getprop debug.adb.usb  # # # setprop persist.service.adb.enable 0 disabling adb # adb_release android_usb gadget: high speed config #1: android setprop debug.adb.usb 1 # # setprop persist.service.adb.enable 1 enabling adb # adb_open adb_release adb_open android_usb gadget: high speed config #1: android # Ubuntu Side On Ubuntu side, the most important tip is regarding permission. ADB server MUST be started with root right. Example of right mistake: $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb devices List of devices attached ????????????    no permissions  $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb shell error: insufficient permissions for device How to proceed to get permission: $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb kill-server $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb start-server * daemon not running. starting it now * * daemon started successfully * $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb devices List of devices attached 0123456789ABCDEF    device  $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb shell ADB over Ethernet/Wi-Fi To make ADB work in i.MX51 using TCP: In your host machine: - Install Android SDK - export ADBHOST=BOARD_IP (setenv ADBHOST=xxx.xxx.xxx.xxx) - adb kill-server In your board: - make sure that ro.secure property is *not* set when the adbd daemon is launched, so edit the file default.prop - make sure that /dev/android_adb or /dev/android do *not* exist - stop adbd - start adbd Now you will be able to list the device: hamilton@saygon:/opt/work/androidsdk/android-sdk-linux_86/tools$ ./adb kill-server hamilton@saygon:/opt/work/androidsdk/android-sdk-linux_86/tools$ ./adb devices * daemon not running. starting it now * * daemon started successfully * List of devices attached emulator-5554   device

Wayland:   Wayland is a display SERVER and COMPOSITION protocol. It is relatively new, as its first release was in 2012. The protocol enables applications to allocate their own off-screen buffers and render their window contents directly, using hardware accelerated libraries like OpenGL ES, or high quality software implementations like Cairo. Wayland is ONLY a display server protocol, not a display server itself. Weston is the reference Wayland protocol implementation.   YOCTO Setup . $ mkdir ~/bin $ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH $ git config --global user.name "Your Name" $ git config --global user.email "Your Email" $ git config –list $ mkdir fsl-release-bsp $ cd fsl-release-bsp $ repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-3.14.52-1.1.0_ga $ repo sync     you will be able to build Yocto and also have all the recipes to do so, we need to add WAYLAND, then execute the following steps: $ DISTRO=fsl-imx-wayland MACHINE=imx6qsabresd source fsl-setup-release.sh -b build-wayland $ bitbake fsl-image-gui After these steps, you will have a wayland based i.MX6Q image where you will be able to play with all the knowledge we provided here.   Once your image has been properly generated, you will find the Weston source codes in: <YOUR YOCTODIR>/build-wayland/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/weston/1.9.0-r0/weston-1.9.0     Wayland application for extended desktop: This functionality is only supported using the GAL2D blitter, in order to enable a multiple desktop approach, you need to pass the following parameters to your weston command: /etc/init.d/weston stop echo 0 > /sys/class/graphics/fb4/blank weston --tty=1 --use-gal2d=1 --use-gl=0 --device=/dev/fb0,/dev/fb4 &     Xwayland: Wayland is a complete window system in itself, but even so, if we're migrating away from X, it makes sense to have a good backwards compatibility story. With a few changes, the Xorg server can be modified to use wayland input devices for input and forward either the root window or individual top-level windows as wayland surfaces.   DISTRO=fsl-imx-xwayland MACHINE=imx6qsabresd source ./fsl-setup-release.sh -b build-xwayland bitbake fsl-image-gui Once you have the image your Wayland/Weston image will be able to run X11 applications   Excepting X11 applications that use EGL, we don’t support that, if you plan to use EGL apps, please use the Wayland provided functions to create the buffer.   Application for rotation: Weston allows rotating windows with super-key + middle mouse button. As this works for Wayland clients only, you can run Xwayland in weston, run your X application on Xwayland, and rotate the Xwayland display. For another option: Create a file ~/.config/weston.ini with this content: [core] modules=xwayland.so shell=desktop-shell.so idle-time=0 [shell] background-color=0xff002244 locking=false # panel-location=none    [launcher] icon=/usr/share/icons/gnome/24x24/apps/utilities-terminal.png path=/usr/bin/weston-terminal [launcher] icon=/usr/share/icons/hicolor/48x48/apps/firefox.png path=/usr/bin/firefox [output] name=X1 mode=640x800 transform=90 # wanna get mad? use: transform=flipped-270 scale=1 This weston.ini enables a rootless xwayland.so in weston. The [output] section with name=X1 defines weston's appearance as X client. transform=90 rotates the weston display.   the [launcher] sections can be used to create custom panel starters for your X applications. See  /usr/share/doc/weston/examples/weston.ini for more detailed information for further cases, I will attach in the future.