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.

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

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.

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)

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

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.

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.

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.

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.

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

We are very proud to announce that Element14's SabreLite i.MX6Q board is now officially supported by Adeneo Embedded's i.MX6 WEC7 BSP. As a consequence, our customers are able to use the SabreLite board from Element14 as well as the one from Boundary Devices. Follow this link for Adeneo Embedded's i.MX6 WEC7 BSP Follow this link for Element 14's SabreLite board Ce document a été généré à partir de la discussion suivante : Element14's SabreLite board officially supported by Adeneo Embedded's i.MX6 WEC7 BSP

Abstract This is a small tutorial about running a simple OpenCL application in an i.MX6Q. It covers a very small introduction to OpenCL, the explanation of the code and how to compile and run it.   Requirements   Any i.MX6Q board. Linux BSP with the gpu-viv-bin-mx6q package (for instructions on how to build the BSP, check the BSP Users Guide)   OpenCL overview   OpenCL allows any program to use the GPGPU features of the GC2000 (General-Purpose Computing on Graphics Processing Units) that means to use the i.MX6Q GPU processing power in any program.   OpenCL uses kernels which are functions that can be executed in the GPU. These functions must be written in a C99 like code. In our current GPU there is no scheduling so each kernel will execute in a FIFO fashion. iMx6Q GPU is OpenCL 1.1 EP conformant. The Code   The example provided here performs a simple addition of arrays in the GPU. The header needed to use openCL is cl.h and is under /usr/include/CL in your BSP rootfs when you install the gpu-viv-bin-mx6q package. The header is typically included like this: #include <CL/cl.h> The libraries needed to link the program are libGAL.so and libOpenCL.so those are under /usr/lib in your BSP rootfs.   For details on the OpenCL API check the khronos page: http://www.khronos.org/opencl/ Our kernel source is as follows: __kernel void VectorAdd(__global int* c, __global int* a,__global int* b) {      // Index of the elements to add      unsigned int n = get_global_id(0);      // Sum the nth element of vectors a and b and store in c      c[n] = a[n] + b[n]; } The kernel is declared with the signature     __kernel void VectorAdd(__global int* c, __global int* a,__global int* b).   This takes vectors a and b as arguments adds them and stores the result in the vector c. It looks like a normal C99 method except for the keywords kernel and global. kernel tells the compiler this function is a kernel, global tells the compiler this attributes are of global address space. get_global_id built-in function   This function will tell us to which index of the vector this kernel corresponds to. And in the last line the vectors are added. Below is the full source code commented. //************************************************************ // Demo OpenCL application to compute a simple vector addition // computation between 2 arrays on the GPU // ************************************************************ #include <stdio.h> #include <stdlib.h> #include <CL/cl.h> // // OpenCL source code const char* OpenCLSource[] = { "__kernel void VectorAdd(__global int* c, __global int* a,__global int* b)", "{", " // Index of the elements to add \n", " unsigned int n = get_global_id(0);", " // Sum the nth element of vectors a and b and store in c \n", " c[n] = a[n] + b[n];", "}" }; // Some interesting data for the vectors int InitialData1[20] = {37,50,54,50,56,0,43,43,74,71,32,36,16,43,56,100,50,25,15,17}; int InitialData2[20] = {35,51,54,58,55,32,36,69,27,39,35,40,16,44,55,14,58,75,18,15}; // Number of elements in the vectors to be added #define SIZE 100 // Main function // ************************************************************ int main(int argc, char **argv) {      // Two integer source vectors in Host memory      int HostVector1[SIZE], HostVector2[SIZE];      //Output Vector      int HostOutputVector[SIZE];      // Initialize with some interesting repeating data      for(int c = 0; c < SIZE; c++)      {           HostVector1[c] = InitialData1[c%20];           HostVector2[c] = InitialData2[c%20];           HostOutputVector[c] = 0;      }      //Get an OpenCL platform      cl_platform_id cpPlatform;      clGetPlatformIDs(1, &cpPlatform, NULL);      // Get a GPU device      cl_device_id cdDevice;      clGetDeviceIDs(cpPlatform, CL_DEVICE_TYPE_GPU, 1, &cdDevice, NULL);      char cBuffer[1024];      clGetDeviceInfo(cdDevice, CL_DEVICE_NAME, sizeof(cBuffer), &cBuffer, NULL);      printf("CL_DEVICE_NAME: %s\n", cBuffer);      clGetDeviceInfo(cdDevice, CL_DRIVER_VERSION, sizeof(cBuffer), &cBuffer, NULL);      printf("CL_DRIVER_VERSION: %s\n\n", cBuffer);      // Create a context to run OpenCL enabled GPU      cl_context GPUContext = clCreateContextFromType(0, CL_DEVICE_TYPE_GPU, NULL, NULL, NULL);      // Create a command-queue on the GPU device      cl_command_queue cqCommandQueue = clCreateCommandQueue(GPUContext, cdDevice, 0, NULL);      // Allocate GPU memory for source vectors AND initialize from CPU memory      cl_mem GPUVector1 = clCreateBuffer(GPUContext, CL_MEM_READ_ONLY |      CL_MEM_COPY_HOST_PTR, sizeof(int) * SIZE, HostVector1, NULL);      cl_mem GPUVector2 = clCreateBuffer(GPUContext, CL_MEM_READ_ONLY |      CL_MEM_COPY_HOST_PTR, sizeof(int) * SIZE, HostVector2, NULL);      // Allocate output memory on GPU      cl_mem GPUOutputVector = clCreateBuffer(GPUContext, CL_MEM_WRITE_ONLY,      sizeof(int) * SIZE, NULL, NULL);      // Create OpenCL program with source code      cl_program OpenCLProgram = clCreateProgramWithSource(GPUContext, 7, OpenCLSource, NULL, NULL);      // Build the program (OpenCL JIT compilation)      clBuildProgram(OpenCLProgram, 0, NULL, NULL, NULL, NULL);      // Create a handle to the compiled OpenCL function (Kernel)      cl_kernel OpenCLVectorAdd = clCreateKernel(OpenCLProgram, "VectorAdd", NULL);      // In the next step we associate the GPU memory with the Kernel arguments      clSetKernelArg(OpenCLVectorAdd, 0, sizeof(cl_mem), (void*)&GPUOutputVector);      clSetKernelArg(OpenCLVectorAdd, 1, sizeof(cl_mem), (void*)&GPUVector1);      clSetKernelArg(OpenCLVectorAdd, 2, sizeof(cl_mem), (void*)&GPUVector2);      // Launch the Kernel on the GPU      // This kernel only uses global data      size_t WorkSize[1] = {SIZE}; // one dimensional Range      clEnqueueNDRangeKernel(cqCommandQueue, OpenCLVectorAdd, 1, NULL,      WorkSize, NULL, 0, NULL, NULL);      // Copy the output in GPU memory back to CPU memory      clEnqueueReadBuffer(cqCommandQueue, GPUOutputVector, CL_TRUE, 0,      SIZE * sizeof(int), HostOutputVector, 0, NULL, NULL);      // Cleanup      clReleaseKernel(OpenCLVectorAdd);      clReleaseProgram(OpenCLProgram);      clReleaseCommandQueue(cqCommandQueue);      clReleaseContext(GPUContext);      clReleaseMemObject(GPUVector1);      clReleaseMemObject(GPUVector2);      clReleaseMemObject(GPUOutputVector);      for( int i =0 ; i < SIZE; i++)           printf("[%d + %d = %d]\n",HostVector1[i], HostVector2[i], HostOutputVector[i]);      return 0; } How to compile in Host   Get to your ltib folder and run $./ltib m shell This way you will be using the cross compiler ltib uses and the default include and lib directories will be the ones in your bsp. Then run LTIB> gcc cl_sample.c -lGAL -lOpenCL -o cl_sample. How to run in the i.MX6Q   Insert the GPU module root@freescale/home/user $ modprobe galcore Copy the compiled CL program and then run root@freescale /home/user$ ./cl_sample References   [1] ttp://www.khronos.org/opencl/ Original Attachment has been moved to: libOpenCL.so.zip Original Attachment has been moved to: libCLC_Android.so.zip Original Attachment has been moved to: libOpenCL_Android.so.zip Original Attachment has been moved to: libCLC.so.zip

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.

Question: What exactly does the DTE/DCE interface in the i.MX6's UART module do and how are RTS and CTS affected by the UARTxUFCR[DTEDCE] bit? In i.MX6 RM, revision 1: Sections 64.2.1.2.1  (CTS) and 64.2.1.2.2 (RTS) both state that CTS and RTS change direction between DCE and DTE modes.  However, sections 64.4.3.1 (RTS_B) and 64.4.3.8 (CTS_B) state they do not change functions.  Is this a documentation error, or is there a difference between CTS/RTS and CTS_B/RTS_B? It appears that some of this is covered in the IOMUX daisy chain by switching which pins are connected to CTS and RTS. Answer: Example 1: UART1 in DTE mode. RTS is an output from the UART IP block so it must be routed to a CTS pin. Therefore, the SELECT_INPUT register could only use settings 00 or 10. Example 2: UART1 in DCE mode. RTS is an input to the UART IP block so it must be routed to an RTS pin. Therefore, the SELECT_INPUT register could only be set to 01 or 11. At this point, we have assumed that the internal signals connected to the UART block do not change direction.  We believe that DCEDTE from the UART block connects into the IOMUX logic and controls the direction of the PAD.  Then, the IOMUX INPUT_SELECT mux is used to choose one of four pads to connect to the UART inputs while the IMOUX MUX_CTRL connects the output path.  Further, we assume it is an error to connect the UART input to a pad configured as an output or a UART output to a pad configured as an input. The attached shows our assumptions For the Uart IP, the CTS_B is always an output and RTS_B always an input. But the RTS_B &CTS_B IO will be swapped  when UART operates in different DTE or DCE mode.  IO port DTE mode DCE mode direction Uart IP port(internal) direction Uart IP port(internal) UART_CTS_B O CTS_B I RTS_B UART_RTS_B I RTS_B O CTS_B UART_TXD O TXD I RXD UART_RXD I RXD O TXD Regarding how to configure the IOMUX, please see the attached PDF.

                                                                                         Watch the Freescale i.MX team boot up Android 5.0 Lollipop in i.mx6 application processors—在线播放—优酷网，视频高清在线观看 The Freescale i.MX Android team has booted up Android 5.0 Lollipop in the SABRE platform for i.mx6 series. Google pushed all of the latest source for its Android release to AOSP on Nov. 5, and the Freescale Android Team started their work. With the previous 6 days to boot Android Lollipop up, the Freescale i.MX Android team enabled the basic features like connectivity, audio/video playback, sensors, inputs and display on day 7! You can see the some changes in the demo video at the beginning of the post. The Freescale i.MX Android team has closely followed almost every version of Android since it is released by AOSP and has good experience on it. Below are some snapshots and pictures for the Android Lollipop.

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.

Boundary Devices has a tool to load directly a U-boot binary file, all using the USB OTG port. Assuming that you have connected your i.MX board to your Linux Host through an USB cable, board is power-on  with dip switches configure to 'Serial Download Mode' (this configuration depends on the board you are booting),  clone the imx_usb_loader repo, generate the tool then boot as indicate below: $ git clone https://github.com/boundarydevices/imx_usb_loader.git $ cd imx_usb_loader $ make $ ./ imx_usb   ../ tmp/deploy/images/ u-boot.imx On the console terminal, you should see the booting kernel logs and at the end reaching the login prompt. Useful Links: [1] Unbricking a Nitrogen6X or Sabre Lite i.MX6 board [2] Boundary Devices Repos [3] Boundary Devices Main page

If you want to use a USB camera (these types of cameras are also called 'Web Cameras') with GStreamer on i.MX6 devices (Linux Kernel version >= 3.035), you need to either load the module dynamically or compile and link statically selecting (Y) the following config on the Kernel configuration      Device Drivers -> Multimedia support -> Video capture adapters -> V4L USB devices -> <*> USB Video Class (UVC) After the Kernel image has been built, flash it into the target, plug the web cam, then on a (target) terminal run      gst-launch v4l2src ! mfw_v4lsink You should see what the camera is capturing on the display. In case you need to encode the camera src data, you need to place the encoder into the pipeline      gst-launch v4l2src num-buffers=100  ! queue ! vpuenc codec=0 ! matroskamux ! filesink location=output.mkv sync=false We are using a certain codec (codec=0 means mpeg4), check options using 'gst-inspect vpuenc'.

Multiple-Overlay (or Multi-Overlay) means several video playbacks on a single screen. In case multiple screens are needed, check the dual-display case GStreamer i.MX6 Multi-Display $ export VSALPHA=1 $ SAMPLE1=sample1.avi; SAMPLE2=sample2.avi; SAMPLE3=sample3.avi; SAMPLE4=sample4.avi; $ WIDTH=320; HEIGHT=240; SEP=20 Four displays (2x2) $gst-launch \ playbin2 uri=file://`pwd`/$SAMPLE1 video-sink="mfw_isink axis-top=0 axis-left=0   disp-width=$WIDTH disp-height=$HEIGHT" \ playbin2 uri=file://`pwd`/$SAMPLE2 video-sink="mfw_isink axis-top=0 axis-left=`expr $WIDTH + $SEP` disp-width=$WIDTH disp-height=$HEIGHT" \ playbin2 uri=file://`pwd`/$SAMPLE3 video-sink="mfw_isink axis-top=`expr $HEIGHT + $SEP` axis-left=0   disp-width=$WIDTH disp-height=$HEIGHT" \ playbin2 uri=file://`pwd`/$SAMPLE4 video-sink="mfw_isink axis-top=`expr $HEIGHT + $SEP` axis-left=`expr $WIDTH + $SEP` disp-width=$WIDTH disp-height=$HEIGHT" Basic rotation, (2 x 1, normal and inverted) gst-launch \ playbin2 uri=file://`pwd`/$SAMPLE1 video-sink="mfw_isink axis-top=0 axis-left=0   disp-width=$WIDTH disp-height=$HEIGHT rotation=0" \ playbin2 uri=file://`pwd`/$SAMPLE2 video-sink="mfw_isink axis-top=`expr $HEIGHT + $SEP` axis-left=0 disp-width=$WIDTH disp-height=$HEIGHT rotation=3"

In some cases it is desired to directly have progressive content available from a TV-IN interface through the V4L2 capture device. In the BSP, HW accelerated de-interlacing is only supported in the V4L2 output stream. Below is a patch created against a rather old BSP version that adds support for de-interlaced V4L2 capture. The patch might need to be adapted to newer BSPs, However, the logic and functionality is there and should shorten the development time. This patch adds another input device to the V4L2 framework that can be selected to perform the deinterlacing on the way to memory. The selection is done by passing the index “2” as an argument to the VIDIOC_S_INPUT  V4L2 ioctl. Attached is also a modified the tvin unit test to give an example of how to use the new driver. An example sequence for running the test is as follows: modprobe mxc_v4l2_capture ./mxc_v4l2_tvin_vdi.out -ow 720 -oh 480 -ol 10 -ot 20 -f YU12 Some key things to note: This driver does not support resize or color space conversion on the way to memory. The requested format and size should match what can be provided directly by the sensor. The driver was tested on a Sabre AI Rev A board running Linux 12.02. This code is not an official delivery and as such no guarantee of support for this code is provided by Freescale.