GTK+ is a highly usable, feature rich toolkit for creating graphical user interfaces which boasts cross platform compatibility and an easy to use API. GTK+ it is written in C, but has bindings to many other popular programming languages such as C++, Python and C# among others. GTK+ is licensed under the GNU LGPL 2.1 allowing development of both free and proprietary software with GTK+ without any license fees or royalties. [Source: gtk.org] As GTK+ is a graphical library, a program using GTK+ can be done in many languages like C, C++, Python, Perl, PHP, Ruby, and many others. Here a C example will be done. How to make a simple program with GTK An easier way to make a graphical interface (GUI) program using GTK+ is to use Glade as Graphical Editor. Glade3 Screenshot To install Glade on Ubuntu type: $sudo apt-get install glade-3 Old Glade versions used to generate C code. Currently version ONLY generates a .glade file that can be parsed in a .xml file which describes the hierachy of the widgets. Let's create, compile and test a sample program on host and after, cross-compile for iMX platform and check it running on a PDK i.MX31 Development kit. In order to develop on host PC, install libgtk2.0-dev typing: $sudo apt-get install libgtk2.0-dev

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

Prerequisites: The build is verified on prebuilt rootfs(based on LTIB) which can be downloaded from freescale.com EGL uses framebuffer backend libEGL.so -> libEGL-fb.so libGAL.so -> libGAL-fb.so QT4.8 1. Download the git respository for qt4.8: $ git clone http://git.gitorious.org/qt/qt.git qt $ cd qt Let us consider this as <QTDir> 2. Create /tftpboot and point your target fileystem. As like $ mkdir -p /tftpboot $ cd /tftpboot $ ln -s $(ROOTFFS) rootfs TBD:Need to work on this to use sysroot option 3. Create a build directory to install for the qt4 packages. This directory can be  in any location. For example, $ mkdir /opt/qt4 $ sudo chown -R <username> /opt/qt4 Let us consider the the <installdir> as /opt/qt4 4. Extract the attached mkspecs(linux-imx6-g++.tar.gz) to  <QTDir>/mkspecs/qws/ 5. Apply the attached cd 0001-add-i.MX6-EGL-support.patch attached to enable egl support for i.MX6 $ cd <QTDir> $ patch -p1<0001-add-i.MX6-EGL-support.patch 6. Export CROSS-COMPILE location path to PATH $ export PATH=$PATH:/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/ 7. Enter to the <QTDir>. Do configure. You can select the options as you like. Here is an example $ cd <QTDir> $ ./configure -qpa -arch arm -xplatform qws/linux-imx6-g++ -no-largefile -no-accessibility \ -opensource -verbose -system-libpng -system-libjpeg -system-freetype -fast -opengl es2 -egl -confirm-license \ -qt-zlib  -qt-libpng  -no-webkit -no-multimedia \ -make examples -make demos \ -release -make libs -exceptions -no-qt3support -prefix <installdir> 8. When the configure summary is shown make sure the Qt has OpenGL ES 2.0 support. Do build $ make $ make install 9. Now need to build eglfs plugin $ cd <QTDir>/src/plugins/platforms/eglfs $ make $ make install     Now the eglfs will be installed to the QT Install directory. 10. By now all required QT files are in <install directory> 11. Copy the install directory to target filesystem $ cp -rf /opt/qt4 /tftpboot/rootfs/opt/. 12. Running Qt apps on target     - Boot the target either with NFS or SD Image     - Ensure that folder <installdir> is copied on target file system at “/usr/local”.     - Launch application using $ cd /opt/qt4/examples/opengl/hellogl_es2 $ ./hellogl_es2 -platform eglfs QT5 These steps are performed on the host 1. Download the git respository for qt5: $ git clone git://gitorious.org/qt/qt5.git qt5 $ cd qt5     Let us consider this as <QTDir> 2. Create a build directory to install for the qt5 packages. This directory can be  in any loctation. For example, $ sudo mkdir /opt/qt5 $ sudo chown -R <username> /opt/qt5 Let us consider the the installdir as /opt/qt5 3. Enter the Qt5 directory and run the init-repository script to download all the source code for    Qt5. To download all the source code will take about an hour. $ ./init-repository Update:  In the latest Qt5 release the webkit library is included by default and there are some issues trying to compile it. use the next line to avoid problems if not desired to use webkit. $ ./init-repository --no-webkit 4. From the following path $ gedit qtbase/mkspecs/devices/linux-imx6-g++/qmake.conf 5. At the top of the qmake.conf, there is a configure line. Copy and paste the configure line into a text file located    in your build build directory. Edit the configure line to find your toolchain and filesystem. Also make sure to    include the options -no-pch, -no-opengl, -opengl es2, Here is an example of    a configure line. Update: In the latest Qt5 stable, the option to compile the examples/demos is -compile-examples, instead of -make examples -make demos If you are running into problems with webkit,  use the option -no-icu, this will disable the webkit. $ cd <QTDir> $ cd qtbase $ ./configure -v -opensource -confirm-license -no-pch -no-xcb -no-opengl -opengl es2  \         -make libs -device imx6 \        -compile-examples \       -device-option CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-fsl-linux-gnueabi- \        -sysroot <rootfs> -no-gcc-sysroot \       -prefix <installdir> 7. Make the textfile that has the configure line and executable and run it. When the configure summary is shown make sure the Qt5 has openGL ES 2.0 support. Do build $ make $ sudo make install    When Qt5 has finished building, Qt5 will be installed in two places:            1. <location of rootfs>/<installdir>            2. <HOST Machine>/<install dir> This is good because now all the libraries and binaries for Qt5 are installed on the host and the target filesystem. Therefore, the target already has all the libraries and  binaries needed to run Qt5. 8. Also need to build qtjsbackend and qtdeclarative. $ cd <location to Qt5 git> $ cd qtjsbackend $ ../qtbase/bin/qmake -r $ make && sudo make install $ cd <location to Qt5 git> $ cd qtdeclarative $ ../qtbase/bin/qmake -r $ make && sudo sudo make install 9. Running Qt apps on target     - Boot the target either with NFS or SD Image     - Ensure that folder <installdir> is copied on target file system at “/usr/local”.     - Launch application using $ cd /opt/qt5/examples/opengl/hellowindow $ ./hellowindow -platform eglfs FAQ: On the target file system, the location of target libaries and includes may present in arm-linux-gnueabi directory. Make sure to create soflinks to QT can find. For example $ cd $(ROOTFS)/usr/lib $ ln -s arm-linux-gnueabi/libffi.so.6 libffi.so.6 While building QT5, you may see a build error that libQt5V8.so.5 is not found. This might be some problem to be addressed in QT. Workaround is to copy all the binaries to correct path as like this $ cp  <ROOTFS>/<installdir>/lib/* <HOST Machine>/<installdir>/. What is coming up next: 1. QT on X is already available on Yocto filesystem. Steps to enable GPU Acceleration TDB. 2. QT with Wayland support.

The System Controller Unit (SCU) is in charge of controlling several features related to power management of the whole system. The user gets access to the following features through the System Controller Firmware: Powering up/down the system,resources and partitions Configuring resource clocks Reset controls Configuring wake-up sources This document will cover the more commonly used features, for details on the full capabilities of the API please refer to the API document for your device. Resource Power Control The SCU is in charge of managing power control to the resources (peripherals) in the SoC. Attempting to access a resource on the OFF state will result in a bus error or a hang All resources are organized within several subsystems, subsystems group together resources with common functionality. Subsystems are independent of each other and have their own PLLs and power domains, this allows modular control of clocks and power to the resources. The System Controller Unit has a dedicated I2C channel to interact with the PMIC, this allows dynamic control of some power sources for resources like the GPUs and Cortex-A cores. The SCU can enable/disable the LDO that supplies power to the GPU for instance and also turn on/off the internal power domains. The mapping of PMIC supplies and resources happens on the board.c (included in the SCFW Porting kit) and it is part of the porting process of the SCFW to new boards. The function board_get_pmic_info is where the mapping of resources to supplies happen, see: /*--------------------------------------------------------------------------*/ /* Get the pmic ids and switchers connected to SS. */ /*--------------------------------------------------------------------------*/ static void board_get_pmic_info(sc_sub_t ss,pmic_id_t *pmic_id, uint32_t *pmic_reg, uint8_t *num_regs) { /* Map SS/PD to PMIC switch */ switch (ss) { case SC_SUBSYS_A53 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_0_ADDR; pmic_reg[0] = PF8100_SW5; *num_regs = 1U; } break; case SC_SUBSYS_A72 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_0_ADDR; pmic_reg[0] = PF8100_SW3; pmic_id[1] = PMIC_0_ADDR; pmic_reg[1] = PF8100_SW4; *num_regs = 2U; } break; case SC_SUBSYS_GPU_0 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_1_ADDR; pmic_reg[0] = PF8100_SW1; pmic_id[1] = PMIC_1_ADDR; pmic_reg[1] = PF8100_SW2; *num_regs = 2U; } break; case SC_SUBSYS_GPU_1 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_1_ADDR; pmic_reg[0] = PF8100_SW3; pmic_id[1] = PMIC_1_ADDR; pmic_reg[1] = PF8100_SW4; *num_regs = 2U; } break; default : ; /* Intentional empty default */ break; } }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Only some subsystems have their own dedicated external power supplies, in the example above A cores and GPUs are the only ones with a dedicated external power supplies. Most of the other subsystems are powered from the main power supply and power gating happens internally, each subsystem contains different power domains that can be turned on/off to manage power consumption. The SCFW API used to power on/off resources is the following: sc_err_t sc_pm_set_resource_power_mode (sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_power_mode_t mode)‍‍‍‍‍ Where: ipc - is the interprocessor communication channel used to communicate with the SCU (obtained by calling sc_ipc_open). resource - is the resource that will have the power mode change mode - is the power mode to change to The available power mode options are the following: Power mode Voltage Clocks SC_PM_PW_MODE_OFF OFF All clocks off SC_PM_PW_MODE_STBY ON All clocks off SC_PM_PW_MODE_LP ON PLLs off resource running from XTAL SC_PM_PW_MODE_ON ON PLLs on In order to be able to access a resource it must be at least on SC_PM_PW_MODE_LP mode, since that mode has the resource voltage on and the clock is supplied by the 24MHz crystal. For more details please refer to the SCFW API document. Clocks Configuration As in the power management case, clocks are also organized in a distributed manner within the device. Each subsystem has it's own PLLs and all of them are clocked by the 24MHz crystal. The number of PLLs in each subsystem varies between all subsystems. To see how many PLLs are within a subsystem please refer to the datasheet of the device you are interested on. For instance on the datasheet of the i.MX8QXP on table 16 in Chapter 4.3.1: It can be seen that the GPU subsystem contains two PLLs, the ADMA subsystem contains 4 PLLs, Display Controller 3, etc... The SCFW API used to configure a clock is the following: sc_err_t sc_pm_set_clock_rate ( sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_clk_t clk, sc_pm_clock_rate_t ∗ rate )‍‍‍‍‍ Where: ipc - is the interprocessor communication channel used to communicate with the SCU (obtained by calling sc_ipc_open). resource - is the resource that will have the clock rate change clk - is the clock to set the rate to (each resource can have different clocks associated with it for instance the GPU resource has a clock associated for its shader and another for the GPU, this parameter is used to identify the clock) rate - this contains the desired clock rate, the SCFW will try to match the provided rate if not possible it will then set the closest possible value and return the value that was actually configured. To identify the clk that needs to be passed, please refer to the SCFW API chapter called "Clock List" That chapter contains a table with all the different clocks that are configurable by the SCFW, in the case of the GPUs for instance to select the rate for the Shader or GPU, either the SC_PM_CLK_MISC or SC_PM_CLK_PER options would have to be selected. Set=Y indicates the clock/PLL is not shared and the rate can be set via sc_pm_set_clock_rate(). Enable=Y indicates the clock is not auto gated and must be enabled via sc_pm_clock_enable(). As an example the following snippet configures the GPU_0 shader clock: sc_clock_rate_t shader_clk=700000000; // 700 MHz sc_pm_set_clock_rate(ipc, SC_R_GPU_0_PID0, SC_PM_CLK_MISC, &shader_clk);‍‍ System Controller Firmware 101 

Download Linux kernel 2.6.29: $ wget -c http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2 Extract this: $ tar jxvf linux-2.6.29.tar.bz2 Apply the patches: $ cd linux-2.6.29 Edit the file drivers/net/cs89x0.c adding: #include <mach/hardware.h> Export CROSS_COMPILE environmet: $ export PATH="$PATH:/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/" $ export CROSS_COMPILE=arm-none-linux-gnueabi- Unselect all no essentials features: $ make ARCH=arm allnoconfig Start the configuration menu: $ make ARCH=arm menuconfig Change/Select the kernel options below. Select the MXC/iMX platform and iMX31ADS board: System Type ->             ARM system type -> (X) Freescale MXC/iMX-based             Freescale MXC Implementations  ->                            MXC/iMX Base Type -> (X) MX3-based                            MX3 Options  -> [*] Support MX31ADS platforms (NEW) Select ARM EABI standard to compile the kernel: Kernel Features  --->           [*] Use the ARM EABI to compile the kernel Add support to Linux Binary Format ELF: Userspace binary formats ->              [*] Kernel support for ELF binaries Add support to Network (TCP/IP): [*] Networking support  ->          Networking options  ->                          [*] Packet socket                          [*] Unix domain sockets                          [*] PF_KEY sockets                          [*] TCP/IP networking                                   [*] IP: kernel level autoconfiguration                                   [*]     IP: DHCP support Select network driver (CS89x0), serial driver and unselect VGA console: Device Drivers  ->                      [*] Network device support  --->                                      [*]   Ethernet (10 or 100Mbit)  --->                                             [*]   CS89x0 support                      Character devices  ->                              Serial drivers  --->                                       [*] IMX serial port support                                       [*]   Console on IMX serial port                      Graphics support  ->                             Console display driver support  --->                                        [ ] VGA text console Add support to NFS and support to use it as root file system: File systems  ->                            [*] Network File Systems (NEW)  ->                                        [*]   NFS client support                                        [*]     Root file system on NFS Compile the kernel: $ make ARCH=arm Copy the created zImage to tftp directory: $ cp arch/arm/boot/zImage /tftpboot/ Configure your RedBoot to boots with this kernel: load -r -b 0x100000 /tftpboot/zImage exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.29.240.191:/tftpboot/rootfs ip=dhcp"

Hi All, The new i.MX 6 SL L3.0.35_2.1.0 release is now available on the http://www.freescale.com/site. ·         Files available # Name Description 1 L3.0.35_2.1.0_LINUX_DOCS i.MX   6SoloLite Linux BSP Documentation. Includes Release Notes, Reference Manual,   User guide. API Documentation 2 L3.0.35_2.1.0_LINUX_MMDOCS i.MX 6SoloLite Linux Multimedia Codecs   Documentation. Includes   CODECs Release Notes and User's Guide 3 L3.0.35_2.1.0_ER_SOURCE i.MX   6SoloLite Linux BSP Source Code Files 4 L3.0.35_2.1.0_MM_CODECS i.MX   6SoloLite Linux Multimedia Codecs Sources 5 L3.0.35_2.1.0_AACP_CODECS i.MX   6SoloLite Linux AAC Plus Codec 6 L3.0.35_2.1.0_DEMO_IMAGE i.MX   6SoloLite Linux Binary Demo Files ·         Target HW boards o   i.MX6SL-EVK ·         New features o   Updated thermal equation for i.MX 6SoloLite o   Added Fuse check for all the devices o   Enabled DISPLAY power gating feature on TO1.2 ·         Known issues o   For known issues and limitations please consult the release notes.

Dear All,       Our board is designed based on both EVK and HEG (Adeneo Embedded Home Energy Gateway), the ENET_FEC_RESET_B on EVK is replaced by LCD_D11 as it on HEG. We have re-config all pins based on i.mx28 BSP and successfully built by ltib. However, eth0 is not working due to "PHY is not found"! and we are still trying to figure it out.       The changes we apply on the BSP are(in mx28evk_pins.c): in static struct pin_desc mx28evk_fixed_pins[]:       the definition of LCD_D11 change to { .name = "LCD_D11", .id = PINID_LCD_D11, /* PHY reset pin*/ .fun = PIN_GPIO,      .voltage    = PAD_3_3V,      .strength = PAD_8MA,      .output     = 0, },      and replace all "PINID_ENET0_RX_CLK" in mx28evk_pins.c by "PINID_LCD_D11"      To prevent any possible interrupt, we also disable all LCD pins in both mx28_pins.h and mx28evk_pins.c since we don't have LCD.      Any comment/suggestion is highly appreciate! BR, TF

  IMX6 S/DL for consumer has both PXP and IPU. Automotive and Industrial versions doesn't have PXP. As IMX6 also has IPU, the Linux framebuffer driver uses IPU and not PXP. Note : “pxp_v4l2_test.out” from unit_tests was made for processors (i.MX6 SL), that have only PXP and its framebuffer driver applies PXP to accelerate image processing. “pxp_v4l2_test.out” should not be used with i.MX6 S/DL. To test PXP device with i.MX6 S/DL users have to try “pxp_test.out”.

One chunk of the file system for the Linux Image i.MX 6Dual/6Quad Power Consumption Measurement Linux Image

Hi all, Most of IoT customers request to enable/demo i.MX EVK with FSL Zigbee solution. In default i.MX Linux/Android BSP, Zigbee function is not enabled. Here we make a lighting demo setup through i.MX6Q SabreSD, KW20 USB dongle and Philips Hue light. KW20 is configured as Zigbee coordinator, connected with USB OTG in i.MX6Q, then i.MX6Q can issue On/Off, brightness and color control commands through KW20 to toggle Philips Hue light directly. Please find the attachment for details. Best regards, Carl

The i.MX 6 D/Q L3.035_1.0.2 patch release is now available on the www.freescale.com ·         Files available # Name Description 1 L3.0.35_1.0.2_LDO_PATCH This patch release is based on the i.MX 6Dual/6Quad Linux   12.09.01 release. The purpose of this patch release is to manage the LDO and   PMIC ramp-up time correctly.

Computer On Module • Processor Freescale i.MX 6Quad, 1GHz • RAM 1GB DDR3 SDRAM 64-bit • ROM 4GB NAND Flash UP to 16GB • ROM 2M SPI Nor Flash ! • Power supply Single 5V • Size 40mm SO-DIMM • Temp.-Range          0 to + 95C (Consumer)         -20 to + 105C (Extended Consumer)         -40 to +105C (Industrial)         -40 to + 125C (Automotive) Key Features • 10/100Mbps Ethernet • One High Speed USB 2.0 ports • Full HD LCD controller, 24bpp • OpenGL ES 2.0 and OpenVG 1.1 hardware accelerators • Multi-format HD 1080p60 video decoder and 1080p30 encoder hardware engine • Two Camera Interfaces • NEON MPE coprocessor — SIMD Media Processing Architecture — dual, single-precision floating point execute pipeline • Unified 1MB L2 cache • Several interfaces: 5x UART, 2x SDIO, 1x SSI/AC97/I2S, 3x I2C, 2xCSPI • 3.3V I/O • 2x Controller Area Network (FlexCAN) • PCIe 2.0 (1-lane) OS Support     • Linux 3.0     • Android 4.2 Application:Media Tablet,Education Tablet PC,EBook,Automotive Infotainment,Aviation Infotainment,HMI,Portable Medical Instruments,IPTV,IP Phone,Smart Energy Systems,Intelligent industrial control systems For more information, please see Attachment We can provide a complete solution

INTRODUCTION REQUIREMENTS CREATE A NEW PROJECT GPU EXAMPLE GSTREAMER EXAMPLE 1. INTRODUCTION:      The below steps show how to create different application examples using Elipse IDE. 2. REQUIREMENTS:      A fully working image and meta-toolchain generated in Yocto . You can follow the  next training: Yocto Training - HOME      Install and configure the Yocto Eclipse Plug-in. For more details about this requirement please refer to Setting up the Eclipse IDE for Yocto Application Development         To demonstrate the steps, L3.14.28  BSP, fsl-image-qt5 image and i.MX6Q SABRE-SDP board were used. 3. CREATE A NEW PROJECT      Follow the section Creating a Hello World Project of this document Setting up the Eclipse IDE for Yocto Application Development 4. GPU EXAMPLE           For this project we use the source code found in the fsl-gpu-sdk that can be downloaded from:      https://www.freescale.com/webapp/Download?colCode=IMX6_GPU_SDK&location=null&Parent_nodeId=1337637154535695831062&Parent…      Follow section 3 and create a new project named gputest.      From the IMX6_GPU_SDK choose one of the examples of GLES2.0 folder. In this case the 01_SimpleTriangle is chosen.      Copy the .c and .h files to the src directory of the gputest project. The Project Explorer window should look like this:              Add the needed files and libraries to compile and link in the Makefile.am file found in the ´src´ folder. The Makefile.am file should have the below content:          bin_PROGRAMS = gputest          gputest_SOURCES = gputest.c fsl_egl.c fslutil.c          AM_CFLAGS = @gputest_CFLAGS@          AM_LDFLAGS = @gputest_LIBS@ -lstdc++ -lm -lGLESv2 -lEGL -lX11 -ldl          CLEANFILES = *~ ​    Add the PATH to CFLAGS where the compiler will look for the headers at Project->Properties->Autotools->configure:           In this project there is no need to add extra PATHs for the headers. Apply the changes by clicking on Reconfigure Project. Build the project To test the file you can send the executable to the board with:           $ scp gputest root@<board_ip>:/home/root      $./gputest      You should get the next output in the display: 5. GSTREAMER EXAMPLE      For this project we use the source code found at Basic tutorial 1: Hello world! - GStreamer SDK documentation - GStreamer SDK documentation    Follow section 3 and create a new project named Gstreamer.    Copy the code of the basic tutorial to your Gstreamer.c file.    Add the needed files and libraries to compile and link in the Makefile.am file found in the ´src´ folder. The Makefile.am file should have the below content:                           bin_PROGRAMS = Gstreamer      Gstreamer_SOURCES = Gstreamer.c      AM_CFLAGS = @Gstreamer_CFLAGS@      AM_LDFLAGS = @Gstreamer_LIBS@ -lstdc++  -lVDK -lm -lGLESv2 -lGAL -lEGL  -ldl -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2 -lglib-2.0      CLEANFILES = *~         ​    Add the PATH to CFLAGS where the compiler will look for the headers at Project->Properties->Autotools->configure:           For this example the next lines are added             -I${Sysroot}/usr/include/gstreamer-1.0        -I${Sysroot}/usr/include/glib-2.0        -I${Sysroot}/usr/include/libxml2        -I${Sysroot}/usr/lib/glib-2.0/include      Apply the changes by clicking on Reconfigure Project. Build the project To test the file you can send the executable to the board with:           $ scp Gstreamer root@<board_ip>:/home/root To execute the application on the board:      $./Gstreamer The board should have internet access and the application should play the video found at http://docs.gstreamer.com/media/sintel_trailer-480p.webm

Join FSL-community-bsp project: https://lists.yoctoproject.org/listinfo/meta-freescale In order to test Yocto Project for i.MX6 or any other supported board please follow the instructions pointed by FSL Community BSP. In order to download the source code, please follow this instructions FSL Community BSP. With the downloaded source code, you can follow the steps from this training: Yocto Training - HOME If you face a problem, please, send an email to https://lists.yoctoproject.org/listinfo/meta-freescale This page made sense when there was not other tutorial to point people on how to download and build the very first image using Yocto Project tools for i.MX family boards. Today, FSL Community BSP has become a complete environment with its own landing page (FSL Community BSP) and a collaborative community around meta-freescale mailing list. I encourage you to register in meta-freescale mailing list. I configured this document to be closed for new comments. In case of any issue or bug, please, send an email to meta-freescale.

HDMI Dongle SW: The attachment is an HDMI dongle patch based on R13.4 GA. The patches include r13.4-ga-add-on-patches. You can patch it after applying R13.4 GA patch such as add-on patches. You can run script to revb_dongle_patch_install.sh to apply these patches. How to apply the hdmidongle_REVB_R13.4_patch-20121115.tgz: 1. Suppose your android source top is ~/myandroid 2. tar zfvx hdmidongle_REVB_R13.4_patch-20121115.tgz -C ~/ 3. copy revb_dongle_patch_install.sh to ~/ 4. cd hdmidongle_REVB_R13.4_patch 5. ~/revb_dongle_patch_install.sh 6. The  revb_dongle_patch_install.sh will take ~/myandroid as default directory to do patch 7. If your android source tree top is not ~/myandroid. For example, ~/myandroid_ICS, please run ~/revb_dongle_patch_install.sh ~/myandroid_ICS   The following is the release notes for  hdmidongle_REVB_R13.4_patch-20130118.tgz 1. New features:    a. uboot fastboot    b. ldo bypass    c. ntfs support    d. bluetooth A2DP   2. Bug fix    a. WifiDirect connect issue    b. realtek throughput issue with TPLink AP   3. File list:    README.TXT                                      --- this file    0001-uboot_fastboot.patch                       --- uboot fastboot  patch    0002-LDOBYPASS.patch                            --- enable ldo bypass  patch    0003-WifiDirect.patch                           --- wifi direct connect patch    0004-ntfs_support.patch                         --- ntfs support patch    0005-BT_enable.patch                            --- enable bluetooth A2DP    0006-1G_boot_stable.patch                       --- make 1G bootup stable    ntfs-3g.tar.gz                                  --- open source ntfs-3g for ntfs support    rtl8192ce_v4.0.0_6239.20121226_TPIOT1.tgz       --- realtek new driver for TPLink AP throughput issue    MD5SUM.TXT                                      --- md5 check sum   4. Patch guide    Please run md5sum -c MD5SUM.TXT first to confirm all the files received are ok.    All these patches are based on the patch release hdmidongle_REVB_R13.4_patch-20121115.tgz    You need to do as following: R13.4 GA--->patch hdmidongle_REVB_R13.4_patch-20121115.tgz --> patch hdmidongle_REVB_R13.4_patch-20130118.tgz    Supposed the ~/myandroid is your top directory of the android source tree.    Please run the following command to apply the patches .    $tar zfvx hdmidongle_REVB_R13.4_patch-20130118.tgz -C ~/    $cd ~/myandroid    $git apply  ~/hdmidongle_REVB_R13.4_patch-20130118/0001-uboot_fastboot.patch --verbose    $git apply  ~/hdmidongle_REVB_R13.4_patch-20130118/0002-LDOBYPASS.patch --verbose    $git apply  ~/hdmidongle_REVB_R13.4_patch-20130118/0003-WifiDirect.patch --verbose    $git apply  ~/hdmidongle_REVB_R13.4_patch-20130118/0004-ntfs_support.patch --verbose    $git apply  ~/hdmidongle_REVB_R13.4_patch-20130118/0005-BT_enable.patch --verbose    $git apply  ~/hdmidongle_REVB_R13.4_patch-20130118/0006-1G_boot_stable.patch --verbose    $rm -rf kernel_imx/drivers/net/wireless/rtl8192ce    $tar zfvx ~/hdmidongle_REVB_R13.4_patch-20130118/rtl8192ce_v4.0.0_6239.20121226_TPIOT1.tgz    $tar zfvx ~/hdmidongle_REVB_R13.4_patch-20130118/ntfs-3g.tar.gz -C external   5. Build and run     new patch 0007-battery_always_full.patch:   Some games check the battery capacity to determine, it could run or not. But on the hdmi dongle we have no real battery, it makes some games can not run on the hdmi dongle.  We enable the fake battery let the andorid feel it has battery and it is 100% full. 1. Please use this patch after patch hdmidongle_REVB_R13.4_patch-20130118.tgz 2. suppose your android top directory is ~/myandroid and you put he 0007-battery_always_full.patch in your home directory ~ 3. cd ~/myandroid 4. git apply --verbose ~/0007-battery_always_full.patch 5. please rebuild bootimage and run   patch   0008-boot_unlock_screen.patch: When bootup, it goes into desktop rather than screen locker.   1. suppose your android top directory is ~/myandroid and you put the 0008-boot_unlock_screen.patch in your home directory ~ 2. cd ~/myandroid 3. git apply --verbose ~/0008-boot_unlock_screen.patch 4. please rebuild systemtimage and run 2. cd ~/myandroid 3. git apply --verbose ~/0008-boot_unlock_screen.patch patch 0009-uboot-enable-mmu-fix.patch: This patch is for some issue in mmu enable. It will improve all the modules in uboot.   1. suppose your android top directory is ~/myandroid and you put the 0009-uboot-enable-mmu-fix.patch in your home directory ~ 2. cd ~/myandroid 3. git apply --verbose ~/0009-uboot-enable-mmu-fix.patch 4. please rebuild uboot  and rub     patch tarball   hdmidongle_REVB_R13.4_patch-20130123.tgz:   hdmidongle_REVB_R13.4_patch-20130123.tgz contains 0007-battery_always_full.patch  0008-boot_unlock_screen.patch 0009-uboot-enable-mmu-fix.patch remove attached files here: 0007-battery_always_full.patch  0008-boot_unlock_screen.patch 0009-uboot-enable-mmu-fix.patch     Remove hdmidongle_REVB_R13.4_patch-20130123.tgz, hdmidongle_REVB_R13.4_patch-20130118.tgz and upload hdmidongle_REVB_R13.4_patch-20130124.tgz   hdmidongle_REVB_R13.4_patch-20130124.tgz  contains all patches in hdmidongle_REVB_R13.4_patch-20130123.tgz, hdmidongle_REVB_R13.4_patch-20130118.tgz. Please use the  hdmidongle_REVB_R13.4_patch-20130124.tgz.   hdmidongle_REVB_R13.4_patch-20130131.tgz: Besides all the patches released before. Three more patches are added in this patch tar ball.     0010-boot_disable_screenlocker.patch                     --- For fix  0008-boot_unlock_screen.patch 0011-wm8326-DC_CONTROL_RATE.patch                        --- Change the wm8326 pmic rate to immediate voltage change 0012-Added-default-video-mode-check-make-sur.patch       --- Video mode check   hdmidongle_REVB_R13.4_patch-20130201.tgz:   Just change the readme  to place emphasis on   the 0006-1G_boot_stable.patch reverse   Reverse patch 0008-boot_unlock_screen.patch and 0006-1G_boot_stable.patch   0008-boot_unlock_screen.patch: it has some problem but doesn't do any harm to the hdmi dongle.                                                  Please use 0010-boot_disable_screenlocker.patch, instead. 0006-1G_boot_stable.patch:  The patch take more cpu delay to adapt the pmic, we change the pmic setting                                             in  0010-boot_disable_screenlocker.patch. This patch is no needed. And it will lower                                            the performance. Please reverse it.                                            cd ~/myandroid                                            git apply --verbose ~/0006-1G_boot_stable.patch                                                                                           hdmidongle_REVB_R13.4_patch-20130221.tgz: There are three important fixes include in this release. They make the dongle stable. 1. lowmem killer issue fix 2. Update realtek wifi driver to fix the soft ap issue 3. Wifi p2p framework fix to resovle wifi direct only one side work issue   Please read the README.TXT for detail and the other changes.   hdmidongle_REVB_R13.4_patch-20130308.tgz: This patch tar ball include all the patches in hdmidongle_REVB_R13.4_patch-20130221.tgz. Besides, it has a new patches 0020-DL_WifiDirect_Concunrrent_crash_fix.patch to fix the crash issue on DL board.   HDMI Dongle HW:   HDMI Dongle schematic, pcb, gerber and BOM have been attached, the detailed hardware feature has been list below:   Android 4.x HDMI Dongle SPECIFICATION Core Configure Operating System Android 4.x Operating System Based on Micro-PC Platform CPU Processor Freescale i.MX6x DualLite/Quad Core DRAM Storage DDR3 1GigaByte Size, Data rate 1066MT/s Flash Storage 4GigaByte NAND flash ROM Power System Power Supply DC JACK / Micro USB : 5V/2A LED Status Green: Power ON; Red: System Run Socket/Connector MicroSD Socket SDXC Support, Up to 32GB size USB HOST 2.0 USB 2.0 HOST Support USB OTG 2.0 USB 2.0 OTG Support Display/Audio HDMI Output HDMI TypeA Plug connector, 1080p@60Hz output Video Decoder Support Variety of Video Format: MPEG4/H.263/H.264/MJPEG/Xvid/VC-1/WMV/MPEG2/VP8... Audio Decoder Support Variety of Audio Format: MP3/AAC/LPCM/FLAC/AMR/AC3/WMA/Vorbis GPU Support GC2000 GPU core,2D/3D engine support,OpenGL support Wireless Network WiFi Network IEEE 802.11b/g/n,Up to 300Mbps,AP/P2P/Sta Mode Support Others Key Recovery key support RevB2     OTT TV BOX LINK: https://community.freescale.com/docs/DOC-94561   JB4.2 patches link : Patches for HDMI Dongle JB4.2.2_1.0.0-GA Release

i.MX6UL CSI (CMOS Sensor Interface) host port support BT.656(CCIR656) Interlace mode by hardware.  It can received  PAL(720pix X 576pix) and NTSC(720pix X 480 pix) format data from camera. This document introduce how to add this feature to Linux L3.14.38-ga and receive ADV7180 output. Software: yocto L3.14.38-ga. Hareware:  i.mx6ul-evk + ADV7180. ADV7180: PAL 720pix X576pix  ,  YUV4:2:2(UYVY) interlace output. LCD Display screen resolution:  800 X 480,  RGB565. 1) Note : For BT.656 mode,   parallel data port is  CSI_DATA[9:2], not CSI_DATA[13:6].    So,  "pinctrl_csi1" is the same as "ov5640" in "imx6ul-14x14-evk.dts": pinctrl_csi1: csi1grp {    fsl,pins = <     MX6UL_PAD_CSI_MCLK__CSI_MCLK  0x1b088     MX6UL_PAD_CSI_PIXCLK__CSI_PIXCLK 0x1b088     MX6UL_PAD_CSI_VSYNC__CSI_VSYNC  0x1b088     MX6UL_PAD_CSI_HSYNC__CSI_HSYNC  0x1b088     MX6UL_PAD_CSI_DATA00__CSI_DATA02 0x1b088     MX6UL_PAD_CSI_DATA01__CSI_DATA03 0x1b088     MX6UL_PAD_CSI_DATA02__CSI_DATA04 0x1b088     MX6UL_PAD_CSI_DATA03__CSI_DATA05 0x1b088     MX6UL_PAD_CSI_DATA04__CSI_DATA06 0x1b088     MX6UL_PAD_CSI_DATA05__CSI_DATA07 0x1b088     MX6UL_PAD_CSI_DATA06__CSI_DATA08 0x1b088     MX6UL_PAD_CSI_DATA07__CSI_DATA09 0x1b088     MX6UL_PAD_SNVS_TAMPER5__GPIO5_IO05 0x17059            /* configue csi_reset in this case */     MX6UL_PAD_SNVS_TAMPER6__GPIO5_IO06 0x17059            /* configure csi_en in this case*/    > 2) Applay the video driver patches as attatched.   $git am 0001-Enable-CSI-support-BT656-interlace-and-add-adv7180.patch 3) Build the kernel.    make imx_v7_defconfig    make -j4 4) Use  unit_tests "mx6s_v4l2_capture_uyvy.out" to test it,  source code is attached "mx6s_v4l2_capture.c": Copy "mx6s_v4l2_capture_uyvy.out" to target device FS  "/unit_tests" folder, and run it like this: ./mx6s_v4l2_capture_uyvy.out -m 0 -t 50 -d /dev/video0 5) In this "mx6s_v4l2_capture.c" demo test code,   it can utilize software algorithm to implement CSC(Color Space Conversion) from YUV4:2:2 to RGB. PXP module can realize hardware CSC and image resize. 6) How to use CSI + PXP to preview camera, refer to  unit_tests "imx-test" package "pxp_v4l2_test" - "pxp_v4l2_test.c"  . Run following command in Target device FS:   /unit_tests /*Record raw camera UYVY data(720x576) to save in test1.yuv */ ./mx6s_v4l2_capture_uyvy.out -m 0 -t 10 -of test1.yuv -d /dev/video0 /*Play this test1.yuv file(UYVY) by PXP engine and resize to full screan(800x480) */ ./pxp_v4l2_test.out -sx 800 -sy 480 -res 720:576 -dst 0:0:800:480 -a 100 -f 5 test1.yuv BLANK 7) The "pxp_v4l2_preview_test.c" demo attached  is  a TV-in demo for i.MX6ul which support ADV7180 camera preview by PXP in time. This demo implements scaling image frame to full screen, Alpha blending and Composite two image together function by PXP hardware.

It is based on L3.0.35_GA4.1.0 BSP.   In default Linux BSP, there are 3 kinds of de-interlace mode, motion =0,1,2 mode, motion mode 0 and 1 will use three fields for de-interlace, and motion mode 2 wil use one field for de-interlace, so the whole fps is 30. In this mode, for motion mode 0 and 1, field 1,2,3 was used for first VDI output frame of display; and field 3,4,5 was used for second VDI output frame of display; field 5,6,7 was used for third VDI output frame of display. One field data (such as 2,4,6) was used only once, so there is data lost.   After applied these patches, the VDI de-interlace output will be 60fps: for motion mode 0 and 1, field 0,1,2 was used for first VDI output frame of display; and field 1,2,3 was used for second VDI output frame of display; field 2,3,4 was used for third VDI output frame of display. So all field data will be used twice, there is no video data lost, the VDI quality was improved.   Kernel patches: 0001-Add-MEM-to-VDI-to-MEM-support-for-IPU.patch 0002-Add-IPU-IC-memcpy-support.patch 0003-IPU-VDI-support-switch-odd-and-even-field-in-motion-.patch 0004-IPU-VDI-correct-vdi-top-field-setting.patch   mxc_v4l2_tvin_imx6_vdi_60fps.zip: this is the test application sample code.   Test commands, parameter "-vd" means double fps VDI: ./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 720 -oh 480 -m 0 -vd  

Overview As more and more communication required between online and offline, the QR code is widely used in the mobile payment, mobile small apps, industry things identification and etc. The i.MX6UL/ULL has the IP of CSI and PXP for camera connection and image CSC/FLIP/ROTATION acceleration. A LCDIF IP is supporting the display, but no 3D IP support. This means this low power and low end AP is very suitable for the industry HMI segment, which does not require a cool 3D graphic display, but a simple and straightforward GUI for interaction. QR code scanner is one of the use cases in the industry segment, which more and more customer are focusing on. The i.MX6UL CPU freq of i.MX6UL is about 500Mhz, and it does not have GPU IP, so a lightweight GUI and window system is required. Here we recommend the QT with wayland backend (without X11), which would make the window system small and faster than traditional X11 UI. Why chose QT is because of it has open source version, rich components, platform independent, good performance for embedded system and strong development staffs like QtCreator for creating application. How to enable the QT development environment, check this: Enable QT developement for i.MX6UL (v2)  Here I made a QR code scanner demo based on QT5.6 + QZXing (QR/Bar code scan engine) running on the i.MX6UL EVK board with a UVC camera (at least 640x480 resolution is required) and 480x272px LCD. Source code is open here (License Apache2.0): https://github.com/muddog/QRScanner  Implementation To do camera preview and capture, you must think on the gstreamer first, which is easy use and has the acceleration pads which implemented by NXP for i.MX6UL. Yes, it's very easy for you to enable the preview in console like: $ gst-launch-1.0 v4l2src device=/dev/video1 ! video/x-raw,format=YUY2,width=640,height=320 ! imxvideoconvert_pxp ! video/x-raw,format=RGB16 ! waylandsink It works under the i.MX6UL EVK, with PXP IP to do color space convert from YUY2 -> RGB16 acceleration, also the potential scaling of the image. The CPU loading of this is about 20-30%, but if you use the component of "videoconvert" to replace the "imxvideoconvert_pxp", we do CSC and scale by CPU, then the loading would increase to 50-60%. The "/dev/video1" is the device node for UVC camera, it may different in your environment. So our target is clear, create such pipeline (with PXP acceleration) in the QT application, and use a appsink to get preview images, do simple "sink" to one QWidget by drawing this image on the widget surface for preview (say every 50ms for 20fps). Then in other thread, we fetch the preview buffer in a fixed frequency (like every 0.5s), then feed it into the ZXing engine to decode the strings inside this image. Here are the class created inside the source code: ScannerQWidgetSink It act as a gstreamer sink for preview rendering. Init the pipeline, create a timer with timeout every 50ms. In the timer handler, we use appsink to copy the camera buffer from gstreamer, and tell the ViewfinderWidget to do update (re-draw event). ViewfinderWidget This class inherit from the QWidget, which draw the preview buffer as a QImage onto it's own surface by using QPainter. The QImage is created at the very begining with the image buffer created by the ScannerQWidgetSink. Because QImage itself does not maintain the image buffer, so the buffer must be alive during it's usage. So we keep this buffer during the ScannerQWidgetSink life cycle, copy the appsink buffer from pipeline to it for preview. MainWindow Create main window, which does not have title bar and border. Start any animation for the red line scan bar. Create instance of DecoderThread and ScannerQWidgetSink. Setup and start them. DecoderThread A infinite loop, to wait for a available buffer released by the ScannerQWidgetSink every 0.5s. Copy the buffer data to it's own buffer (imgData) to avoid any change to the buffer by sink when doing decoding. Then feed this copy of buffer into ZXing engine to get decoder result. Then show on the QLabel. Screenshot under wayland (weston) desktop: Customize Camera instance Now I use the UVC camera which pluged in the USB host, which device node is /dev/video1. If you want to use CSI or other device, please change the construction parameters for ScannerQWidgetSink(): sink = new ScannerQWidgetSink(ui->widget, QString("v4l2src device=/dev/video1")); Image resolution captured and review Change the static member value of ScannerQWidgetSink class: uint ScannerQWidgetSink::CAPTURE_HEIGHT = 480; uint ScannerQWidgetSink::CAPTURE_WIDTH = 640; Preview fps and decoding frequency Find the "framerate=20/1" strings in the ScannerQWidgetSink::GstPipelineInit(), change to your fps. You also have to change the renderTimer start timeout value in the ::StartRender(). The decoding frequency is determined by renderCnt, which determine after how many preview frames showed to feed the decoder. Main window size It's fixed size of main window, you have to change the mainwindow.ui. It's easy to do in the QtCreate Designer. FAQ Why not use CSI camera in demo? Honestly, I do not have CSI camera module, it's also DNP when you buying the board on NXP.com. So a widely used UVC camera is preferred, it's also easy for you to scan QR code on your phone, your display panel etc. Why not use QCamera to do preview and capture? The QCamera class in the Qtmultimedia component uses the camerabin2 gstreamer plugin, which create a very long pipeline for different usage of viewfinder, image capture and video encoder. Camerabin2 would eat too much CPU and memory resource, take picture and recording are very very slow. The preview of 30fps would eat about 70-80% CPU loading even I hacked it using imxvideoconvert_pxp instread of software videoconvert. Finally I give up to implement the QRScanner based on QCamera. How to make sure only one instance of QT app is running? We can use QSharedMemory to create a share memory with a unique KEY. When second instance of app is started, it would check if the share memory with this KEY is created or not. If the shm is there, it means there's already one instance running, it has to exit(). But as the QT mentioned, the QSharedMemory can not be destroyed correctly when app crashed, this means we have to handle each terminate signal, and do delete by ourselves: static QSharedMemory *gShm = NULL; static void terminate(int signum) {    if (gShm) {       delete gShm;       gShm = NULL;    }    qDebug() << "Terminate with signal:" << signum;    exit(128 + signum); } int main(int argc, char *argv[]) {    QApplication a(argc, argv);    // Handle any further termination signals to ensure the    // QSharedMemory block is deleted even if the process crashes    signal(SIGHUP, terminate ); // 1    signal(SIGINT, terminate ); // 2    signal(SIGQUIT, terminate ); // 3    signal(SIGILL, terminate ); // 4    signal(SIGABRT, terminate ); // 6    signal(SIGFPE, terminate ); // 8    signal(SIGBUS, terminate ); // 10    signal(SIGSEGV, terminate ); // 11    signal(SIGSYS, terminate ); // 12    signal(SIGPIPE, terminate ); // 13    signal(SIGALRM, terminate ); // 14    signal(SIGTERM, terminate ); // 15    signal(SIGXCPU, terminate ); // 24    signal(SIGXFSZ, terminate ); // 25    gShm = new QSharedMemory("QRScannerNXP");    if (!gShm->create(4, QSharedMemory::ReadWrite)) {       delete gShm;       qDebug() << "Only allow one instance of QRScanner";       exit(0);    } .....

Hello everyone, this document will explain on how to use the UUU (Universal Update Utility) tool to flash Linux to an i.MX device (i.MX 8MM).   Requirements:   MX 8M Mini EVK UUU tool documentation, available here Linux Binary Demo Files - i.MX 8MMini EVK UUU 1.2.135 binary Serial console emulator (tera term or putty)   UUU auto script For this example is used the L4.14.98_2.0.0_ga demo image for the i.MX 8MM, inside the demo image we will find the auto script, which by default flash the eMMC of the board, the structure of the script is as following   /***********************************************************************************/ uuu_version 1.2.39   # This command will be run when i.MX6/7 i.MX8MM, i.MX8MQ SDP: boot -f imx-boot-imx8mmevk-sd.bin-flash_evk   # This command will be run when ROM support stream mode # i.MX8QXP, i.MX8QM SDPS: boot -f imx-boot-imx8mmevk-sd.bin-flash_evk   # These commands will be run when use SPL and will be skipped if no spl # SDPU will be deprecated. please use SDPV instead of SDPU # { SDPU: delay 1000 SDPU: write -f imx-boot-imx8mmevk-sd.bin-flash_evk -offset 0x57c00 SDPU: jump # }   # These commands will be run when use SPL and will be skipped if no spl # if (SPL support SDPV) # { SDPV: delay 1000 SDPV: write -f imx-boot-imx8mmevk-sd.bin-flash_evk -skipspl SDPV: jump # }   FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd mmc dev ${emmc_dev} FB: flash -raw2sparse all fsl-image-validation-imx-imx8mmevk.sdcard FB: flash bootloader imx-boot-imx8mmevk-sd.bin-flash_evk FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB: done /***********************************************************************************/    In short, when the board goes into serial downloader mode UUU downloads the bootloader to internal RAM, once done and uboot is running, through fastboot utility it will flash .sdcard file and uboot to the eMMC on the board.   More information about the protocol UUU use please refer to the UUU documentation (UUU.pdf) section 5 Supported protocol.   Running the tool In order to run the tool the binary of uuu needs to be downloaded, the binary files can be downloaded from the link above, uuu.exe is for Windows and uuu is for Linux. Once downloaded it can be placed inside the same file as the demo image, this so it is easy to run and cleaner on the shell commands.   Windows In windows OS the tool should be run using the Windows PowerShell in administrator mode, once open we will run the next commands: > .\uuu.exe uuu.auto   Linux >$ sudo ./uuu uuu.auto   The tool will start running and should be waiting for any i.MX device to be detected by host pc   Preparing the board For the board to be flashed it is needed to be in download mode, the switch configuration (i.MX 8MM EVK) is as following: SW1101  -  1010XXXXXX SW1102  -  XXXXXXXXX0   Connect a USB cable from the host pc which will run the tool to the USB OTG/TYPE C port, usually specified as download, on the board.   Connect a USB cable from the host to the OTG-to-UART for console output, usually specified as debug, on the board.   Open terminal emulator program with the following settings: Bits per second - 115200 Data bits - 8 Parity - None Stop bits - 1 Flow control - None   Power on the board, the download will start and the serial prompt will show the progress in uboot, wait until the tool show success.   Finally power off the board and change the switch configuration to boot from the eMMC, power on the board again and it should boot successfully!   Built in scripts One can use the built in scripts using the -b option to burn the bootloader  and the rootfs to the target flash, just type the command accordingly to the target flash device.    SD Write bootloader only: Windows: > .\uuu.exe -b sd <bootloader> Linux: $ sudo ./uuu -b sd <bootloader>   Replace <bootloader> for your .imx/.bin file, example using the i.MX 8MM for Windows and Linux respectively below. > .\uur.exe -b sd imx-boot-imx8mmevk-sd.bin-flash_evk $ sudo ./uuu -b sd imx-boot-imx8mmevk-sd.bin-flash_evk    Write whole Linux image Windows: > .\uuu.exe -b sd_all <bootloader> <rootfs>.sdcard Linux: $ sudo ./uuu -b sd_all <bootloader> <rootfs>.sdcard   Replace <bootloader> and <rootfs> for the name of your .imx/.bin and .sdcard files respectively, example using the i.MX 8MM below. > .\uuu.exe -b sd_all  imx-boot-imx8mmevk-sd.bin-flash_evk fsl-image-validation-imx-imx8mmevk.sdcard $ sudo ./uuu -b sd_all  imx-boot-imx8mmevk-sd.bin-flash_evk fsl-image-validation-imx-imx8mmevk.sdcard   eMMC Write bootloader only Windows: > .\uuu.exe -b emmc <bootloader> Linux: $ sudo ./uuu -b emmc <bootloader>   Example using i.MX 8MM > .\uuu.exe -b emmc imx-boot-imx8mmevk-sd.bin-flash_evk $ sudo ./uuu -b emmc imx-boot-imx8mmevk-sd.bin-flash_evk   Write whole Linux image Windows: > .\uuu.exe -b emmc_all <bootloader> <rootfs>.sdcard Linux: $ sudo ./uuu -b emmc_all <bootloader> <rootfs>.sdcard   Example using i.MX 8MM > .\uuu.exe -b emmc_all imx-boot-imx8mmevk-sd.bin-flash_evk fsl-image-validation-imx-imx8mmevk.sdcard $ sudo ./uuu -b emmc_all imx-boot-imx8mmevk-sd.bin-flash_evk fsl-image-validation-imx-imx8mmevk.sdcard   Hope this will helpful for everyone who is starting to use this flashing tool.