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 

I've been asked to help to upload the doc in MPU support space. The doc describes some ideas about how to support a customer to enable a mipi-csi2 sensor connected with i.MX6DQ/6DL. Hope this may be helpful.

For iMX6DQ, there are two IPUs, so they can support up to 4 cameras at the same time. But the default BSP can only support up to two cameras at the same time.     The attached patch can make the BSP support up to 4 cameras based on 3.10.53 GA 1.1.0 BSP.   The 4 cameras can be: - 1xCSI, 3xMIPI - 2xCSI, 2xMIPI - 4xMIPI   For 4xMIPI case, the four cameras should be combined on the single MIPI CSI2 interface, and each camera data should be transfered on a mipi virtual channel.   In this patch, we given the example driver for Intersil ISL79985. The input to ISL79985 is four CVBS camera. There are four patches: 0001-IPU-update-IPU-capture-driver-to-support-up-to-four-.patch      Updated IPU common code to support up to four cameras.   0002-Add-Intersil-ISL79985-MIPI-Video-Decoder-Driver-for-.patch      ISL79985 driver, which can support both 1 lanes and 2 lanes mode.   0003-Remove-the-page-size-align-requirement-for-v4l2-capt.patch      With this patch, the mxc_v4l2_tvin test application can use overlay framebuffer as V4l2 capture buffer directly.   0004-IPU-CSI-Drop-1-2-frame-on-MIPI-interface-for-interla.patch      This patch is option, it will drop one field data, so for each camera, the input will be 720*240 30 FPS.   For 720P HD solution, it is based on Maxim MAX9286: iMX6DQ MAX9286 MIPI CSI2 720P camera surround view solution for Linux BSP   How to builld the kernel with ISL79985 support:       make imx_v7_defconfig       make menuconfig (In this command, you should select the ISL79985 driver:             Device Drivers  --->                   <*> Multimedia support  --->                         [*]   V4L platform devices  --->                               <*>   MXC Video For Linux Video Capture                                       MXC Camera/V4L2 PRP Features support  --->                                           <*>Intersil ISL79985 Video Decoder support                                           <*>mxc VADC support                                           <*>Select Overlay Rounting (Queue ipu device for overlay library)                                           <*>Pre-processor Encoder library                                           <*>IPU CSI Encoder library)       make zImage       make dtbs   The built out image file:       arch/arm/boot/dts/imx6q-sabresd.dtb       arch/arm/boot/zImage   "mxc_v4l2_tvin.zip" is the test application, test command to capture the four cameras and render on 1080P HDMI display: /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d &   2015-10-10 Update: Updated the test application "mxc_v4l2_tvin_isl79985.tar.gz" to fix the Yocto build errors. Updated ISL79985 register setting "page5, isl79985_write_reg(0x07, 0x46)" in patch "0002-Add-Intersil-ISL79985-MIPI-Video-Decoder-Driver-for-.patch", which can fix the green line issue.   2016-01-25 Update: Added de-interlace support, L3.10.53_ISL79985_Surroundview_Patch_20160125.tar.gz New test capplication for de-interlance: mxc_v4l2_tvin_isl79985_vdi_20160125.tar.gz New test commands: /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d -m & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d -m & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d -m & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d -m &   Note:  with the 0005-Add-interlaced-mode-capture-for-ISL79985.patch, the V4l2 capture driver will return 720x480 video size, but only odd lines have the video data, they are filled in line skip line mode.     2016-11-21 Update: Added ISL79987 support, L3.10.53_ISL7998x_Surroundview_Patch_20161121.zip New test capplication for de-interlance support: mxc_v4l2_tvin_isl7998x.tar.gz   Test commands (without de-interlace): /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d &   Test commands (with de-interlace, for ISL79987 only): /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -m 1 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -m 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -m 1 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -m 1 -g2d &     Now the same patch can support both ISL79985 and ISL79987, with NTSC CVBS camera, for ISL79985, it captures 60fps 720*240; for ISL79987, it captures 30fps 720*480.   2016-11-22 Update: Added patch for L4.1.15 BSP, it supports both ISL79985 and ISL79987, L4.1.15_ISL7998x_Surroundview_Patch_20161122.zip Test capplication mxc_v4l2_tvin_isl7998x.tar.gz is re-used.

Graphics are a big topic in the Android platform, containing java/jni graphic framework and 2d/3d graphic engines (skia, OpenGL-ES, renderscript). This document describes the general Android graphic stack and UI features on Freescale devices. 1. Android Graphic Stacks All Android 3D apps and games have the following graphic stack: Android system UI and all Apps UI follow 2D graphic stack as below, the hardware render will accelerate Android 2D UI with GPU HW OpenGL-ES 2.0 to improve the whole UI performance. Hardware acceleration can be disabled on i.mx6 in device/fsl/imx6/soc/imx6dq.mk USE_OPENGL_RENDERER := false Then rebuild frameworks/base/core/jni, and replace libandroid_runtime.so Surfaceflinger is responsible of all surface layers composition, and  then generate the framebuffer pixmap for display devices. these graphic surface layers are from 2D/3D apps. Hwcomposer is the alternative module of Surfaceflinger with OpenGL-ES. Hwcomposer is used to combine the specific surface layers supported by specific vendor devices. Freescale i.MX6 devices use GPU 2D to combine most surface layers, and the system power can be reduced with GPU 2D instead of GPU 3D. The typical power saving case is video playback. Hwcomposer with GPU 2D can offload GPU 3D task when running game and benchmarks, it is proved to improve the overall system performance about 20%. 2. Performance measurment Show FPS for Android system performance For NFS boot you can set “debug.sf.showfps” to 1 in init.freescale.rc (“setprop debug.sf.showfps 1”) and then reboot the system. For SD or EMMC boot, you can issue command “setprop debug.sf.showfps 1” in console, then find system_server thread by top and kill it to reset the system. Graphic benchmarks for 3D capability measurement Quadrant Full test benchmark cover CPU, Memory, IO, 2D and 3D GLBenchmark http://www.glbenchmark.com/ NenaMark2 https://market.android.com/details?id=se.nena.nenamark2 An3DBench http://www.androidzoom.com/android_applications/tools/an3dbench_hnog.html AnTutu http://www.antutu.com/software.html 3DMark http://www.futuremark.com/benchmarks/3dmark06/introduction/ Browser benchmarks http://www.webkit.org/perf/sunspider/sunspider.html http://v8.googlecode.com/svn/data/benchmarks/current/run.html http://www.craftymind.com/guimark2/ http://www.craftymind.com/factory/guimark/GUIMark_HTML4.html http://themaninblue.com/writing/perspective/2010/03/22/ 3.  Android UI features Dual display with same content This feature is supported in the default image in Android i.MX 6 release package. In this feature, LVDS panel and HDMI output can be supported simultaneously. It is only enabled when the HDMI TV has been connected with the board. Overscan for TV devices Some TVs may miss display the contents in overscan area. To avoid the contents in overscan area being lost, the common implement is by underscanning with an adjustable black border and letitng the viewer adjust the width of the black border. The downscan operation is done by surfaceflinger when it does surface composition through HW OpenGL ES. There is no performance impact since all the work is done by GPU HW. Overscan can be configured in display setting in visual mode: 32 bits color depth 32bpp UI can be supported by adding “bpp=32” in uboot as below: setenv bootargs ‘… video=mxcdi1fb:RGB666,XGA,bpp=32 …’, also can configure it in display setting. Enable 32bpp frame buffer and application surface buffer will be allocate to RGBA8888 format instead of default RGB565 format, that means more system memory is allocated. After enabling 32bpp, if some applications still don't have better UI quality, check to see if  there is hard code to request RGB565 format surface (should request RGBA8888 format to get better quality). Sample code is attached to test for 32bpp (left is on 16bpp, right is on 32bpp) Display Visual Setting The display setting is the add-on feature in FSL Android release, it is very convenient for end-users to change display property, mostly for the following features: Dual display enablement Display color depth setting(16bpp, 32bpp) Overscan adjustment in horizontal and vertical orientation 4. Issue Diagnosis Application Compatibility Some Android applications may not run correctly on some Android releases. It may cause application compatibility, so check the application in other platforms. For example Neocore and Asphalt 5 can run on Eclair, Froyo, and Gingerbread, but will not correctly run on Honeycomb. GPU Compatibility Some game UIs may not correctly display on our Android release. When encountering this kind of issue, the customer can check whether it is caused by the game using an OpenGL extension which our GPU does not support. They can download another data package (for example not extension data package) to have a check. Others Enlarge GPU memory if you encounter UI abnormally displaying after running an application for a while. Some applications need Wifi connections, so monitor the console log to see whether there are any error reports.

Note: All these gstreamer pipelines have been tested using a i.MX6Q board with a kernel version 3.0.35-2026-geaaf30e. Tools: gst-launch gst-inspect FSL Pipeline Examples: GStreamer i.MX6 Decoding GStreamer i.MX6 Encoding GStreamer Transcoding and Scaling GStreamer i.MX6 Multi-Display GStreamer i.MX6 Multi-Overlay GStreamer i.MX6 Camera Streaming GStreamer RTP Streaming Other plugins: GStreamer ffmpeg GStreamer i.MX6 Image Capture GStreamer i.MX6 Image Display Misc: Testing GStreamer Tracing GStreamer Pipelines GStreamer miscellaneous

Yocto Project versions and names Preparing host environment For virtual machine (VirtualBox): Download the source code from NXP Code Aurora Yocto Project versions and names See here the list of all yocto version names: Releases - Yocto Project  The current stable release is Zeus Preparing host environment For virtual machine (VirtualBox): Please set memory size minimal to 1GB and disk size to 32GB. (24Feb2014 Ubuntu 12.04LTS)   First, make sure your host PC has the required packages to run Yocto The essential packages you need for a supported Ubuntu distribution are shown in the following command: $ sudo apt-get build-dep qemu $ sudo apt-get remove oss4-dev $ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \   build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \   xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \   xterm‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ For other Linux distribution or newer Yocto Project release see here the updated list. Download the source code from community Install the repo $ sudo apt-get install repo‍‍‍‍ Download the BSP source: $ mkdir fsl-community-bsp $ cd fsl-community-bsp $ repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b zeus $ repo sync‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Download the source code from NXP Code Aurora See here the list of all BSP releases from NXP: imx-manifest - i.MX Release Manifest  Currently, the latest NXP release how to is here: README - imx-manifest - i.MX Release Manifest  To understand the difference between the 2 source code (community X NXP BSP) see here Go to https://community.nxp.com/docs/DOC-94849  Go to Task #2

Script which patches the ltib folder on Ubuntu 12.04. Steps: $ cp patch-ltib-ubuntu12.04.sh <your ltib folder> $ cd <your ltib folder> $ chmod +x patch-ltib-ubuntu12.04.sh $ ./patch-ltib-ubuntu12.04.sh

Here is a quick summary at booting u-boot on the i.MX 6 sabre sd platform. This assumes you already have a "working" Linux development environment with some ARM cross-compilers at hand (e.g. Debian + Emdebian). Get u-boot sources We will use git to fetch the U-Boot sources:   $ git clone git://git.denx.de/u-boot.git This should create a u-boot directory with all the latest sources. 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 'v2*', 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 u-boot   $ export CROSS_COMPILE=arm-linux-gnueabihf-   $ make mx6qsabresd_config   $ make This should create a number of files, including u-boot.imx. Put on SD U-boot should reside at offset 1024B of your SD card. To put it there, do:   $ dd if=u-boot.imx of=/dev/<your-sd-card> bs=1k seek=1   $ sync Your SD card device is typically something in /dev/sd<X> or /dev/mmcblk<X>. 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. Boot! Your SD card is ready for booting. Insert it in 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, power up the platform and you should see something like:   U-Boot 2013.07-rc1-00014-g74771f4 (Jun 20 2013 - 19:05:09)   CPU:   Freescale i.MX6Q rev1.2 at 792 MHz   Reset cause: POR   Board: MX6Q-SabreSD   DRAM:  1 GiB   MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2   *** Warning - bad CRC, using default environment   In:    serial   Out:   serial   Err:   serial   Net:   FEC [PRIME]   Warning: FEC using MAC address from net device   Hit any key to stop autoboot:  0 Enjoy! See also... u-boot most common mission is to boot the Linux kernel. See this post for details on how to do it. If you plan to compile u-boot often, you might want to use a C compiler cache; see this post. Running a Script in U-boot u-boot on the Vybrid tower board in a few commands

iMX6DQ TP2854 MIPI CSI2 720P HD-TVI camera surround view solution for Linux BSP.   For iMX6DQ, there are two IPUs, so they can support up to 4 cameras at the same time. But the default BSP can only support up to two cameras at the same time. The attached patch can make the BSP support up to 4 cameras based on 3.14.52 GA 1.1.0 BSP and 4.1.15 GA1.2.0 BSP. The 4 cameras can be: - 1xCSI, 3xMIPI - 2xCSI, 2xMIPI - 4xMIPI For 4xMIPI case, the four cameras should be combined on the single MIPI CSI2 interface, and each camera data should be transfered on a mipi virtual channel. In this patch, we given the example driver for Techpoint TP2854, it was verified working on iMX6DQ SabreAuto board. The input to TP2854 is four 720P30 HD-TVI cameras.   The MIPI CSI2 720P digital camera surround view solution can be found at: iMX6DQ MAX9286 MIPI CSI2 720P camera surround view solution for Linux BSP   The kernel patches: 0001-IPU-update-IPU-capture-driver-to-support-up-to-four-.patch      Updated IPU common code to support up to four cameras.   0002-Remove-the-page-size-align-requirement-for-v4l2-capt.patch      With this patch, the mxc_v4l2_tvin test application can use overlay framebuffer as V4l2 capture buffer directly.   0003-Add-TP2854-support-on-SabreAuto-board-which-can-supp.patch      TP2854 driver.   How to builld the kernel with TP2854 support:       make imx_v7_defconfig       make menuconfig (In this command, you should select the TP2854 driver:             Device Drivers  --->                   <*> Multimedia support  --->                         [*]   V4L platform devices  --->                               <*>   MXC Video For Linux Video Capture                                       MXC Camera/V4L2 PRP Features support  --->                                           <*>Techpoint tp2854 HD CVBS Input support                                           <*>mxc VADC support                                           <*>Select Overlay Rounting (Queue ipu device for overlay library)                                           <*>Pre-processor Encoder library                                           <*>IPU CSI Encoder library)       make zImage       make dtbs   The built out image file:       arch/arm/boot/dts/imx6q-sabreauto.dtb       arch/arm/boot/zImage "mxc_v4l2_tvin_3.14.52.zip" is the test application, test command to capture the four cameras and render on 1080P HDMI display: /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d & Details for TP2854, please contact with Techpoint. [2019-04-04] Update Add application to preview + encode at the same time:    /mxc_vpu_test.out -E "-x 0 -o /enc.h264 -w 1280 -h 720 -L 0 -T 0 -W 512 -H 384 -c 5000 -f 2" The camera input data go through CSI->MEM path, and IDMAC 0/1 will convert data from YUV422 ro NV12 for VPU encoder, no resize. Another modification in the mxc_vpu_test, it use different thread to encode and preview.

i.MX6Q PCIe EP/RC Validation and Throughput Hardware setup     * Two i.MX6Q SD boards, one is used as PCIe RC; the other one is used as PCIe EP. Connected by 2*mini_PCIe to standard_PCIe  adaptors, 2*PEX cable adaptors,  and one PCIe cable. Software configurations     * When building RC image, make sure that         CONFIG_IMX_PCIE=y         # CONFIG_IMX_PCIE_EP_MODE_IN_EP_RC_SYS is not set         CONFIG_IMX_PCIE_RC_MODE_IN_EP_RC_SYS=y     * When build EP image, make sure that         CONFIG_IMX_PCIE=y         CONFIG_IMX_PCIE_EP_MODE_IN_EP_RC_SYS=y         # CONFIG_IMX_PCIE_RC_MODE_IN_EP_RC_SYS is not set Features     * Set-up link between RC and EP by their stand-alone 125MHz running internally. * In EP's system, EP can access the reserved ddr memory    (default address:0x40000000) of PCIe RC's system, by the   interconnection between PCIe EP and PCIe RC. NOTE: The layout of the 1G DDR memory on SD boards is 0x1000_0000 ~ 0x4FFF_FFFF) Use mem=768M in the kernel command line to reserve the 0x4000_0000 ~ 0x4FFF_FFFF DDR memory  space used to do the EP access tests. (The example of the RC’s cmd-line: Kernel command line: noinitrd console=ttymxc0,115200 mem=768M root=/dev/nfs nfsroot=10.192.225.216:/home/r65037/nfs/rootfs_mx5x_10.11,v3,tcp ip=dhcp rw) Throughput results ARM core used as the bus master, and cache is disabled ARM core used as the bus master, and cache is enabled IPU used as the bus master(DMA) Data size in one write tlp 8 bytes 32 bytes 64 bytes Write speed ~109MB/s ~298MB/s ~344MB/s Data size in one read tlp 32 bytes 64 bytes 64 bytes Read speed ~29MB/s ~100MB/s ~211MB/s IPU used as the bus master(DMA) Here is the summary of the PCIe throughput results tested by IPU. Write speed is about 344 MB/s. Read speed is about 211MB/s ARM core used as the bus master (define EP_SELF_IO_TEST in pcie.c driver) write speed ~300MB/s. read speed ~100MB/s. Cache is enabled. PCIe EP: Starting data transfer... PCIe EP: Data transfer is successful, tv_count1 54840us, tv_count2 162814us. PCIe EP: Data write speed is 298MB/s. PCIe EP: Data read speed is 100MB/s. Regarding to the log, the data size of each TLP when cache is enabled, is about 4 times of the data size in write, and 2 times of the data size in read, when the cache is not enabled. Cache is disabled Cache is enabled Data size in one write tlp 8 bytes 32 bytes Write speed ~109MB/s ~298MB/s Data size in one read tlp 32 bytes 64 bytes Read speed ~29MB/s ~100MB/s Cache is not enabled PCIe EP: Starting data transfer... PCIe EP: Data transfer is successful, tv_count1 149616us, tv_count2 552099us. PCIe EP: Data write speed is 109MB/s. PCIe EP: Data read speed is 29MB/s. One simple method used to connect the imx6 pcie ep and rc View of the whole solution: HW materials: 2* iMX6Q SD boards,  2* Mini PCIe to STD PCIe adaptors, one SATA2 data cable. the mini-pcie to standard pcie exchange adaptor. Here is the URL: http://www.bplus.com.tw/Adapter/PM2C.html How to make it. signals connections Two adaptors, one is named as A, the other one is named as B. A                  B TXM <----> RXM TXN <----> RXN RXM <----> TXM RXN <----> TXN A1 connected to B3 A2 connected to B4 A3 connected to B1 A4 connected to B2 Connect the cable to the adaptor. Connect the SATA2 data cable to Mini PCIe to STD PCIe adaptor (A)    Connect the SATA2 data cable to Mini PCIe to STD PCIe adaptor (B) NOTE: * Please keep length of Cable as short as possible.  Our cable is about 12cm. * Please connect shield wire in SATA2 Cable to GND at both board. * Please boot up PCIe EP system before booting PCIe RC system. Base one imx_3.0.35 mainline, the patch, and the IPU test tools had been attached. NOTE: * IPU tests usage howto. Unzip the xxx.zip, and run xxx_r.sh to do read tests, run xxx_w.sh to do the write tests. Tests log: EP: root@freescale ~/pcie_ep_io_test$ ./pcie-r.sh pass cmdline 14, ./pcie_ipudev_test.out new option : c frame count set 1 new option : l loop count set 1 new option : i input w=1024,h=1024,fucc=RGB4,cpx=0,cpy=0,cpw=0,cph=0,de=0,dm=0 new option : O 640,480,RGB4,0,0,0,0,0 new option : s show to fb 0 new option : f output file name ipu1-1st-ovfb new option : ÿ show_to_buf:0, input_paddr:0x1000000, output.paddr0x18800000 ====== ipu task ====== input:         foramt: 0x34424752         width: 1024         height: 1024         crop.w = 1024         crop.h = 1024         crop.pos.x = 0         crop.pos.y = 0 output:         foramt: 0x34424752         width: 640         height: 480         roate: 0         crop.w = 640         crop.h = 480         crop.pos.x = 0         crop.pos.y = 0 total frame count 1 avg frame time 19019 us, fps 52.579000 root@freescale ~/pcie_ep_io_test$ ./pcie-w.sh pass cmdline 14, ./pcie_ipudev_test.out new option : c frame count set 1 new option : l loop count set 1 new option : i input w=640,h=480,fucc=RGB4,cpx=0,cpy=0,cpw=0,cph=0,de=0,dm=0 new option : O 1024,1024,RGB4,0,0,0,0,0 new option : s show to fb 1 new option : f output file name ipu1-1st-ovfb new option : ÿ show_to_buf:1, input_paddr:0x18a00000, output.paddr0x1000000 ====== ipu task ====== input:         foramt: 0x34424752         width: 640         height: 480         crop.w = 640         crop.h = 480         crop.pos.x = 0         crop.pos.y = 0 output:         foramt: 0x34424752         width: 1024         height: 1024         roate: 0         crop.w = 1024         crop.h = 1024         crop.pos.x = 0         crop.pos.y = 0 total frame count 1 avg frame time 11751 us, fps 85.099140 root@freescale ~$ ./memtool -32 01000000=deadbeaf Writing 32-bit value 0xDEADBEAF to address 0x01000000 RC: Before run "./memtool -32 01000000=deadbeaf" at EP. root@freescale ~$ ./memtool -32 40000000 10 Reading 0x10 count starting at address 0x40000000 0x40000000:  00000000 00000000 00000000 00000000 0x40000010:  00000000 00000000 00000000 00000000 0x40000020:  00000000 00000000 00000000 00000000 0x40000030:  00000000 00000000 00000000 00000000 After run "./memtool -32 01000000=deadbeaf" at EP. root@freescale ~$ ./memtool -32 40000000 10 Reading 0x10 count starting at address 0x40000000 0x40000000:  DEADBEAF 00000000 00000000 00000000 0x40000010:  00000000 00000000 00000000 00000000 0x40000020:  00000000 00000000 00000000 00000000 0x40000030:  00000000 00000000 00000000 00000000 Labels parameters

System Memory Usage and Configuration Introduction This document describes i.MX android memory usage, layout and configuration for the entire system. Total DDR memory usage When i.MX Android is running, the DDR memory will be used by the following components: Linux Kernel reserved space, including: kernel text, data section and initrd kernel page tables       Normal zone space managed by kernel’s MM (high memory zone is also included) Used by application by brk() or malloc() in libc Used by kernel by mm api, like: kmalloc, dma_alloc, vmalloc       Reserved memory for GPU drivers, used by GPU libs, drivers Android surface view, normal surface buffers VPUs working buffer and bitstream (we allocate the VPU buffer from GPU driver to make a unify method of allocation) Reserved space for framebuffer BG triple buffers Framebuffer display are always required to have triple and large buffers       Memory layout The following diagram shows the default memory usage and layout on i.MX6Q/DL platform. Memory configuration According to different type of product and different hardware configurations (ddr size, screen resolution, camera), customer may do some configurations to the memory layout and usage to optimize their system. Some memory reservation can be configured by command line or modifying the code. The kernel reserved space cannot be adjusted. It is controlled by the kernel and the Normal zone size and it depends on the total DDR size and the reserved spaces. Reserved GPU memory size can be adjusted by adding "gpumem=" parameters in kernel commandline. It's size is highly depends on the screen resolution, the video stream decoding requirement and the camera resolution, fps. gpumem=<size>M Reserved memory size for BG (background) framebuffer can be configured by command line fbmem=<fb0 size>,<fb2 size>,<fb4 size>,<fb5 size> For example: If you have two display devices, one is XGA LVDS, the other is HDMI 1080p device (default 32bpp), you have to specify the BG buffer size for them: fbmem=10M,24M The size is calculated by xres*yres*bpp*3: 10M ~= 1024x768x4(32bpp)x3(triple buffer) 24M ~= 1920x1080x4(32bpp)x3(triple buffer)

Introduction The "smart" package management system is available in  Yocto Project for managing  packages on a target machine. A host is configured as a server for the packages and on the target the "package-management" feature is enabled for working with the packages. The steps for setup and usage are described below. Resources The Yocto Project package management system will work with many hosts and targets. The following were used for creating this document: Host: Ubuntu 14.04 64-bit Target: MCIMX6Q-SDP Freescale Yocto Project Release Documentation: Linux 3.14.38_6ul BSP & Multimedia Codecs Documentation (fsl-yocto-L3.14.38_6ul-ga.tar.gz) Host You have successfully installed a Freescale Yocto Project release. (Refer to Freescale Yocto Project Release Documentation). There are two steps for adding package management and then building: 1. Modify conf/local.conf EXTRA_IMAGE_FEATURES = "debug-tweaks package-management" ‍ 2. Build the image: bitbake core-image-minimal ‍ The core-image-minimal recipe provides an image enabling the target board to boot and support a serial console. 3. Create SDCARD: $ cd <build>/tmp/deploy/images/imx6qsabresd $ sudo dd if=core-image-minimal-imx6qsabresd.sdcard of=/dev/sdb bs=4M && sync ‍‍ Note - verify location of SDCARD on your host, /dev/sdb in this example. Examine 'cat /proc/partitions' 4. Setup web server and add link to rpm packages A web server, lighttpd, is installed. $ sudo apt-get install lighttpd ‍ Provide user write capability in /var/www $ sudo chmod 777 /var/www ‍ Create a soft link in the default web server directory to the rpm directory from the build. Note: Please update $HOME/<build> to your actual location: $ ln -s $HOME/<build>/tmp/deploy/rpm /var/www/imx6qsd ‍‍‍ Target Insert the SDCARD created from step 3 above, connect power and console cable  and power on the MCIMX6Q-SDP. Login using the "root" id, no password required. The /usr/bin/smart application is now used to setup the channels and perform package commands. For all smart options: smart --help ‍ 1. Add channels To add the packages from the host to your target, the smart  channel --add is used: Please enter the IP adress of your server, replacing SERVERIP below: smart channel --add all type=rpm-md name=all baseurl= http://SERVERIP/imx6qsd/all smart channel --add cortexa9hf_vfp_neon type=rpm-md name=cortexa9hf_vfp_neon baseurl= http://SERVERIP/imx6qsd/cortexa9hf_vfp_neon smart channel --add imx6qsabresd type=rpm-md name=imx6qsabresd baseurl= http://SERVERIP/imx6qsd/imx6qsabresd ‍‍‍‍‍‍‍‍‍ Check  the added channels: root@imx6qsabresd:~# smart channel --list all imx6qsabresd rpmsys cortexa9hf_vfp_neon ‍‍‍‍‍ 2. Update  local package cache Once the chanels have been added, the local package cache is updated. Note  SERVERIP below will be the host IP address in your network. root@imx6qsabresd:~# smart update Loading cache... Updating cache...               ######################################## [100%] Fetching information for 'all'...                                           -> http://SERVERIP/imx6qsd/all/repodata/repomd.xml                          repomd.xml                      ######################################## [ 16%]                                                                             Fetching information for 'imx6qsabresd'... -> http://SERVERIP/imx6qsd/imx6qsabresd/repodata/repomd.xml                 repomd.xml                      ######################################## [ 41%]                                                                             Fetching information for 'cortexa9hf_vfp_neon'... -> http://SERVERIP/imx6qsd/cortexa9hf_vfp_neon/repodata/repomd.xml          repomd.xml                      ######################################## [ 66%] Updating cache...               ######################################## [100%] Channels have no new packages. 3. Searching for packages Let us look at all packages containing the string client root@imx6qsabresd:~# smart search client* Loading cache... Updating cache...               ######################################## [100%] libice-dbg - ICE: Inter-Client Exchange library - Debugging files libice-dev - ICE: Inter-Client Exchange library - Development files libice-doc - ICE: Inter-Client Exchange library - Documentation files libice-staticdev - ICE: Inter-Client Exchange library - Development files (Static Libraries) libice6 - ICE: Inter-Client Exchange library libsm-dbg - SM: Session Management library - Debugging files libsm-dev - SM: Session Management library - Development files libsm-doc - SM: Session Management library - Documentation files libsm-staticdev - SM: Session Management library - Development files (Static Libraries) libsm6 - SM: Session Management library libx11-6 - Xlib: C Language X Interface library libx11-dbg - Xlib: C Language X Interface library - Debugging files libx11-dev - Xlib: C Language X Interface library - Development files libx11-doc - Xlib: C Language X Interface library - Documentation files libx11-locale - Xlib: C Language X Interface library libx11-staticdev - Xlib: C Language X Interface library - Development files (Static Libraries) libx11-xcb1 - Xlib: C Language X Interface library libxau-dbg - Xau: X Authority Database library - Debugging files libxau-dev - Xau: X Authority Database library - Development files libxau-doc - Xau: X Authority Database library - Documentation files libxau-staticdev - Xau: X Authority Database library - Development files (Static Libraries) libxau6 - Xau: X Authority Database library python-netclient - Python Internet Protocol clients xtrans-dbg - XTrans: X Transport library - Debugging files xtrans-dev - XTrans: X Transport library - Development files xtrans-doc - XTrans: X Transport library - Documentation files ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Adding openssh client to core-image minimal The core-image-minimal does not provide openssh client applications like ssh or scp. Let's add them on the host then update the target cache of packages and then install. Host Run bitbake to exercise all the tasks for packagegroup-core-ssh-openssh $ bitbake packagegroup-core-ssh-openssh ‍ After building a package individually, always update the package-index $ bitbake package-index ‍ Target Run smart to update the local cache which will pickup the new packages from the bake above. root@imx6qsabresd:~# smart update Loading cache... Updating cache...               ######################################## [100%] Fetching information for 'all'...                                              -> http://SERVERIP/imx6qsd/all/repodata/repomd.xml                           repomd.xml                      ######################################## [ 16%] -> http://SERVERIP/imx6qsd/all/repodata/primary.xml.gz                       primary.xml.gz                  ######################################## [ 25%] -> http://SERVERIP/imx6qsd/all/repodata/filelists.xml.gz                     filelists.xml.gz                ######################################## [ 33%]                                                                                Fetching information for 'imx6qsabresd'... -> http://SERVERIP/imx6qsd/imx6qsabresd/repodata/repomd.xml                  repomd.xml                      ######################################## [ 50%] -> http://SERVERIP/imx6qsd/imx6qsabresd/repodata/primary.xml.gz              -> http://SERVERIP/imx6qsd/imx6qsabresd/repodata/filelists.xml.gz            filelists.xml.gz                ######################################## [ 58%] primary.xml.gz                  ######################################## [ 66%]                                                                                Fetching information for 'cortexa9hf_vfp_neon'... -> http://SERVERIP/imx6qsd/cortexa9hf_vfp_neon/repodata/repomd.xml           repomd.xml                      ######################################## [ 83%] -> http://SERVERIP/imx6qsd/cortexa9hf_vfp_neon/repodata/primary.xml.gz       primary.xml.gz                  ######################################## [ 91%] -> http://SERVERIP/imx6qsd/cortexa9hf_vfp_neon/repodata/filelists.xml.gz     filelists.xml.gz                ######################################## [100%] Updating cache...               ######################################## [100%] Channels have 15 new packages. Saving cache... ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Examine information about local cache: root@imx6qsabresd:~# smart stats Loading cache... Updating cache...               ######################################## [100%] Installed Packages: 80 Total Packages: 3586 Total Provides: 6580 Total Requires: 1611 Total Upgrades: 3565 Total Conflicts: 25 ‍‍‍‍‍‍‍‍‍‍‍ See what ssh packages are now available: root@imx6qsabresd:~# smart search *ssh* Loading cache... Updating cache...               ######################################## [100%] openssh - Secure rlogin/rsh/rcp/telnet replacement openssh-dbg - Secure rlogin/rsh/rcp/telnet replacement - Debugging files openssh-dev - Secure rlogin/rsh/rcp/telnet replacement - Development files openssh-doc - Secure rlogin/rsh/rcp/telnet replacement - Documentation files openssh-keygen - Secure rlogin/rsh/rcp/telnet replacement openssh-misc - Secure rlogin/rsh/rcp/telnet replacement openssh-ptest - Secure rlogin/rsh/rcp/telnet replacement - Package test files openssh-scp - Secure rlogin/rsh/rcp/telnet replacement openssh-sftp - Secure rlogin/rsh/rcp/telnet replacement openssh-sftp-server - Secure rlogin/rsh/rcp/telnet replacement openssh-ssh - Secure rlogin/rsh/rcp/telnet replacement openssh-sshd - Secure rlogin/rsh/rcp/telnet replacement packagegroup-core-ssh-openssh - OpenSSH SSH client/server packagegroup-core-ssh-openssh-dbg - OpenSSH SSH client/server - Debugging files packagegroup-core-ssh-openssh-dev - OpenSSH SSH client/server - Development files ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Install openssh root@imx6qsabresd:~# smart install openssh Loading cache... Updating cache...               ######################################## [100%] Computing transaction... Installing packages (9):   openssh-6.7p1-r0@cortexa9hf_vfp_neon                                            openssh-keygen-6.7p1-r0@cortexa9hf_vfp_neon                                     openssh-scp-6.7p1-r0@cortexa9hf_vfp_neon                                        openssh-ssh-6.7p1-r0@cortexa9hf_vfp_neon                                        openssh-sshd-6.7p1-r0@cortexa9hf_vfp_neon                                       shadow-4.2.1-r0@cortexa9hf_vfp_neon                                             shadow-base-4.2.1-r0@cortexa9hf_vfp_neon                                        shadow-securetty-4.2.1-r3@imx6qsabresd                                          util-linux-sulogin-2.25.2-r1@cortexa9hf_vfp_neon                              1.4MB of package files are needed. 3.2MB will be used. Confirm changes? (Y/n): y Fetching packages...                                                           -> http://SERVERIP/imx6qsd/.../openssh-6.7p1-r0.cortexa9hf_vfp_neon.rpm      -> http://SERVERIP/imx6qsd/.../shadow-securetty-4.2.1-r3.imx6qsabresd.rpm    shadow-securetty-4.2.1-r3.imx.. ######################################## [ 11%] -> http://SERVERIP/imx6qsd/.../openssh-scp-6.7p1-r0.cortexa9hf_vfp_neon.rpm openssh-scp-6.7p1-r0.cortexa9.. ######################################## [ 22%] openssh-6.7p1-r0.cortexa9hf_v.. ######################################## [ 33%] -> http://SERVERIP/imx6qsd/.../openssh-sshd-6.7p1-r0.cortexa9hf_vfp_neon.rpm openssh-sshd-6.7p1-r0.cortexa.. ######################################## [ 44%] -> http://SERVERIP/imx6qsd/.../shadow-4.2.1-r0.cortexa9hf_vfp_neon.rpm       -> http://SERVERIP/imx6qsd/.../openssh-ssh-6.7p1-r0.cortexa9hf_vfp_neon.rpm openssh-ssh-6.7p1-r0.cortexa9.. ######################################## [ 55%] -> http://SERVERIP/imx6qsd/.../shadow-base-4.2.1-r0.cortexa9hf_vfp_neon.rpm shadow-base-4.2.1-r0.cortexa9.. ######################################## [ 66%] shadow-4.2.1-r0.cortexa9hf_vf.. ######################################## [ 77%] -> http://SERVERIP/.../util-linux-sulogin-2.25.2-r1.cortexa9hf_vfp_neon.rpm util-linux-sulogin-2.25.2-r1... ######################################## [ 88%] -> http://SERVERIP/.../openssh-keygen-6.7p1-r0.cortexa9hf_vfp_neon.rpm       openssh-keygen-6.7p1-r0.corte.. ######################################## [100%]                                                                                Committing transaction... Preparing...                    ######################################## [  0%]    1:Installing openssh-ssh     ######################################## [ 11%] Output from openssh-ssh-6.7p1-r0@cortexa9hf_vfp_neon:                          update-alternatives: Linking /usr/bin/ssh to /usr/bin/ssh.openssh                 2:Installing openssh-scp     ######################################## [ 22%] Output from openssh-scp-6.7p1-r0@cortexa9hf_vfp_neon:                          update-alternatives: Linking /usr/bin/scp to /usr/bin/scp.openssh                 3:Installing shadow-secure.. ######################################## [ 33%]    4:Installing shadow-base     ######################################## [ 44%] Output from shadow-base-4.2.1-r0@cortexa9hf_vfp_neon:                          update-alternatives: Linking /usr/bin/newgrp to /usr/bin/newgrp.shadow         update-alternatives: Linking /usr/bin/groups to /usr/bin/groups.shadow update-alternatives: Linking /bin/login to /bin/login.shadow update-alternatives: Linking /bin/su to /bin/su.shadow    5:Installing util-linux-su.. ######################################## [ 55%] Output from util-linux-sulogin-2.25.2-r1@cortexa9hf_vfp_neon:                  update-alternatives: Linking /sbin/sulogin to /sbin/sulogin.util-linux            6:Installing openssh-keygen  ######################################## [ 66%]    7:Installing shadow          ######################################## [ 77%] Output from shadow-4.2.1-r0@cortexa9hf_vfp_neon:                               update-alternatives: Linking /usr/bin/passwd to /usr/bin/passwd.shadow         update-alternatives: Linking /usr/bin/chfn to /usr/bin/chfn.shadow update-alternatives: Linking /usr/bin/chsh to /usr/bin/chsh.shadow update-alternatives: Linking /usr/sbin/chpasswd to /usr/sbin/chpasswd.shadow update-alternatives: Linking /sbin/vipw to /sbin/vipw.shadow update-alternatives: Linking /sbin/vigr to /sbin/vigr.shadow Output from openssh-sshd-6.7p1-r0@cortexa9hf_vfp_neon:                         Removing any system startup links for sshd ...                                Running useradd commands... NOTE: Performing useradd with [ --system --no-create-home --home-dir /var/run/sshd --shell /bin/false --user-group sshd] and 10 times of retry    8:Installing openssh-sshd    ######################################## [ 88%] Adding system startup for /etc/init.d/sshd.                                   Starting OpenBSD Secure Shell server: sshd   generating ssh RSA key...   generating ssh ECDSA key...   generating ssh DSA key...   generating ssh ED25519 key... done.    9:Installing openssh         ######################################## [100%] ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Check for the scp command: root@imx6qsabresd:~# which scp /usr/bin/scp ‍‍ Summary To add a new package on the server host, run bitbake <recipe> then bitbake package-index to update the rpm tracking information. On the target board, run smart update and then smart install <package>. Use smart search <regular expression string> to hunt for a package to install.

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

The original implementation is from Frias Renato for Sabreauto board. How to define the booting time? The booting time we defined here is from the board be powered up to the main application working and main application be showed directly to the end user, for example: for the media play purpose board, the booting time count to the first video frame be shown on the screen. For minimizing the booting time, some methods be tried. Optimizing for performance. Remove unnecessary modules at boot time. Start main application at the first time after the kernel be boot up. Optimizing for performance: U-Boot:   1:Enable MMU and L2-Cache.   2:Optimizing memset and memcpy.   3:Implementation of SDMA, accelerate copying data from NOR flash to memory.   4:Implementation of uSDHC’s ADMA, improve performance for SD card read. Kernel:   1:Optimizing _memcpy_fromio function at  arch/arm/kernel/io.c Remove unnecessary modules: U-Boot:   1: Disable uart output at u-boot procedure and add quiet parameter to Kernel boot.   2: Remove boot up delay at u-boot.   3: Disable I2C, SPI, SPLASH_SCREEN at u-boot. Kernel: Below removing unnecessary modules just for Sabresd board boot up through SD card and MIPI camera overlay on LVDS screen application, for other special board and special board usage application please don’t use below directly.   1: Modify arch/arm/mach-mx6/board-mx6q_sabresd.c just keep necessary module initialization at  mx6_sabresd_board_init : iomux configuration, uart0, voda, ipu, ldb, v4l2, mipi-csi, i2c1, uSDHC1, pwm0, dvfs, mipi camera clock.   2: Update Linux kernel configuration file. Try to just keep necessary module and configuration to keep minim size. Build necessary modules from external to Kernel itself. Create uImage from Image instead of zImage to reduce Kernel self extraction time. Use ext4 file system on SD card to accelerate rootfs mounting.    Notice: Kernel configuration remove NETWORK support, it includes Unix Domain Socket, the udev mechanism need it, so this kernel configuration can't support rootfs udev dynamic /dev/ nodes and all /dev/ nodes must be created before boot up at rootfs. Start main application at the first time after the kernel boots up. As normal boot up procedure, the init process will handle sysinit script firstly, this script will do some initialization and preparation for most of the user process, But this script normally will be executed for about 1~5 seconds, so now try do main application before the sysinit, while the necessary preparation of main application will be handle by this application internally. See below example for MIPI camera overly on LVDS screen: /etc/inittab ::once:/unit_tests/mxc_v4l2_overlay.out -iw 640 -ih 480 -it 0 -il 0 -ow 1024 -oh 768 -ot 0 -ol 0 -r 0 -t -1 -d 0 -fg -fr 30 ::once:/etc/rc.d/rcS ::once:/sbin/getty -L ttymxc0 115200 vt100 # GENERIC_SERIAL Test result of fast boot on Sabresd board for MIPI camera overly on LVDS screen: The main application be executed from the board be powered up is about 958ms.    Running Bootloader [0.356417 0.356417] [ 0.046637] _regulator_get: get() with no identifier [ 0.958425  0.602008] starting pid 21, tty '': '/unit_tests/mxc_v4l2_overlay.out -iw 640 -ih 480 -it 0 -il 0 -ow 1024 -oh 768 -ot 0 -ol 0 -r 0 -t -^@ [0.969609 0.011184] starting pid 22, tty '': '/etc/rc.d/rcS' [0.973368 0.003759] g_display_width = 1024, g_display_height = 768 [0.977540 0.004172] g_display_top = 0, g_display_left = 0 [0.980927 0.003387] starting pid 23, tty '': '/sbin/getty -L ttymxc0 115200 vt100 ' [1.048454 0.067527] Mounting /proc and /sys [1.089526 0.041072] Setting the hostname to freescale [1.116635 0.027109] Mounting filesystems [1.527320 0.410685] sensor chip is ov5640_mipi_camera [1.530627 0.003307] sensor frame size is 640x480 [1.533482 0.002855] sensor frame format is UYVY [1.640221 0.106739] frame_rate is 30 [1.642249 0.002028] [1.642270 0.000021] frame buffer width 0, height 0, bytesperline 0 [1.989728 0.347458] [1.990761 0.001033] arm-none-linux-gnueabi-gcc (Freescale MAD -- Linaro 2011.07 -- Built at 2011/08/10 09:20) 4.6.2 20110630 (prerelease) [2.001161 0.010400] root filesystem built on Tue, 11 Sep 2012 11:43:24 +0800 [2.006249 0.005088] Freescale Semiconductor, Inc. [2.009394 0.003145] [2.009531 0.000137] freescale login: Please see below fast boot video. I also attached sample code for U-boot and kernel for your reference. Patch code based on L3.0.35_12.09.01_GA.

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.

Introduction This guide provides a step by step explanation of what is involved in adding a new WiFi driver and making a new WiFi card work well in a custom Android build. (This guide was written for Android 4.1 but should be applicable to previous Android releases and hopefully future releases.) Contents Understand how Android WiFi works Port WiFi driver. Compile a proper wpa_supplicant in your BoardConfig.mk Modify your wifi.c in HAL. Launch wpa_supplicant and dhcpcd services in init.rc. Several debug tips. Understand How Android WiFi Works As the following figure, Android wireless architecture can be divided into three parts: Java Framework(WifiManager, WifiMonitor etc..), HAL(wifi.c,wpa_supplicant,netd) kernel space modules(wireless stack, wifi drivers) Java Framework communicate with wpa_supplicant using native interface (wifi.c). Wpa_supplicant and netd uses wireless extension or nl80211 to control WiFi drivers. Port WiFi driver Usually WiFi driver is provided as a kernel module. There are mainly two types of Android WiFi architecture:nl80211 and wext. With the implementation of nl80211/cfg80211 many wireless drivers in main line kernel  support nl80211 interface instead of wireless extension. For different vendors’ WiFi drivers, writing one Android.mk to add its compile into Android is what you should do. Here take atheros’s AR6kl as an example: ath6kl_module_file :=drivers/net/wireless/ath/ath6kl/ath6kl_sdio.ko $(ATH_ANDROID_SRC_BASE)/$(ath6kl_module_file):$(mod_cleanup) $(TARGET_PREBUILT_KERNEL) $(ACP)         $(MAKE) -C $(ATH_ANDROID_SRC_BASE) O=$(ATH_LINUXPATH) ARCH=arm CROSS_COMPILE=$(ARM_EABI_TOOLCHAIN)/arm-eabi- KLIB=$(ATH_\ LINUXPATH) KLIB_BUILD=$(ATH_LINUXPATH)         $(ACP) -fpt $(ATH_ANDROID_SRC_BASE)/compat/compat.ko $(TARGET_OUT)/lib/modules/         $(ACP) -fpt $(ATH_ANDROID_SRC_BASE)/net/wireless/cfg80211.ko $(TARGET_OUT)/lib/modules/ include $(CLEAR_VARS) LOCAL_MODULE := ath6kl_sdio.ko LOCAL_MODULE_TAGS := optional LOCAL_MODULE_CLASS := ETC LOCAL_MODULE_PATH := $(TARGET_OUT)/lib/modules LOCAL_SRC_FILES := $(ath6kl_module_file) include $(BUILD_PREBUILT) Compile a proper wpa_supplicant in your BoardConfig.mk In Android’s external directory, there are two wpa_supplicant_* projects. For wext-based wifi driver, wpa_supplicant_6 can be used. For nl80211-based WiFi driver, wpa_supplicnat_8 can only be used. But if WiFi vendors supply their own customized wpa_supplicant, it will be much easier to debug the communication between wpa_supplicant and WiFi drivers. No matter which supplicant  you choose, just control their compile in your BoardConfig.mk. Take atheros’s ath6kl as an example: ifeq ($(BOARD_WLAN_VENDOR),ATHEROS) BOARD_WLAN_DEVICE                        := ar6003 BOARD_HAS_ATH_WLAN                      := true WPA_SUPPLICANT_VERSION                  := VER_0_8_ATHEROS WIFI_DRIVER_MODULE_PATH                  := "/system/lib/modules/ath6kl_sdio.ko" WIFI_DRIVER_MODULE_NAME                  := "ath6kl_sdio" WIFI_DRIVER_MODULE_ARG                  := "suspend_mode=3 wow_mode=2 ar6k_clock=26000000 ath6kl_p2p=1" WIFI_DRIVER_P2P_MODULE_ARG              := "suspend_mode=3 wow_mode=2 ar6k_clock=26000000 ath6kl_p2p=1 debug_mask=0x2413" WIFI_SDIO_IF_DRIVER_MODULE_PATH          := "/system/lib/modules/cfg80211.ko" WIFI_SDIO_IF_DRIVER_MODULE_NAME          := "cfg80211" WIFI_SDIO_IF_DRIVER_MODULE_ARG          := "" WIFI_COMPAT_MODULE_PATH                  := "/system/lib/modules/compat.ko" WIFI_COMPAT_MODULE_NAME                  := "compat" WIFI_COMPAT_MODULE_ARG                  := "" endif then you need to provide a proper wpa_supplicant.conf  for your device. wpa_supplicant.conf  is very important because the control socket for android is specified in this file(ctrl_interface=). This file should be copied to /system/etc/wifi. Minimum required config options in wpa_supplicant.conf : There are two different ways in which wpa_supplicant can be configured, one is to use a "private" socket in android namespace, created by socket_local_client_connect() function in wpa_ctrl.c and another is by using a standard UNIX socket. Android private socket ctrl_interface=wlan0 update_config=1 - Unix standard socket ctrl_interface=DIR=/data/system/wpa_supplicant GROUP=wifi update_config=1 Modify your wifi.c in HAL Here what you should do is modifying some codes like wifi_load_driver and wifi_unload_driver. For Broadcom or CSR’s wifi driver, you can directly use the original wifi.c. But for atheros’s ath6kl driver, there are total three  .ko modules to install. So some micro variables and codes need to be changed to adapt it. Launch wpa_supplicant and dhcpcd services in init.rc If you have configured to use android private socket, you should do like this: service wpa_supplicant /system/bin/wpa_supplicant -Dwext -iwlan0 -c / data/misc/wifi /wpa_supplicant.conf socket wpa_wlan0 dgram 660 wifi wifi disabled oneshot or if you have configured to use unix standard socket, you should do like this: service wpa_supplicant /system/bin/wpa_supplicant -Dwext -iwlan0  -c/data/misc/wifi/wpa_supplicant.conf disabled oneshot If WiFi driver is not “wext” but “nl80211”, you should change it to –Dnl80211. For dhcpcd, you should lunch it like the following: service dhcpcd_wlan0 /system/bin/dhcpcd -ABKL     class late_start     disabled oneshot The parameters “-ABKL” can largely enhance wifi connection speed.  About what “ABKL” stand for, you can refer to dhcpcd’s GNU manual. Several debug tips Incorrect permissions will result in wpa_supplicant not being able to create/open the control socket andlibhardware_legacy/wifi/wifi.c won't connect. Since Google modified wpa_supplicant to run as wifi user/group the directory structure and file ownership should belong to wifi user/group (see os_program_init() function in wpa_supplicant/os_unix.c ). Otherwise errors like: E/WifiHW  (  😞 Unable to open connection to supplicant on "/data/system/wpa_supplicant/wlan0": No such file or directory will appear. Also wpa_supplicant.conf should belong to wifi user/group because wpa_supplicant will want to modify this file. How to Enable debug for wpa_supplicant.               By default wpa_supplicant is set to MSG_INFO that doesn't tell much.                    To enable more messages:                 modify common.c and set wpa_debug_level = MSG_DEBUG                 modify common.h and change #define wpa_printf from if ((level) >= MSG_INFO) to if ((level) >= MSG_DEBUG)         3. WiFi driver’s softmac.               For most vendors’ WiFi driver, the mac address is fixed. We should add one softmac rule to let WiFi driver’s mac is unique for each board.

Application notes covering the necessary changes to enable Bluetooth on the Sabre-SD EVK with the Silex SX-SDCAN 802.11a/b/g/n + BT WiFi device. Overview of the modifications needed on the Sabre-SD board, including information on Silex SD images for Android and Ubuntu that include the WiFi and BT drivers.

Qt Creator can be a very good IDE in order to develop great QT applications. This IDE does not only helps with syntax highlighting, access to examples and tutorials, but also helps you to configure different toolchains Qt binary versions and target options. First download the binary installer from: For 32 bits: $ wget http://releases.qt-project.org/qtcreator/2.6.2/qt-creator-linux-x86-opensource-2.6.2.bin For 64 bits: $ wget http://releases.qt-project.org/qtcreator/2.6.2/qt-creator-linux-x86_64-opensource-2.6.2.bin execute the binary $ ./qt-creator-linux-x86_64-opensource-2.6.2.bin Follow the Installer GUI and choose a location. Default options should be OK. in my case the installation was done here: $ /home/b35153/qtcreator-2.6.2/bin Open Qt Creator (in my case from command line, use "&" to regain control of the terminal) $./qtcreator & Open Tools -> Options Choose Build & Run  on the menu of the left. and Select the Compilers Tab Here you can add the toolchain GCC compiler of your convenience. It will appear in the "Manual"  section. Now click on Qt Version Tab.  Here you can add the Qmake that you had created with your Qt installation; for example, the Qt5 installation described here: Building QT for i.MX6 It will appear in the Manual section. In my case I have Qmake for PC and Qmake for i.MX6. Now click on Kits Tab Here you can create combinations of Compilers and Qmake, and also specify where do you want the executables to go. In my case here I combined the i.MX6 toolchain and the Qmake for I.MX6 i had created. I did not set up device configuration since the sysroot is already shared to my device via NFS, but you can configure it so the files are sent via ssh to your device. And that's It! Next time you load a project you can choose which Kit you want to work on, and it will be compiled just as you need.

How to Test Yocto for i.MX6 i.MX Yocto Project: How Can I Collaborate on the Freescale Yocto Project? i.MX Yocto Project: How Can I Build the Freescale Yocto Images using bitbake? i.MX Yocto Project: How Can I Build the Freescale Yocto Images using hob? i.MX Yocto Project: What Can I Do if I Run Into a Compilation Error? i.MX Yocto Project: Are There Prebuilt Images Available? i.MX Yocto Project: How Can I Quicken the Compilation? i.MX Yocto Project: how can I conserve disk space during builds? i.MX Yocto Project: How do I add an existing package to an image? i.MX Yocto Project: Can I use a virtual machine to build? i.MX Yocto Project: How can I build an image with (latest) mainline kernel? i.MX Yocto Project: How can I (quickly) modify a package' source code and test it? i.MX Yocto Project: How can I find out the packages include on an image? i.MX Yocto Project: How can I compile the kernel manually? i.MX Yocto Project: How can I patch the kernel? i.MX Yocto Proyect: How can I create a new Layer? i.MX Yocto Project: How can I contribute to the community? i.MX Yocto Project: Where can I see current  BSP issues? i.MX Yocto Project: Where are the mainstream repositories hosted? Tutorials: Yocto Training - HOME http://www.slideshare.net/OtavioSalvador/yocto-training-in-english - Great tutorial created by the Community's maintainer (there is also a Portuguese version) i.MX Yocto Project: Freescale Yocto Project Tutorial - It covers some basic developing tasks Others: Useful bitbake commands i.MX Yocto Project: ltib versus bitbake