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.

I've done some research in Android boot optimization in the past months and have some getting. This page is for recording and sharing purpose only. It's target to provide some hints and directions for Android optimization. It's NOT a Freescale official document or patch release. The code/doc inside is only for reference. Background:      1. I've used SabreSD + Android KK 4.4.2 GA 1.0 as a reference platform.      2. I'm not doing some popular optimization way such as "hibernation", "suspend". I'm trying to "optimize" the boot process by re-arranging the boot process and make GUI related process run earlier and fine tune some boot code for running faster.      3. It's target to the Android IVI product. So, some features that will never be used in a IVI environment will be disabled or removed. Minor of them. I've come out with a patch package (latest is milestone 4 which is "_m4" in the version for short) and  a training document. I didn't find any confidential information from the patch or doc, so I'm open the sharing here. Updated on 2016/01/08 for new version (milestone m5): --------------------------------------------------------------------------------------- Change log against previous (milestone 4) version:      1. BSP base changed to Android KK 4.4.3 GA 2.0 which has a Linux kernel 3.10.53      2. Linux kernel and uboot optimization added. Kernel boot time (POR -> Android init entry) is less than 1.5s.      3. Some bug fixes.      4. Document updated accordingly. Total boot time tested on SabreSDP is about 8s.

This document intends to provide an overview of the i.MX8 Boot process and walk you through the process of creating a bootable image.   Boot process Coming out of a reset state the i.MX8 ROM (firmware that is stored in non-volatile memory of the i.MX8) reads the boot mode pins to determine the boot media/device that will be used. The i.MX8 can boot out of the following boot devices: eMMC/SD card FlexSPI Flash NAND Serial Download Protocol (USB) - This is used in manufacturing mode to bring-up a board by downloading an image to RAM and then flashing the on-board boot device.   The following table indicates the available options on a i.MX8QXP, the i.MX8 reads the boot mode pads and based in the configuration selects the desired boot device.   Once the boot device has been identified, ROM configures the boot media and attempts to read the image from a predefined address in the boot device, the following table shows the addresses where the image is expected to be on different boot devices. ROM loads data from the predefined addresses above (depending on the selected boot device) to the System Controller Unit (SCU) internal memory (tightly coupled memory) and parses it to find the image container. It can also boot by downloading an image through USB.   The image container has all the information needed to load all the images to the system, the first images that get loaded are the System Controller Firmware (SCFW) and Security Controller Firmware (SECO). The SECO FW needs to be loaded to refresh the watchdog timer (kick the dog) in the device, if the SECO FW is not loaded before the watchdog expires the device will reset, this usually happens when the device fails to fetch a valid image from the boot media.   Once the SCFW is loaded, ROM jumps to it and starts executing it. The SCFW then initializes the DDR and starts loading the images for the Cortex-M4 (optional) and the Cortex-A cores (optional). Once the images are loaded to their destination memory the SCFW boots the cores and sets them in their start address.   Creating a bootable image As a recap a bootable image is comprised of as minimum the System Controller Firmware and the Security Controller Firmware, optionally it can contain images for the Cortex M4 cores (if more than one available as in the case of QM devices) and Cortex A cores. It is possible to boot an image that only contains the SCFW and SECO FW, this could be useful in the first stages of porting the SCFW to the target board. It is also possible to boot an image with only the Cortex-M4 image (baremetal, FreeRTOS, AutoSAR...), only the Cortex-A image (U-boot or any bootloader) or both Cortex-M4 and Cortex-A images.   Mkimage tool The tool in charge of merging all these images and creating a bootable image for the i.MX8 is called mkimage, and can be obtained in source form in the following repository: https://github.com/nxp-imx/imx-mkimage mkimage is only supported in Linux So the first step is to clone the mkimage repository into our machine and checkout the latest branch, at the time of writing this document the latest release is 4.14.98_02: git clone https://source.codeaurora.org/external/imx/imx-mkimage cd imx-mkimage git checkout imx_4.14.98_2.0.0_ga‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ You should now be able to see the following folders:   Getting the SCFW Now that you have the mkimage tool you need some actual images to work with, if you are using a custom board you might need to port the SCFW and DDR configuration files for it (depending on how close it follows NXP's reference board).   The following is a compendium of documents on the basics of the SCFW and how to build it from scratch you can go there if you need help getting started with the porting process: https://community.nxp.com/docs/DOC-342654   If you are trying this on one of NXP's reference board you can use a pre-built SCFW binary, this can be obtained through the building process of the Yocto project or by downloading the porting kit and following these steps: Dowload SCFW binaries for release 4.14.98_02 here. chmod a+x imx-sc-firmware-1.2.bin ./imx-sc-firmware-1.2.bin‍‍‍‍‍‍‍‍‍‍ You will prompted to accept a license agreement and after that the binaries will be extracted:   Getting the SECO FW The Security Controller Firmware is only distributed in binary form and can be obtained from the NXP website. Download SECO FW binaries for release 4.14.98_02 here. chmod a+x firmware-imx-8.1.bin ./firmware-imx-8.1.bin‍‍‍‍‍‍‍‍‍‍ You will prompted to accept a license agreement and after that the binaries will be extracted: The SECO FW is under firmware/seco mx8qm-ahab-container.img -----> SECO FW for QM devices mx8qx-ahab-container.img ------> SECO FW for QXP devices   Getting an image for the Cortex-M4 The image for the Cortex-M4 can be generated using the SDK: https://mcuxpresso.nxp.com/en/select Just select the device you are working with and click Build MCUXpresso SDK, then you will prompted to select your IDE and host. Click on Download SDK and a compressed file containing the SDK will be dowloaded to your computer. Now you only need to uncompress the file and follow the steps in the getting started document to generate the image.  The getting started document includes steps to setup the toolchain and build an image for the M4. An M4 binary for the QM and QXP MEKs is also attached in this document, the example outputs a hello world message on the M4 terminal. Getting an image for the Cortex-A  The bootloader for the Cortex-A cores can be obtained through the Yocto BSP: The steps on generating the image for the 4.14.98 release can be found here: https://www.nxp.com/webapp/Download?colCode=imx-yocto-L4.14.98_2.0.0_ga    Some more details on the Yocto BSP can be found here: https://community.nxp.com/docs/DOC-94849   All the required binaries to create a bootable image for the Cortex-A cores on the MEK platforms are attached here.   Building a bootable image Once all the required pieces have been built/obtained, the bootable image can be created. The SCFW, SECO FW and respective Cortex-M4/A images need to be copied to the folder for the target device, i.e. if you are building an image for an i.MX8QX variant copy the binaries for that variant to its folder:   Here is a list of the required files to build a bootable image: scfw_tcm.bin -------------------------------------------- System Controller Firmware binary for the target board mx8qm(qx)-ahab-container.image ---------------- Security Controller Firmware for the QM or QXP variants bl31.bin --------------------------------------------------- ARM Trusted Firmware binary (Required if using u-boot with ATF) Only needed to create Cortex-A image with u-boot u-boot.bin ------------------------------------------------ U-boot binary (optional) m4_image ----------------------------------------------- M4 binary image, the QM variant has 2 Cortex-M4s and in this case to M4 binaries might be required (optional)   Once the required binaries have been copied to the desired variant folder (QXP or QM in this example), you are ready to start building some images.   All the targets for building different images are defined on the soc.mak file contained in each folder, this file contains different examples for creating a lot of the supported bootable images.   Creating a SCFW only image The target used to create a SCFW only image is flash_b0_scfw and it is defined under the soc.mak file of each variant. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_b0_scfw‍‍‍ To invoke this target for QM from the imx-mkimage directory: make SOC=iMX8QM flash_b0_scfw‍‍‍   The target definition for flash_b0_scfw can be seen below. Definition for QXP: flash_scfw flash_b0_scfw: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin ./$(MKIMG) -soc QX -rev B0 -dcd skip -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -out flash.bin ‍‍‍‍‍‍‍‍ Definition for QM: flash_b0_scfw: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -out flash.bin‍‍‍‍‍‍   Creating a Cortex-A image only The target used to create a Cortex-A image only is called flash_b0. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_b0 ‍‍‍ To invoke this target for QM from the imx-mkimage directory: make SOC=iMX8QM flash_b0‍ ‍‍‍ The target definition for flash_b0 can be seen below. Definition for QXP:   flash flash_b0: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin u-boot-atf.bin ./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -ap u-boot-atf.bin a35 0x80000000 -out flash.bin‍‍‍‍ Definition for QM:   flash_b0: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin u-boot-atf.bin ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -ap u-boot-atf.bin a53 0x80000000 -out flash.bin‍‍‍‍   Creating a Cortex-M4 image only The target used to create a Cortex-m4 image only is called flash_b0_cm4 on QXP and QM has different targets since there are two M4s available in the system. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_b0_cm4‍‍ To invoke this target for QM from the imx-mkimage directory: // For Cortex-M4_0 only make SOC=iMX8QM flash_b0‍_cm4‍_0 // For Cortex-M4_1 only make SOC=iMX8QM flash_b0‍_cm4‍_1 // For both Cortex-M4_0 and Cortex-M4_1 make SOC=iMX8QM flash_b0‍_m4‍s_tcm ‍‍‍‍‍‍‍‍‍‍‍‍‍   The target definition for flash_b0_cm4 can be seen below. Definition for QXP: flash_cm4 flash_b0_cm4: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin m4_image.bin ./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m4_image.bin 0 0x34FE0000 -out flash.bin‍‍‍‍ Definitions for QM: flash_b0_cm4_0: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin m4_image.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m4_image.bin 0 0x34FE0000 -out flash.bin flash_b0_cm4_1: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin m4_image.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m4_image.bin 1 0x38FE0000 -out flash.bin flash_b0_m4s_tcm: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin m40_tcm.bin m41_tcm.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m40_tcm.bin 0 0x34FE0000 -m4 m41_tcm.bin 1 0x38FE0000 -out flash.bin‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   The examples above are for M4 images booting from TCM, the M4 is capable of booting and executing from DDR and it is also able to XIP (execute in place) from SPI memory, for examples on this targets please look at the soc.mak for the desired variant. Creating an image with both Cortex-A and Cortex-M4 images The target used to create an image with software for all the cores is called flash_linux_m4. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_linux_m4‍ ‍ To invoke this target for QM from the imx-mkimage directory: make SOC=iMX8QM flash_linux_m4‍ ‍ The target definition for flash_linux_m4 can be seen below. Definition for QXP: flash_linux_m4: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin u-boot-atf.bin m4_image.bin ./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap u-boot-atf.bin a35 0x80000000 -p3 -m4 m4_image.bin 0 0x34FE0000 -out flash.bin‍‍   Definition for QM: flash_linux_m4: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin u-boot-atf.bin m4_0_image.bin m4_1_image.bin ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap u-boot-atf.bin a53 0x80000000 -p3 -m4 m4_0_image.bin 0 0x34FE0000 -p4 -m4 m4_1_image.bin 1 0x38FE0000 -out flash.bin‍‍     Flash image This will create a bootable image named flash.bin, to flash this image to the SD card and boot it on your MEK simply do: sudo dd if=iMX8QX/flash.bin of=/dev/mmcblkX bs=1k seek=32‍‍‍‍‍‍‍ If the desired target is a QM variant change if=iMX8QX... to if=iMX8QM. Then match your SD card device on "of=/dev/mmcblkX" you can see how your SD card enumerates by typing lsblk on your console before and after inserting your SD card. Remember from the information above that the i.MX8 will search for the image at 32k on the SD card, that is why we are flashing it there. For more examples please look at the soc.mak file, it includes examples for different boot media (NAND/QSPI) as well as different configurations and usage.   Additional resources Reference Manual Chapter 5 System Boot SCFW API and Port document imx-mkimage README System Controller Firmware 101 

We use PCIe to connect Intersil TW6865 chip for the surround view solution. This is the connection of PCIe to iMX6Q SabreSD board.   This is the block diagram of the connection: This is the 4 camera surround view:   Code base is L3.0.35_12.10.02 release. You can merge the patch file to the latest Freescale release. Please check the attach file for the patch code.   Note:  It is only a test version. The last code for L3.0.35 BSP: L3.0.35_GA4.1.0 Patches.7z The last code for L3.10.53 BSP: L3.10.53_TW686x_patch.7z Patch for L4.1.15 1.1.0 GA BSP: TW6865 driver for Linux L4.1.15_1.1.0-ga.7z

本文已经发表于中国集成电路杂志2014年第七期 For English version, please check following link. Freescale i.MX6 DRAM Port Application Guide-DDR3

In our reference design board the eMMC IC is Sandisk SDIN5C2-8 (4.41), and in i.MX6 Reference manual and datasheet we can known that it compatible with the MMC System Specification version 4.2/4.3/4.4, and details in datasheet declare that the uSDHC module is "fully compliant with the MMC command/response sets and Physical Layer as defined in the Multimedia Card System Specification, v4.2/4.3/4.4/4.41, including high-capacity (> 2 GB) HC MMC cards." EMMC4.4/4.41 of cause can work in our released BSP. But eMMC 4.4 has been discontinued and there is a possibility eMMC 4.41 will be discontinued.  And many of our customers will choose the eMMC 4.5 or high verison EMMC 5.0 and EMMC 5.1. And how to make the eMMC 4.5 , EMMC 5.0 and EMMC 5.1 work on i.MX6 ? The EMMC 4.5 or EMMC 5.0 /5.1 is backward-compatible with eMMC4.4, we can use it in eMMC4.4 mode to enable eMMC4.4 functionality and performance on the i.MX6 platform. Booting from a eMMC 4.5 device or high version is not supported,  boot ROM will fall back to the eMMC4.4 standard when a eMMC4.5 or high version capable device is detected. In BSP it is possible to bypass eMMC version checking, so that eMMC v4.5 or high version can work as eMMC v4.4 cards, no specific v4.5 feature supported. Only basic read/write operations are supported. In the source code we can change check value of card->ext_csd.rev. Take the eMMC 4.5 work as example, the current i.MX6 Linux BSP (L3.0.35_4.1.0) has added code to interface with an eMMC4.5 card to operate as an eMMC4.4 card. Change the value of card->ext_csd.rev 5 to 6, now eMMC 5.0 can work as an eMMC 4.4. The code drivers/mmc/core/mmc.c: And for the EMMC 5.0 and EMMC5.1, modify the kernel to support eMMC 5.0 and 5.1 extended CSD revisions, as shown below: /drivers/mmc/core/mmc.c : if (card->ext_csd.rev > 6) {              // The '6' has to be replaced with '7' For EMMC5.0                                                         //  The '6' has to be replaced with '8'  For EMMC5.1 pr_err("%s: unrecognised EXT_CSD revision %d\n", mmc_hostname(card->host), card->ext_csd.rev); err = -EINVAL; goto out;          } After modifying the code we need to rebuild the the firmware uImage used for MfgTool . Update the uImage in Mfgtool , and it can flash successful. Then the eMMC version 5.0 and 5.1 can be used with IMX6 based boards.

Application Note AN13872  Enabling SWUpdate on i.MX 6ULL, i.MX 8M Mini, and i.MX 93 is available on www.nxp.com    SWUpdate: Embedded Systems become more and more complex. Software for Embedded Systems have new features and fixes can be updated in a reliable way. Most of time, we need OTA(Over-The-Air) to upgrade the system. Like Android has its own update system. Linux also need an update system. SWUpdate project is thought to help to update an embedded system from a storage media or from network. However, it should be mainly considered as a framework, where further protocols or installers (in SWUpdate they are called handlers) can be easily added to the application. Mongoose daemon mode: Mongoose is a daemon mode of SWUpdate that provides a web server, web interface and web application. Mongoose is running on the target board(i.MX8MM EVK/i.MX8QXP MEK).Using Web browser to access it.   Suricatta daemon mode: Suricatta regularly polls a remote server for updates, downloads, and installs them. Thereafter, it reboots the system and reports the update status to the server. The screenshot is SWUpdate scuricatta working with hawkbit server.          

i.mx8x启动代码定制文档   目录 1    i.MX8X 板级开发包镜像结构... 2 2    创建 i.MX8QXP Linux 4.14.78_ga 板级开发包编译环境... 2 2.1  下载板级开发包... 2 2.2  创建yocto编译环境: 3 3    i.MX8X SC firmware. 11 3.1  SC firmware 目录结构... 11 3.2  SC firmware 启动流程... 12 3.3  SC firmware定制... 12 4    i.MX8X ATF. 18 5    FSL Uboot 定制... 20 5.1  FDT支持... 21 5.2  DM(driver model)支持... 27 5.3  Uboot目录 结构... 40 5.4  Uboot编译... 42 5.5  Uboot初始化流程... 43 5.6  uboot 定制... 53 5.7  uboot debug信息... 60

Here is a quick summary at booting Linux on the i.MX 6 sabre sd platform. This assumes you already have u-boot working on your platform as described here. This implies you already have a "working" Linux development environment with some ARM cross-compilers at hand (e.g. Debian + Emdebian). Get Linux sources We will use git to fetch Linux sources:   $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git This should create a linux directory with all the latest sources (after a while). Note that for more stability you might want to checkout a release instead of the latest version; to do so, list the available release tags with e.g. git tag -l 'v*', and git checkout <the-desired-tag>. Compile Assuming your cross compiler is called e.g. arm-linux-gnueabihf-gcc, you can compile by doing:   $ cd linux   $ export ARCH=arm   $ export CROSS_COMPILE=arm-linux-gnueabihf-   $ make imx_v6_v7_defconfig   $ make You then need to supply a LOADADDR (as joowonkim pointed out); do:   $ make uImage LOADADDR=0x10008000 This should create a number of files, including arch/arm/boot/uImage and arch/arm/boot/dts/imx6q-sabresd.dtb. Put on SD We need a proper FAT partition on the SD card, from which u-boot will be able to load the kernel and dtb. Also, we need to make sure we leave some space for u-boot starting from offset 1024B. Here is an example SD card layout:   +-----+------+--------+-----+----------------   | MBR |  ... | u-boot | ... | FAT partition ...   +-----+------+--------+-----+----------------   0     512    1024           1M (offsets in bytes) Here is an example SD card layout, as displayed by fdisk:   Device    Boot      Start         End      Blocks   Id  System   /dev/sdc1            2048     8054783     4026368    c  W95 FAT32 (LBA) (units: 512B sectors) You can format the FAT partition, mount, copy and unmount with:   $ mkfs.vfat /dev/<your-sd-card-first-partition>   $ mount /dev/<your-sd-card-first-partition> /mnt   $ cp arch/arm/boot/uImage arch/arm/boot/dts/imx6q-sabresd.dtb /mnt/   $ umount /mnt Your SD card first partition is typically something in /dev/sd<X>1 or /dev/mmcblk<X>p1. Note that you need write permissions on the SD card for the command to succeed, so you might need to su - as root, or use sudo, or do a chmod a+w as root on the SD card device node to grant permissions to users. Also, be sure to have u-boot on the SD card as explained in this post. Boot! That's it; u-boot already knows how to deal with your kernel by default so you are good to go. Insert the SD card into the SD card slot of your i.MX6 sabre sd platform, connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data and power up the platform. You should see u-boot messages:   U-Boot 2013.07-rc1-00014-g74771f4 (Jun 21 2013 - 16:27:39) u-boot should load the uImage and dtb from SD card and boot the kernel:   (...)   reading uImage   4215344 bytes read in 449 ms (9 MiB/s)   Booting from mmc ...   reading imx6q-sabresd.dtb   22818 bytes read in 22 ms (1012.7 KiB/s)   ## Booting kernel from Legacy Image at 12000000 ...      Image Name:   Linux-3.10.0-rc6      Image Type:   ARM Linux Kernel Image (uncompressed)      Data Size:    4215280 Bytes = 4 MiB      Load Address: 10008000      Entry Point:  10008000      Verifying Checksum ... OK   ## Flattened Device Tree blob at 11000000      Booting using the fdt blob at 0x11000000      Loading Kernel Image ... OK   OK      Using Device Tree in place at 11000000, end 11008921   Starting kernel ... The kernel should boot:   Booting Linux on physical CPU 0x0   Linux version 3.10.0-rc6 (vstehle@debian) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Fri Jun 21 18:09:26 CEST 2013 By default, the kernel will try to mount a root filesystem from the SD card second partition, as can be read in the default kernel command line:   (...)   Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw ...but we did not prepare a root filesystem partition, so after a number of boot messages the kernel will wait indefinitely:   (...)   mmc1: new SDHC card at address b368   (...)    mmcblk0: p1   (...)   Waiting for root device /dev/mmcblk1p2... We will see in another post how to prepare this root filesystem on the second SD card partition. Enjoy! See also... If you plan to compile Linux often, you might want to use a C compiler cache; see this post. Once you have Linux booting on your platform the next step is to give it a root filesystem. See this post for a Debian root filesystem, this post for a minimal busybox filesystem and this post for generating a root filesystem with buildroot.

i.MX6X_3.14.28_内核驱动代码与定制_devicetree_V1-20150918.doc

1. INTRODUCTION:      This document explains the general and basic steps to customize U-Boot for your own board. The board used in this document it is a working and stable board, the UDOO board (http://udoo.org). 2. REQUIREMENTS:     Install Yocto Project. See the Freescale Yocto Project User's Guide.     Generate and install the meta-toolchain. Follow this great training to do so  Yocto Training - HOME     Generate core-image-minimal of L3.14.28 of FSL BSP obtained from https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_iMX6QDLS_BUNDLE&appType=license&location=null&Parent_no…   3. ADDING i.MX6 CUSTOM BOARD SUPPORT FOR U-BOOT.     This section follows the steps found in Chapter 1 of the i.MX6 BSP Porting Guide of the Yocto documentation (L3.14.28) https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_LINUX_DOCS&location=null&fpsp=1&WT_TYPE=Supporting%20In… . Obtain U-Boot Source Code. After having installed Yocto project and generate a valid imx6 image, the U-Boot code should be located at <build directory>/tmp/work/<machine>-poky-linuxgnueabi/u-boot-imx/<version>/git. Prepare the Code. Choose a board as reference, this board should be as similar as possible to your custom board. Copy the board directory :                $ cp -R board/freescale/mx6sabresd/ board/freescale/mx6_udoo Copy the existing mx6sabresd.h configuration file as mx6_udoo.h                $ cp include/configs/mx6sabresd.h include/configs/mx6_udoo.h Create one entry in boards.cfg. Add a configuration entry in the boards.cfg file. Active  arm  armv7  mx6  freescale  mx6_udoo mx6_udoo mx6_udoo:IMX_CONFIG=board/freescale/mx6_udoo/mx6dl_4x_mt41j128.cfg,MX6Q,DEFAULT_FDT_FILE="imx6q-udoo.dtb",DDR_MB=1024 Rename <board>.c file. Rename board/freescale/mx6sabresd/mx6sabresd.c   to   board/freescale/mx6_udoo/mx6_udoo.c Modify Makefile. Change the line of COBJS to your custom board at  board/freescale/mx6_udoo/:      obj-y  := mx6sabresd.o Create a Shell script. Create a script to compile your new configuration. The script for this example is shown below and its name is build_u-boot.sh: #!/bin/bash export ARCH=arm export CROSS_COMPILE=/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi- make distclean; make mx6_udoo_config make Run the script to verify if the new configuration is correct.      $./build_u-boot.sh 4. CUSTOMIZING BOARD CODE      The fist part to customize is the DCD table. The DCD table contains configuration data for the DDR controller and memory. The DCD is read by the BootROM code in the iMX family and executed before copying the Uboot image to DDR. The DCD is built in the .cfg file pointed in the new entry we just added in the boards.cfg file (mx6dl_4x_mt41j128.cfg). Below you can find an example of the data that can be found in this file: /* * Device Configuration Data (DCD) * * Each entry must have the format: * Addr-type           Address        Value * * where: *      Addr-type register length (1,2 or 4 bytes) *      Address   absolute address of the register *      value     value to be stored in the register */ DATA 4, 0x020e0774, 0x000C0000 DATA 4, 0x020e0754, 0x00000000 DATA 4, 0x020e04ac, 0x00000030 DATA 4, 0x020e04b0, 0x00000030 DATA 4, 0x020e0464, 0x00000030 DATA 4, 0x020e0490, 0x00000030 DATA 4, 0x020e074c, 0x00000030 DATA 4, 0x020e0494, 0x00000030 DATA 4, 0x020e04a0, 0x00000000 The .cfg files used in this example were taken from an old U-Boot version (2009) non dtb capable. The used files are found in the attached .zip file. The specific initialization code for each board is found in mx6<customer board>.c in board/freescale/mx6<customer board>.c  in this case board/freescale/mx6_udoo/mx6_udoo.c file. Below it is explained the needed changes to route the serial console to the correct UART module, disable an external watchdog, configure and initialize the Ethernet PHY, change the lvds clock and configure the correct USDHC module.        U-Boot calls already defined functions from a function pointer array that takes care of the board initialization at different stages. For example the board_early_init_f() is called at an        early phase where we can disable the wdog and initialize the uart pins; board_init() and board_late_init() are called after board_early_init_f(). The UDOO board features an external watchdog that needs to be disabled with a GPIO, otherwise U-Boot resets after a few seconds:          The WDOG pins need to be configured and in the mx6_udoo.c file a global struct configuration for those pins is declared, as well as macros for each pin #define WDT_EN  IMX_GPIO_NR(5, 4) #define WDT_TRG IMX_GPIO_NR(3, 19) iomux_v3_cfg_t const wdog_pads[] = {         MX6_PAD_EIM_A24__GPIO5_IO04 | MUX_PAD_CTRL(NO_PAD_CTRL),         MX6_PAD_EIM_D19__GPIO3_IO19, }; static void setup_iomux_wdog(void) {         imx_iomux_v3_setup_multiple_pads(wdog_pads, ARRAY_SIZE(wdog_pads));         gpio_direction_output(WDT_TRG, 0);         gpio_direction_output(WDT_EN, 1);         gpio_direction_input(WDT_TRG); } This configuration needs to be called at some point of the board_early_init_f() int board_early_init_f(void) {         setup_iomux_wdog();         This way the board_early_init_f() calls the iomux for the external wdog and disables it. The UART console is routed to UART2, EIM_D26/UART2_TXD and EIM_D27/UART2_RXD. A different structure is defined with the pin configuration for the UART2.      iomux_v3_cfg_t const uart2_pads[] = {         MX6_PAD_EIM_D26__UART2_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),         MX6_PAD_EIM_D27__UART2_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL), }; This configuration should be called at early stage too. static void setup_iomux_uart(void) {         imx_iomux_v3_setup_multiple_pads(uart2_pads, ARRAY_SIZE(uart2_pads)); } int board_early_init_f(void) {         setup_iomux_wdog();         setup_iomux_uart(); Also the UART BASE register has to be defined as well as the console device. This is defined in the include/configs/mx6_udoo.h file. #define CONFIG_MXC_UART_BASE   UART2_BASE #define CONFIG_CONSOLE_DEV      "ttymxc1" The UDOO board features only one micro SD slot to boot and U-Boot environment storage. It uses only 4 bits and it has to be configured too. In the include/configs/mx6_udoo.h file the USDHC module has to be defined and the MMC environment device. #define CONFIG_SYS_FSL_USDHC_NUM   3 #define CONFIG_SYS_MMC_ENV_DEV       0     /* SDHC3 */          The USDHC3 pin configuration has to be defined:      iomux_v3_cfg_t const usdhc3_pads[] = {         MX6_PAD_SD3_CLK__SD3_CLK   | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_CMD__SD3_CMD   | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_NANDF_D0__GPIO2_IO00    | MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */ }; struct fsl_esdhc_cfg usdhc_cfg[1] = {         {USDHC3_BASE_ADDR, 0, 4}, }; This must be called and configured from the board_mmc_init() function: int board_mmc_init(bd_t *bis) {         s32 status = 0;         imx_iomux_v3_setup_multiple_pads(         usdhc3_pads, ARRAY_SIZE(usdhc3_pads));         usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);                 status |= fsl_esdhc_initialize(bis, &usdhc_cfg[0]);         return status; } The Ethernet PHY is configured in the board_eth_init() function. This function should initialize the pins for the external ethernet phy, mdio and phy configuration.  Just a piece of code is shown below: iomux_v3_cfg_t const enet_pads1[] = {         MX6_PAD_ENET_MDIO__ENET_MDIO            | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_ENET_MDC__ENET_MDC              | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TXC__RGMII_TXC       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD0__RGMII_TD0       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD1__RGMII_TD1       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD2__RGMII_TD2       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD3__RGMII_TD3       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL      | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_ENET_REF_CLK__ENET_TX_CLK       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RXC__RGMII_RXC       | MUX_PAD_CTRL(ENET_PAD_CTRL),         /* RGMII reset */         MX6_PAD_EIM_D23__GPIO3_IO23              | MUX_PAD_CTRL(NO_PAD_CTRL),         /* alimentazione ethernet*/         MX6_PAD_EIM_EB3__GPIO2_IO31              | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 32 - 1 - (MODE0) all */         MX6_PAD_RGMII_RD0__GPIO6_IO25            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 31 - 1 - (MODE1) all */         MX6_PAD_RGMII_RD1__GPIO6_IO27            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 28 - 1 - (MODE2) all */         MX6_PAD_RGMII_RD2__GPIO6_IO28            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 27 - 1 - (MODE3) all */         MX6_PAD_RGMII_RD3__GPIO6_IO29            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 33 - 1 - (CLK125_EN) 125Mhz clockout enabled */         MX6_PAD_RGMII_RX_CTL__GPIO6_IO24         | MUX_PAD_CTRL(NO_PAD_CTRL), }; static iomux_v3_cfg_t const enet_pads2[] = {         MX6_PAD_RGMII_RD0__RGMII_RD0       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RD1__RGMII_RD1       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RD2__RGMII_RD2       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RD3__RGMII_RD3       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RX_CTL__RGMII_RX_CTL      | MUX_PAD_CTRL(ENET_PAD_CTRL), }; static void setup_iomux_enet(void) {         imx_iomux_v3_setup_multiple_pads(enet_pads1, ARRAY_SIZE(enet_pads1));         udelay(20);         gpio_direction_output(IMX_GPIO_NR(2, 31), 1); /* Power on enet */         gpio_direction_output(IMX_GPIO_NR(3, 23), 0); /* assert PHY rst */         gpio_direction_output(IMX_GPIO_NR(6, 24), 1);         gpio_direction_output(IMX_GPIO_NR(6, 25), 1);         gpio_direction_output(IMX_GPIO_NR(6, 27), 1);         gpio_direction_output(IMX_GPIO_NR(6, 28), 1);         gpio_direction_output(IMX_GPIO_NR(6, 29), 1);         udelay(1000);         gpio_set_value(IMX_GPIO_NR(3, 23), 1); /* deassert PHY rst */         /* Need delay 100ms to exit from reset. */         udelay(1000 * 100);         gpio_free(IMX_GPIO_NR(6, 24));         gpio_free(IMX_GPIO_NR(6, 25));         gpio_free(IMX_GPIO_NR(6, 27));         gpio_free(IMX_GPIO_NR(6, 28));         gpio_free(IMX_GPIO_NR(6, 29));         imx_iomux_v3_setup_multiple_pads(enet_pads2, ARRAY_SIZE(enet_pads2)); }           Let's notice that the external PHY is not the same as the SABRESD AR8031. The UDOO features the MICREL KSZ9031 PHY. The latter needs to be defined and the former undefined in the include/configs/mx6_udoo.h file. #undef  CONFIG_PHY_ATHEROS #define CONFIG_PHY_MICREL #define CONFIG_PHY_MICREL_KSZ9031 Besides the PHY address has to be changed. #define CONFIG_FEC_MXC_PHYADDR  6 At this point, the serial console, SD card saving arguments and ethernet should be working. The last point is to configure the LVDS display. The LVDS display of the UDOO board is connected in the same port as the SABRE-SD board, but the operation frequency is different and it has to be modified to work at ~ 33.26MHz for the 7 inches LVDS display.      The mx6_udoo.c file contains a setup_display function that configures the LDB module. This functions is called in the board_early_init_f(). With the current clock configuration is not possible to get  the 33.2MHz for the LVDS and a different clock source for the LDB module must be chosen. The backlight and lvds power signals must be on.           The current configuration uses the mmdc_ch1 clock and to get closer to 33.26MHz the PLL2_PFD0 is chosen.        gpio_direction_output(IMX_GPIO_NR(1, 2), 1); /* LVDS power On */         gpio_direction_output(IMX_GPIO_NR(1, 4), 1); /* LVDS backlight On */         imx_iomux_v3_setup_multiple_pads(di0_pads, ARRAY_SIZE(di0_pads));         enable_ipu_clock();         imx_setup_hdmi();         /* Turn on4LDB0, LDB1, IPU,IPU DI0 clocks */         reg = readl(&mxc_ccm->CCGR3);         reg |=  MXC_CCM_CCGR3_LDB_DI0_MASK | MXC_CCM_CCGR3_LDB_DI1_MASK;         writel(reg, &mxc_ccm->CCGR3);         /* set LDB0, LDB1 clk select to 011/011 */         reg = readl(&mxc_ccm->cs2cdr);         reg &= ~(MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_MASK                  | MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_MASK);         reg |= (1 << MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_OFFSET)               | (1 << MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_OFFSET);         writel(reg, &mxc_ccm->cs2cdr); With this changes you can compile the new U-Boot image with ./build_u-boot.sh and then just copy the uboot.imx file to your sd: # sudo cp if=uboot.imx of=/dev/sdX bs=512 seek= 2 && sync 5. TESTING YOUR CHANGES Inser the sd with the U-Boot image to micro sd slot and power up the board. You should get the U-Boot serial console like shown below. In the console you can test the ethernet and phy configuration with the PING command: I hope you find these basic steps useful for different boards.

This is a HW design checklist for customer's reference. Please read and fill it in carefully before requesting a schematic review. Rev3.1 @2016.10.19 -- 1. Add i.MX6DQP related contents.

Some questions arise when we think about the Android boot sequence. What is the Zygote, init.rc, what is the difference between the linux kernel and the android linux kernel?. This document is intended to explain how the booting process runs. Consider the following graph: Step 1: Power On and System Startup When we press the power button, the Boot ROM code starts executing from a pre-defined location which is hardwired in ROM. It loads the Bootloader into RAM and starts executing. Step 2: Bootloader The bootloader is a small program which runs before Android does. This is NOT part of the Android operating system. The bootloader is the place where manufacturer puts their locks and restrictions. The bootloader executes in two stages. In the first stage it detects external RAM and loads a program which helps in the second stage. In the second stage, the bootloader setups the network, memory, etc, which requires to run kernel. The bootloader is able to provide configuration parameters or inputs to the kernel for specific purposes. The bootloader can be found at: <android source>/bootable/bootloader/legacy/usbloader This legacy loader contains 2 important files: 1- Init.s :: Initializes stacks, zeros the BSS segments and  call_main() in main.c 2- Main.c :: Initializes hardware (clocks, board, keyboard, console) and creates linux tags. Step 3: Kernel The Android kernel starts in a similar way as the linux kernel.  As the kernel launches, is starts to setup cache, protected memory, scheduling and loads drivers. When the kernel finishes the system setup, it looks for “init” in the system files. What is the difference between the linux and android kernels?, here's a list of changes/addons that the Android Project made to the Linux kernel: Binder: It is an Android specific interprocess communication mechanism and remote method invocation system. ashmem:  "Android Shared Memory". It is a new shared memory allocator, similar to POSIX SHM but with a different behavior and sporting a simpler file-based API. pmem: "Process memory allocator": It is used to manage large (1-16+ MB) physically contigous regions of memory shared between userspace and kernel drivers. logger:  This is the kernel support for the logcat command. wakelocks: It is used for power management files. It holds the machine awake on a per-event basis until wakelock is released. oom handling: It kills processes as available memory becomes low. alarm manager: It lets user space tell the kernel when it would like to wake up. RAM_CONSOLE: Allows to save kernel printk messages to a buffer in RAM, so that after a kernel panic they can be viewed in the next kernel invocation. USB gadget driver for ADB yaffs2 flash filesystem Step 4: init process Init is the very first process, we can say it is a root process, or the grandfather of all processes. The init process has two responsibilities.      1- Mounts directories like /sys , /dev    or /proc      2- Runs init.rc script - The init process can be found at /init :: <android source>/system/core/init - Init.rc file can be found at :: <android source>/system/core/rootdir/ Android has specific format and rules for init.rc files. More information about this rules can be found in: What is inside the init.rc and what is it used for. At  this stage, you can finally see the Android logo in your screen. Step 5: Zygote and Dalvik In Java, we know that a separate Virtual Machine instance will popup in memory for separate per app, but in the case of Android, the VM should run as quick as possible for an app. But what happens if you have several apps thus launching several instances of the Dalvik (VM)?, it would consume an immense amount of memory. To overcome this problem, the Android OS has a system called “Zygote”.  The Zygote enables code sharing across the Dalvik VM, achieving a lower memory footprint and minimal startup time.  Zygote is a virtual machine process that starts at system boot. The Zygote preloads and initializes core library classes. The Zygote loading process: Load Zygote Init class: <android source>/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java registerZygoteSocket() :: It registers a server socket for zygote command connections. preloadClasses() :: Is a simple text file that contains a list of classes that need to be preloaded, you can find the file at <android source>/framework/base preloadResources()  :: Everything that is included in the android.R file will be loaded with this method (themes and layouts). At this time, you can see the boot animation. Step 6: System service After the above steps are completed,  Zygote launches the system services.  The Zygote forks a new process to launch the system services. Core services: Starting power manager Creating the Activity Manager Starting telephony registry Starting package manager Set activity manager service as system process Starting context manager Starting system contact providers Starting battery service Starting alarm manager Starting sensor service Starting window manager Starting Bluetooth service Starting mount service Other services: Starting status bar service Starting hardware service Starting NetStat service Starting connectivity service Starting Notification Manager Starting DeviceStorageMonitor service Starting Location Manager Starting Search Service Starting Clipboard Service Starting checkin service Starting Wallpaper service Starting Audio Service Starting HeadsetObserver Starting AdbSettingsObserver Now we have finally completed the booting process (system service are up and running in memory). Need to analyze the Android Bootup? The logcat ::  Use adb to get the booting process events from the logcat. ‘adb logcat –d –b events | grep “boot” ‘adb logcat –d | grep preload’ More information about ADB can be found here: Using ADB with your Sabre Board

1. User Case: Demo Architecture: Demo Description: A, B, C and Speaker all are i.MX6DQ SabreSD board and running Ubuntu system. A is media server which send out broadcast 30Mbps h264 video and audio stream and running iperf to send out tcp packets via best efforts lane to PC. B and C are clients to get video data only and play in screen.  Speaker is a client to receive audio data only and play to speaker. PC which install ubuntu system is used to received best efforts data from A. Demo Goal: Use Gstreamer playback 30Mbps streaming  "H264_AVC_1080p_30fps_27Mbps_mp3.avi", while running iperf TCP streaming under the following two case: 1. Running the non-CBS kernel 2. Enable the FIQ kernel Validate the Qav (Queue and Forwarding Protocol) which is developed by SW. 2. Resource: FIQ Patch: 0001-GIC-FIQ-EPIT-implement.patch 0002-set-EPIT-priority-to-highest.patch 0003-GIC-support-SMP-4-cores-of-FIQ.patch CBS &Shaper Patch: 0004-Implement-credit-base-shaper-alogrithim-to-schdule-A.patch 0005-enet-avb-CBS-SIRQ-rum-mode-pass-performance-stress-t.patch Others Patch: 0006-Fix-the-61883-sub-type-protocol-check.patch 0007-Add-hrtimer-for-the-sirq.-Talker-transmit-packets-nu.patch 0008-1.-Fix-memory-map-size-issue.patch 0009-Increase-BD-entries-to-reduce-the-full-times.patch 0010-Add-sys-interface-to-log-out-the-video-packet-number.patch 0011-Add-AVB-timestamp-support.patch 0012-GIC-support-SMP-4-cores-of-FIQ.patch Gstreamer UDPAVB Plug-in Library and Source: Library: udp/output/libgstudp.so Source: udp/* 3. Setup the Patch:       - Low level:  kernel enet driver implement CBS and traffic shaper:              1. Apply all the patches in the patch_whole.tar.gz in the attachment               2. Rebuild kernel 3.0.35: Enable "CONFIG_ENET_IMX6_AVB" to support AVB.                        Enable "CONFIG_RUN_IN_FIQ"  in kernel:            let CBS run in FIQ mode.                3. make uImage.                You can also use the uImage-avb-fig in the attachment directly.  Flash to the SD card use dd command, the user gudie refer to the  i.MX_6Dual6Quad SABRE_SD_Linux_User_Guide.pdf.                Note: the uImage_org_nonavb in the attachment is the kernel image without QAV and FIQ. - High level: use Gstreamer as the media input/output interface, encapsulation with IEEE1722 format:         Before the below action, you should already have seutp the Ubuntu Rootfs,  copied all the Freescale *.deb files that come alone with the Release BSP demo image package and copied all the MM codec *.deb files (IMX_MMCODEC_3.0.7.tar) that from Freescale offical website, the user gudie refer to the  i.MX_6Dual6Quad SABRE_SD_Linux_User_Guide.pdf. 1. Add gstreamer setup version as following: - gstreamer core version: 0.10.35 - gst-plugins-good version: 0.10.30 - gst-plugins-bad version: 0.10.11 2. Setup: - tar xvzf udp.tar.gz - cd gst-plugins-good-0.10.30 - ./configure - make - make install - cp ~/udp/* gst/udp/ - cd gst/udp - make - cp  libgstudp.so /usr/lib/gstreamer-0.10/ - gst-inspect | grep avb         //Check whether the avb plugin is installed successfully. If the three avb plugin is printed out in the terminal, the avb plugins are proved to install properly. 4. Run the Demo:       1.  Start the iperf server in PC linux machine by inputting " iperf -s -i 1&".              2.  Power on the A board, ensure the board can get the DHCP IP address, Start the iperf client on the demo board which sends outgoing Audio-Video streaming in the background. Input "iperf -c <iperf server ip> - t 6000&". If the connection is  successful, the iperf log should be able to be seen in the linux machine terminal.              3.  Power on the B and C board, inputting the following command to receive video data:            Run "./startRxVideoAVB.sh"  to start gstreamer video receive process on video display board       4.  Power on the speaker board, inputting the following command to receive audio data:             Run "./startRxAudioAVB.sh" to start gstream audio receive process on audio  playback board 5.  Inputting the following command to send video/audio data to client at the A board terminal windowns:                              Run "./startTxAVB.sh" to start the 1722 streaming traffic                                      (note: H264_AVC_1080p_30fps_27Mbps_mp3.avi located at current directory)               6.  Change to the kernel with QAV and follow the steps 1~5 above 5. Result: Without FIQ Qav,  video play at client B and C serious freeze. It takes 3 minutes to play 1min 40s h264 stream.  iperf speed over 80Mbps. With FIQ Qav, video play at client B and  C is smooth and same as without iperf in background. Iperf show speed is less than 70Mbps.  FIQ Qav correctly reserve necessary bandwidth to AV stream 6. Know issues Failed to request the IP from DHCP         [Solution]  For FIQ, after kernel up, you must run the command: echo 1 > /sys/devices/platform/imx_wfi_issue.0/enable   2.   Kernel is halted or crashed [Solution] In bootloader parameter, add 'nosmp' in bootargs_mmc.

On default i.MX6UL EVK board, it supports three boot device: SD Card boot in main board, micro-SD card boot in CPU board and QSPI-FLASH in CPU board. As we know, i.MX6UL supports NAND device boot and there are NAND device footprint in the EVK board. If customer wants to use NAND boot, there is something to rework in both hardware and software. Hardware Modification NAND device boot mode is conflict with micro-SD card and QSPI-FLASH device boot modes. 1. Remove U303 in CPU board and DO NOT insert micro-SD card into J301 2. Solder U302 NAND FLASH on EVK board Software Modification In Yocto-Linux BSP standard release, NAND device boot is not supported. We need add support in u-boot, linux DTB and MFGTool. 1. u-boot-imx modification and build Replace u-boot-imx/include/configs/mx6ul_14x14_evk.h with the same file in the attachment Copy mx6ul_14x14_evk_nand_defconfig in the attachment to u-boot-imx/configs/ Build the new u-boot.imx: make distclean; make mx6ul_14x14_evk_nand_defconfig;make Rename u-boot.imx to u-boot-imx6ulevk_nand.imx 2. Linux DTB modification and build Copy imx6ul-14x14-evk-gpmi-weim.dts in the attachment to kernel/arch/arm/boot/dts/ Build imx6ul-14x14-evk-gpmi-weim.dtb: make imx6ul-14x14-evk-gpmi-weim.dtb Rename imx6ul-14x14-evk-gpmi-weim.dtb to zImage-imx6ul-14x14-evk-gpmi-weim.dtb 3. MFGTOOL modification Copy mfgtool2-yocto-mx6ul-evk-nand.vbs in the attachment to MFGTOOL root direcory Copy u-boot-imx6ulevk_nand.imx and zImage-imx6ul-14x14-evk-gpmi-weim.dtb to MFGTOOL\Profiles\Linux\OS Firmware\firmware\ Copy u-boot-imx6ulevk_nand.imx and zImage-imx6ul-14x14-evk-gpmi-weim.dtb to MFGTOOL\Profiles\Linux\OS Firmware\files\ Congratulations!!!  You can burn NAND image to i.MX6UL-EVK board with mfgtool2-yocto-mx6ul-evk-nand.vbs script now!!

Note, the tools described in this page are deprecated and are no longer maintained.  For the latest maintained i.MX 6/7 series DDR tools, the user can find these here: i.MX 6/7 Series DDR Tool Release Hi All, DDR_Stress_Tester is a software application for fine tuning DDR parameters and verifying DDR performance on i.MX6 boards. It performs write leveling, DQS gating, read/write delay calibration on the target board to match the layout of the board and archive the best DDR performance. In addition, the stress test can help the user to verify the DDR performance on their boards.   The following are the features supported: • Support i.MX6Q, i.MX6D, i.MX6DL, iMX6S, i.MX6SL, and i.MX6SX DDR calibration. • Support DDR3 write leveling, DQS gating, Read/Write Delay auto-calibration. • Support LPDDR2 Read/Write Delay auto-calibration. • Support 16 bits, 32 bits, and 64 bits data bus. • Support fixed-mapping 2-channel LPDDR2. • Support DDR stress test between the frequency 135MHz and 672 MHz   If  USB OTG port is not available on customer board, please use the images in DDR_Stress_Tester_V1.0.3_UART1_for_SDboot&JTAG.zip. The bin files in the packages can be loaded by uboot and elf files are used by JTAG load.  Please note when the image is loaded by u-boot, the DDR is initialized by u-boot (reference flash_header.S).   To run ddr stress test from u-boot, CONFIG_SPLASH_SCREEN must be disabled in u-boot. Because when enter self refresh mode in ddr stress test, DRAM access will be blocked. If splash screen in u-boot is enabled, IPU will continuously access DRAM, so the system will hang up. If you have other DMA access in u-boot, it must be disabled.   If customer uses different RX/TX pin for UART, please contact FAE.   UART1 6DQ 6DL 6SL 6SX TX CSI0_DAT10/ALT3 CSI0_DAT10/ALT3 UART1_TXD/ALT0 GPIO1_IO04/ALT0 RX CSI0_DAT11/ALT3 CSI0_DAT11/ALT3 UART1_RXD/ALT0 GPIO1_IO05/ALT0   The commands to run ddr test in i.MX6Q uboot: U-Boot > fatload mmc 2:1 0x907000 ddr-stress-test-mx6dq.bin U-Boot > go 0x907000     For i.MX6Q/6D 4K interleaved LPDDR2, please use version v1.0.3.1. i.MX6 DDR Stress Test Tool V1.0.3.1 for LPDDR2 4K interleaved mode For i.MX6/i.MX7 DDR Stress Test Tool with GUI interface, please use version V2.x: i.MX6/7 DDR Stress Test Tool V2.10   History V1.0.3:  i.MX6SoloX is supported.

NFS and TFTP Boot 1  Introduction This document explains the required steps to boot Linux Kernel and mount a NFS on your target. 2 Requirements A functional Yocto environment (Images generated for your target). Your preferred target.  (SABRE-AI, SABRE-SD) 1 Ethernet Cable 1 Micro USB cable USB to Serial converter depending on your target features. 3 Yocto Folders When you develop your Linux kernel and Root File System with Yocto, different folders are created and each folder contains different information. {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/  This directory contains the output images, like Kernel, U-Boot and the File System in a tar file. This directory will be used to fetch the kernel and device tree blob file only. {YOCTO_BUILD_DIR}/tmp/sysroot/{TARGET}/  This folder contains all the development files used to generate our Yocto images. Here we can find all the dynamic libraries and headers used for development. This folder is used as parameter for cross-compilation. {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs This folder contains the uncompressed rootfs of our target. This folder will be used as entry in the host NFS server. 4 IP Address and Network Setup This section covers how to boot Linux that mounts the root file system (RFS) over the network. Remember that in this scenario, the RFS exists on the laptop hard drive, and the kernel that runs on the target board will mount the RFS over Ethernet. This setup is used for developing and debugging Linux applications. It allows for applications to be loaded and run without having to re-boot the kernel each time. First some packages on your host need to be installed: # apt-get install xinetd tftp tftpd isc-dhcp-server nfs-kernel-server portmap For development, it is best to have a static IP setup for the board and Linux environment. This way U-Boot options won’t change between reboots as you get a new IP address as you would using DHCP. 4.1 Linux Host Setup This section describes how to setup a static IP in your Linux host environment. This is not required but will allow the IP address of your virtual host system to remain unchanged. Because u-boot parameters use specific IP addresses, this step is recommended because u-boot parameters may need to be updated in the future to match your virtual IP address if it should ever change. You could take the existing IP address and make it static, but you would lose the Internet connection in your virtual machine. Instead we want to make use of the virtual environment and add a secondary Ethernet port that is tied to your wired Internet connection, while keeping the original Ethernet port which can use the wireless connection on your laptop. In the Linux virtual environment, type sudo ifconfig and note that you should have one Ethernet adapter (eth0). The other item listed (lo) is a virtual port for loopback mode. Shutdown the Linux virtual machine In VMware Player, go to Edit virtual machine settings. And add a Bridged Network Adapter, choosing only the wired Ethernet port. And click on OK.  See below for example: Start up the Linux VM. Open a terminal and type: sudo ifconfig You should have a new entry (eth1). This is the new Ethernet port you created in the virtual machine, and it is bridged to your wired Ethernet port. This is the port we want to make a static IP address. To set eth1 to a static IP, open /etc/nework/interfaces sudo gedit /etc/network/interfaces Add the following to set eth1 to your desired IP address. auto eth1 iface eth1 inet static address 192.168.0.100      <-- Your HOST IP netmask 255.255.255.0 gateway 192.168.0.1 Save the file Restart eth1 sudo ifdown eth1 sudo ifup eth1 4.2 Target Setup We need to setup 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.100 <-- This must be your Host IP address setenv ipaddr 192.168.1.102  <-- This must be your target IP addres setenv ip_dyn no The path where the rootfs is placed in our host has to be indicated in the U-Boot: setenv nfsroot /home/usuario/fsl-release-bsp/buildimx6q/tmp/work/imx6qsabresd-poky-linux-gnueabi/fsl-image-gui/1.0-r0/rootfs setenv image zImage setenv fdt_file uImage-imx6q-sabresd.dtb setenv netargs 'setenv bootargs console=${console},${baudrate} ${smp} root=/dev/nfs ip={ipaddr} nfsroot=${serverip}:${nfsroot},v3,tcp' 4.3 TFTP and NFS Configuration Now configure the Trivial File Transfer Protocol (TFTP) server and Networked File System (NFS) server. This is how U-Boot will download (via TFTP) the Linux kernel, and then the kernel will mount (via NFS) its root file system on the computer hard drive. 4.3.1 TFTP Setup Next setup the TFTP server. The following commands show that we are logged in as root (#). If you are not root ($) then precede each instruction with “sudo”. Edit /etc/xinetd.conf gedit /etc/xinetd.conf Add and save the following lines in the file service tftp { socket_type = dgram protocol = udp wait = yes user = root server = /usr/sbin/in.tftpd server_args = -s {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/  disable = no } Notice that {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/   has to be written as absolute path. Restart the xinetd service service xinetd restart Test that TFTP is working tftp localhost tftp> get {An Image found in the tftp folder} tftp> quit 4.3.2 NFS Setup Edit the /etc/exports file gedit /etc/exports Add the path where the rootfs is found in your host. {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs *(rw,no_root_squash)                                                                 NOTE:      {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs may work most of the times,        but it is recommended to untar the {IMAGE}.bz2 in an exported           folder keeping using sudoand keeping the chmod of each file.     3. Restart the NFS service sudo service portmap stop sudo service nfs-kernel-server stop sudo service portmap start sudo service nfs-kernel-server start 5 Host Final Configuration and Booting Linux over NFS In your host, under the images folder {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/ create the below links ln -s zImage_imx_v7_defconfig zImage      2. In U-boot type the below command:                run netboot After a pair of minutes you should get a Linux working system on your target.

This is a simple document  explaining the basics of creating a new layer within a Yocto BSP. We will be using the latest i.MX6 Linux BSP as reference, but the same logics apply to any Yocto Project BSP including the Community BSP. If you are new to Yocto it is recommended to go through the following very informative Training which is focused on the FSL Community BSP but covers the basics of Yocto step-by-step in a very clear and concise manner. Yocto Training - HOME Requirements - L4.1.15 BSP Release for the i.MX6 family of processors installed on the host. For more information on requirements for the Host please refer to the Yocto User’s Guide available as part of the Linux BSP Document Bundle (available on the link below) http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors/embedded-linux-for-i.mx-applications-processors:IMXLINUX?code=IMXLINUX -tree tool for the host, to see the directory format of the different layers. You may install it with the following command: sudo apt-get install tree - We will work with the bitbake environment so this needs to be initialized in our terminal. Introduction to layers in Yocto Layers in Yocto allow us to organize the long list of providers and to easily customize for our target hardware while reusing a lot of tools already available. It also makes it easy to distribute our customizable source code trough a unique layer. Once your environment is setup you can see the layers that compose the BSP using the command: bitbake-layers show-layers The layers that constitute out BSP will be displayed along with the path and priority of each. Layer Priority: Each layer has a priority, which is used by bitbake to decide which layer takes precedence if there are recipe files with the same name in multiple layers. A higher numeric value represents a higher priority. We can see that the poky and open embedded layers have a lower priority than those than the BSP and SDK layers as the later sit on top of the former. The general layout of a BSP is shown on the image below. If you would like to have a better look at the distinctive Layers that make up the Yocto BSP Release and the FSL Community Release please look at the Yocto Project Layers Mind Map available on the following link: YOCTO PROJECT LAYERS MIND MAP Adding an empty layer and a new recipe There are a couple of scripts available as part of the Open embedded tools that allows for easy creation of a new layer and recipe. Layers are basically a group of directories and meta data in configuration and recipe files (which contains metadata as text), so you may create these directories and meta data files by hand. However, it’s always easier to use the new layer script in order to create the required structure and then fill in with our customized configuration. cd <BSP_DIR>/sources ./poky/scripts/yocto-layer create <NEW_LAYER_NAME> We’ll name the new layer “new-layer” as shown below: ./poky/scripts/yocto-layer create new-layer We’ll be asked to enter le layer priority, we’ll keep the default 6 but you may want a higher priority depending on your application. You may opt for an example recipe to be created on your new layer.  We’ll leave this example recipe with the default settings. You may see the structure of the new layer by using the following command: tree -L 4 ./meta-new-layer Basic requirements of a layer - It is not a must but it’s strongly recommended to have the name of the layer start with “meta-“, the Poky new layer script uses this naming convention. - A README with information regarding what’s contained in the layer and any dependencies - A COPYING file with the copyright and use notice for the hardware in the new layer. - A conf folder which contains the layer’s configuration (.conf) files. Adding the layer to our BSP Once the layer has been created it’s necessary to add it to the list of Layers that make up the BSP so Bitbake can locate it and parse the metadata contained within it, in other words, you must make the build system aware of your new layer. In order to enable your layer you need to add the layer’s path to the BBLAYERS variable in the conf/bblayers.conf file which is found on the build directory. Please note that you will need to add your layer to each build directory in which you want to use it. We can add the following line to add our new layer. BBLAYERS += " ${BSPDIR}/sources/meta-new-layer " After doing so we’ll see that our layer is now listed when we run show-layers in bitbake-layers. bitbake-layers show-layers Adding a new recipe The new layer script also creates a basic recipe. It is recommended to look for recipes similar to what we need and use them as a template or starting point, as part of the benefits of Yocto is to be able to reuse a lot of open sourced code and resources. If there are many versions of the same recipe the default behavior is to use the recipe contained in the highest priority layer even if it’s not the higher version of the recipe. If you would want to force bitbake to use a certain version you may use the following variable on the local.conf file. PREFERRED_VERSION_recipename Main requirements of a recipe: SRC_URI which points to the location of the source code SRC_REV if applicable it would correspond to a particular commit or branch from the source code repository LICENSE a variable that defines the type of license to bitbake LIC_FILES_CHKSUM should point to a file within the source tree that corresponds to the md5 check-sum of the license file so it can be verified. Adding an append to a recipe You may also select the option to have the script create an append file. The append files allow us to change an existing recipe. The name of the file must be the same as the original recipe plus the append suffix (.bbappend) and should be located on the same path as the original recipe but in our own layer. The append file can be described as a piece of code or metadata that is added to the end of the original recipe. If there are more than one append files for a particular recipe all of them will be joined in reverse priority, that is, the highest priority layer’s bbappend will be added last. Appendix. Useful References FSL Community BSP Yocto Training - HOME Yocto Project Board Support Package Developer's Guide

Yoctoproject Framework Installing any Needed Package Using Yocto and i.MX Boards Testing Yocto for i.MX6 i.MX53 QSB - Quick Start Board i.MX6 Sabre Lite Board Build the image SDCard Image Yoctoproject Framework Yoctoproject is a framework for creating Linux distributions for embedded devices. Its layering mechanism makes it easy to add Linux to new target devices highly customized for a particular platform; it can include custom start-up scripts, software packages built with a high degree of optimization for a particular architecture, and different user interfaces from full Gnome desktop to a simple a serial console. Yocto has 2 basic layers: board support packages layer and core layer. In the BSP layer is where all the custom software and configuration tweaks for a particular platform are included, while the core layer provides the common software stack to provide from a simple command line interface to Sato desktop interface (Matchbox based and Gnome mobile software stack). A third layer could be added to provide additional user interfaces LXDE, XFCE, and more; YP is quite flexible&emdash;one of it major strengths. Installing any Needed Package Go to Yocto Project Quick Start and double check that you have all the necessary packages installed for your machine. For example, if building machine was an Ubuntu machine: $ sudo apt-get install gawk wget git-core diffstat unzip texinfo  build-essential chrpath libsdl1.2-dev xterm curl Using Yocto and i.MX Boards Please, go to project's README file in order to see the recommended instructions to download the source code. Testing Yocto for i.MX6 How to test Yocto for i.MX 6 i.MX53 QSB - Quick Start Board Edit conf/local.conf user config file and set imx53 Quick start board machine and enable parallel build features. MACHINE ?= "imx53qsb" BB_NUMBER_THREADS = "4" PARALLEL_MAKE = "-j 4" i.MX6 Sabre Lite Board Edit conf/local.conf user config file and set i.MX6 Sabrelite board machine and enable parallel build features MACHINE ?= "imx6qsabrelite" BB_NUMBER_THREADS = "4" PARALLEL_MAKE = "-j 4" if you've been facing problems to get yocto's images working on your i.MX Sabre Lite board, please take a look on this comment Re: The kernel sometins hang  in L3.0.35_4.0.0_130424 release Build the image some example of available image: image name description core-image-minimal A small image just capable of allowing a device to boot. core-image-base A console-only image that fully supports the target device hardware. core-image-sato Image with sato, a mobile environment and visual style for mobile devices.  The image supports X11 with a Sato theme, Pimlico applications and contains terminal, editor and file manager. fsl-image-test Builds contents core-image-base plus Freescale test applications and multimedia components. fsl-image-gui Builds contents of core-image-sato with Freescale test applications and multimedia with hardware accelerated X11 To build the image: $ bitbake <image_name> Build using Dash instead can bring some problems. You can check what your system uses typing: "ls -l /bin/sh". On Ubuntu you can change it using "dpkg-reconfigure bash". Some Ubuntu releases you must use "dpkg-reconfigure dash" and choose Bash Built images are located in cd tmp/deploy/images SDCard Image sudo dd if=core-image-minimal-imx6qsabrelite.sdcard of=/dev/sdb i.MX Yocto Project: Frequently Asked Questions

The i.MX Android N7.1.1_1.0.0 release is now available on Web Site (i.MX6 BSP Updates and Releases -> Android).   Files available: # Name Description 1 android_N7.1.1_1.0.0_docs.tar.gz i.MX Android N7.1.1_1.0.0 BSP Documentation 2 android_N7.1.1_1.0.0_source.tar.gz Source Code of Android N7.1.1_1.0.0 BSP (4.1 kernel) for i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo  i.MX 6Sololite, i.MX6SX and i.MX7D 3 android_N7.1.1_1.0.0_image_6dqpsabreauto.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE for Automotive Infotainment based on i.MX 6QuadPlus, i.MX 6Quad, and i.MX 6DualLite 4 android_N7.1.1_1.0.0_image_6dqpsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Platform and SABRE Board based on i.MX 6QuadPlus, i.MX 6Quad and i.MX 6DualLite. 5 android_N7.1.1_1.0.0_image_6slevk.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - i.MX 6Sololite evaluation kit. 6 android_N7.1.1_1.0.0_image_6sxsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Board based on i.MX 6SoloX 7 android_N7.1.1_1.0.0_image_6sxsabreauto.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE for Automotive infotainment based on i.MX 6SoloX 8 android_N7.1.1_1.0.0_image_7dsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Board based on i.MX 7Dual 9 android_N7.1.1_1.0.0_tools.tar.gz Manufacturing Toolkit and VivanteVTK for N7.1.1_1.0.0   Supported Hardware SoC/Boards: MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-SD board and platform MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-AI board and platform MX 6SoloLite EVK platform MX 6SoloX SABRE-SD board and platforms MX 6SoloX SABRE-AI board and platforms MX 7Dual SABRE-SD board and platform   Changes: Compared to the M6.0.1_2.1.0 release, this release has the following major changes: Upgraded the Android platform version to Android 7.1. Upgraded the U-Boot and Linux Kernel Code base from the L4.1.15_1.0.0 release to the L4.1.15_1.2.0-ga release. Added support for the i.MX 7Dual SABRE-SD board. Upgraded the GPU driver from 5.0.11p8 to 6.2.0.p2.   Feature: For features please consult the release notes.   Known issues For known issues and more details please consult the Release Notes.