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.

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

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.