For iMX6DQ, there are two IPUs, so they can support up to 4 cameras at the same time. But the default BSP can only support up to two cameras at the same time. The attached patch can make the BSP support up to 4 cameras based on 3.10.53 GA 1.1.0 BSP.   The 4 cameras can be: - 1xCSI, 3xMIPI - 2xCSI, 2xMIPI - 4xMIPI   For 4xMIPI case, the four cameras should be combined on the single MIPI CSI2 interface, and each camera data should be transfered on a mipi virtual channel.   In this patch, we given the example driver for Maxim MAX9286, it was verified working on iMX6DQ SabreAuto board. The input to MAX9286 is four 720P30 cameras. The verified camera boards:     (1) Onsemi AR0140+AP0101+MAX9271 boards.     (2) OmniVision OV10635+MAX9271 boards.   The MIPI CSI2 CVBS camera surround view solution can be found at: iMX6DQ ISL79985/79987 MIPI CSI2 CVBS camera surround view solution for Linux BSP The MIPI CSI2 CVBS HD camera surround view solution can be found at: iMX6DQ TP2854 MIPI CSI2 720P CVBS 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-Add-Max9286-support-on-SabreAuto-board-which-can-sup.patch      MAX9286 driver, it includes MAX9271, AP0101 and AR0140 drivers.   0003-Remove-the-page-size-align-requirement-for-v4l2-capt.patch      With this patch, the mxc_v4l2_tvin test application can use overlay framebuffer as V4l2 capture buffer directly.   0004-Max9286-skip-AP0101-camera-re-initialization.patch      If the camera board's power had been kept after initialized, this patch will bypass the re-initialization to reduce the start up time.   0005-Max9286-set-I2C-speed-to-400Kbps.patch     Set I2C to 400Kbps to reduce the AP0101+AR0140 initialization time.   0006-Max9286-add-retry-for-MAX9271-I2C-access.patch     Added retry for MAX9271 I2C access.   0007-Max9286-Add-support-for-OV10635-camera.patch     Updated code for OV10635 camera.   0008-Max9286-support-auto-detect-camera-number.patch     Make the Max9286 driver can detect the camera number automatically.     How to builld the kernel with MAX9286 support:       make imx_v7_defconfig       make menuconfig (In this command, you should select the MAX9286 driver:             Device Drivers  --->                   <*> Multimedia support  --->                         [*]   V4L platform devices  --->                               <*>   MXC Video For Linux Video Capture                                       MXC Camera/V4L2 PRP Features support  --->                                           <*>Maxim max9286 GMSL Deserializer Input support                                               Select Camera Sensor (OmniVision OV10635 camera sensor)  // Or (Onsemi AP0101 and AR0140 camera sensor)                                           <*>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_max9286.tar.gz" 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 &   Some hardware check point on AR0140+AP0101+MAX9271 camera board (Please get MAX9286 and OV10635 schematics from Maxim): 1. In this patch, MAX9286's I2C address is 0x4D, so ADD0 and ADD1 should be connected to high. AP0101's I2C address is 0xBA, so SADDR should be connected to high.   2. AP0101's DOUT0~DOUT7 should be connected to MAX9271's DIN7~DIN0, the order should be switched, MSB connected to LSB.   3. MAX9271's GPO pin should be connected to AP0101's FRAME_SYNC pin. The pull down resistance on FRAME_SYNC pin should not be 0 ohm.   Some known limitation: 1. AP0101's VSYNC invalid time, last video line's HSYNC to VSYNC porch's max value is 255 pixel clocks, it is not enough for MAX9286 to generate the Frame End MIPI packets for each camera. So in order to let iMX6DQ to capture 1280x720 video for each camera, we had let AP0101 output 1280*724 frame size, and iMX6 will only capture 720 lines, the remained video data and Frame End will be ignored. This solution will not impact the function, but there will be "Error matching Frame Start with Frame End for Virtual Channel x" error reported from iMX6 MIPI_CSI_ERR1 register. Maxim suggested to use MAX96705 to relace the MAX9271, it can delay the VSYNC invalid time, then the MIPI error will be fixed.     2015-11-17 update: Updated for OV10635 camera support. File: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2015-11-17.zip   2015-12-04 update: File: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2015-12-04.zip Added patch 0009-Max9286-updated-PCLK-edge-setting-for-OV10635.patch to correct the OV10635 PCLK edge setting     2016-03-07 update: File L3.14.38_GA_MAX9286_Surroundview_Patch_2016-03-07.zip Added kernel patch for L3.14.38 GA 1.1.0 BSP.   2016-07-26 update: Files: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip; L3.14.38_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip; L3.14.52_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip. Added gstreamer support. Added MAX96705 support. Added patch for L3.14.52_GA1.1.0.   2017-12-11 update: Added CVBS surround view link: iMX6DQ TP2854 MIPI CSI2 720P CVBS camera surround view solution for Linux BSP     2021-04-26 update: Some customer reported, when system loading is heavy, sometimes, some camera will flicker left and right. It is caused by SFMC FIFO data lost. The original patch used IDMAC 0 and IDMAC 1 for two cameras on one IPU, this is not the best setting.  IDMAC 1 is fixed to use 1/4 SMFC FIFO and it will cause IDMAC 0 to use 1/4 SMFC FIFO too. And another 1/2 of SMFC FIFO can't be used in this case. Some code update to improve it: For each IPU, please use IDMAC 0 and IDMAC 2 to capture the two cameras. This needs change the hard coding in "drivers\media\platform\mxc\capture\ipu_csi_enc.c", "CSI_MEM1" and "IPU_IRQ_CSI1_OUT_EOF" should be changed to "CSI_MEM2" and "IPU_IRQ_CSI2_OUT_EOF". In this case, all SMFC FIFO can be used. And in "ipu_common.c", function ipu_probe(), the followed code should be changed to make IDMAC2 use high priority too. /* Set sync refresh channels and CSI->mem channel as high priority */ - ipu_idmac_write(ipu, 0x18800003L, IDMAC_CHA_PRI(0)); + ipu_idmac_write(ipu, 0x1880000FL, IDMAC_CHA_PRI(0));

Here are two patches to support BT656 and BT1120 output for i.MX6 ipuv3. With this patch, the i.MX6 can support the CVBS output on TV encoder. It is useful for a TV box. "L3.0.35_1.1.0_GA_bt656_output_patch.zip" is the patch for Freescale L3.0.35_1.1.0_GA_iMX6DQ BSP. "r13.4.1_bt656_output_patch.zip" is the patch for Freescale Android R13.4.1 BSP. 1. Features supported:     1) Support BT656(8 bits) and BT1120 (16 bits)interlaced output on display port.     2) Support both RGB and YUV frame buffer for BT656/BT1120 output.     3) Support PAL and NTSC mode.     4) Support on the fly switch between PAL and NTSC mode.     5) Support CVBS output based on adv7391 TV encoder. 2. Hardware link between iMX6 and adv7391 TV encoder chip.     IPU1_DI0_DISP_CLK connected to adv7391 CLKIN pin.     IPU1_DISP0_DAT_23~DISP0_DAT_16 connected to adv7391 P7~P0 pins.     IPU1_DI0_PIN2 connected to adv7391 HSYNC pin. (option)     IPU1_DI0_PIN4 connected to adv7391 VSYNC pin. (option)   - Android R13.4.1 kernel. 3. How to use -- Copy the two patch files to kernel folder.     $ git apply ./0001-Support-BT656-and-BT1120-output-for-iMX6-ipuv3.patch     $ git apply ./0002-Support-adv739x-TV-encoder-for-BT656-output.patch -- Select them in kernel config and build the new kernel image:                     Device Drivers  --->                       Graphics support  --->                           [*]   MXC BT656 and BT1120 output                           [*]   ADV7390/7391 TV Output Encoder -- Uboot parameters for video mode    Output BT656 NTSC data to display port with UVYV frame buffer mode:       "video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=UYVY16"    Output BT656 NTSC data to display port with RGB565 frame buffer mode:       "video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=RGB565"    Output BT656 PAL data to display port with RGB24 frame buffer mode:       "video=mxcfb0:dev=bt656,BT656-PAL,if=BT656,fbpix=RGB24"    Output CVBS NTSC signal on adv7391 with UYVY frame buffer mode:       "video=mxcfb0:dev=adv739x,BT656-NTSC,if=BT656,fbpix=UYVY16"    Output CVBS PAL signal on adv7391 with RGB565 frame buffer mode:       "video=mxcfb0:dev=adv739x,BT656-PAL,if=BT656,fbpix=RGB565" -- Switch between PAL and NTSC    $ echo D:720x480i-60 > /sys/class/graphics/fb0/mode    $ echo D:720x576i-50 > /sys/class/graphics/fb0/mode 4. Note     1) For 8 bits BT656 interface, the default data pins are "DISP0_DAT_23~DISP0_DAT_16", it can also        be any other continued display data pins, for example if "DISP0_DAT_7~DISP0_DAT_0" are used, the        macro "BT656_IF_DI_MSB" in "kernel_imx/drivers/mxc/ipu3/ipu_disp.c" should be changed from "23"        to "7".     2) For 16 bits BT1120 interface, the default data pins are "DISP0_DAT_23~DISP0_DAT_8", it can also        be any other continued display data pins, the macro "BT656_IF_DI_MSB" should be modified if the        hardware pins are changed.     3) When bt656 interface is the second display for each IPU,1-layer-fb (it can be checked with command        "$ cat /sys/class/graphics/fbx/fsl_disp_propperty"), the frame buffer can only be YUV format. In this        case, the IPU DC channel was used for BT656 display, it has no CSC function, so RGB frame buffer was        not supported. 2013-08-09 updated: The new release package "L3.0.35_1.1.0_GA_bt656_output_patch_2013-08-09.zip" had fixed the BT656 dual display issue on iMX6S/DL. Removed the old release package. 2013-09-04 updated: The new release package "r13.4.1_bt656_output_patch_2013-09-04.zip" had fixed the BT656 dual display issue on iMX6S/DL. For default, the dual display was tested with HDMI + CVBS, HDMI is the main display and adv739x CVBS output is the second display. For iMX6DQ which has two IPUs, please assign dual display to two IPUs, for example adv739x is on IPU1 DI0, it is fixed, because hardware pins used for it is fixed. Then we can assign HDMI or LVDS to another IPU (IPU2). For iMX6S/DL which has only one IPU, since adv739x had used IPU1 DI0, another display should be IPU1 DI1. 2013-09-30 updated: Added patch for L3.0.35_4.1.0_GA BSP, the file is "L3.0.35_4.1.0_GA_bt656_output_patch_2013-09-30.zip". 2014-07-21 updated: Added patch for L3.10.17_1.0.0_GA BSP, the file is "L3.10.17_1.0.0_GA_bt656_output_patch_2014-07-21.zip". 2015-01-26 updated: Updated the IPU microcode for 1080i50 and 1080i60 BT1120 output, the parameters "N" for command BMA is a 8 bits parameters, so its max value is 255, but for 1080i50 and 1080i60 output, it needs more blank data in each line, the "N" will be bigger than 255, the updated IPU microcode can fix this limitation. The updated file is "IPU_Microcode_Update_for_BT1120_1080i_20150126.zip". You can update the macro "DC_MCODE_BT656_xxx"  and function _ipu_dc_setup_bt656_interlaced() to the old patch if you used BT1120 mode to support 1080i display. The verified 1080i display mode is: {    /* 1080I60 Interlaced output */   "BT1120-1080I60", 30, 1920, 1080, 13468,   20, 3,   20, 2,   280, 1,   FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,   FB_VMODE_INTERLACED,   FB_MODE_IS_DETAILED,}, {   /* 1080I50 Interlaced output */   "BT1120-1080I50", 25, 1920, 1080, 13468,   20, 3,   20, 2,   720, 1,   FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,   FB_VMODE_INTERLACED,   FB_MODE_IS_DETAILED,}, 2016-01-28 updated: Updated IPU microcode to align with BT656.4 specification for NTSC output. For other BSP version with NTSC format support, please reference to ipu_disp_update.c for the final microcode. File "L3.0.35_4.1.0_GA_bt656_output_patch_20160128.zip"., Details, please reference to the readme.txt file in the package. 2016-06-24 update: Added BT656 and BT1120 progressive mode support. File "L3.0.35_4.1.0_GA_bt656_output_patch_20160624.zip". Details, please reference to the readme.txt file in the package. The patch for 3.14.52 GA1.1.0 BSP will be released in next week. 2016-06-27 update: Add BT656 and BT1120 display patch for 3.14.52 BSP. File "L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27.zip", details, please reference to the readme.txt in the package. 2017-03-10 update: Fixed a hard coding DC macro issue for progressive mode. Added patch "0008-Fixed-a-hard-coding-DC-macro-issue-for-progressive-m.patch" in L3.0.35_4.1.0_GA_bt656_output_patch_2017-03-10.zip. The code in patch "L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27" is correct.

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.

This patch made the display no interrupt from uboot to kernel to Android. The IPU and related hardware display interface will only be initialized once in Uboot, the kernel code will skip the IPU initialization.   1. Description     1) Support HDMI, LVDS and LCD output in UBoot.     2) Support UBoot logo keep from uboot to kernel to Android.     3) For HDMI, both 720P and 1080P mode were supported.     4) For LVDS, 1024x768 and 1080P dual channel panels were supported.     5) The logo file is a 32 bpp bmp file. 2. File List -- kernel_imx\0001-Keep-uboot-logo-for-Android-boot-supports-HDMI-LCD-a.patch -- kernel_imx\0002-Bug-fix-for-uboot-logo-keep-patch.patch    Kernel patch to support the logo keep feature. -- uboot-imx\0001-Enable-uboot-logo-for-HDMI-LCD-and-LVDS.patch    Uboot patch to support the logo display. -- logo.bmp    Example 32bpp logo file. -- readme.txt    this file, please refer to it before use the patches 3. Requirement - iMX6 SabreSD board. - Android JB4.2.2_1.1.0-GA UBoot and kernel. 4. How to use -- Copy the two patch files to Android kernel_imx and uboot-imx folder and apply them.     $ cd ~/myandroid/kernel_imx/     $ git apply ./0001-Keep-uboot-logo-for-Android-boot-supports-HDMI-LCD-a.patch     $ cd ~/myandroid/bootable/bootloader/uboot-imx/     $ git apply ./0001-Enable-uboot-logo-for-HDMI-LCD-and-LVDS.patch     $ git apply ./0002-Bug-fix-for-uboot-logo-keep-patch.patch   -- Build the new uboot image:     $ cd ~/myandroid/bootable/bootloader/uboot-imx     $ export CROSS_COMPILE=~/myandroid/prebuilt/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-     $ export ARCH=arm     $ make mx6q_sabresd_android_config     $ make   -- Before build new UBoot image, the display type can be selected from file uboot-imx\include\configs\mx6q_sabresd.h // Select one of the output mode #define IPU_OUTPUT_MODE_HDMI //#define IPU_OUTPUT_MODE_LVDS //#define IPU_OUTPUT_MODE_LCD   -- Build the new kernel image:     $ cd ~/myandroid/kernel_imx     $ export CROSS_COMPILE=~/myandroid/prebuilt/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi-     $ export ARCH=arm     $ make imx6_android_defconfig     $ make uImage   -- Before "make uImage", make menuconfig can be used to select the display type.                 System Type  --->                    Freescale MXC Implementations  --->                       MX6 clk setting for smooth UI transtion from bootloader to kernel  --->                           Select Display Interface                              ( )  Smooth UI transtion on LCD, IPU1, DI0                              ( )  Smooth UI transtion on LVDS, IPU1, DI1                              (X)  Smooth UI transtion on HDMI, IPU2, DI0   -- Uboot parameters for video mode    1080P HDMI:       "video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 fb0base=0x27b00000 fbmem=28M hdmi_audio_clk=148500000"      720P HDMI:       "video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 fb0base=0x27b00000 fbmem=28M hdmi_audio_clk=74250000"      1024x768 LVDS:       "video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666,bpp=32 fb0base=0x27b00000 fbmem=28M"      800x480 LCD:       "video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB565,bpp=32 fb0base=0x27b00000 fbmem=28M" -- dd the logo.bmp to SD card address 0x100000 and skip the 54 bytes bmp file header.    sudo dd if=logo.bmp of=/dev/sdc bs=1 seek=1048576 skip=54 5. Note     1) The logo.bmp file should be 32bpp or 16bpp, and it should be synced with video mode parameters "bpp=xx",          and uboot config file mx6q_sabresd.h (#define DISPLAY_BPP  xx).       2) The IPU number and DI number are hard coded in kernel file "board-mx6q_sabresd.c". static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {   .ipu_id = 1,   .disp_id = 0, }; static struct fsl_mxc_lcd_platform_data lcdif_data = {   .ipu_id = 0,   .disp_id = 0,   .default_ifmt = IPU_PIX_FMT_RGB565, }; static struct fsl_mxc_ldb_platform_data ldb_data = {   .ipu_id = 0,   .disp_id = 1,   .ext_ref = 1,   .mode = LDB_SEP1,   .sec_ipu_id = 0,   .sec_disp_id = 0, };       3) The IPU number and DI number are defined by Macro in Uboot file "include\configs\mx6q_sabresd.h" #define IPU_NUM   2  // 1 for IPU1, 2 for IPU2. #define DI_NUM   0  // 0 for DI0, 1 for DI1.       4) The display type used in uboot and kernel must be same, same type, same IPU number, same DI port and        same resolution.     [2015-06-29 Update]: JB4.2.2_1.1.0_uboot_logo_keep_patch_2015-06-29.zip Fix some LVDS issues for iMX6DL. Also given an example for LVDS0 with DI0. New Uboot patches:      0002-Updated-lvds-clock-source-to-pll2_pfd0.-Same-as-kern.patch      0003-Add-support-for-iMX6DL.patch   New kernel patches      0003-Skip-lvds-re-initialization-for-logo-keep.patch      0004-Add-examlpe-for-LVDS0-logo-keep.patch     [2015-08-07 Update]: JB4.2.2_1.1.0_uboot_logo_keep_patch_2015-08-07.zip Added the new Uboot patch 0004-Correct-the-sequence-to-set-LDB-clock.patch It can correct the LVDS clock set sequence whch is a known issue that caused no LVDS display sometimes.   [2015-09-18 Update]: JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip Added the patch for Android JB4.3_GA1.1.1 release. Updated clock usecount, after blank the display, the related clock can be gated off correctly. Support LVDS clock from PLL5.   [2015-12-21 Update]: Added 3.10.53_GA1.1.0 patch: L3.10.53_GA1.1.0_uboot_logo_keep_patch_2015-12-21.zip. Verified on iMX6DL/Q SabreSD board. It supports LCD and LVDS panels, HDMI patch will be released later.   [2016-01-04 Update]: Added 3.10.53_GA1.1.0 patch: L3.10.53_GA1.1.0_uboot_logo_keep_patch_2016-01-04.zip. Added HDMI display support. Now it supports LCD, LVDS and HDMI displays. Fixed the video playback issue for boot up.   [2016-05-18 Update]: 0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch An issue was founded, when dual channel 4 lanes LVDS panel was used, in uboot there will be no LVDS TX3 signa on one LVDS port, the attach "0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch" was used to fix this issue, it is based on JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip, for other BSP, please port it manually.   [2016-08-29 Update]: 0001-After-reset-IPU-in-SRC-Control-Register-wait-for-res.patch On some iMX6 chip, after reset the IPU in SRC Control Register, enable IPU at once will cause system hang up, to avoid such issue, software needs wait for IPU reset done by polling the SRC register. The attach "0001-After-reset-IPU-in-SRC-Control-Register-wait-for-res.patch" was used to fix this issue, it is based on JB4.3_1.1.1_uboot_logo_keep_patch_2015-09-18.zip + "0001-Fix-the-split-mode-LVDS-panel-no-TX3-signal-issue.patch", for other BSP, please port it manually.   [2017-01-06 Update] Added patch for L4.1.15_GA1.2.0 BSP and Android M6.0.1_GA2.1.0 BSP. Files: L4.1.15_GA1.2.0_uboot_logo_keep_patch_2017-01-06.zip; M6.0.1_2.1.0_uboot_logo_keep_patch_2017-01-06.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. i.MX 6/7 Family DDR Stress Test  The i.MX6/7 DDR Stress Test Tool is a PC-based software to fine-tune DDR parameters and verify the DDR performance on a non-OS, single-task environment(it is a light-weight test tool to test DDR performance). It performs write leveling, DQS gating and read/write delay calibration features. The tool described on this page cover the following i.MX 6/7 series SoCs: i.MX 6DQP (Dual/Quad Plus) i.MX 6DQ (Dual/Quad) i.MX 6DL/S (Dual Lite/Solo) i.MX 6SoloX i.MX 6SL i.MX 6SLL i.MX 6UL i.MX 6ULL/ULZ i.MX 7D/S i.MX 7ULP Note that the DDR Stress test tool supports the all of the above i.MX SoCs, however, some of the supported i.MX SoCs named in the tool support multiple i.MX SoCs as follows: MX6DQ – when selected, this supports both i.MX 6DQ and i.MX 6DQP (Plus) MX6DL – when selected, this supports both i.MX 6DL and i.MX 6S (i.MX 6DLS family) MX6ULL – when selected, this supports both i.MX 6ULL and i.MX6 ULZ MX7D – when selected, this supports both i.MX 7D and i.MX 7S The purpose of the i.MX 6/7 series DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.). This process equips the user to then proceed with the bring-up of a boot loader and an OS. Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface. The i.MX 6/7 series DDR Tools consist of: DDR Register Programming Aid (RPA): i.MX 6/7 Series DDR Tool Release DDR Stress test: Described below There are three options to run the DDR Stress test. Each of these options are provided in the attached zip files. The following is a high-level overview of each option along with the naming convention of the associated zip file: Option 1 GUI based: Run the GUI executable and connect your board to the host PC via USB Archive file: ddr_stress_tester_vX.xx.zip The tool will first need to run a DDR initialization script for the specified i.MX SoC (refer to Load Init Script in the GUI tool).  Example initialization scripts based on NXP's development boards can be found in this zip file under the script folder.  Note, these scripts may need to be modified for your custom board and memory.   Option 2 DDR Stress Tester: JTAG Interface A hardware debugger connected to the board via the JTAG interface is used to download an elf file into the i.MX SoC OCRAM (internal RAM) and then begin execution. Results are shown on the UART serial port (115200-8-n-1). Archive file: ddr_stress_tester_jtag_vX.xx.zip As with the GUI tool, the JTAG/debugger option will first need to run a DDR initialization script for the specified i.MX SoC. Refer to the GUI tool description above for the location of the example scripts (which are found in the ddr_stress_tester_vX.xx.zip file). Note that the scripts are available either in the RealView ICE format (.inc file) or the DS-5 DSTERAM format (.ds). For other debuggers, the user will have to modify the script's command syntax for their specific debugger. This is also true if converting from a RealView Ice (.inc) format to a DS-5 DSTREAM (.ds) format and vice versa. The DDR Stress Tester executable (starting with V2.20) has an auto UART detection feature. If a different UART port for the serial console has been chosen than used on the NXP development tool (EVK, SABRE) specific commands can be added to the DDR initialization script that allows you to configure for the specific UART and then load and run the elf executable. Refer to the FAQ section of this community post and the txt file found in the JTAG archive file for instructions.   Option 3 U-Boot: The boot loader u-boot is running and commands in u-boot are used to download the bin file into SoC OCRAM and begin execution. Results are shown on the UART serial port (115200-8-n-1) Archive file: ddr_stress_tester_uboot_vX.xx.zip When downloading the DDR Stress Tool by u-boot, please copy the ddr-test-uboot-jtag-mxxxx.bin to SD card and load it to IRAM using the 'fatload' u-boot command (see notes below when using newer versions of u-boot). For i.MX6, please load the binary to 0x00907000. For i.MX7D, please load the binary to 0x00910000.  It is imperative to first disable the I and D cache in u-boot as shown below as the DDR Stress Test re-configures and re-enables the cache and MMU page table. While this option allows the user to load and run the DDR stress test from u-boot, NXP highly recommends executing the GUI based version for system testing and debugging. The u-boot version is considered a “last resort” for systems in production which may not have USB or JTAG connectivity. The reasons behind this stance are: In the GUI version, the system starts “clean” and uninitialized, whereas u-boot initializes many SoC features outside the knowledge of the DDR stress test and may conflict with the stress test operation When running the u-boot version, the test will overwrite the contents of u-boot residing in DDR, hence the test will overwrite any data in DDR. Once the stress test is loaded and executed, u-boot itself will no longer be accessible. To return to the functionality of u-boot, a system re-boot is required. Newer versions on u-boot do not allow a direct loading of the DDR stress test code from the SD card (boot media) directly to the SoC internal OCRAM (aka IRAM). Hence, the procedure is updated to first load the DDR stress test code into DDR and then copy into OCRAM, as shown in the procedure below: u-boot> dcache off;icache off;fatload mmc 2:1 0x12000000 ddr-test-uboot-jtag-mx6dq.bin;cp.b 0x12000000 0x00907000 0x20000;go 0x00907000 As u-boot initializes many peripherals that may conflict with the operation of the DDR stress test, it is necessary to clock gate these peripherals prior to running the DDR stress test. Hence, it is highly recommended to augment the procedure above as follows: u-boot> dcache off;icache off;fatload mmc 2:1 0x12000000 ddr-test-uboot-jtag-mx6dq.bin;cp.b 0x12000000 0x00907000 0x20000; u-boot> mw 0x020c4068 0x00C0000F; u-boot> mw 0x020c406c 0x00000000; u-boot> mw 0x020c4074 0x3F300000; u-boot> mw 0x020c4078 0x0000F300; u-boot> mw 0x020c407c 0x0F000003; u-boot> mw 0x020c4080 0x000003FC; u-boot> go 0x00907000 Note, in the above procedure, it is recommended to write to each clock gate register in separate commands (refer to commands starting with “mw”). The SoC requires a finite amount of time to gate each clock hence performing this sequence with a new command line write ensures the SoC has time to gate the intended clocks.   Stress Test Revision Features Comments 3.00 Add i.MX 7ULP support in the GUI version Known issues: USB connection is unstable when under USB HUB or some PC environments 2.92 Minor correction with write leveling calibration code error check to avoid a corner case of flagging an error when none have occurred.    2.91 Resolved issue with write leveling calibration code where a race condition in the code may result in the calibration routine not being able to find any delay values.   Only applies to MX6 series SoCs that support DDR3.  2.90 Reserve write delay line register (MMDC_MPWRDLCTL) configuration as DDR script does when do write calibration. In previous releases, MMDC_MPWRDLCTL would be changed to 0x40404040 by default.      * Further details available in the release notes  _________________________________________________________________________________________________________________________________________    FAQ   Q. I see an error message that states "ERROR: DCD addr is out of valid range.", why is this and how do I resolve?   A. Sometimes, when using the register programming aid, there are registers writes that are not supported in the DCD range.  Try looking for the following items and comment them out from the DDR initialization script: wait = on setmem /16 0x020bc000 = 0x30 // disable watchdog (note the address for this may be different between i.MX6x devices)  Q. How do I select the "DDR Density" pull-down menu and what is the purpose of this?   A. The DDR Density pull-down menu gives the user the option of testing a DDR density smaller than what they actually have on their board.  The advantage of doing this is to speed up test time to allow the user to perform a "quick test" of their system.  IMPORTANT: it is imperative that the user not set this value higher than the supported density on their board, doing so will cause the stress test to fail and/or lock up. The DDR Density has a different meaning depending on the memory type being tested (DDR3 or LPDDR2): For DDR3, this is the density per CHIP SELECT.  So if your board has two chip selects, and each chip select has 512MB, you would simply select 512MB or lower.  The default setting will simply set this to the detected density per chip select. For LPDDR2, this is the density per CHANNEL.  This is only relevant for MX6 devices that support 2 channel LPDDR2 memories (MX6DQ, MX6DL).  For other MX6 devices that support only one LPDDR2 channel, then this is the total density (for the maximum setting) for that channel. Note that for LPDDR2, the number of chip selects (per channel) is irrelevant when selecting the density to test as the stress test combines both chip-selects into one combined density per channel.  For example, lets say you have a 2GB LPDDR2 device, which 2 channels and 2 chip-selects per channel.  That means you have 512MB per chip select, per channel.  Or, it also means you have 1GB per channel when combining both chip selects per channel.  In this case, you would choose (a maximum setting of) 1GB in the DDR Density drop down menu.  However, this is also the same setting as the default setting (which you are welcome to still choose 1GB to convince yourself that 1GB per channel is indeed being tested). Now let's assume you have only one channel (LPDDR2) and one chip select, with a density of 128MB; in this case, the maximum DDR Density you can select is 128MB. Let's assume you have one channel and two chip selects, each chip select is 128MB;  in this case, the maximum DDR Density you can select is 256MB (a combination of both chip selects).   Note, for the MX7D, an actual density needs to be entered. For the MX6x series, simply leaving this field as Default will cause the DDR stress test to ascertain the supported density from the DDR init script. As the MX7D DDR controller is different, this feature is not supported, hence it is required for the user to enter an actual density (for more details regarding MX7D usage of density and number of chip-selects, see the next FAQ on the DDR CS setting).   Q.  What is the purpose of the "DDR CS" pull-down option?   A.  The answer depends on which processor you are testing:   For the i.MX 6x series: This pull down menu gives you the option of testing one chip select (CS0) or ALL (both) chip selects *IF* you have a two-chip select configuration.  If you have a two-chip select configuration, then this allows you to test only one chip select for faster test time; else you can choose to test both chip selects.  Note that if you have a one-chip select configuration and you choose "ALL", the stress test will return an error.   For the iMX 7D: Because the MX7D DDR controller is different, the DDR stress test will need the user to supply the entire supported density found on their board. The chip select field should be left as is (0) as the test will naturally test one chip select to the next. For example, let’s assume you are using two chip selects, with each chip select being 512MB. In this case, you would enter 1GB for the DDR Density field ensuring that both chip selects will be tested. The user is allowed to enter a density less than the density found on their board (for quicker testing), but keeping in mind both chip selects may not be tested in this case.   Q. I run DDR calibration using the DDR Stress Test Tool to obtain the calibration results.  Are these calibration parameters are written to the uboot flash_header.S automatically or manually?   A. The calibration values obtained from the DDR Stress Test Tool will need to be manually updated in the flash_header.S file or any other DDR initialization script.   Q. When running the DDR stress test on MX7D and I try to perform calibration, I get an error stating that calibration is not supported, is this expected?   A. Yes, calibration is not supported or needed when using MX7.  The reason is, MX7 uses a different memory controller than the MX6 series.  The MX6 series memory controller has built-in support for calibration where the MX7 memory controller does not.   Q. When running the GUI version of the DDR stress test, on MX7 and I leave DDR Density as default, I get an error in the tool stating I must supply a density.  Why is this?   A. This is due to the fact that MX7 uses a different memory controller than the MX6 series.  In the MX6 series, it was possible to calculate the memory density from the memory controller register settings.  The MX7 memory controller is different and does not lend itself to easily calculate the supported density based on the register settings.  Instead, the user should verify the density on their board and selected this value in the DDR Density pull-down menu.    Q. I noticed that when I run write-leveling calibration I sometimes see a note that due to the write-leveling calibration value being greater than 1/8 clock cycle that WALAT must be set to 1.  What does this mean?   A. In the MMDC chapter of the reference manual for the specific i.MX 6 device, the need to set WALAT is described in the MDMISC register as follows: "The purpose of WALAT is to add time delay at the end of a burst write operation to ensure that the JEDEC time specification for Write Post Amble Delay (tWPST) is met (DQS strobe is held low at the end of a write burst for > 30% a clock cycle before it is released). If the value of any of the WL_DL_ABS_OFFSETn register fields are greater than ‘1F’, WALAT should be set to ‘1’ (cycle additional delay). WALAT should be further increased for any full-cycle delays added by the WL_CYC_DELn register fields." Therefore, if the write-leveling calibration routine detects any write-leveling delay value greater than 0x1F, it will note to the user that WALAT must be set and the user should update their DDR3 init script to ensure WALAT is set.  Sometimes, a user may find that the write-leveling delay value may fluctuate from one run to the next, which is quite normal.  If it is found that this delay is "borderline" meaning sometimes it is greater than 0x1F and sometimes it might be slightly less, then it is ok to go ahead and set WALAT permanently in your init script as there is no harm in doing so and will ensure you will stay within JEDEC's tWPST.   Q. I sometimes see that after running write-leveling calibration that delay values being reported back are zero'd out (0x00), and then at times I see a non-zero value being reported, why is this? A. It is quite normal to see slight variations in the delay value between write-leveling calibration runs.  The write-leveling calibration routine assumes a majority of users have designed their board such that the DDR3 memories are placed close to the i.MX 6 SoC. There’s a mechanism in NXP’s DDR Stress test write leveling calibration code that checks the returned write leveling value. If the write-leveling calibration routine detects that the returned delay value is greater than ¾ of a clock cycle, it will "zero out" the delay value. It does this because it assumes that such a large delay result is due to the fact that the DQS signal is already delayed relative to the SDCLK, and to align DQS with SDCLK requires the calibration routine to delay DQS even further to align it to the next SDCLK edge, something we ideally would like to avoid.  JEDEC specs that the DQS edge must be within 25% of a SDCLK cycle with respect to the SDCLK edge, so having DQS initially slightly delayed from SDCLK is actually ok, hence why the calibration routine “zero’s” this out when the returned value exceeds ¾ of a clock cycle.  In cases like this, the DQS edge and SDCLK edge are so close together that in some calibration runs, the DQS edge may slightly precede SDCLK (resulting in a very small write-leveling delay value) and other runs, it may be slightly delayed relative to the SDCLK (resulting in a very large write-leveling delay value that will try to align DQS to the next SDCLK edge, hence needs to be zero’d out).   Q. When using the JTAG version of the DDR stress test, how can I select a different UART port for my serial port?   A. Under the folder ddr_stress_tester_jtag_v2.52, there's a text file that describes how to add a different UART port by adding a few additional commands to your DDR init script.  The following is an outline of these commands: 1. Ungate UART module clocks (most NXP scripts ungate all of the peripheral clocks at the beginning of the script, so this part is already done) 2. Configure the IOMUX options for the pins you wish the UART to use (normally an IOMUX option for UART_TX and UART_RX, and a daisy chain option for the UART_RX input) 3. Enable the desired UART module via the register UCR1, bit UART_EN 4. Disable other UART modules (UCR1[UART_EN] = 0).  Normally disabling UART1 should be sufficient, but it doesn't hurt to disable all of the other un-used UART options for the purpose of the stress test.   Here's an example in the .ds file vernacular of a set up as follows: MX6DQ, UART4 on KEY_COL0 and KEY_ROW0 (assume clock is ungated to all peripherals): mem set 0x020E01F8 32 0x00000004   #// config_pad_mode(KEY_COL0, ALT4) mem set 0x020E01FC 32 0x00000004   #// config_pad_mode(KEY_ROW0, ALT4); mem set 0x020E0938 32 0x00000001   #// Pad KEY_ROW0 is involved in Daisy Chain. mem set 0x02020080 32 0x00000000   #//disable UART1 in UART1_UCR1 (Note, you can disable other UART modules as well) mem set 0x021F0080 32 0x00000001   #//enable UART4 in UART4_UCR1   Here's another example in the .inc file vernacular of a set up as follows: MX6SX, UART5 on SD4_DATA4 abd SD4_DATA5 (assume clock is ungated to all peripherals): setmem /32 0x020E0294 = 0x2 //IOMUXC_SW_MUX_CTL_PAD_SD4_DATA5, ALT2; UART5_TX_DATA setmem /32 0x020E0290 = 0x2 //IOMUXC_SW_MUX_CTL_PAD_SD4_DATA4, ALT2; UART5_RX_DATA setmem /32 0x020E0850 = 0x00000000 // IOMUXC_UART5_IPP_UART_RXD_MUX_SELECT_INPUT, daisy chain for UART5_RX input to use SD4_DATA4 setmem /32 0x021F4080 = 0x00000001 // Enable UART_EN in UCR1 of UART5 // Disable UART_EN in UCR1 of UART1, UART2, UART3, and UART4 setmem /32 0x02020080 = 0x00000000 // UART1 setmem /32 0x021F0080 = 0x00000000 // UART2 setmem /32 0x021EC080 = 0x00000000 // UART3 setmem /32 0x021E8080 = 0x00000000 // UART4     Related Resources Links: iMX 8M Mini Register Programming Aid DRAM PLL setting  i.MX 8/8X Series DDR Tool Release  i.MX 8M Family DDR Tool Release 

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

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

Prerequisites: The build is verified on prebuilt rootfs(based on LTIB) which can be downloaded from freescale.com EGL uses framebuffer backend libEGL.so -> libEGL-fb.so libGAL.so -> libGAL-fb.so QT4.8 1. Download the git respository for qt4.8: $ git clone http://git.gitorious.org/qt/qt.git qt $ cd qt Let us consider this as <QTDir> 2. Create /tftpboot and point your target fileystem. As like $ mkdir -p /tftpboot $ cd /tftpboot $ ln -s $(ROOTFFS) rootfs TBD:Need to work on this to use sysroot option 3. Create a build directory to install for the qt4 packages. This directory can be  in any location. For example, $ mkdir /opt/qt4 $ sudo chown -R <username> /opt/qt4 Let us consider the the <installdir> as /opt/qt4 4. Extract the attached mkspecs(linux-imx6-g++.tar.gz) to  <QTDir>/mkspecs/qws/ 5. Apply the attached cd 0001-add-i.MX6-EGL-support.patch attached to enable egl support for i.MX6 $ cd <QTDir> $ patch -p1<0001-add-i.MX6-EGL-support.patch 6. Export CROSS-COMPILE location path to PATH $ export PATH=$PATH:/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/ 7. Enter to the <QTDir>. Do configure. You can select the options as you like. Here is an example $ cd <QTDir> $ ./configure -qpa -arch arm -xplatform qws/linux-imx6-g++ -no-largefile -no-accessibility \ -opensource -verbose -system-libpng -system-libjpeg -system-freetype -fast -opengl es2 -egl -confirm-license \ -qt-zlib  -qt-libpng  -no-webkit -no-multimedia \ -make examples -make demos \ -release -make libs -exceptions -no-qt3support -prefix <installdir> 8. When the configure summary is shown make sure the Qt has OpenGL ES 2.0 support. Do build $ make $ make install 9. Now need to build eglfs plugin $ cd <QTDir>/src/plugins/platforms/eglfs $ make $ make install     Now the eglfs will be installed to the QT Install directory. 10. By now all required QT files are in <install directory> 11. Copy the install directory to target filesystem $ cp -rf /opt/qt4 /tftpboot/rootfs/opt/. 12. Running Qt apps on target     - Boot the target either with NFS or SD Image     - Ensure that folder <installdir> is copied on target file system at “/usr/local”.     - Launch application using $ cd /opt/qt4/examples/opengl/hellogl_es2 $ ./hellogl_es2 -platform eglfs QT5 These steps are performed on the host 1. Download the git respository for qt5: $ git clone git://gitorious.org/qt/qt5.git qt5 $ cd qt5     Let us consider this as <QTDir> 2. Create a build directory to install for the qt5 packages. This directory can be  in any loctation. For example, $ sudo mkdir /opt/qt5 $ sudo chown -R <username> /opt/qt5 Let us consider the the installdir as /opt/qt5 3. Enter the Qt5 directory and run the init-repository script to download all the source code for    Qt5. To download all the source code will take about an hour. $ ./init-repository Update:  In the latest Qt5 release the webkit library is included by default and there are some issues trying to compile it. use the next line to avoid problems if not desired to use webkit. $ ./init-repository --no-webkit 4. From the following path $ gedit qtbase/mkspecs/devices/linux-imx6-g++/qmake.conf 5. At the top of the qmake.conf, there is a configure line. Copy and paste the configure line into a text file located    in your build build directory. Edit the configure line to find your toolchain and filesystem. Also make sure to    include the options -no-pch, -no-opengl, -opengl es2, Here is an example of    a configure line. Update: In the latest Qt5 stable, the option to compile the examples/demos is -compile-examples, instead of -make examples -make demos If you are running into problems with webkit,  use the option -no-icu, this will disable the webkit. $ cd <QTDir> $ cd qtbase $ ./configure -v -opensource -confirm-license -no-pch -no-xcb -no-opengl -opengl es2  \         -make libs -device imx6 \        -compile-examples \       -device-option CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-fsl-linux-gnueabi- \        -sysroot <rootfs> -no-gcc-sysroot \       -prefix <installdir> 7. Make the textfile that has the configure line and executable and run it. When the configure summary is shown make sure the Qt5 has openGL ES 2.0 support. Do build $ make $ sudo make install    When Qt5 has finished building, Qt5 will be installed in two places:            1. <location of rootfs>/<installdir>            2. <HOST Machine>/<install dir> This is good because now all the libraries and binaries for Qt5 are installed on the host and the target filesystem. Therefore, the target already has all the libraries and  binaries needed to run Qt5. 8. Also need to build qtjsbackend and qtdeclarative. $ cd <location to Qt5 git> $ cd qtjsbackend $ ../qtbase/bin/qmake -r $ make && sudo make install $ cd <location to Qt5 git> $ cd qtdeclarative $ ../qtbase/bin/qmake -r $ make && sudo sudo make install 9. Running Qt apps on target     - Boot the target either with NFS or SD Image     - Ensure that folder <installdir> is copied on target file system at “/usr/local”.     - Launch application using $ cd /opt/qt5/examples/opengl/hellowindow $ ./hellowindow -platform eglfs FAQ: On the target file system, the location of target libaries and includes may present in arm-linux-gnueabi directory. Make sure to create soflinks to QT can find. For example $ cd $(ROOTFS)/usr/lib $ ln -s arm-linux-gnueabi/libffi.so.6 libffi.so.6 While building QT5, you may see a build error that libQt5V8.so.5 is not found. This might be some problem to be addressed in QT. Workaround is to copy all the binaries to correct path as like this $ cp  <ROOTFS>/<installdir>/lib/* <HOST Machine>/<installdir>/. What is coming up next: 1. QT on X is already available on Yocto filesystem. Steps to enable GPU Acceleration TDB. 2. QT with Wayland support.

Note, the tools described in this page are deprecated and are no longer maintained.  For the latest maintained i.MX 6/7 series DDR tools, the user can find these here: i.MX 6/7 Series DDR Tool Release Hi All,   DDR_Stress_Tester is a software application for fine tuning DDR parameters and verifying DDR performance on i.MX6 boards. It performs write leveling, DQS gating, read/write delay calibration on the target board to match the layout of the board and archive the best DDR performance. In addition, the stress test can help the user to verify the DDR performance on their boards.   The following are the features supported: • Support i.MX6Q, i.MX6D, i.MX6DL, iMX6S, i.MX6SL, and i.MX6SX DDR calibration. • Support DDR3 write leveling, DQS gating, Read/Write Delay auto-calibration. • Support LPDDR2 Read/Write Delay auto-calibration. • Support 16 bits, 32 bits, and 64 bits data bus. • Support fixed-mapping 2-channel LPDDR2. • Support DDR stress test between the frequency 135MHz and 672 MHz   If  USB OTG port is not available on customer board, please use the images in DDR_Stress_Tester_V1.0.3_UART1_for_SDboot&JTAG.zip. The bin files in the packages can be loaded by uboot and elf files are used by JTAG load.  Please note when the image is loaded by u-boot, the DDR is initialized by u-boot (reference flash_header.S).   To run ddr stress test from u-boot, CONFIG_SPLASH_SCREEN must be disabled in u-boot. Because when enter self refresh mode in ddr stress test, DRAM access will be blocked. If splash screen in u-boot is enabled, IPU will continuously access DRAM, so the system will hang up. If you have other DMA access in u-boot, it must be disabled.   If customer uses different RX/TX pin for UART, please contact FAE.   UART1 6DQ 6DL 6SL 6SX TX CSI0_DAT10/ALT3 CSI0_DAT10/ALT3 UART1_TXD/ALT0 GPIO1_IO04/ALT0 RX CSI0_DAT11/ALT3 CSI0_DAT11/ALT3 UART1_RXD/ALT0 GPIO1_IO05/ALT0   The commands to run ddr test in i.MX6Q uboot: U-Boot > fatload mmc 2:1 0x907000 ddr-stress-test-mx6dq.bin U-Boot > go 0x907000     For i.MX6Q/6D 4K interleaved LPDDR2, please use version v1.0.3.1. i.MX6 DDR Stress Test Tool V1.0.3.1 for LPDDR2 4K interleaved mode For i.MX6/i.MX7 DDR Stress Test Tool with GUI interface, please use version V2.x: i.MX6/7 DDR Stress Test Tool V2.10   History V1.0.3:  i.MX6SoloX is supported.

The Guide is how to use Ubuntu filesystem with i.MX8 series platform.At present, I had try it on i.MX8QXP with 4.14.98 kernel with ubuntu16.04. The Document will be continuously updated with enable VPU, ubuntu18.04. The desktop we can chose Gnome or weston.  Because driver  support issue, gc7000 series gpu not support render Gnome destop but it can render weston destop.  Update 2019/7/31: Ubuntu-i.MX8-weston.pdf   Feature: weston + ubuntu18.04 + 4.14.98 kernel VPU (enable with gplay or gst-play)  GPU (could render desktop and run GPU demo under root privileges on Weston Desktop) I also try ubuntu with gnome desktop, ubuntu18.04 can not run gnome, need use ubuntu19.04. But Gnome Desktop just render by CPU.  ------------------------------------------------------------------------------------- Update 2020/3/6: Ubuntu-i.MX8M.pdf Just a simple guide for IMX8M series, will be  continuously updated. 

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

These are my notes for compiling Qt 5.3.0 release using the fsl-community-bsp and the meta-qt5 layer graciously provided by the much lauded Otavio and Martin Jansa.  My test board is the wandboard solo.  My original procedure was based on this document: Compiling Qt5.3.0-beta1 on Yocto which was in turn based on this tutorial: Building Qt5 using yocto on Wandboard - Wandboard Wiki Steps to build: repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b daisy; repo sync cd sources; git clone https://github.com/cetola/meta-qt5.git **as of this commit: https://github.com/meta-qt5/meta-qt5/commit/e9ad98bbed6065989ef4648e724f27275b35b838 the meta-qt5 official repo is now using qt 5.3.  I won't be updating my layer, and I suggesting using theirs. add to bblayers.conf:   ${BSPDIR}/sources/meta-openembedded/meta-ruby \   ${BSPDIR}/sources/meta-qt5 \ add to local.conf: DISTRO_FEATURES_remove = "x11 wayland" PACKAGECONFIG_append_pn-qtmultimedia = " gstreamer010 " bitbake wandboard-image-qt5 I will do my best to keep this working with the latest in daisy. Current functionality includes playing hardware accellerated video in QML.  However, examples such as multimediawidgets/player,  multimediawidgets/videowidget do not play video. Also qtwebkit/browser, qtwebkit/youtubeview qtwebkit/fanicybrowser do not support HTML5 video. Comments welcome. Cheers, Stephano

This post describes the setup detail for installing Ubuntu based distro in any i.Mx6x NXP Boards. Details are described on: 1. Select your board, Setting the host, Download and compile uboot , dtb and and the Kernel version on your board. 2. Installing the Ubuntu core, Lubuntu graphics desktop version and/or Build your own Ubuntu rootfs with debootstrap. 3. Modify rootfs and Installing needed packages 4. Setting with SD image. 5. Setting Ubuntu on target 6. Adding GPU acceleration 1: Select your board, Setting the host, Download and compile uboot , dtb and and the Kernel version on your board. Supported NXP HW boards: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6Quad SABRE-SD Board and Platform i.MX 6DualLite SABRE-SD Board i.MX 6Quad SABRE-AI Board i.MX 6DualLite SABRE-AI Board i.MX 6SoloX SABRE-SD Board i.MX 6SoloX SABRE-AI Board Install host dependences (version tested 14.04): $ sudo apt-get install gparted git build-essential libncurses5 wget u-boot-tools zlib1g-dev ncurses-dev \ cmake libc-dev-armhf-cross pkg-config-arm-linux-gnueabihf build-essential checkinstall cmake \ pkg-config lzop libc6 libstdc++6 debootstrap qemu-user-static binfmt-support Download the compiler toolchain and extract it: $ cd ~/ $ wget -c https://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz $ tar xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz Create general variable environments: $ export target=mx6q (e.g. processor: mx6sx, mx6d, mx6dl,etc) $ export board=sabresd (e.g. sabresd, sabreauto) $ export ARCH=arm $ export CROSS_COMPILE=../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ unset LDFLAGS Download u-boot At the release of this document, latest uboot version was imx_3.14.52, it should work with other version as well, so please check the proper version for your board: $ cd ~/ $ wget –c http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/snapshot/uboot-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ tar -xf uboot-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ cd uboot-imx-rel_imx_3.14.52_1.1.0_ga $ make $targetboard_config    # e.g. mx6qsabresd_config $ make Linux Kernel, Firmware, headers, modules and DTS files $ cd ~/ $ wget –c http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/snapshot/linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ tar xf linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ make imx_v7_defconfig $ make menuconfig $ make -j4 zImage modules dtbs $ cd ~/ move your image to binary folder: $ sudo cp –v uboot-imx-rel_imx_3.14.52_1.1.0_ga/u-boot.imx binary/ $ sudo cp –v linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga/arch/arm/boot/zImage binary/ $ sudo cp –v linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga/arch/arm/boot/dts/i$target-$board.dtb binary/ Now you have the bootloader, device tree and kernel image of your board ready, let’s create the rootfs. 2: Installing the Ubuntu core, Lubuntu graphics desktop version and/or Build your own Ubuntu rootfs with debootstrap. Installing ubuntu core: $ cd ~/ $ sudo mkdir –p core /media/rootfs /media/kernel $ wget –c http://cdimage.ubuntu.com/ubuntu-core/releases/14.04/release/ubuntu-core-14.04.4-core-armhf.tar.gz $ sudo tar –xf ubuntu-core-14.04.4-core-armhf.tar.gz –C core $ sudo cp -vr core/* /media/rootfs $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ sudo make modules_install firmware_install INSTALL_MOD_PATH=/media/rootfs/ ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ sudo make ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- headers_install INSTALL_HDR_PATH=/media/rootfs/usr Now you should have your ubuntu rootfs on /media/rootfs folder. and you can pass to part 3 of this post. Installing ubuntu Linaro LXDE: $ cd ~/ $ sudo mkdir –p core /media/rootfs /media/kernel $ wget https://releases.linaro.org/14.10/ubuntu/trusty-images/alip/linaro-trusty-alip-20141024-684.tar.gz $ sudo tar -xf linaro-trusty-alip-20141024-684.tar.gz –C core $ sudo mv core/binary/* core/ $ sudo rm –rf core/binary $ sudo cp -vr core/* /media/rootfs $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ sudo make modules_install firmware_install INSTALL_MOD_PATH=/media/rootfs/ ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ sudo make ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- headers_install INSTALL_HDR_PATH=/media/rootfs/usr Now you should have your ubuntu rootfs on /media/rootfs folder. and you can pass to part 3 of this post. Installing with debootstrap $ cd ~/ $ target=rootfs $ distro=trusty $ sudo debootstrap --arch=armhf --foreign --include=ubuntu-keyring,apt-transport-https,ca-certificates,openssl $distro "$target" http://ports.ubuntu.com $ sudo cp /usr/bin/qemu-arm-static $target/usr/bin $ sudo cp /etc/resolv.conf $target/etc Now have a minimal Ubuntu rootfs - chroot to it and perform the 2nd stage install: $ sudo chroot $target  //Now we are in chroot # distro=trusty # export LC_ALL=C LANGUAGE=C LANG=C # /debootstrap/debootstrap --second-stage Edit the sources.list repositories # cat <<EOT > /etc/apt/sources.list deb http://ports.ubuntu.com/ubuntu-ports/ $distro main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ $distro-updates main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ $distro-security main restricted universe multiverse EOT # apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 40976EAF437D05B5 # apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 3B4FE6ACC0B21F32 # apt-get update # apt -y -f install # apt-get upgrade # apt-get install nano Now you should be able to login without password, then use passwd command to set one. If you like to add custom users: # passwd root # adduser <myuser> # usermod -a -G tty myuser # usermod -a -G dialout, adm, sudo, dip, plugdev myuser # visudo Under the line that looks like: root ALL=(ALL:ALL) ALL add the following (change user with your actual username) <myuser> ALL=(ALL) ALL your rootfs is ready, exit chroot # exit $ sudo rm $target/etc/resolv.conf $ sudo rm $target/usr/bin/qemu-arm-static $ sudo mv rootfs/* /media/rootfs $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ sudo make modules_install firmware_install INSTALL_MOD_PATH=/media/rootfs/ ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ sudo make ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- headers_install INSTALL_HDR_PATH=/media/rootfs/usr Now you should have your ubuntu rootfs on /media/root. 3: Modify Rootfs and Install needed packages Edit and verify the sources.list repositories $ cd /media/rootfs $ sudo cat <<EOT > etc/apt/sources.list deb http://ports.ubuntu.com/ubuntu-ports/ trusty main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ trusty-updates main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ trusty-security main restricted universe multiverse EOT Edit networks interfaces and append in the existing file: $ sudo nano etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp If you require Serial Console, remove and include an additional line at the end of the file for  ttymxc0 output as below, $ sudo nano etc/init/tty1.conf exec /sbin/getty -8 38400 tty1 exec /sbin/getty -L 115200 ttymxc0 If you like to change the localhostname: $ sudo nano etc/hostname and change to “your name” e.g. imx6Q. Set the date and time clock and update $ sudo nano /etc/rc.local  Add this: if [ `date +"%Y"` -eq "1970" ]; then                     date --set="2016-04-01" fi exit 0 (optional for Linaro rootfs) Edit passwd and remove the x in root and linaro lines $ sudo nano etc/passwd root:x:0:0:root:/root:/bin/bash linaro:x:0:0.. and change like this:                                   root::0:0:root:/root:/bin/bash linaro:::0:.. Now you are ready to program your sd image. 4: Setup microSD/SD card For these instructions, we are assuming: DISK=/dev/sdg on your HOST, cat /proc/partitions is very useful for determining the device id. $ cd ~/ $ export DISK=/dev/sdg Erase microSD/SD card: $ sudo dd if=/dev/zero of=${DISK} bs=1M count=10 Install Bootloader $ cd binary/ $ sudo dd if=u-boot.imx of=${DISK} bs=512 seek=2 $ sync Create Partition layout: $ cd ~/ $ sudo fdisk ${DISK} steps:        d ///delete all partitions currently on sd n // create new partition p // Primary partition 1 // partition number 1 2048 //default +1G // n // created 2d parition p 2 default default 1 // firts B // to be fat32 W // write partiotions $ sudo mkfs.vfat ${DISK}1 $ sudo mkfs.ext3  ${DISK}2 Mount ext3 SD partition to /media/rootfs: $ sudo mount ${DISK1} /media/kernel_target $ sudo mount ${DISK}2 /media/rootfs_target Copy Files on the SD. $ cd ~/ $ sudo cp –v binary/ i$target-$board.dtb /media/kernel_target $ sudo cp –v binary/zImage /media/kernel_target $ sudo mv /media/rootfs/* /media/rootfs_target Remove SD: $ sync $ sudo umount /media/kernel_target $ sudo umount /media/rootfs_target Boot the target, in console you should be login as root. root@imx6QSabreSD:~# 5: Setting Ubuntu on target Note: If you have issues with sudo on user UID, need to logout and log as root: imx6Q login: root Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.14.52 armv7l) root@imx6Q:~# chown root:root /usr/bin/sudo root@imx6Q:~# chmod 4755 /usr/bin/sudo root@imx6Q:~# exit Login with <user $> or root # # apt-get update # apt-get –f install # apt-get install locales dialog wget # dpkg-reconfigure locales # apt-get upgrade Optional – install some useful packages: # apt-get install openssh-server can-utils usbutils build-essential automake autoconf libtool Get and Install the BSP packages (EULA required) # cd /home/user # mkdir –p vpu_pack # cd vpu_pack # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//firmware-imx-5.3.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-vpu-5.4.32.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//libfslcodec-4.0.8.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-lib-5.1.tar.gz # chmod +x * # ./firmware-imx-5.3.bin --auto-accept --force # mkdir –p /lib/firmware/vpu # cp -ravf firmware-imx-5.3/firmware/* /lib/firmware/ # ./imx-vpu-5.4.32.bin --auto-accept --force # cd imx-vpu-* # make PLATFORM=IMX6Q all # make install # tar -xf imx-lib-5.1.tar.gz # cd  imx-lib-5.1/ # make -j1 PLATFORM="IMX6Q" # make PLATFORM="IMX6Q" install # cd .. # ./libfslcodec-4.0.8 --auto-accept –force # cd libfslcodec-* # ./autogent.sh --prefix=/usr --enable-fhw --enable-vpu # make # make install # mv /usr/lib/imx-mm/video-codec/* /usr/lib # mv /usr/lib/imx-mm/audio-codec/* /usr/lib # rm –rf /usr/lib/imx-mm/ # cd .. # mkdir –p gpu_pack # cd gpu_pack # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-gpu-viv-5.0.11.p7.4-hfp.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//xserver-xorg-video-imx-viv-5.0.11.p7.4.tar.gz # chmod +x * # ./imx-gpu-viv-5.0.11.p7.4-hfp –-auto-accept -–force # cd imx-gpu* # cp g2d/usr/include/* /usr/include/ # cp -d g2d/usr/lib/* /usr/lib/ # cp -Pr gpu-core/usr/* /usr # optional: install demos # cp -r gpu-demos/opt / # optional: install gpu tools # cp -axr gpu-tools/gmem-info/usr/bin/* /usr/bin/ # cd .. Installing gstreamer-imx, IPU, VPU and GPU support: Install build deps, gstreamer1.x, this step could take some time (~350MB): # apt-get install python pkg-config git gstreamer1.0-x gstreamer1.0-tools gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-alsa libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libgstreamer-plugins-good1.0-dev g++-multilib # git clone git://github.com/Freescale/gstreamer-imx.git # cd gstreamer-imx # ln –s /usr/lib/arm-linux-gnueabihf/gstreamer-1.0/ /usr/lib/gstreamer-1.0 # ./waf configure --prefix=/usr --kernel-headers=/include # ./waf # ./waf install # cd ../../ (optional) Install libimxvpuapi library: This library provides a community based open-source API to the NXP imx-vpu library (the low-level IMX6 VPU interface). # git clone git://github.com/Freescale/libimxvpuapi.git # cd libimxvpu* # ./waf configure –-prefix=/usr # ./waf # ./waf install # cd .. note './waf install' installs artifacts to its prefix + /lib/gstreamer-1.0 but they need to be installed to /usr/lib/arm-linux-gnueabihf/gstreamer-1.0 which is why we created a symlink above before installing note g2d lib required to build G2D note that x11 library is required to build EGL sink with Vivante direct textures (only needed for X11 support) note that libfslaudiocodec is required to build audio plugins Now you are ready to test gstreamer 6: Add GPU HW Acceleration for X11 NOTE: The original version of these build instructions can be found in the Gateworks wiki . Many thanks to them for writing this! IMX6 IPU, VPU, and GPU support via GStreamer and Gstreamer-imx plugins. Many of the pieces needed (firmware and source-code) are from NXP and not freely redistributable thus must be downloaded from their mirror and extracted from a shell script that forces you to read and agree to their End User License Agreement (EULA). The following instructions can be used on top of the debootstrap and should work on other sources of Ubuntu or other Linux distributions root filesystems as well You can easily add X11 support to a base image created with the debootstrap instructions above by adding a few package groups. You will need the following: X11 server - ie Xorg Display Manager - this controls the login to the X session Window Manager - manages window position, re-sizing, decorations, etc for X clients If in any case you have installed the Linaro LXDE rootfs, it includes the Xorg X11 server, the lxdm Display Manager, the openbox Window Manager, and others useful user applications including the Chromium browser, if you do not install linaro lxde and want to install it please do: this step could take some time (~650MB)   # apt-get install xinit lxde lxterminal lxappearance lxrandr lxshortcut lxinput xinit  xserver-xorg-dev mesa-utils mesa-utils-extra Notes: you will need to add a non-root user with adduser for Chromium browser to work. You may choose to set up auto-login for that user by editing /etc/lxdm/default.conf and setting the autologin property in the base section at the beginning of the config file. /etc/xdg/lubuntu/lxdm/lxdm.conf This document takes as based kernel version 3.14.52v, vivante 5.0.11p7.4 correspond to the kernel version used. you should check the BSP release notes in order to know which xserver and Vivante GPU files need to be downloaded from the NXP repos. $ sudo nano /etc/lxdm/default.conf    [base]    autologin=user To add hardware GPU acceleration to X11 you need to add some libraries and drivers provided by Freescale from the imx-gpu-viv package. This requires signing Freescales End User License Agreement (EULA). This package provides the following: libg2d - a documented low-level API to the GPU (used by things like libimxvpuapi for gstreamer-imx and the gpu-core drivers) gpu-core - provides all the various OpenGL libs (libGL, libGLESv1_CM, libGLESv1_CL, libGLESv2, libGLSLC, libCLC, libEGL, libGAL, libOpenCL, ls libOpenVG) typically provided by the mesa project. Note that several versions of libEGL/libGAL/libGLESv2/libVIVANTE are provided for different backend rendering systems: dfb, fb, wl, x11. # cd gpu_pack #cd imx-gpu-* # cp gpu-core/usr/lib/dri/vivante_dri.so /usr/lib/xorg/modules/drivers/ # chmod 644 /usr/lib/xorg/modules/drivers/vivante_dri.so # rm /usr/lib/arm-linux-gnueabihf/mesa/libGL.so* # rm /usr/lib/arm-linux-gnueabihf/mesa-egl/libEGL.so* # rm /usr/lib/arm-linux-gnueabihf/mesa-egl/libGLESv2.so* # rm /usr/lib/arm-linux-gnueabihf/mesa-egl/libOpenVG.so* # cd ../../ # cd gpu-pack # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//xserver-xorg-video-imx-viv-5.0.11.p7.4.tar.gz # tar –xf xserver* # cd xserver-org-video-imx* #looks lik have to made #git init # ./fastbuild.sh  BUILD_HARD_VFP=1 XSERVER_GREATER_THAN_13=1 # cd.. # cd kernel-modu* # make Switch to gpu-core x11 backend: # backend=x11 # ln -sf libEGL-${backend}.so /usr/lib/libEGL.so # ln -sf libEGL-${backend}.so /usr/lib/libEGL.so.1 # ln -sf libEGL-${backend}.so /usr/lib/libEGL.so.1.0 # ln -sf libGAL-${backend}.so /usr/lib/libGAL.so # ln -sf libGLESv2-${backend}.so /usr/lib/libGLESv2.so # ln -sf libGLESv2-${backend}.so /usr/lib/libGLESv2.so.2 # ln -sf libGLESv2-${backend}.so /usr/lib/libGLESv2.so.2.0.0 # ln -sf libVIVANTE-${backend}.so /usr/lib/libVIVANTE.so # ln -sf libGAL_egl.dri.so /usr/lib/libGAL_egl.so # for i in egl glesv1_cm glesv2 vg; do         cp /usr/lib/pkgconfig/${i}_${backend}.pc/usr/lib/pkgconfig/${i}.pc     done #rm /usr/lib/*-dfb.so /usr/lib/*-fb.so /usr/lib/*-wl.so (Optional in case you deploy your kernel version with GPU as module) make vivante kernel module (GPU kernel driver) load on boot: # echo vivante >> /etc/modules # nano /etc/udev/rules.d/10-imx.rules KERNEL=="galcore",  MODE="0660", GROUP="video" KERNEL=="mxc_asrc",  MODE="0666" Create an xorg.conf configured for the Vivante fbdev driver: # nano /etc/X11/xorg.conf Section "Device"     Identifier "i.MX Accelerated Framebuffer Device"     Driver "vivante"     Option "fbdev" "/dev/fb0"     Option "vivante_fbdev" "/dev/fb0"     Option "HWcursor" "false" EndSection Section "ServerFlags"     Option "BlankTime"  "0"     Option "StandbyTime"  "0"     Option "SuspendTime"  "0"     Option "OffTime"  "0" EndSection # cd .. Make sure the files copied into the correct places. If all compiled and copied, you should now see a bunch of new libraries in /usr/lib! Congratulations! After you finish you can reboot your system and start playing. Testing Gstreamer examples: show gstreamer-imx plugins: # gst-inspect-1.0 | grep imx imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder imxvpu:  imxvpudec: Freescale VPU video decoder imxv4l2videosrc:  imxv4l2videosrc: V4L2 CSI Video Source imxg2d:  imxg2dcompositor: Freescale G2D video compositor imxg2d:  imxg2dvideotransform: Freescale G2D video transform imxg2d:  imxg2dvideosink: Freescale G2D video sink imxipu:  imxipucompositor: Freescale IPU video compositor imxipu:  imxipuvideosink: Freescale IPU video sink imxipu:  imxipuvideotransform: Freescale IPU video transform imxpxp:  imxpxpvideotransform: Freescale PxP video transform imxpxp:  imxpxpvideosink: Freescale PxP video sink imxipuvideosink: # gst-launch-1.0 videotestsrc ! imxipuvideosink imxg2dvideosink: # gst-launch-1.0 videotestsrc ! imxg2dvideosink The imxeglvivsink allows hardware accelerated display to a window on the X11 host # export DISPLAY=:0.0 # gst-launch-1.0 videotestsrc ! imxeglvivsink To test if you have graphics support you can run any glmark2 and/or mesa-utils or can run example of the next route: # cd /opt/viv_samples/vdk/ # ./tutorial1                                                                      //any example root@imx6Q:~# glxgears -info GL_RENDERER   = Vivante GC2000 GL_VERSION    = 2.1 2.0.1 GL_VENDOR     = Vivante Corporation GL_EXTENSIONS = WGL_ARB_extensions_string WGL_EXT_extensions_string WGL_EXT_swap_control GL_EXT_texture_env_add GL_ARB_multitexture GL_ARB_multisample GL_ARB_texture_env_add GL_ARB_texture_compression GL_ARB_texture_env_combine GL_ARB_depth_texture GL_ARB_window_pos …. 1606 frames in 5.0 seconds = 321.130 FPS 1650 frames in 5.0 seconds = 329.834 FPS L_RENDERER   = Vivante GC2000 GL_VERSION    = 2.1 2.0.1 GL_VENDOR     = Vivante Corporation1629 frames in 5.0 seconds = 325.644 FPS 1621 frames in 5.0 seconds = 324.072 FPS 1650 frames in 5.0 seconds = 329.806 FPS 1651 frames in 5.0 seconds = 330.079 FPS

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

This is a HW design checklist for customer's reference. Please read and fill it in carefully before requesting a schematic review. Rev3.1 @2016.10.19 -- 1. Add i.MX6DQP related contents.

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.

1. User Case: Demo Architecture: Demo Description: A, B, C and Speaker all are i.MX6DQ SabreSD board and running Ubuntu system. A is media server which send out broadcast 30Mbps h264 video and audio stream and running iperf to send out tcp packets via best efforts lane to PC. B and C are clients to get video data only and play in screen.  Speaker is a client to receive audio data only and play to speaker. PC which install ubuntu system is used to received best efforts data from A. Demo Goal: Use Gstreamer playback 30Mbps streaming  "H264_AVC_1080p_30fps_27Mbps_mp3.avi", while running iperf TCP streaming under the following two case: 1. Running the non-CBS kernel 2. Enable the FIQ kernel Validate the Qav (Queue and Forwarding Protocol) which is developed by SW. 2. Resource: FIQ Patch: 0001-GIC-FIQ-EPIT-implement.patch 0002-set-EPIT-priority-to-highest.patch 0003-GIC-support-SMP-4-cores-of-FIQ.patch CBS &Shaper Patch: 0004-Implement-credit-base-shaper-alogrithim-to-schdule-A.patch 0005-enet-avb-CBS-SIRQ-rum-mode-pass-performance-stress-t.patch Others Patch: 0006-Fix-the-61883-sub-type-protocol-check.patch 0007-Add-hrtimer-for-the-sirq.-Talker-transmit-packets-nu.patch 0008-1.-Fix-memory-map-size-issue.patch 0009-Increase-BD-entries-to-reduce-the-full-times.patch 0010-Add-sys-interface-to-log-out-the-video-packet-number.patch 0011-Add-AVB-timestamp-support.patch 0012-GIC-support-SMP-4-cores-of-FIQ.patch Gstreamer UDPAVB Plug-in Library and Source: Library: udp/output/libgstudp.so Source: udp/* 3. Setup the Patch:       - Low level:  kernel enet driver implement CBS and traffic shaper:              1. Apply all the patches in the patch_whole.tar.gz in the attachment               2. Rebuild kernel 3.0.35: Enable "CONFIG_ENET_IMX6_AVB" to support AVB.                        Enable "CONFIG_RUN_IN_FIQ"  in kernel:            let CBS run in FIQ mode.                3. make uImage.                You can also use the uImage-avb-fig in the attachment directly.  Flash to the SD card use dd command, the user gudie refer to the  i.MX_6Dual6Quad SABRE_SD_Linux_User_Guide.pdf.                Note: the uImage_org_nonavb in the attachment is the kernel image without QAV and FIQ. - High level: use Gstreamer as the media input/output interface, encapsulation with IEEE1722 format:         Before the below action, you should already have seutp the Ubuntu Rootfs,  copied all the Freescale *.deb files that come alone with the Release BSP demo image package and copied all the MM codec *.deb files (IMX_MMCODEC_3.0.7.tar) that from Freescale offical website, the user gudie refer to the  i.MX_6Dual6Quad SABRE_SD_Linux_User_Guide.pdf. 1. Add gstreamer setup version as following: - gstreamer core version: 0.10.35 - gst-plugins-good version: 0.10.30 - gst-plugins-bad version: 0.10.11 2. Setup: - tar xvzf udp.tar.gz - cd gst-plugins-good-0.10.30 - ./configure - make - make install - cp ~/udp/* gst/udp/ - cd gst/udp - make - cp  libgstudp.so /usr/lib/gstreamer-0.10/ - gst-inspect | grep avb         //Check whether the avb plugin is installed successfully. If the three avb plugin is printed out in the terminal, the avb plugins are proved to install properly. 4. Run the Demo:       1.  Start the iperf server in PC linux machine by inputting " iperf -s -i 1&".              2.  Power on the A board, ensure the board can get the DHCP IP address, Start the iperf client on the demo board which sends outgoing Audio-Video streaming in the background. Input "iperf -c <iperf server ip> - t 6000&". If the connection is  successful, the iperf log should be able to be seen in the linux machine terminal.              3.  Power on the B and C board, inputting the following command to receive video data:            Run "./startRxVideoAVB.sh"  to start gstreamer video receive process on video display board       4.  Power on the speaker board, inputting the following command to receive audio data:             Run "./startRxAudioAVB.sh" to start gstream audio receive process on audio  playback board 5.  Inputting the following command to send video/audio data to client at the A board terminal windowns:                              Run "./startTxAVB.sh" to start the 1722 streaming traffic                                      (note: H264_AVC_1080p_30fps_27Mbps_mp3.avi located at current directory)               6.  Change to the kernel with QAV and follow the steps 1~5 above 5. Result: Without FIQ Qav,  video play at client B and C serious freeze. It takes 3 minutes to play 1min 40s h264 stream.  iperf speed over 80Mbps. With FIQ Qav, video play at client B and  C is smooth and same as without iperf in background. Iperf show speed is less than 70Mbps.  FIQ Qav correctly reserve necessary bandwidth to AV stream 6. Know issues Failed to request the IP from DHCP         [Solution]  For FIQ, after kernel up, you must run the command: echo 1 > /sys/devices/platform/imx_wfi_issue.0/enable   2.   Kernel is halted or crashed [Solution] In bootloader parameter, add 'nosmp' in bootargs_mmc.

The reference code is based on L4.14.78 GA1.0.0 BSP and M4 SDK 2.5.1.  It is tested on iMX8QXP MEK board, and it should also work for iMX8QM board. In L4.14.78 GA1.0.0 BSP, MU_5 is used for RPMSG between M4 FreeRTOS and A35 Linux, SC_R_MU_5B is M4 side and SC_R_MU_5A is A35 side. In linux side, we used the "imx_rpmsg_tty.ko" for this test, this driver is built as module in default BSP. Case 1: M4 wake up A35. Apply "L4.14.78_rpmsg_wakeup.patch" to linux kernel, this patch will enable the RPMSG wake up feature. "rpmsg_lite_pingpong_rtos.tar.bz2" is the M4 side test code. After booted the board with Linux + M4 rpmsg software, run followed test commands: 1. In A35 UART side, run followed commands:     # echo enabled > /sys/bus/platform/devices/90000000.rpmsg/power/wakeup     # insmod ./imx_rpmsg_tty.ko     # /unit_tests/Remote_Processor_Messaging/mxc_mcc_tty_test.out /dev/ttyRPMSG30 115200 R 100 1000 &     # echo deadbeaf > /dev/ttyRPMSG30     # echo mem > /sys/power/state 2. M4 UART side:    After run "echo deadbeaf > /dev/ttyRPMSG30" from Linux side, it will show "Got ping..." and wait there, after run A35 suspend commane "echo mem > /sys/power/state", Linux suspends. Then from M4 UART side, press "c" key, it will send RPMSG to A35 and wake up A35 Linux. Case 2: A35 wake up M4. "power_mode_switch_rpmsg_wakeup.tar.bz2" is the M4 side test code, After booted the board with Linux + M4 rpmsg software, the M4 UART will wait for A35 RPMSG driver ready. Test commands: 1. In A35 UART side, run followed commands to make RPMSG driver ready:     # insmod ./imx_rpmsg_tty.ko     # /unit_tests/Remote_Processor_Messaging/mxc_mcc_tty_test.out /dev/ttyRPMSG30 115200 R 100 1000 &     # echo deadbeaf > /dev/ttyRPMSG30 2. Now M4 UART shows ping pong messages to make sure RPMSG is ready. Now M4 is in power switch menu, select VLLS power mode in M4 UART:      Press  H for enter: VLLS     - Very Low Leakage Stop mode     ... ...      Press R for RPMSG. After press "R" key in M4 UART, M4 will print "Send a RPMSG message to wake up" and goto suspend mode. 3. Wake up M4 from A35 side, send any data to RPMSG:     # echo deadbeaf > /dev/ttyRPMSG30 M4 resumed and goto power switch menu again. SDK folder to compile the two M4 sample code: SDK/boards/mekmimx8qx/multicore_examples/rpmsg_lite_pingpong_rtos SDK/boards/mekmimx8qx/demo_apps/power_mode_switch

Revisions Revisions Description Details V1.0 Initial version   V1.2 Make a little update 1. Modify the path of the toolchain 2. Remove the command: make menuconfig 3. Modify the path of folder "out" in some commands   Hardware Requirement PC Host: Ubuntu for compiling, Windows for downloading and debugging Target: i.MX6ULL 14x14 EVK with LCD or HDMI TF card USB cables for console and download Power adapter Overview Ubuntu uses the same packaging management system (deb and apt) and with each development cycle pulls in the latest packages from Debian and then adapts them to Ubuntu specifics and adds more features and patches where necessary. They also push changes back to Debian and often developers are Ubuntu and Debian developers. Both of them have a nice UI and can install softwares easier than Yocto. The purpose of this doc is to install the Debian 8 Jessie Rootfs on NXP i.MX6ULL EVK Board. The doc contains several steps as following:    1. Download and compile the u-boot, kernel and dtb.    2. Get and modify the linaro rootfs.    3. Download all things to the SD card via MfgTool.    4. Run the Debian 8 Jessie in the board. Download and compile the u-boot, kernel and dtb.    a. Download the toolchain cd ~/ wget -c https://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/arm-linux-gnueabihf/gcc-linaro-6.3.1-2017.02-i686_arm-linux-gnueabihf.tar.xz mkdir toolchain tar xvf gcc-linaro-6.3.1-2017.02-i686_arm-linux-gnueabihf.tar.xz -C toolchain/ --strip-components 1 export ARCH=arm export CROSS_COMPILE=../toolchain/bin/arm-linux-gnueabihf- mkdir out    b. Download and make the u-boot cd ~/ wget -c http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/snapshot/uboot-imx-imx_v2016.03_4.1.15_2.0.0_ga.tar.bz2 mkdir uboot-imx tar jxvf uboot-imx-imx_v2016.03_4.1.15_2.0.0_ga.tar.bz2 -C uboot-imx/ --strip-components 1 cd uboot-imx make mx6ull_14x14_evk_defconfig make    c. Download and make the kernel and dtb cd ~/ wget -c http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git/snapshot/linux-imx-imx_4.1.15_2.0.0_ga.tar.bz2 mkdir linux-imx tar jxvf linux-imx-imx_4.1.15_2.0.0_ga.tar.bz2 -C linux-imx/ --strip-components 1 cd linux-imx vi arch/arm/configs/imx_v7_defconfig Add a line “CONFIG_FHANDLE=y” in the file to prevent the error when boot into rootfs. ****************************************************************************** Note: If you want to use the HDMI port instead of LCD to output the screen, you should modify the file /arch/arm/boot/dts/imx6ull-14x14-evk.dts to add a child node in &i2c2 : sii902x: sii902x@39 {         compatible = "SiI,sii902x";         pinctrl-names = "default";         interrupt-parent = <&gpio2>;         interrupts = <13 IRQ_TYPE_EDGE_FALLING>;         mode_str ="1280x720M@60";         bits-per-pixel = <16>;         reg = <0x39>;         status = "okay"; }; ****************************************************************************** make imx_v7_defconfig make -j4 zImage dtbs    d. Copy the u-boot, kernel and dtb to a folder cd ~/ sudo cp uboot-imx/u-boot.imx  out/ sudo cp linux-imx/arch/arm/boot/zImage  out/ sudo cp linux-imx/arch/arm/boot/dts/imx6ull-14x14-evk.dtb  out/ Get and modify the linaro rootfs. cd ~/ wget -c https://releases.linaro.org/debian/images/alip-armhf/16.04/linaro-jessie-alip-20160428-22.tar.gz mkdir rootfs tar xvf linaro-jessie-alip-20160428-22.tar.gz -C rootfs/ --strip-components 1 cd rootfs tar jcvf linaro-jessie-alip-20160428-22.tar.bz2 ./* sudo mv linaro-jessie-alip-20160428-22.tar.bz2  ../out Now the uboot, kernel, dtb and rootfs are ready in folder ~/out/!   Download all things to the SD card via MfgTool. Download the MfgTool in: http://www.nxp.com/products/automotive-products/microcontrollers-and-processors/arm-mcus-and-mpus/i.mx-application-processors/i.mx-6-processors/sabre-board-for-smart-devices-based-on-the-i.mx-6quad-applications-processors:RD-IMX6Q-SABRE?tab=Design_Tools_Tab Select the “IMX6_L4.1.15_2.0.0_MFG-TOOL” and download. Extract “L4.1.15_2.0.0-ga_mfg-tools.tar.gz” to Windows, and then extract again the “mfgtools-with-rootfs.tar.gz” to <your path>/mfgtools/. You should rename the files in the folder ~/out/ and copy to the path <your path>/mfgtools/Profiles/Linux/OS Firmware/files/ to replace the original files: u-boot.imx -> u-boot-imx6ull14x14evk_sd.imx zImage -> zImage imx6ull-14x14-evk.dtb -> zImage-imx6ull-14x14-evk.dtb linaro-jessie-alip-20160428-22.tar.bz2 -> rootfs_nogpu.tar.bz2 Switch the SW602 in i.MX6ULL EVK board to D1: off, D2: on, insert the TF card in slot SD2 and power on the board. Connect the board with PC by two micro-USB to USB cables(one is for downloading and another is for watching log) Finally, open the script “mfgtool2-yocto-mx-evk-sdcard-sd2.vbs” in the <your path>/mfgtools/. When the “HID-compliant device” shows then click “Start”.   If the processing is done, all things have been download to the board and you can go to the next step. Run the Debian 8 Jessie in the board. The following table shows the DIP switch settings for booting from the TF slot. Switch D1 D2 D3 D4 SW601 OFF OFF ON OFF SW602 ON OFF - -   Then power on the board and the logs will show in the serial console. Debian 8 will automatic login to root. ****************************************************************************** Note: If you want to use the HDMI port instead of LCD to output the screen, you should press any key when the log: Hit any key to stop autoboot shows and change the bootargs like following example: setenv bootargs console=ttymxc0,115200 init=/init video=mxcfb0:dev=hdmi,1280x720M@60,if=RGB24,bpp=32 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off vmalloc=256M androidboot.console=ttymxc0 consoleblank=0 androidboot.hardware=freescale cma=384M saveenv ****************************************************************************** When inputting “startx &” in serial console, the alip GUI will appear in the screen.   You can also use command ”apt-get” to install softwares(E.g. Firefox as following). ****************************************************************************** Note: If you have issues with “sudo” on user UID, need to execute the following commands: root@linaro-alip:~# chown root:root /usr/bin/sudo root@linaro-alip:~# chmod 4755 /usr/bin/sudo root@linaro-alip:~# chown root:root /usr/lib/sudo/sudoers.so root@linaro-alip:~# chown root:root /etc/sudoers root@linaro-alip:~# chown root:root /etc/sudoers.d/ root@linaro-alip:~# chown root:root /etc/sudoers.d/README   Note: If you have issues with “su” from user to root, need to execute the following commands: root@linaro-alip:~# chown root:root /bin/su root@linaro-alip:~# chmod 4755 /bin/su   Note: If you want to disable the warning window “Failed to apply network settings” after executing command “startx &”, you should deactive the Bluetooth: root@linaro-alip:~# sudo systemctl stop bluetooth.service root@linaro-alip:~# sudo systemctl disable bluetooth.service ******************************************************************************

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