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.   This is a detailed programming aid for the registers associated with i.MX 8/8X DDR initialization.  For more details, refer to the i.MX 8/8X main DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8-8X-Family-DDR-Tools-Release/ta-p/1121519   To reduce the number of attachments, older RPAs may be found in the attached zip file. Note: Devices with 17-row addresses (R0-R16) are not supported by this SoC.  ***IMPORTANT: For SCFWv1.7.0 and later, you must use the following RPA versions or later: MX8QXP_C0_B0_LPDDR4_RPA_1.2GHz_v16 MX8DualX_C0_B0_LPDDR4_RPA_1.2GHz_v16 MX8QuadXPlus_DualXPlus_C0_B0_DDR3L_RPA_v22 MX8DualX_C0_B0_DDR3L_RPA_v20 Older versions of the RPA are not aligned to SCFWv1.7.0 and later.  If trying to use an older version of an RPA with SCFWv1.7.0, it will cause the SCFW not to boot.  The offending lines in the DCD output are as follows: For MX8QXP/DualX: DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ If the user wishes to use an older RPA with SCFW 1.7.0 and later (not recommended), then the above lines must be removed from older RPA DCD file outputs.  In addition, wrapping these lines are "#ifndef SCFW_DCD", "#else", and "#endif" preprocessor commands.  These should be removed as well.  For example of MX8QXP: [remove] #ifndef SCFW_DCD [remove] -/* For 1200MHz DDR, DRC 600MHz operation */ [remove] DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ [remove] #else <keep code as is> [remove] #endif

For long I looked for a working tutorial to build Qt5 with YOCTO (Yocto Training - HOME) both the libraries for the board image and also a toolchain to build Qt5 applications for the board. See the full tutorial here: Building Qt5 using yocto on Wandboard - Wandboard Wiki The Tutorial is written for the Wandboard that also uses an i.MX6 CPU but you can adapt the tutorial for most of the boards of the i.MX6 family I think - in my case it worked with the i.MX6 SABRE AI without problems. You only have to adjust the sysroot and maybe also the toolchain-path because the wiki entry is a little bit older Ask your questions for this topic - maybe I can help.

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)

Understanding and using the .sdcard format One very useful feature enabled by default in both the Yocto Communiy BSP and Release BSP is the option of generating the baked images in .sdcard format. If the .sdcard format is not selected by default it can be enabled on the conf/local.conf file by adding it with the IMAGE_FSTYPES as follow: IMAGE_FSTYPES="sdcard" It’s important to note that if this variable is specified only the file systems typed defined will be created. The default value used most often for this variable is: IMAGE_FSTYPES="tar.bz2 ext3 sdcard" The .sdcard format creates an image with all necessary partitions and loads the bootloader, kernel and rootfs to this image. You can just low level copy the data on this file to the SD card device using dd as on the following command example: $ sudo dd if=<image name>.sdcard of=/dev/sd<partition> bs=1M && sync Partitions used on the .sdcard file The .sdcard partitions looks as follow: IMAGE_ROOTFS_ALIGNMENT Unpartitioned space reserved for the bootloader BOOT_SPACE Kernerl and other data ROOTFS_SIZE The rootfs. Granting more free space on the RootFS partition The size of the .sdcard file will depend solely on the size of the rootfs. This means that the resulting file won’t partition all our SD Card capacity unless we add extra space to the rootfs partition. (Of course there is always the option of editing the partitions once loaded on the SD Card) In order to add more space you may use the IMAGE_ROOTFS_EXTRA_SPACE variable. You may add it to your local.conf file with the added free disk space in Kbytes. For example, if you would like to guarantee 1GB of extra space you may add the following line to your local.conf file. IMAGE_ROOTFS_EXTRA_SPACE = "1048576" It is important to note that this is space additional to the IMAGE_OVERHEAD_FACTOR variable which defines a multiplier that is applied to the initial image size. This is only applied when the multiplier times the By default, the build process uses a multiplier of 1.3 for this variable. This default value results in 30% free disk space added to the image when this method is used to determine the final generated image size. This would mean that there should be 30% of free disk space before post install scripts. If you wish for more space you may edit this variable as bellow: IMAGE_OVERHEAD_FACTOR = "1.5" Which would result in 50% free disk space added to the image, before post install scripts and without considering overhead that may come from the package management system. How the IMAGE_ROOTFS_SIZE is calculated This variable is also measured in Kbytes and it’s determined by the OpenEmbedded build system using an algorithm that considers the initial disk space used for the generated image, the requested size for the image (trough the overhead factor) and the additional free space to be added to the image (trough the extra space variable). The build system first runs a du (disk usage) command to determine the size of the rootfs directory tree. If the IMAGE_ROOTFS_SIZE current value is larger than the disk usage times the overhead factor only the extra space is added. If the IMAGE_ROOTFS_SIZE is smaller than the disk usage times the overhead factor then the disk usage is multiplied times the overhead factor prior to adding the extra space. IMAGE_ROOTFS_SIZE must be set on a default value which is usually very low as it’s just initialized and updated with the actual size requirements each time an image is baked. You may also use this variable directly in order to select the space you would like to allocate to the RootFS.For example setting the RootFS to 2GB would require the following addition to the local.conf file: IMAGE_ROOTFS_SIZE = “2097152” IMAGE_OVERHEAD_FACTOR = “1.0” In this example we would leave the overhead factor to 1 so no extra space is added since we’re specifying the rootfs size that we want.

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

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

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.   This is a detailed programming aid for the registers associated with i.MX 8/8X DDR initialization.  For more details, refer to the i.MX 8/8X main DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8-8X-Family-DDR-Tools-Release/ta-p/1121519 Note: Devices with 17-row addresses (R0-R16) are not supported by this SoC.  To reduce the number of attachments, older RPAs may be found in the attached zip file.   ***IMPORTANT: For SCFWv1.7.0, you must use the following RPA versions or later: MX8QM_B0_LPDDR4_RPA_1.6GHz_v23 Older versions of the RPA are not aligned to SCFWv1.7.0.  If trying to use an older version of an RPA with SCFWv1.7.0, it will cause the SCFW not to boot.  The offending lines in the DCD output are as follows: For MX8QM: DATA 4 0xff148000 0x00000885 /* DRC0 bringup */ DATA 4 0xff1a0000 0x00000885 /* DRC1 bringup */ If the user wishes to use an older RPA with SCFW 1.7.0 (not recommended), then the above lines must be removed from older RPA DCD file outputs.  In addition, wrapping these lines are "#ifndef SCFW_DCD", "#else", and "#endif" preprocessor commands.  These should be removed as well.  For example of MX8QM: [remove] #ifndef SCFW_DCD [remove] /* For 1600MHz DDR, DRC 800MHz operation */ [remove] DATA 4 0xff148000 0x00000885 /* DRC0 bringup */ [remove] DATA 4 0xff1a0000 0x00000885 /* DRC1 bringup */ [remove] #else <keep code as is> [remove] #endif  

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

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

This document shows the necessary steps to configure the Eclipse IDE for development of Yocto applications. Requirements 1) Linux machine. Ubuntu 12.4 or higher is recommended. 2) Yocto Freescale BSP Release or Freescale Community BSP. For this example we'll use the Freescale BSP Release L3.14.28 but you may use the FSL Community BSP. - Freescale Community BSP FSL Community BSP - Freescale BSP Release  Documentation L3.14.28 (login required) https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_LINUX_DOCS&location=null&fpsp=1&WT_TYPE=Supporting%20In… 3) Poky Meta Toolchain (Poky 1.7 / L3.14.28 for our example but you should use the toolchain that corresponds to the BSP that will be used) For information on how to extract and install the meta toolchain please follow the steps on the next document. Task #7 - Create the toolchain 4) Eclipse Luna. We’ll use the Luna SR2 (4.4.2) version of the Eclipse IDE. You may find it on the following website: http://www.eclipse.org/downloads/packages/release/luna/sr2 Look for the “Eclipse IDE for C/C++ Developers”, which contains the Eclipse Platform, the Java Development Tools (JDT), and the Plug-in Development Environment. Once you have downloaded the tarball extract it. The following command unpacks and installs the downloaded Eclipse IDE tarball into a clean directory using the default name eclipse:      $ cd ~      $ tar -xzvf ~/Downloads/eclipse-cpp-luna-SR2-linux-gtk-x86_64.tar.gz Configuring the Eclipse IDE Once with Eclipse Luna installed you may run the Eclipse IDE with the following command: $ cd eclipse $ ./eclipse Select a new workspace. Chose "Install New Software" from the "Help" pull-down menu. Select the "Luna - http://download.eclipse.org/releases/luna" Find and expand the Linux Tools option and select: Linux Tools LTTng Tracer Control Linux Tools LTTng Userspace Analysis LTTng Kernel Analysis If some of these options are not listed it means that they are already installed. (To change this you may uncheck the Hide items that are already installed box) Find and expand the Mobile and Device Development and select the following:   C/C++ Remote Launch (Requires RSE Remote System Explorer)   Remote System Explorer End-user Runtime   Remote System Explorer User Actions   Target Management Terminal (Core SDK)   TCF Remote System Explorer add-in   TCF Target Explorer If some of these options are not listed it means that they are already installed. (To change this you may uncheck the Hide items that are already installed box) Expand Programming Languages and select:   C/C++ Autotools Support   C/C++ Development Tools Chose Next and accept the necessary EULA Clck on the Finish button. The selected packages will be downloaded and installed. You will be asked to restart Eclipse IDE to finish the installation. Adding the Yocto Plug-in to the Eclipse IDE Next step is to install the Eclipse Yocto Plug-in into the Eclipse IDE. We'll show how to install the pre-built plug in. Start the Eclipse IDE In Eclipse, select "Install new Software" from the "Help" menu Click the "Add..." button to add a repository and enter: Name: Any name, we will use Yocto Fio Location: http://downloads.yoctoproject.org/releases/eclipse-plugin/1.8/luna Click "Ok" and then chose this new repository on the "Work with" drop-down menu and select the following plug-ins from the list:   Yocto Project ADT Plug-in   Yocto Project Bitbake Commander Plug-in   Yocto Project Documentation plug-in Install these plug-ins and click "OK" when prompted about installing software that contains unsigned content. You may be asked to restart the Eclipse IDE. Configuring the Eclipse Yocto Plug-in With all the necessary packages installed we'll now configure the Eclipse Yocto Plug-in. In this steps we will configure the Cross Compiler options and the Target options. These will then be used as default for your projects from within your working workspace. Select "Preferences" from the "Window" menu. Click on Yocto Project ADT from the left options and then under Cross Compiler Options select the Standalone pre-built toolchain radio button. We need to point to the Toolchain Root location of our installed toolchain. This is covered on the following community document: Task #7 - Create the toolchain In this case we'll be using poky 1.7 tollchain which has the following default location: /opt/poky/1.7 As fo the Sysroot Location this would correspond to your build directory sysroot folder, which is located on the following path: <YOCTO_BSP_DIR>/<BUILD_DIR>/tmp/sysroots/<MACHINE> In our case our Tartget architecture would be the Cortex-A9, which correspond to the i.MX6 and which is also the only option installed on the chosen directory. For Target Options we would be using the actual HW in order to test our application so keep the External HW option selected. Creating a Hello World Project We are now ready to create our project. Just to test our configuration we'll create a Hello World project.We can do so by selecting File->New->C Project or C++ Project We must then select a Project name and in project type we can chose either an Empty project or as in our case a Hello World Project, all this under the Yocto Project ADT Autotools Project folder. We will have the GNU Autotools Tolchain selected. The next screen will show some of the Basic Properties for our project, including the GNU license. Fill these as required. You may clock on Finish at this point. We should see that the HelloWorld project was created. We should right-click on the project folder and then chose Reconfigure Project in order to fill the necessary libraries. After this is completed we can build our project either by choosing the hammer icon or in the Build Project option inside the Project menu. We can look for correct competition or any errors or warning on the Console tab. Further Application Development After this basic setup you may work on more complex examples like a GPU and a Gstreamer Application examples on the following nicely written document: Yocto Application Development Using Eclipse IDE

I²C is a communication protocol used to exchange information between cores. To see more about I²C, please follow this link Wikipedia:I²C. Enable I2C-tools in LTIB into Package List: Reboot your file system, there are three new I²C commands: i2cdetect, i2cdump and i2cset. All examples below were tested in a iMX27ADS, but this programs seems to have the same behavior to all platforms. Detecting busses This command lists all installed bus. mx27# i2cdetect -l i2c-0   unknown         MXC I2C Adapter                         Algorithm unavailable There is one installed bus with address 0. Installed Chips I2cdetect shows the installed chips too. mx27# i2cdetect 0     WARNING! This program can confuse your I2C bus, cause data loss and worse!     I will probe file /dev/i2c/0.     I will probe address range 0x03-0x77.         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f 00:          XX XX XX XX XX XX XX XX XX XX XX XX XX 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 20: XX XX XX XX XX XX XX XX XX XX XX XX XX 2d XX XX 30: UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 60: XX XX XX XX XX XX XX XX XX XX UU XX XX XX XX XX 70: XX XX XX XX XX XX XX XX There are several cores installed into bus i2c-0. If you received an error message like this: # i2cdetect 0 Error: Could not open file `/dev/i2c-0' or `/dev/i2c/0': No such file or directory You will need to create the special file /dev/i2c-0 : # mknod /dev/i2c-0 c 89 0 Chip Registers i2cdump shows a list of all registers for a core. For example, the command above shows registers for core with address 0x6a: mx27# i2cdump 0 0x6a No size specified (using byte-data access)     WARNING! This program can confuse your I2C bus, cause data loss and worse!     I will probe file /dev/i2c/0, address 0x6a, mode byte         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef 00: 00 00 28 00 00 03 15 03 00 00 00 00 00 00 03 01    ..(..???......?? 10: 04 01 00 00 04 01 00 00 17 41 1d 00 09 09 1f 03    ??..??..?A?.???? 20: 00 00 40 00 08 00 0c 00 0f 01 00 00 00 00 08 11    ..@.?.?.??....?? 30: 00 0f 05 fe 0b 00 00 00 82 00 0c 02 00 00 01 00    .????...?.??..?. 40: 21 f0 7c 1f 00 00 01 00 7a 40 80 38 00 01 47 00    !?|?..?.z@?8.?G. 50: 3c 00 17 21 1b 1b 24 9f 00 3e 0f 0f 60 05 cd 03    <.?!??$?.>??`??? 60: 89 04 89 01 02 00 0a 05 00 19 ff 03 24 0f 78 00    ?????.??.?.?$?x. 70: 00 b2 06 14 04 08 00 a3 c8 15 05 15 3c 00 00 20    .?????.?????<.. 80: 07 2f 07 00 00 00 00 00 00 00 00 ff 03 1a 1a 1a    ?/?.........???? 90: 1a 1a 40 03 00 00 00 00 00 00 00 00 00 00 e4 00    ??@?..........?. a0: 00 02 4d 00 96 00 1d 00 a0 00 db 00 7e 00 00 00    .?M.?.?.?.?.~... b0: 00 00 00 00 00 00 f0 00 00 00 00 00 00 00 00 00    ......?......... c0: 00 00 00 00 48 9c 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a    ....H??????????? d0: 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a    ???????????????? e0: 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a    ???????????????? f0: 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a    ???????????????? Setting a register To change some register value, use i2cset like in example below: mx27# i2cset 0 0x6a 01 0x0008 w     WARNING! This program can confuse your I2C bus, cause data loss and worse!     I will write to device file /dev/i2c/0, chip address 0x6a, data address     0x00, data 0x08, mode word. Value 0x8 written, readback matched Where: 0 is the bus address 0x6a is the slave address 01 is the register address 0x0008 is the new value for register w is the word mode for the setting

Update The source code is one week old now, so please, update it! $ repo sync Images - the result of a bitbake Example of a content after bitbake build_mx6/tmp/deploy/images: fsl-image-gui-imx6qsabresd-20130505174618.rootfs.ext3 fsl-image-gui-imx6qsabresd-20130505174618.rootfs.sdcard fsl-image-gui-imx6qsabresd-20130505174618.rootfs.tar.bz2 fsl-image-gui-imx6qsabresd-20130508162511.rootfs.ext3 fsl-image-gui-imx6qsabresd-20130508162511.rootfs.sdcard fsl-image-gui-imx6qsabresd-20130508162511.rootfs.tar.bz2 fsl-image-gui-imx6qsabresd.ext3 fsl-image-gui-imx6qsabresd.sdcard fsl-image-gui-imx6qsabresd.tar.bz2 modules-3.0.35-1.1.0+yocto+g0596856-r32.10-imx6qsabresd.tgz README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt u-boot.imx u-boot-imx6qsabresd.imx u-boot-imx6qsabresd-v2013.04-r3.imx* uImage uImage-3.0.35-r32.10-imx6qsabresd-20130505174618.bin uImage-imx6qsabresd.bin Get used with generated images. Understand which file is a symbolic link and which one is the image in fact. Symbolic link will always point to latest image. sdcard image Take a look how sdcard is generated here meta-fsl-arm - Layer containing Freescale ARM hardware support metadata The disk layout used is: 0-> IMAGE_ROOTFS_ALIGNMENT    reserved to bootloader (not partitioned) IMAGE_ROOTFS_ALIGNMENT -> BOOT_SPACE    kernel and other data BOOT_SPACE -> SDIMG_SIZE     rootfs Use IMAGE_OVERHEAD_FACTOR to add more space Please, go to original file in order to understand the disk layout. It´s basically some initial space for u-boot. One partition for uImage. One partition for rootfs. The total sdcard size will be calculate for every image, if you want to add more empty space inside generated sdcard, use IMAGE_OVERHEAD_FACTOR. Deploy Deploy the sdcard image: $ sudo dd if=fsl-image-gui-imx6qsabresd.sdcard of=/dev/sdX bs=1M Or, deploy the ext3 rootfs $ sudo dd if=fsl-image-gui-imx6qsabresd.ext3 of=/dev/sdX2 bs=1M Or deploy only the tar.bz rootfs $ sudo mount /dev/sdX2 /mnt/card $ sudo tar xf imagename-imx53qsb.tar.bz2 -C /mnt/card In order to deploy only kernel $ sudo cp uImage-3.0.35-r32.10-imx6qsabresd-20130505174618.bin /media/Boot In order to  deploy only u-boot $ sudo dd if=u-boot-imx6qsabresd-v2012.10-r3.imx of=/dev/sdX bs=512 seek=2 If using HDMI please, modify u-boot environment arguments: setenv mmcargs "setenv bootargs console=${console},${baudrate} root=${mmcroot} rootwait rw video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24" This is the how sdcards are made by meta-fsl-arm. Of course you can use your own. But double check the u-boot bootenv. Plug your sdcard and let the board boot To login: root Go to HOME Go to Task #3 - The build result Go to Task#5 - kernel

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

Here are my experiences for compiling Qt5.3.0-beta1 on Yocto. Special thanks to Martin Jansa, the maintainer of the meta-qt5 layer and his help on this. My original procedure was based on this tutorial: Building Qt5 using yocto on Wandboard - Wandboard Wiki Reason: Qt5.3 contains a nice new plugin that allows the use of gstreamer output for textures without the CPU intensive step of copying them (Gerrit Code Review). This allows to play even full HD videos and apply all the power of Qt5 (e.g. shaders) to them. Steps: Setup your repo: repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b master-next; repo sync Download meta-qt5 branch: cd sources; git clone -b jansa/qt5-5.3.0-beta1 https://github.com/meta-qt5/meta-qt5.git Checkout a specific revision: cd meta-qt5; git checkout 92be18a3a14deed9d38b8fc6e89f09ba4d730597 Apply the following patch (maybe later no longer needed): diff --git a/recipes-qt/qt5/qt5.inc b/recipes-qt/qt5/qt5.inc index dfc1c76..a2f9a73 100644 --- a/recipes-qt/qt5/qt5.inc +++ b/recipes-qt/qt5/qt5.inc @@ -54,6 +54,7 @@ FILES_${PN}-tools-dbg = " \ " FILES_${PN}-plugins-dbg = " \      ${OE_QMAKE_PATH_PLUGINS}/*/.debug/* \ +    ${OE_QMAKE_PATH_PLUGINS}/*/*/.debug/* \ " # extra packages @@ -98,6 +99,7 @@ FILES_${PN}-tools = " \ " FILES_${PN}-plugins = " \      ${OE_QMAKE_PATH_PLUGINS}/*/*${SOLIBSDEV} \ +    ${OE_QMAKE_PATH_PLUGINS}/*/*/*${SOLIBSDEV} \ " FILES_${PN}-mkspecs = "\      ${OE_QMAKE_PATH_ARCHDATA}/mkspecs \ Define your machine: export MACHINE=xxx (replace with your board) Setup build environment: cd .. ; . setup-environment build edit your local layer conf ("conf/bblayers.conf") and add the following two lines:   ${BSPDIR}/sources/meta-openembedded/meta-ruby \   ${BSPDIR}/sources/meta-qt5 \ edit your local.conf and add the following lines: DISTRO_FEATURES_remove = "x11 wayland" IMAGE_INSTALL_append = " \     firmware-imx-vpu-imx6q \     firmware-imx-vpu-imx6d \ " IMAGE_INSTALL_append = " \     cpufrequtils \     nano \     packagegroup-fsl-gstreamer \     packagegroup-fsl-tools-testapps \     packagegroup-fsl-tools-benchmark \     gstreamer \     gst-plugins-base-app \     gst-plugins-base \     gst-plugins-good \     gst-plugins-good-rtsp \     gst-plugins-good-udp \     gst-plugins-good-rtpmanager \     gst-plugins-good-rtp \     gst-plugins-good-video4linux2 \     qtbase-fonts \     qtbase-plugins \     qtbase-tools \     qtbase-examples \     qtdeclarative \     qtdeclarative-plugins \     qtdeclarative-tools \     qtdeclarative-examples \     qtdeclarative-qmlplugins \     qtmultimedia \     qtmultimedia-plugins \     qtmultimedia-examples \     qtmultimedia-qmlplugins \     qtsvg \     qtsvg-plugins \     qtsensors \     qtimageformats-plugins \     qtsystems \     qtsystems-tools \     qtsystems-examples \     qtsystems-qmlplugins \     qtscript \     qt3d \     qt3d-examples \     qt3d-qmlplugins \     qt3d-tools \     qtwebkit \     qtwebkit-examples-examples \     qtwebkit-qmlplugins \     cinematicexperience \     " PACKAGECONFIG_append_pn-qtmultimedia = " gstreamer010" QT5_VERSION = "5.2.1+5.3.0-beta1+git%" PREFERRED_VERSION_qtbase-native = "${QT5_VERSION}" PREFERRED_VERSION_qtbase = "${QT5_VERSION}" PREFERRED_VERSION_qtdeclarative = "${QT5_VERSION}" PREFERRED_VERSION_qtjsbackend = "${QT5_VERSION}" PREFERRED_VERSION_qtjsbackend-native = "${QT5_VERSION}" PREFERRED_VERSION_qtgraphicaleffects = "${QT5_VERSION}" PREFERRED_VERSION_qtimageformats = "${QT5_VERSION}" PREFERRED_VERSION_qtmultimedia = "${QT5_VERSION}" PREFERRED_VERSION_qtquick1 = "${QT5_VERSION}" PREFERRED_VERSION_qtquickcontrols = "${QT5_VERSION}" PREFERRED_VERSION_qtsensors = "${QT5_VERSION}" PREFERRED_VERSION_qtserialport = "${QT5_VERSION}" PREFERRED_VERSION_qtscript = "${QT5_VERSION}" PREFERRED_VERSION_qtsvg = "${QT5_VERSION}" PREFERRED_VERSION_qttools-native = "${QT5_VERSION}" PREFERRED_VERSION_qtwebkit = "${QT5_VERSION}" PREFERRED_VERSION_qtwebkit-examples = "${QT5_VERSION}" PREFERRED_VERSION_qtxmlpatterns = "${QT5_VERSION}" build an image: bitbake core-image-minimal This image will build QT5.3 for framebuffer. If you want to use it with X11, then adapt according to this tutorial: Integrate Qt5 into yocto sato image on Wandboard - Wandboard Wiki Please tell me, if I missed something. I wrote this as I remembered the steps.

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

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

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

Freescale LTIB provides only the low level FlexCAN driver, so you can add Canutils and Libsocketcan developed by Pengutronix to have some more functions available on user space and some test and monitoring applications. Adding Flexcan driver support on Kernel On kernel menuconfig, add the following items: [*] Networking support  --->     <*>  CAN bus subsystem support  --->         <*>  Raw CAN Protocol (raw access with CAN-ID filtering)         <*>  Broadcast Manager CAN Protocol (with content filtering)     CAN Device Drivers  --->         <*> Virtual Local CAN Interface (vcan)         [*] CAN devices debugging messages         <*> Freescale FlexCAN Adding Canutils and Libsocketcan Packages on LTIB Download the libsocketcan-0.0.8.tar.bz2 and canutils-4.0.6.tar.bz2 source codes from the links below and save them on your PC at /opt/freescale/pkgs http://www.pengutronix.de/software/libsocketcan/download/libsocketcan-0.0.8.tar.bz2 http://www.pengutronix.de/software/socket-can/download/canutils/v4.0/canutils-4.0.6.tar.bz2 On LTIB directory, create the spec file folders: cd <ltib directory>/dist/lfs-5.1 mkdir canutils mkdir libsocketcan Download the following spec files, unpack them on their respective folders: Can_specs.tar.gz ( attached below ) Now, on ltib directory, unpack, build and deploy them: cd <ltib directory> ./ltib -p libsocketcan.spec -f ./ltib -p canutils.spec -f Testing the FlexCAN network To test the Flexcan network, first set the bitrate and after enable the can port: canconfig can0 bitrate 125000 ifconfig can0 up                                         Now it's possible to test the network connecting two boards: On board 1: cansend can0 -i0x100 11 22 33 44 On board 2: canecho can0 -v Board 2 will show the data coming from board 1.

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.

Pre-requisites: An TFTP server U-boot with TFTP capabilities If you need to run a script (for example, running multiple setenv's commands) in U-boot for many boards, you can instead create a U-boot script (called script image), place it into your tftp folder, then ask U-boot to fetch it and run it. For example, you want to run the following setenv instructions setenv loadaddr 0x10800000 setenv bootargs_base 'setenv bootargs console=ttymxc0,115200' setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666' setenv bootcmd_mmc 'run bootargs_base bootargs_mmc;mmc dev 3;mmc read ${loadaddr} 0x800 0x2000;bootm' run bootcmd_mmc save it into a file, I choose the name 'myscript'; under your <U-boot folder>/tools, execute $ mkimage -T script -C none -n 'My Script' -d myscript myscript.img and copy myscript.img file into your TFTP folder. On the target, set the following two variables (serverip and bootcmd) # Set the Server IP, where the TFTP server is running setenv serverip <the server IP> # In case the server IP is static, you can place this line into the U-boot script setenv scriptaddr 0x10700000 setenv scriptname myscript.img # You can use either TFTP or DHCP setenv tftpcmd tftp # or 'dhcp'  in case you want to use dhcp U-boot command # Not needed for dhcp setenv ipaddr <the target IP> # needed in case the command tftp is used setenv gatewayip <the Gateway IP> # needed in case the command tftp is used setenv bootcmd '${tftpcmd} ${scriptaddr} ${scriptname}; source ${scriptaddr}' saveenv reset That is all you need to do. Enjoy U-booting!