This documents shows how to secure and encrypt boot loader image for i.MX6 processor. Secure boot is necessary to be sure that CPU is allowed to run genuine and authentic images. Encrypted image secures your intellectual property from theft. Both methods secure/encryption can be extended to cover whole software on board. Boot loader image encryption is easy to do with CST tools and HAB feature build in Freescale processor. Encrypted image preparation is consist of three parts: Encrypt u-boot.imx plain image by CST utility; Wrap DEK to get DEK blob by specific board; Append DEK blob key to the u-boot image. In this document as reference board we used SABRESD iMX6q. But it's easily to adjust it for any other board based on i.MX6 CPU with HAB4.1 feature. Encrypted u-boot image consist of: IVT, DCD, u-boot.bin, CSF, dek_blob.bin. In our example finished u-boot_encrypted.imx image looks like: Address in file Data 0x000000 IVT 0x000020 DCD + pad to address 0xC00 0x000C00 u-boot.bin + pad to address* 0x7BC000 0x07DBB8 CSF bin data + pad to address** 0x07DBB8 + Wrapped DEK (dek_blob.bin)** * (IVT + DCD + u-boot.bin) has to be padded to align 0x1000. ** (CSF bin data + padding + dek_blob.bin) has to have size 0x2000 Step-by-step instruction: Clone u-boot git repository. $ mkdir ~/imx6encryption $ cd ~/imx6encryption $ git clone git://git.denx.de/u-boot.git $ cd u-boot $ git checkout v2016.03 -b tmp To enable secure features in u-boot modify the following files: Add function usec2ticks to the end of file timer.c. $ nano arch/arm/imx-common/timer.c unsigned long usec2ticks(unsigned long usec) {         ulong ticks;         if (usec < 1000)                 ticks = ((usec * (get_tbclk()/1000)) + 500) / 1000;         else                 ticks = ((usec / 10) * (get_tbclk() / 100000));         return ticks; } Press Ctrl+X and Y and Enter to save changes. In file mx6q_4x_mt41j128.cfg add string CSF 0x2000 after string BOOT_FROM sd $ nano board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg Press Ctrl+X and Y and Enter to save changes. Add defines in file mx6sabresd.h before string #define CONFIG_MACH_TYPE 3980. $ nano include/configs/mx6sabresd.h #define CONFIG_SECURE_BOOT #define CONFIG_SYS_FSL_SEC_COMPAT    4 /* HAB version */ #define CONFIG_FSL_CAAM #define CONFIG_CMD_DEKBLOB #define CONFIG_SYS_FSL_SEC_LE #define CONFIG_FAT_WRITE Press Ctrl+X and Y and Enter to save changes. Delete the following strings: gpimage.0 \ gpimage-common.o \ omapimage.o \ in Makefile. $ nano tools/Makefile Press Ctrl+X and Y and Enter to save changes Download Linaro GCC compiler. $ cd ~/imx6encryption $ wget -c https://releases.linaro.org/components/toolchain/binaries/5.3-2016.02/arm-linux-gnueabihf/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf.tar.xz $ tar xf gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf.tar.xz $ export CC=`pwd`/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- Check compiler version. $ ${CC}gcc --version Output: arm-linux-gnueabihf-gcc (Linaro GCC 5.3-2016.02) 5.3.1 20160113 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Build u-boot image with mx6qsabresd_defconfig. $ cd u-boot $ make ARCH=arm CROSS_COMPILE=${CC} distclean $ make ARCH=arm CROSS_COMPILE=${CC} mx6qsabresd_defconfig $ make ARCH=arm CROSS_COMPILE=${CC} Using mkimage utility build and get information of u-boot.imx image. $ ./tools/mkimage -T imximage -n board/freescale/mx6sabresd/mx6q_4x_mt41j128.cfg.cfgtmp -e 0x17800000 -d u-boot.bin u-boot.imx Output: Image Type:   Freescale IMX Boot Image Image Ver:    2 (i.MX53/6/7 compatible) Data Size:    516096 Bytes = 504.00 kB = 0.49 MB Load Address: 177ff420 Entry Point:  17800000 HAB Blocks:   177ff400 00000000 0007bc00 Register an account on NXP website to have access to download NXP Code Signing Tool for the High Assurance Boot library. Copy downloaded archive into “imx6encryption” folder. $ cd ~/imx6encryption $ tar xf cst-2.3.1.tar.gz $ cd cst-2.3.1 $ chmod u+x linux64/* keys/* Compile back end sources of CST utility $ sudo apt-get install libssl-dev $ cd ~/imx6encryption/cst-2.3.1/code/back_end/src $ gcc -o cst -I ../hdr -L ../../../linux64/lib *.c -lfrontend -lcrypto $ mv cst ../../../linux64 Generate keys and certificates which will be used to sign boot loader image. $ cd ~/imx6encryption/cst-2.3.1/keys Create file serial. $ nano serial Enter 8 random digits, for example: 12345678 Press Ctrl+X and Y and Enter to save changes. Create key_pass.txt $ nano key_pass.txt Enter two lines of identical text: HelloWorld HelloWorld Press Ctrl+X and Y and Enter to save changes. Execute hab4_pki_tree.sh. $ ./hab4_pki_tree.sh Do you want to use an existing CA key (y/n)?: n Enter key length in bits for PKI tree: 2048 Enter PKI tree duration (years): 10 How many Super Root Keys should be generated? 4 Do you want the SRK certificates to have the CA flag set? (y/n)?: y Generate SRK table. $ cd ~/imx6encryption/cst-2.3.1/crts $ ../linux64/srktool -h 4 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -d sha256 -c ./SRK1_sha256_2048_65537_v3_ca_crt.pem,./SRK2_sha256_2048_65537_v3_ca_crt.pem,./SRK3_sha256_2048_65537_v3_ca_crt.pem,./SRK4_sha256_2048_65537_v3_ca_crt.pem -f 1 CST utility requires CSF script. This file describes certificates, keys and the data ranges used in sign and encryption functions. Create u-boot.csf file. $ cd ~/imx6encryption/cst-2.3.1/linux64 $ nano u-boot.csf And put the following text: [Header] Version = 4.1 Hash Algorithm = SHA256 Engine Configuration = 0 Certificate Format = X509 Signature Format = CMS Engine = CAAM [Install SRK] File = "../crts/SRK_1_2_3_4_table.bin" # Index of the key location in the SRK table to be installed Source index = 0 [Install CSFK] # Key used to authenticate the CSF data File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem" [Authenticate CSF] [Unlock] Engine = CAAM Features = RNG [Install Key] # Key slot index used to authenticate the key to be installed Verification Index = 0 # Key to install Target Index = 2 File = "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem" [Authenticate Data] # Key slot index used to authenticate the image data Verification Index = 2 #       Address   Offset        Length      Data File Path Blocks = 0x177ff400 0x00000000 0x00000C10 "./u-boot.imx" #Encrypt the boot image and create a DEK [Install Secret Key] Verification Index = 0 Target Index = 0 Key = "./dek.bin" Key Length = 128 Blob Address = 0x1787CFB8 #Provide DEK blob location to decrypt [Decrypt Data] Verification Index = 0 Mac Bytes = 16 Blocks = 0x17800010 0x00000C10 0x0007AFF0 "./u-boot.imx" Press Ctrl+X and Y and Enter to save changes. Execute CST utility to encrypt image. Note that after execution u-boot.imx file will be encrypted. $ cp ~/imx6encryption/u-boot/u-boot.imx . $ ./cst --o u-boot_csf.bin < u-boot.csf $ objcopy -I binary -O binary --pad-to=0x1FB8 --gap-fill=0x00 u-boot_csf.bin u-boot_csf.bin Prepare SD card partition table. Check SD card name in system ($dmesg | tail), for example used /dev/sdb. $ echo -e "o""\n""n""\n""p""\n""1""\n""2048""\n""+256M""\n""w" | sudo fdisk /dev/sdb $ sudo mkfs.vfat /dev/sdb1 $ cd ~/imx6encryption/u-boot $ sudo dd if=u-boot.imx of=/dev/sdb bs=512 seek=2 $ sync Wrap DEK to get DEK blob from i.MX6 CPU. Mount partition 1 and copy dek.bin file to the 1st FAT partition on SD card. $ cd ~/imx6encryption/cst-2.3.1/linux64 $ mkdir /tmp/partition0 $ sudo mount /dev/sdb1 /tmp/partition0 $ sudo cp dek.bin /tmp/partition0 $ sudo umount /tmp/partition0 Insert SD card into the board. And press any key to enter into u-boot prompt. Firstly load dek.bin to the RAM memory. Use dek_blob command to wrap dek.bin. Write file from RAM memory to SD card. => fatload mmc 1:1 0x10800000 dek.bin => dek_blob 0x10800000 0x10801000 128 => fatwrite mmc 1:1 0x10801000 dek_blob.bin 0x48 Append DEK blob key to the u-boot image. Mount SD card partition 1 and copy dek_blob.bin file to the linux64 folder. $ mkdir -p /tmp/partition0 $ sudo mount /dev/sdb1 /tmp/partition0 $ cd /tmp/partition0 $ cp dek_blob.bin ~/imx6encryption/cst-2.3.1/linux64/ $ cd ~/imx6encryption/cst-2.3.1/linux64/ $ sudo umount /tmp/partition0 $ cat u-boot_csf.bin >> u-boot.imx $ cat dek_blob.bin >> u-boot.imx Install encrypted u-boot.imx into SD card. $ sudo dd if=u-boot.imx of=/dev/sdb bs=512 seek=2 $ sync Insert SD card into the board. Press any key to enter into u-boot prompt. And check if hab_status command executes without HAB Event errors. => hab_status Attention, OTP fuses can be programmed once, double check everything before burning. If everything is fine, burn required fuses SRK_HASH, SEC_CONFIG as described in AN4581. As a result we have encrypted boot image which can be loaded and executed by only current board. Because dek_blob.bin is unique per i.MX6 CPU. Vitaliy Vasinovich April 2016

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

1. Enable QtMultimedia 1) In “source/meta-qt5/recipes-qt/qt5/qtmultimedia_git.bb”, add “gstreamer” at the end of “PACKAGECONFIG ??=” .      For example on  L3.14.52  bsp, build  x11  backend: PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)} \                    ${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio', 'pulseaudio', '', d)} \                    gstreamer" 2) Build qtmultimedia:  bitbake qtmultimedia 3) Copy the built package to target file system.      For example : cp  -a ./build-x11/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtmultimedia/5.5.0+gitAUTOINC+46a83d5b86-r0/image/usr/   /usr   export  DISPLAY=:0 Video example application located at : /usr/share/qt5/examples/multimedia/video/qmlvideo 2. Enable Qt Logging Info export  QT_LOGGING_RULES=<category>[.type]=ture|false      For example: Turn on all debug logging:      export QT_LOGGING_RULES=*.debug=true Turn on all logging level of all multimedia module:      export QT_LOGGING_RULES=qt.multimedia.*=true 3. Performance Checking Gstreamer: overlaysink fps=51.585      gst-launch-1.0 playbin uri=file:///H264_AVC_1080p_30fps_27Mbps_mp3.avi  video-sink=”overlaysink sync=false” Gstreamer: glimagesink fps=43.850      gst-launch-1.0 playbin uri=file:///H264_AVC_1080p_30fps_27Mbps_mp3.avi video-sink="glimagesink sync=false" Qtmultimedia: fps=45.201      ./qmlvideo  -url file:///H264_AVC_1080p_30fps_27Mbps_mp3.avi -hide-perf Current qt5 multimedia has a special video node for imx6 at     "/src/plugins/videonode/imx6" which uses GPU DirectVIV to accelerate the video rendering. So  the rendering performance is almost same as the glimagesink. For check the free run frame rate, the qt multimedia source need change a little bit to set sink sync as false and calculate the real video rendering rate. Set sync as false: In "/src/plugins/gstreamer/mediaplayer/qgstreamerplayersession.cpp" QGstreamerPlayerSession::playbinNotifySource(): -       g_object_set(G_OBJECT(self->m_videoSink), "sync", !self->m_isLiveSource, NULL); +       g_object_set(G_OBJECT(self->m_videoSink), "sync", false/!self->m_isLiveSource/, NULL); Get fps: In "/src/gsttools/qgstvideorenderersink.cpp" +#include <QTime> +gint g_frame_showed; +QTime g_time; + bool QVideoSurfaceGstDelegate::start(GstCaps *caps) … +   g_frame_showed = 0; +   g_time.restart(); … void QVideoSurfaceGstDelegate::stop() … +   printf(">>>>> fps=%f:\n", (gdouble)g_frame_showed*1000/g_time.elapsed()); … bool  QVideoSurfaceGstDelegate::handleEvent(QMutexLocker *locker) …             const bool rendered = m_activeRenderer->present(m_surface, buffer); +   g_frame_showed++; … Or use the attached patch: qtmultimedia_fps_check.diff 4. Streaming Playing:  HTTP RTP RTSP HTTP: ./qmlvideo -url http://10.192.225.205/streaming/http/H264_HP13_1280x720_29_2850_AAC_LC_44_64_NobodyMTV.mp4 RTSP: ./qmlvideo -url rtsp://10.192.225.205/MPEG4_SP1_720x576_30fps_282_AMRNB_TVC.mp4 RTP: QT mediaplayer use gstreamer playbin as the backend, playbin don’t support rtp address as uri. So QT mediaplayer can’t support RTP playing directly. 5. Audio Recording /usr/share/qt5/examples/multimedia/audiorecorder/audiorecorder This is a widget application, not a QML application. It use QAudioRecorder as its background worker. By default it will use pulsesrc and lamemp3enc to recorder audio as mkv file at user home folder with name of clip_0001.mkv, clip_0002.mkv, and so on. If need special pipeline for recording, example use imxmp3enc to record mp3 files, we need change the function GstElement *QGstreamerCaptureSession::buildEncodeBin in  “src/plugins/gstreamer/mediacapture/qgstreamercapturesession.cpp” as well as QGstreamerMediaContainerControl(QObject *parent) in “src/plugins/gstreamer/mediacapture/qgstreamermediacontainercontrol.cpp” 6. Camera Widgets Application: “/usr/share/qt5/examples/multimediawidgets/camera/camera” QML Application: “/usr/share/qt5/examples/multimedia/declarative-camera/declarative-camera” Qt Multimedia has some bugs on L3.14.52 with QCamera for recording. Use the attached patches: 0001-gstreamer-fix-camerabin-not-negotiated-error.patch 0001-QCamera-can-t-set-recording-container-format-video-a.patch 0002-QtCamera-change-default-encoding-parameters-to-use-N.patch If you want use overlaysink as the preview sink, then use following patch: 0003-use-overlaysink-as-the-preview-sink.patch Both applications need to set environment variable QT_GSTREAMER_CAMERABIN_VIDEOSRC to use imxv4l2src If camera device is other than /dev/video0, set environment variable QT_GSTREAMER_CAMERABIN_VIDEOSRC_DEVICE to the right camera device, such as "/dev/video1" ,  for example: export QT_GSTREAMER_CAMERABIN_VIDEOSRC=imxv4l2src export DISPLAY=:0 export QT_GSTREAMER_CAMERABIN_VIDEOSRC_DEVICE="/dev/video1" By default, the “post-preview” feature of camerabin was disabled by the patches provided, since the imxv4l2src can’t work with “post-preview” internal “videoconvert” element. To enable “post-preview”  feature, one need uncomment following line //g_object_set(G_OBJECT(m_camerabin), POST_PREVIEWS_PROPERTY, TRUE, NULL); in “/qtmultimedia/src/plugins/gstreamer/camerabin/camerabinsession.cpp”, Function: CameraBinSession::CameraBinSession(GstElementFactory *sourceFactory, QObject *parent) And Change “videoconvert” to “imxvideoconvert_g2d” or “imxvideoconvert_ipu” or “imxvideoconvert_pxp” in line : csp = gst_element_factory_make ("videoconvert", "preview-vconv"); of  file “/gstreamer1.0-plugins-bad/gst-libs/gst/basecamerabinsrc/gstcamerabinpreview.c”  function: GstCameraBinPreviewPipelineData *gst_camerabin_create_preview_pipeline (GstElement * element,   GstElement * filter)

INTRODUCTION REQUIREMENTS DEVICE TREE BOOTING LINUX 1. INTRODUCTION     This document explains how to use the yocto images and tailor the source code for a different board. The board used in this document is the Udoo board that features an iMX6Q. In this document U-Boot Migration Example the U-boot changes are covered and it must be followed before this one. The below steps will cover the next board changes:     Ethernet PHY     SD card     Debug UART 2. REQUIREMENTS A functional Yocto environment (Images generated for your target, core-image-minimal). The images generated must be chosen for the imx6q, which is the one explained in this document. Toolchain. The meta-toolchain is used in this document. L3.14.38 is used in this document. Build Kernel using meta-toolchain A SD card with the core-image-minimal image. NOTE: Follow the next training that explains in detail the steps to cover the requirements. Yocto Training - HOME 3. DEVICE TREE        In previous Linux versions 3.0.35 backwards, the kernel contained hardcoded structures in C language used for board and platform specific configurations. Thanks to the device tree, the same kernel image can be used for different boards and the description of the platform and board is defined in a different file. Therefore the same kernel used by the SABRE-SD or SABRE-AI board can be used for the Udoo board and only  a new Device Tree file has to be generated. 3.1 ADDING A NEW DEVICE TREE After you have chosen the configuration of the corresponding board (imx_v7_defconfig), exported the needed environment variables like ARCH, CROSS_COMPILE; the new .dts file must be added. In the linux source folder arch/arm/boot/dts create a file named imx6q-udoo-doc.dts. This is the .dts file that contains the hardware description. $ touch imx6q-udoo-doc.dts Add the new dts file in the Makefile found in arch/arm/boot/dts. The file must be inside the precomipler directive $(CONFIG_ARCH_MXC) 3.2 DEVICE TREE CONTENT Using your prefered text editor, add the dts version at the top of the file /dts-v1/; There is already a dtsi file that describes  the imx6q device named imx6q.dtsi. Include this file in the new dts . #include "imx6q.dtsi" Add the root node, model and compatible property. The udoo,imx6q-udoo property does not exist in the DT_MACHINE structure, but fsl,imx6q does. / {         model = "Udoo i.MX6 Quad Board";         compatible = "udoo,imx6q-udoo", "fsl,imx6q"; }; Add the memory region. memory{           reg = <0x10000000 0x40000000>; }; Add the pinctrl configurations for the nodes you want to add. UART2_TXD and UART2_RXD are the pins used for the serial debug console. The pin description must be placed in the iomuxc node. &iomuxc{      imx6q-udoo{           pinctrl_uart2: uart2grp{                fsl,pins = <                          MX6QDL_PAD_EIM_D26__UART2_TX_DATA          0x1b0b1                          MX6QDL_PAD_EIM_D27__UART2_RX_DATA          0x1b0b1                           >;                };          };      }; The RGMII connection and SD characteristics are the same as iMX6Q SABRE-SD . pinctrl_usdhc3: usdhc3grp {                         fsl,pins = <                                MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059                                MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059                                MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059                                MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059                                MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059                                MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059                         >;                 }; pinctrl_enet: enetgrp {                         fsl,pins = <                                                  MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0                                MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0                                MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0                                MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0                                MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0                                MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0                                MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0                                MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0                                MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0                                MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0                                MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0                                MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0                                MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0                                MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0                                MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0                                MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8                         >;                      }; The fec, uart2 and usdhc3 nodes must be added. These nodes exist already in the imx6q.dtsi but the status property, pinctrl  among others must be added. &fec {         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_enet>;         phy-mode = "rgmii";             status = "okay";        };                                                      &uart2 {         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_uart2>;         status = "okay";        };                                                                                                                                              &usdhc3 {                                        pinctrl-names = "default";               pinctrl-0 = <&pinctrl_usdhc3>;         non-removable;                  status = "okay"; }; Below is the simple dts file resulting from the above points. /dts-v1/; #include "imx6q.dtsi" / {         model = "Udoo i.MX6 Quad Board";         compatible = "udoo,imx6q-udo", "fsl,imx6q";         memory {                 reg = <0x10000000 0x80000000>;         }; }; &fec {         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_enet>;         phy-mode = "rgmii";         status = "okay"; }; &uart2 {         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_uart2>;         status = "okay"; }; &usdhc3 {         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_usdhc3>;         non-removable;         status = "okay"; }; &iomuxc {         imx6q-udoo {                 pinctrl_enet: enetgrp {                         fsl,pins = <                                 MX6QDL_PAD_RGMII_RXC__RGMII_RXC         0x1b0b0                                 MX6QDL_PAD_RGMII_RD0__RGMII_RD0         0x1b0b0                                 MX6QDL_PAD_RGMII_RD1__RGMII_RD1         0x1b0b0                                 MX6QDL_PAD_RGMII_RD2__RGMII_RD2         0x1b0b0                                 MX6QDL_PAD_RGMII_RD3__RGMII_RD3         0x1b0b0                                 MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL   0x1b0b0                                 MX6QDL_PAD_RGMII_TXC__RGMII_TXC         0x1b0b0                                 MX6QDL_PAD_RGMII_TD0__RGMII_TD0         0x1b0b0                                 MX6QDL_PAD_RGMII_TD1__RGMII_TD1         0x1b0b0                                 MX6QDL_PAD_RGMII_TD2__RGMII_TD2         0x1b0b0                                 MX6QDL_PAD_RGMII_TD3__RGMII_TD3         0x1b0b0                                 MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL   0x1b0b0                                 MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK    0x1b0b0                                 MX6QDL_PAD_ENET_MDIO__ENET_MDIO         0x1b0b0                                 MX6QDL_PAD_ENET_MDC__ENET_MDC           0x1b0b0                                 MX6QDL_PAD_GPIO_16__ENET_REF_CLK        0x4001b0a8                         >;                 };                 pinctrl_uart2: uart2grp {                         fsl,pins = <                                 MX6QDL_PAD_EIM_D26__UART2_TX_DATA       0x1b0b1                                 MX6QDL_PAD_EIM_D27__UART2_RX_DATA       0x1b0b1                         >;                 };                 pinctrl_usdhc3: usdhc3grp {                         fsl,pins = <                                 MX6QDL_PAD_SD3_CMD__SD3_CMD             0x17059                                 MX6QDL_PAD_SD3_CLK__SD3_CLK             0x10059                                 MX6QDL_PAD_SD3_DAT0__SD3_DATA0          0x17059                                 MX6QDL_PAD_SD3_DAT1__SD3_DATA1          0x17059                                 MX6QDL_PAD_SD3_DAT2__SD3_DATA2          0x17059                                 MX6QDL_PAD_SD3_DAT3__SD3_DATA3          0x17059                         >;                 };         }; }; 3.3 COMPILING DEVICE TREE Compiling the .dts will generate a .dtb file that is the binary file the kernel needs. make ARCH=arm dtbs A file named imx6q-udoo-doc.dtb is the file used by our board. It is found in  arch/arm/boot/dts folder. If you have a SD with a working image, place this file in the FAT partition. You may need to change the file name first, in this case for imx6q-udoo.dtb. 4. BOOTING THE IMAGE After this you should have a simple and functional linux system. Just plug-in your SD card and power-up the board.  You should get an output in the serial console like the one below: I hope you find this basic document helpful.

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

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

There are two ways: 1. BitBake. Append the package into the IMAGE_INSTALL variable. But In case you want the package in every image,  add a line to your conf/local.conf file IMAGE_INSTALL_append = " package"           Make sure to include the space BEFORE the package name. You can add other packages, just place spaces in-between. In case you want the package in a particular image, e.g. fsl-image-gui,, add it on meta-fsl-demos/recipes-fsl/images/fsl-image-gui.bb IMAGE_INSTALL += " \     ${SOC_IMAGE_INSTALL} \     cpufrequtils \     nano \     packagegroup-fsl-gstreamer \     packagegroup-fsl-tools-testapps \     packagegroup-fsl-tools-benchmark \     packagegroup-qt-in-use-demos \     qt4-plugin-phonon-backend-gstreamer \     qt4-demos \     qt4-examples \     fsl-gui-extrafiles \     package \     " 2. Hob. Due to its graphical nature, adding more packages to a base image is easier than the bitbake way. Run the hob app under the build folder, select your machine and image, then edit the later (click on the Edit image button) In case the package is not available, you need to create it. As a starting point take a look at this example. In case you consider is good enough to be present on the mainstream repos, send the patch to the meta-freescale mailing list.

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.

Introduction LVDS display panel driving data flow: Display quality: To get the best display quality for 24bit LVDS display panel in Android, we should use 32bit framebuffer, make IPUv3 display Engine and LDB output 24bit pixels, since RGB component information is aligned from source to destination.  2 stages to enable display: Uboot splash screen and Kernel framebuffer Guidelines Uboot splash screen:    Change should be done in board file, like board/freescale/mx6q_sabresd/mx6q_sabresd.c:    1. Set video mode in struct fb_videomode according to the new 24bit LVDS display panel’s spec(please, refer to the example at the end of this doc).    2. Set up pwm, iomux/display related clock trees in lcd_enable(). Note that these should be aligned with Kernel settings to support smooth UI transition        from Uboot splash screen to Kernel framebuffer.    3. Set the output pixel format of IPUv3 display engine and LDB to IPU_PIX_FMT_RGB24 when calling ipuv3_fb_init().    4. Set pixel clock according to the new 24bit LVDS display panel’s spec when calling ipuv3_fb_init().    5. If dual LDB channels are needed to support tough display video mode(high resolution or high pixel clock frequency), we need to enable both of the two LDB        channels and set LDB to work at split mode. LDB_CTRL register should be set accordingly in lcd_enable(). Kernel framebuffer:    As we may add ‘video=‘  and ‘ldb=’ options in kernel bootup command line, Kernel code is more flexible to handle different LVDS display panels with various display color depth than Uboot code. For detail description of ‘video=’ and ‘ldb=’ option, please refer to MXC Linux BSP release notes and Android User Guide. Some known points are:    1. Add a video mode in struct fb_videomode in drivers/video/mxc/ldb.c according to the new 24bit LVDS display panel’s spec(please, refer to the example at        the end of this doc).    2. Set up pwm backlight/display related iomux in platform code.   3. Set appropriate ‘video=‘ option in kernel bootup command line, for example:        video=mxcfb0:dev=ldb,LDB-NEW,if=RGB24,fbpix=RGB32     4. Set appropriate ‘ldb=‘ option in kernel bootup command line if dual LDB channels are needed to support tough display video mode, for example:        ldb=spl0 (IPUv3 DI0 is used)  or  ldb=spl1 (IPUv3 DI1 is used)    5. Set appropriate ‘fbmem=‘ option in kernel bootup command line to reserve enough memory for framebuffer. For example, if we use 1280x800 LVDS panel        for fb0 and fb0 is in RGB32 pixel format, then ‘fbmem=12M’ should be used, since the formula is:        fbmem= width*height*3(triple buf)*Bytes_per_pixel= 1280*800*3*4B=12MB An Example to Set struct fb_videomode:    Let’s take a look at the timing description quoted from a real 1280x800@60 24bit LVDS panel spec: And, standard linux struct fb_videomode definition in include/linux/fb.h: struct fb_videomode {         const char *name;       /* optional */         u32 refresh;            /* optional */         u32 xres;         u32 yres;         u32 pixclock;         u32 left_margin;         u32 right_margin;         u32 upper_margin;         u32 lower_margin;         u32 hsync_len;         u32 vsync_len;         u32 sync;         u32 vmode;                u32 flag; };    What we need to do is to set every field of struct fb_videomode correctly according to the timing description of LVDS display panel’s spec:     1. name: we can set it to ‘LDB-WXGA’.    2. refresh: though it’s optional, we can set it to typical value, that is, 60(60Hz refresh rate).    3. xres: the active width, that is, 1280.    4. yres: the active height, that is, 800.    5. pixclock: calculate with this formula – pixclock=(10^12)/clk_freq. Here, typically, for this example, pixclock=(10^12)/71100000=14065.    6. left_margin/right_margin/hsync_len:        They are the same to HS Back Porch(HBP)/HS Front Porch(HFP)/HS Width(HW) in the spec. Since the spec only tells us that typically        HBP+HFP+HW=160. We may set left_margin=40, right_margin=40, hsync_len=80.    7. upper_margin/lower_margin/vsync_len:        Similar to horizontal timing, the vertical ones can be set to upper_margin=10, lower_margin=3, vsync_len=10.    8. sync: Since the timing chart tells us that hsync/vsync are active low, so we don’t need to set FB_SYNC_HOR_HIGH_ACT or        FB_SYNC_VERT_HIGH_ACT. Moreover, clock polarity and data polarity are invalid, so we set sync to be zero here.    9. vmode: this is a progressive video mode, so set vmode to FB_VMODE_NONINTERLACED.    10. flag: the video mode is provided by driver, so set flag to FB_MODE_IS_DETAILED.

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

Downloading and building the IPU examples IPU examples - v0.1 are available at https://github.com/rogeriorps/ipu-examples To download, just clone the project: $ git clone https://github.com/rogeriorps/ipu-examples.git Follow the README.md on the project root folder to build and install it. Available demos Alpha Blending Basic Combining Cropping Color Space Conversion Deinterlacing Resizing Rotation i.MX5 basic_ex1 rot_ex1 i.MX6 alpha_ex1 alpha_ex2 crop_ex1 csc_ex1 dint_ex1 res_ex1 rot_ex1 i.MX5 Basic examples basic_ex1: Prints all information from all framebuffers. It uses only the framebuffer device /dev/fb*. Rotation examples rot_ex1: Rotate an image a show on display. This example uses the ipu library instead using directly the /dev/mxc_ipu. i.MX6 Alpha blending examples alpha_ex1: This example shows how to use global alpha blending. It fills layer 1 with white color, an overlay layer with 4 color strips and varies the global alpha blending, showing on display 2 planes at the same time with different transparency rates. alpha_ex2: This example shows how to use local alpha blending. This example uses 3 buffers: 1 - Input buffer: Used as layer 1 (background). 2 - Overlay buffer: Used as layer 2 (foreground). 3 - Alpha buffer: Used as alpha buffer, where each pixel will correspond to the transparency value between input and overlay buffers. When running it will fill input and overlay buffers with solid colors, alpha buffer with 4 different alpha strips and will turn on and off the local alpha blending. Color space conversion examples csc_ex1: This example shows how to use color space conversion. It reads 4 different formats images (RGB565, RGBA32, NV12 and YUYV422) and show them on background framebuffer on a RGB565 format. Crop example crop_ex1: This example shows how to crop an image using "output crop". It fills the input buffer with a solid color and crop the output buffer. The result will be a solid block on the display. De-interlace example dint_ex1: This example shows how to de-interlace a single interlaced frame. The example loads an 320x240 interlaced NV12 image and show on display turning on and off the de-interlace feature. Resize examples res_ex1: This example resizes the image freescale_1024x768.raw (1024x768 RGB565 format) to an 800x480 RGB24 format image, storing into a local file output_file.raw. Rotation examples rot_ex1: This example rotates the image freescale_1024x768.raw (1024x768 RGB565 format) and displays using all rotation modes: 0 - No rotation 1 - Vertical flip 2 - Horizontal flip 3 - 180 degrees 4 - 90 degrees right 5 - 90 degrees right with vertical flip 6 - 90 degrees right with horizontal flip 7 - 90 degrees left Known issues

This is the prototype demo to enable surround view demo on SabreSD.   The attached Files are HW&SW guides and demo video. Updating Notes: Add miniPCIE Surround View_Rev A design file (include schematic and layout) as attachement. Add Gerber file   i.MX6Q Surround view patch https://community.freescale.com/docs/DOC-95143 Original Attachment has been moved to: Gerber-file.zip Original Attachment has been moved to: miniPCIe-Surround-View_Rev-A.zip

The Linux Kernel is just another recipe for Yocto, so learning to patch it you learn to patch any other package. In the other hand, Yocto **should not** be used for package development, but in those rare cases follow the below steps. It is assumed that you have already build the package you want to patch. 1. Create the patch or patches. In this example we are patching the Linux kernel for [wandboard-dual](http://www.wandboard.org/) machine; in other words, the value of MACHINE on the `build/conf/local.conf` is `MACHINE ??= 'wandboard-dual'`. In case you already have the patches, make sure these can be nicely applied with the commands `git apply --check <PATCH_NAME>`, and jump this step build $ cd tmp/work/wandboard_dual-poky-linux-gnueabi/linux-wandboard/3.0.35-r0/git build $ # Edit any files you want to change build $ git add <modified file 1> <modified file 2> .. # Select the files you want to commit build $ git commit -s -m '<your commit's title>' # Create the commit build $ git format-patch -1 # Create the patch 2. Create a new layer (see document i.MX Yocto Proyect: How can I create a new Layer?) 3. On the new layer (e.g `meta-fsl-custom`) , create the corresponding subfolders and the `.bbfile` sources $ mkdir -p meta-fsl-custom/recipes-kernel/linux/linux-wandboard-3.0.35/ sources $ cat > meta-fsl-custom/recipes-kernel/linux/linux-wandboard_3.0.35.bbappend FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:" SRC_URI += "file://0001-calibrate-Add-printk-example.patch" PRINC := "${@int(PRINC) + 1}" # SEE NOTE BELLOW ^d (The PRINC variable is not needed starting at Yocto 1.6 ([RFC] base.bbclass: Deprecate the PRINC logic - Patchwork)) 4. Move the patch to the new layer sources $ cp \ ../build/tmp/work/wandboard_dual-poky-linux-gnueabi/linux-wandboard/3.0.35-r0/git/0001-calibrate-Add-printk-example.patch \ meta-fsl-custom/recipes-kernel/linux/linux-wandboard-3.0.35 5. Setup the enviroment and clean previous package's build data (sstate) fsl-community-bsp $ . setup-environment build build $ bitbake -c cleansstate linux-wandboard 6. Compile and Deploy build $ bitbake -f -c compile linux-wandboard build $ bitbake -c deploy linux-wandboard 7. Insert the SD into your Host and copy the `uImage` into the first partition. Do not forget to unmount the partition before removing the card! build $ sudo cp tmp/deploy/images/uImage /media/Boot\ wandbo/ 8. Insert the SD into your board and test your change.

Symptoms   Trying to initialize a repo, for example:  $repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.36-2.1.0.xml we have the below log: File "/home/username/bin/repo", line 51 def print(self, *args, **kwargs): ^ SyntaxError: invalid syntax   Workaround (1)   The first workaround consist in change the python alternatives (caused when you have installed two or more python versions). NOTE: in my case, the python version that i want to change as first priority is python3.8 $sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.8 1   Then we run: $sudo update-alternatives --config python    To verify if your python priority was changed successfully try: $python --version   You should see the version configured as priority number 1.     Workaround (2)   The workaround is very simple, only we need modify the repo file $ nano ~/bin/repo   and we will change the python interpreter in the first line (from python to python3): ORIGINAL FILE   EDITED FILE   After to do this change, repo will works fine again.     I hope this can helps to you!   Best regards.

The edit-compile-test loop is the quickest way so can test your changes. 1. Go to the package's source code folder and edit your files. 2. Compile that particular package, e.g. bitbake linux-imx -c compile -f 3. Deploy, e.g. bitbake linux-imx -c deploy 4. Insert the SD card into your host, and copy the Linux kernel into the the first partition sudo cp tmp/deploy/images/uImage /media/Boot 5. Insert the SD card into your board, boot and test your changes 6. In case you are satisfied with the results, you need to create a patch and add into the package's recipe. Check this document to execute this step.

This is the procedure and patch to set up Ubuntu 14.04 64bit Linux Host PC and building i.MX6x L3.0.35_4.1.0. It has been tested to build GNOME profile and with FSL Standard MM Codec for i.MX6Q SDP with LVDS display. Add suggestion about compiling "gstreamer-plugins-good" when selecting "Min profile" rootfs.  Please refer to the Note session. A) Basic Requirement: Set up the Linux Host PC using ubuntu-14.04-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC      Needed packages: $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 $ sudo apt-get install libc6-dev-i386 $ sudo apt-get install u-boot-tools $ sudo apt-get install scrollkeeper $ sudo ln -s /usr/lib/x86_64-linux-gnu/librt.so   /usr/lib/librt.so      Useful tools: $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd      Note: this operation "$ sudo ln -s /usr/lib/x86_64-linux-gnu/librt.so /usr/lib/librt.so" is used to fix rpm-fs build issue; which is taking reference from: LTIB - Strange problem building IMX6 Linux BSP from fresh on Ubuntu 13.10 C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L3.0.35_4.1.0_130816_source. tar.gz $ ./L3.0.35_4.1.0_130816_source/install D) Apply the patch to make L3.0.35_4.1.0 could be installed and compiled on Ubuntu 14.04 64bit OS $ cd ~/ltib $ git apply 0001_make_L3.0.35_4.1.0_compile_on_Ubuntu_14.04_64bit_OS What the patch is doing: a) The patch modifies the following files: bin/Ltibutils.pm dist/lfs-5.1/base_libs/base_libs.spec dist/lfs-5.1/m4/m4.spec dist/lfs-5.1/ncurses/ncurses.spec dist/lfs-5.1/openssl/openssl.spec dist/lfs-5.1/xorg-server/xorg-server.spec b) Add the following files to the pkgs directory: pkgs/m4-1.4.16-1383761043.patch pkgs/m4-1.4.16-1383761043.patch.md5 pkgs/openssl-1.0.1c-1398677566.patch pkgs/openssl-1.0.1c-1398677566.patch.md5 pkgs/xorg-server-1.6.1-1398785267.patch pkgs/xorg-server-1.6.1-1398785267.patch.md5 E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib F) about the patch: LTIB script warning when running with Perl v5.18.2 associated change: bin/Ltibutils.pm description: It prints out the following warning when doing package unpack, the patch is used to remove the warning. defined(@array) is deprecated at bin/Ltibutils.pm line 259         (Maybe you should just omit the defined()?) busybox compilation issue: associated change: dist/lfs-5.1/base_libs/base_libs.spec reference: Re: LTIB on Ubuntu 13.04 m4 compilation issue: associated change: dist/lfs-5.1/m4/m4.spec pkgs/m4-1.4.16-1383761043.patch pkgs/m4-1.4.16-1383761043.patch.md5 reference: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/m4/files/m4-1.4.16-no-gets.patch alsa-utils compilation issue: associated change: dist/lfs-5.1/ncurses/ncurses.spec reference: Re: Android and LTIB build error in ubuntu 12.04 x86_64 openssl compilation issue due to Perl v5.18.2: associated change: dist/lfs-5.1/openssl/openssl.spec pkgs/openssl-1.0.1c-1398677566.patch pkgs/openssl-1.0.1c-1398677566.patch.md5 description: the build fails in pod2man while trying to generate man pages from the pod files reference: https://forums.freebsd.org/viewtopic.php?&t=41478 https://gist.github.com/martensms/10107481 xorg-server configuration fail: associated change: dist/lfs-5.1/xorg-server/xorg-server.spec pkgs/xorg-server-1.6.1-1398785267.patch pkgs/xorg-server-1.6.1-1398785267.patch.md5 description: When doing configuration, it stops at saying tslib not found.  It could be fixed by adding -dl when doing tslib test in configuration stage. NOTE: A) During the LTIB setup and compilation, these warnings were pop up.  Just ignore them and it seems okay. B) the dist/lfs-5.1/gst-plugins-good.spec is used to configurate/compile/install the "gstreamer-plugins-good" package.  It set up the environment variables pointing to libcairo but disable it when doing configuration. Thus, libcairo is actually not being used.           In Gnome profile, cario has been selected by default.  Thus, it does not experience the problem when compiling "gstreamer-plugins-good". However, in Min profile, if you select gstreamer-plugins-good to compile and install to your rootfs but without selecting cario as well, you will experience the error described in this thread: Re: gst-fsl-plugins build failed Thus, you could follow the solution provide in the Re: gst-fsl-plugins build failed or simply select cairo in your package list.          

Dear all, Below a small howto to get rid of the usual file copy to your rootfs. This is my way of automatically include files to my generated image under yocto. 1. Create a recipe Under source/meta Below in plain text: SUMMARY = "My test videos" DESCRIPTION = "Test Videos" HOMEPAGE = "" LICENSE = "CLOSED" MY_FILES = "/home/freerod/Videos/demo_video_VGA_25fps.MP4" inherit allarch do_install() { install -d ${D}${datadir}/movies install -m 0644 ${MY_FILES} ${D}${datadir}/movies/ } FILES_${PN} += "${datadir}/movies" This aims at creating a movies directory in: /usr/share/movies within the rootfs, with the named demo_video_VGA_25fps.MP4 in it 2. CORE_IMAGE_EXTRA_INSTALL += "myvideos" 3. Check that the video will be put into the generated rootfs: freerod@ubuntu:~/mx6/fsl-yocto-3.14.28_1.0.0/build_mx6dl$ ll tmp/work/all-poky-linux/myvideos/1.0-r0/packages-split/myvideos/usr/share/movies/demo_video_VGA_25fps.MP4 -rw-r--r-- 2 freerod freerod 14076709 Jun  2 01:40 tmp/work/all-poky-linux/myvideos/1.0-r0/packages-split/myvideos/usr/share/movies/demo_video_VGA_25fps.MP4

What is CMA The Contiguous Memory Allocator (CMA) is a framework, which allows setting up a machine-specific configuration for physically-contiguous memory management. Memory for devices is then allocated according to that configuration. The main role of the framework is not to allocate memory, but to parse and manage memory configurations, as well as to act as an in-between between device drivers and pluggable allocators. It is thus not tied to any memory allocation method or strategy.  Various devices on embedded systems have no scatter-getter and/or IO map support and as such require contiguous blocks of memory to operate. They include devices such as cameras, hardware video decoders and encoders, etc. Such devices often require big memory buffers (a full HD frame is, for instance, more then 2 mega pixels large, i.e. more than 6 MB of memory), which makes mechanisms such as kmalloc() ineffective. Some embedded devices impose additional requirements on the buffers, e.g. they can operate only on buffers allocated in particular location/memory bank (if system has more than one memory bank) or buffers aligned to a particular memory boundary. Development of embedded devices have seen a big rise recently (especially in the V4L area) and many such drivers include their own memory allocation code. Most of them use bootmem-based methods. CMA framework is an attempt to unify contiguous memory allocation mechanisms and provide a simple API for device drivers, while staying as customisable and modular as possible. Why use it in default release Most of the i.MX SoC does not have IOMMU for specific IP who requires larger contiguous memory for operations, like VPU/GPU/ISI/CSI. Or they have IOMMU, but performance is not that good. In the default i.MX BSP, we still allocate physical contiguous memory for those IP drivers for DMA transfers. In arm64 kernel, the DMA allocation API would allocate memory in a various way which depends on the device configurations (in dts or gfp flags). The below table shows how the DMA allocation API (w/o IOMMU enabled device) works to find a proper way for pages (by order, coherent pool -> CMA -> Buddy -> SWIOTLB): Allocator (by order) Configurations (w/o IOMMU) Comments Mapping Coherent Pool device dma is not coherent GFP flag is not allow blocking By __alloc_from_pool() Already mapped on boot when coherent pool init in VMALLOC CMA device CMA or system CMA is present GFP flag is allow blocking: __GFP_DIRECT_RECLAIM set By cma_alloc() map_vm_area, mapped in VMALLOC Buddy No CMA (device or system) or GFP not allow blocking By __get_free_pages(), which can only allocate from the DMA/normal zone (lowmem), 32bits address spaces Already mapped in the lowmem area by kernel on boot SWIOTLB No contiguous pages from buddy or return buffer area region > device dma_mask By map_single() Already mapped on boot when SWIOTLB init Also a diagram shows how it works (DMA allocation path): By default, kernel uses CMA as a backend of DMA buffers allocation for most of the cases. That's why i.MX BSP use CMA in the default release for GPU/VPU/CSI/ISI or other buffers for DMA transfers. CMA Pros & Cons Pros Well designed for large contiguous memory allocation even under memory fragment condition. Pages in CMA can be shared by buddy system, not a reserved pool Can be device specific CMA area, only used by this device and share to system Easy to configure it's start addr and size on runtime w/o re-compile kernel Cons Allocation process slow when migration pages needed Easy to be corrupted by system memory allocation. Customer may meet cma_alloc failure when system is out of memory, which would cause bad user experiences when foreground application wants graphic buffers for rendering and RVC wants buffers for CAR reverse. Potential dead lock when cma_alloc() need to migrate some pages, which is still flushing to storage (Some customers already met deadlock when one page is under writeback path by FUSE file system, and cma_alloc wants to migrate it). This is the initial motivation to write this documentation. Why get rid of CMA RED Cons statement above. The key point is to reserve memory for critical path of allocation like GPU graphic buffers and camera/VPU preview/recording buffers to keep a good user experience from allocation failure which would cause black screen, preview stuck, etc. Also avoid potential dead lock when CMA and FUSE work together. How to get rid of CMA To get rid of CMA, the basic idea is to cut off the CMA way in the DMA allocation, turn to coherent pool (atomic pool). Please not that coherent pool can only be used by DMA allocation API, it's not shared to system buddy. 1. Enable coherent pool Add “coherent_pool=<size>” in command line, Coherent pool is actually allocate from system default CMA, so CMA size > coherent_pool. There's no reference for this size, as it's various from system to system and use cases to use cases: The biggest consumer of DMA is GPU, it's usage can be monitored by gmem_info tool. Monitor the gmem_info under the typical use cases, and settle down the GPU required memory. Checking for 2nd consumer of DMA: ISI/Camera, depends on the V4l2 reqbuf size and numbers Checking VPU, depends on the multimedia frameworks Plus alsa snd, USB, fec usage The size must be verified by test to make sure system stable. 2. DMA allocation hack Hack to arch/arm64/mm/dma-mapping.c, remove the gfpflags_allow_blocking check in the __dma_alloc() function: diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c index 7015d3e..ef30b46 100644 --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -147,7 +147,7 @@ static void *__dma_alloc(struct device *dev, size_t size, size = PAGE_ALIGN(size); - if (!coherent && !gfpflags_allow_blocking(flags)) { + if (!coherent) { // && !gfpflags_allow_blocking(flags)) { struct page *page = NULL; void *addr = __alloc_from_pool(size, &page, flags); 3. ION allocator In both Android and Yocto release, ION allocator (android staging driver) is used for VPU buffers. And it default goes into the ION CMA heap. This means ION request for contiguous memory is direct to CMA. To avoid CMA, we can use carveout heap instead of CMA heap in ION: 3.1 Android Enable CARVEOUT heap, disable CMA heap: CONFIG_ION=y CONFIG_ION_SYSTEM_HEAP=y -CONFIG_ION_CMA_HEAP=y +CONFIG_ION_CARVEOUT_HEAP=y +CONFIG_ION_CMA_HEAP=n Adjust the carveout reserved heap base address and size in the dts: / {  reserved-memory {  #address-cells = <2>;  #size-cells = <2>;  ranges;  carveout_region: imx_ion@0 {  compatible = "imx-ion-pool";  reg = <0x0 0xf8000000 0 0x8000000>;  };  }; }; 3.2 Linux Kernel - refer to attached patch for i.MX8QM. Almost same as Linux, but ION carveout heap driver need to be patched. Gstreamer - apply below patch to make allocate from carveout: yocto/build-8qm/tmp/work/aarch64-mx8-poky-linux/gstreamer1.0-plugins-base/1.14.4.imx-r0/git: diff --git a/gst-libs/gst/allocators/gstionmemory.c b/gst-libs/gst/allocators/gstionmemory.c index 1218c4a..12e403d 100644 --- a/gst-libs/gst/allocators/gstionmemory.c +++ b/gst-libs/gst/allocators/gstionmemory.c @@ -227,7 +227,8 @@ gst_ion_alloc_alloc (GstAllocator * allocator, gsize size,    }    for (gint i=0; i<heapCnt; i++) { -       if (ihd[i].type == ION_HEAP_TYPE_DMA) { +       if (ihd[i].type == ION_HEAP_TYPE_DMA || +             ihd[i].type == ION_HEAP_TYPE_CARVEOUT) {                heap_mask |= 1 << ihd[i].heap_id;          }    } References "Aarch64 Linux Kernel memory management" "CMA documentation"

i.MX8X 板级开发包镜像结构 ...................................... 3 2 创建 i.MX8QXP Linux 5.4.24 板级开发包编译环境 ..... 3 2.1 下载板级开发包 ....................................................... 3 2.2 创建yocto编译环境: ................................................. 5 2.3 独立编译 ............................................................... 10 3 i.MX8X SC firmware ................................................. 16 3.1 SC firmware 目录结构 ........................................... 16 3.2 SC firmware 启动流程 ........................................... 18 3.3 SC firmware定制 ................................................... 18 4 i.MX8X ATF .............................................................. 30 5 FSL Uboot 定制 ........................................................ 32 5.1 FDT支持 ............................................................... 33 5.2 DM(driver model)支持 ........................................... 38 5.3 Uboot目录 结构 ..................................................... 52 5.4 Uboot编译 ............................................................. 54 5.5 Uboot初始化流程 .................................................. 55 5.6 uboot 定制 ............................................................ 66 5.7 uboot debug信息 ................................................... 82

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. These are detailed programming aids for the registers associated with DRAM initialization (LPDDR3, DDR3, and LPDDR2). The last work sheet tab in the tool formats the register settings for use with the ARM DS5 debugger. It can also be used with the windows executable for the DDR Stress Test (note the removal of debugger specific commands in this tab). These programming aids were developed for internal NXP validation boards.   This tool serves as an aid to assist with programming the DDR interface of the MX7D and is based on the DDR initialization scripts developed for NXP boards and no guarantees are made by this tool.   The following are some general notes regarding this tool: The default configuration for the tool is to enable bank interleaving. Refer to the "How To Use" tab in the tool as a starting point to use this tool. The tool can be configured for one of the three memory types supported by the MX7D.  However, three separate programming aids are provided based on the DRAM type: LPDDR3, LPDDR2, and DDR3.  Therefore, you may use the tool pre-configured for your desired memory type as a starting point. The DRAM controller IP in MX7D is different from the MX6 series MMDC controller. Results from DRAM calibration may be updated for the following registers: DDR_PHY_OFFSET_WR_CON0 (0x30790030) and DDR_PHY_OFFSET_RD_CON0 (0x30790020).  Also, the MX7D memory map DRAM starting address is fixed at 0x80000000. Some of the CCM programming at the beginning of the DRAM initialization script (in the "DStream .ds file" tab) were automatically generated and in very few cases may involve writing to reserved bits, however, these writes to reserved bits are simply ignored. Note that in the "DStream .ds file" tab there are DS5 debugger specific commands that should be commented out or removed when using the DRAM initialization for non-debugger specific applications (like when porting to bootloaders). This tool may be updated on an as-needed basis for bug fixes or future improvements.  There is no schedule for aforementioned maintenance. For questions or additional assistance using this tool, please contact your local sales or FAE.