This patch release is target for LPDDR2 ( dual channels in interleave mode ) support on i.MX6DL platform. Two patches are prepared to modify u-boot and kernel in order to have correct DRAM init sequence, 400MHz & 24MHz frequency switching and suspend/resume support. The patches are not fully verified. It is provided as reference for customer to enable their i.MX6DL board with LPDDR2. Customization and Testing is needed by customer. We need to remind some points here: MMDC_MDCFG3LP in 24MHz need to increase the margin ( 0x40222 -> 0x80555 ) in order to pass the OS frequency switch stress test. We are identifying the reason but this workaround is working fine and included to the patch. Code changes in kernel is prepared so that it is compatible to DDR3. In other words, the DDR type will be detected and a correct handling will be done for LPDDR2 and DDR3. In LPDDR2 system, we can't put SDQ pin into LPM during suspend. Otherwise, the system cannot resume. Dual channels in fix mapping mode is not recommended to use.

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with MMDC initialization. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP validation boards.

Recently I published this i.MX Dev Blog post about the Gateworks plugin gst-variable-rtsp-server support for i.MX 6. Now, you can check how to use it on i.MX 8 SoCs as well. 1. Preparing the image In order to use gst-variable-rtsp-server plugin, prepare your machine and distro: Add the following line to conf/local.conf: IMAGE_INSTALL_append += "gstreamer1.0-rtsp-server gst-variable-rtsp-server" Download the attached patch and apply it by doing: $ cd <yocto_path>/sources/meta-fsl-bsp-release/ $ git am ~/Download/0001-Add-RTSP-support-for-i.MX-8-L4.14.78_ga1.0.0-or-olde.patch Note: This patch is not necessary for L4.14.98_ga2.0.0 BSP! Then, build the image with bitbake and deploy it to the SD card. 2. Video Test Source Example Server $ gst-variable-rtsp-server -p 9001 -u "videotestsrc ! v4l2h264enc ! rtph264pay name=pay0 pt=96" Client 2. Camera Example Server $ gst-variable-rtsp-server -p 9001 -u "v4l2src device=/dev/video0 ! video/x-raw,width=640,height=480 ! v4l2h264enc ! rtph264pay name=pay0 pt=96" Client In order to use VLC or other application as the client, just enter the URL as shown in the image below:

Hi everyone, Can I stream video at some different resolutions at the same time using I.Mx6? Thank you.

Uploading the i.MX 6 Linux Reference Manual here after being un-able to find it on Google or on i.MX6 product page.

To fix LCD problem: Download DirectFB patches (click here). Copy patches and kernel spec to LTIB: tar zxvf DirectFB-patches-specs.tar.gz cd specs cp kernel-imx31_3stack-2.6.24-DirectFB-LCD-fix.patch /opt/freescale/pkgs/ cp kernel.spec.in ~/ltib-imx31pdk-r14/config/platform/imx/ Remove old kernel: ~/ltib-imx31pdk-r14$ rm -rf rpm/BUILD/linux* Issue LTIB to decompress kernel and apply patches: ~/ltib-imx31pdk-r14$ ./ltib -p kernel -m prep You will see at end: + echo Patch #1 (kernel-imx31_3stack-2.6.24-DirectFB-LCD-fix.patch): Patch #1 (kernel-imx31_3stack-2.6.24-DirectFB-LCD-fix.patch): + patch -p1 -s + exit 0 Build time for kernel: 21 seconds It means which kernel-imx31_3stack-2.6.24-DirectFB-LCD-fix.patch was applied correctly! Now compile your kernel: ~/ltib-imx31pdk-r14$ ./ltib -p kernel -m scbuild Install it on your rootfs: ~/ltib-imx31pdk-r14$ ./ltib -p kernel -m scdeploy To fix Touch-Screen Copy specs to LTIB: cd specs cp tslib.spec ~/ltib-imx31pdk-r14/dist/lfs-5.1/tslib/ cp DirectFB.spec ~/ltib-imx31pdk-r14/dist/lfs-5.1/DirectFB/ Remove old directories: ~/ltib-imx31pdk-r14$ rm -rf rpm/BUILD/tslib-1.0/ ~/ltib-imx31pdk-r14$ rm -rf rpm/BUILD/DirectFB-1.1.0/ Edit your pkg_map and change tslib order. DirectFB needs tslib, then this lib needs be compiled first: [alan@localhost ltib-imx31pdk-r14]$ vi config/userspace/pkg_map ... PKG_TSLIB                                      = tslib PKG_DIRECTFB                               = DirectFB PKG_DIRECTFB_EXAMPLES            = DirectFB-examples ... Now run: alan@armagedon:~/ltib-imx31pdk-r14$ ./ltib -c Then select DirectFB and tslib packages. To test Touch-Screen mx31# mknod /dev/input/tslib0 c 13 65 mx31# export TSLIB_TSDEVICE=/dev/input/tslib0 mx31# rm -f /etc/pointercal mx31# ts_calibrate mx31# df_window

How To Understand JTAG BSDL File This example explains how to understand the BSDL file in order to create an OpenOCD configure file. IR Len That information can be retrieved directly: attribute INSTRUCTION_LENGTH of imx_device: entity is 5; This means that IR Len is 5, then in OpenOCD config it will be informed this way: -irlen 5 IR Capture The IR Capture also can be retrieved directly: attribute INSTRUCTION_CAPTURE of imx_device : entity is "XXX01"; This means that IR Capture is 1, then in OpenOCD config it will be informed this way: -ircapture 0x1 IR Mask The IR Mask is based on IR Len size. Just create a binary number with "IR Len" bits 1. If the IR Len is 4 then the IR Mask will be 0xF (1111). Case the IR Len is 5 the IR Mask will be 0x1F (11111). In this BSDL example (IR Len = 5) the OpenOCD config needs to inform the IR Mask this way: -irmask 0x1f TAP ID attribute IDCODE_REGISTER  of imx_device : entity is     "0010"            & -- Version     "000110"          & -- Design Center Number     "0100000001"      & -- Sequence Number     "00000001110"      & -- Manufacturer Identity     "1";                -- IEEE 1149.1 Requirement This code can be converted directly to TAP ID: Binary: 0010-0001-1001-0000-0001-0000-0001-1101 Hexadecimal: 2-1-9-0-1-0-1-D Then in OpenOCD configure you will create: if { [info exists SDMATAPID ] } {   set _SDMATAPID $SDMATAPID } else {   set _SDMATAPID 0x2190101d } The final configure line will be: jtag newtap $_CHIPNAME smda -irlen 5 -ircapture 0x1 -irmask 0x1f -expected-id $_SDMATAPID

Not all of imx6 boards can support SDR104, refer to imx6sx Reference Manual, BOOT_CFG1[2:3] = 11 is SDR104 normally hardware support 3.3v, but SDR104 only supports 1.8v. refer to the AI board schematic, you can find as below: For current yocto driver, which already supports sd3.0 standard, but kernel should change something to support this, for customer, one can refer to the source code in the yocto, the path:root/arch/arm/boot/dts/imx6sx-sdb.dts or path:root/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi For supporting SDR104, should change the dts file, because of 1.8v only, should remove no-1-8-v in the source code, then add vmmc-supply according to the dts file above. for example, based on the schematic, you can find: &usdhc1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usdhc1>; cd-gpios = <&gpio1 1 0>; no-1-8-v; keep-power-in-suspend; enable-sdio-wakeup; status = "okay"; }; &usdhc3 { pinctrl-names = "default", "state_100mhz", "state_200mhz"; pinctrl-0 = <&pinctrl_usdhc3>; pinctrl-1 = <&pinctrl_usdhc3_100mhz>; pinctrl-2 = <&pinctrl_usdhc3_200mhz>; cd-gpios = <&gpio6 15 0>; wp-gpios = <&gpio1 13 0>; /* * Due to board issue, we can not use external regulator for card slot * by default since the card power is shared with card detect pullup. * Disabling the vmmc regulator will cause unexpected card detect * interrupts. * HW rework is needed to fix this isssue. Remove R695 first, then you * can open below line to enable the using of external regulator. * Then you will be able to power off the card during suspend. This is * especially needed for a SD3.0 card re-enumeration working on UHS mode * Note: reg_sd3_vmmc is also need to be enabled */ /* vmmc-supply = <&reg_sd3_vmmc>; */ keep-power-in-suspend; enable-sdio-wakeup; status = "okay"; }; reg_sd3_vmmc: sd3_vmmc{ compatible = "regulator-fixed"; regulator-name = "P3V3_SDa_SWITCHED"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; gpio = <&gpio7 8 GPIO_ACTIVE_HIGH>; enable-active-high; /* remove below line to enable this regulator */ status="disabled"; };

Hi All I make fsl-image-qt5 in yocto. make command: $ MACHINE=imx6slevk source fsl-setup-release.sh -b build -e fb $ bitbake fsl-image-qt5 However, I couldn't make meta-toolchin-qt5 in yocto. The error is as follows. > | WARNING: exit code 1 from a shell command. > | ERROR: Function failed: do_configure (log file is located at /opt/yocto_build/yocto_fsl-bsp-imx6slevk/fsl-release-bsp/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtdeclarative/5.3.2-r0/temp/log.do_configure.3411) > ERROR: Task 771 (/opt/yocto_build/yocto_fsl-bsp-imx6slevk/fsl-release-bsp/sources/meta-qt5/recipes-qt/qt5/qtdeclarative_5.3.2.bb, do_configure) failed with exit code '1' > NOTE: Tasks Summary: Attempted 1235 tasks of which 1234 didn't need to be rerun and 1 failed. > No currently running tasks (1234 of 3376) > > Summary: 1 task failed: >   /opt/yocto_build/yocto_fsl-bsp-imx6slevk/fsl-release-bsp/sources/meta-qt5/recipes-qt/qt5/qtdeclarative_5.3.2.bb, do_configure > Summary: There was 1 ERROR message shown, returning a non-zero exit code. How do you make toolchain include Qt5?

[中文翻译版] 见附件   原文链接： Enable GmSSL which supports OSCCA Algorithm Toolbox on i.MX 

Host Environment: ubuntu 16.04 LTS Linux BSP For i.MX : version 4.9.88 The document has 5 main contents: 1. Compiling core-image-base in Yocto BSP --Copy u-boot source code to a new directory --Copy linux kernel source code to a new directory 2. Exporting 4.9.88 toolchain from Freescale Yocto BSP (1) Using MACHINE=imx7dsabresd to export the toolchain (2) Using MACHINE=imx6qsabresd to export the toolchain. Actually above 2 are the same toolchain after exporting. Here , only show any one of boards(not ARM64) can be used for MACHINE. So users only need to export it for one time, select (1) or (2) to export toolchain. (3) Using MACHINE=imx8mqevk to export ARM64 toolchain 3. Compling u-boot & linux kernel under Stanalone iMX7DSabreSD --Compiling  u-boot for imx7dsabresd --Compiling kernel and dtb for imx7dsabresd iMX8MQEVK --Compiling u-boot for imx8mqevk --Compiling kernel and dtb for imx8mqevk 4. Compiling OS Firmware for i.MX7DSabreSD board --u-boot for mfg tools --kernel and dtb for mfg tools 5. Copy OS Firmware to the related path of MFG tools --------------------------------------------------------------------------------------------------------------------------- [Content of Document] 1. Compiling core-image-base in Yocto BSP          After repo syn is done according to “i.MX_Yocto_Project_User's_Guide.pdf”, Use the command to compile linux BSP, u-boot & kernel source code will be released. # DISTRO=fsl-imx-fb MACHINE=imx7dsabresd source fsl-setup-release.sh -b build-fb # bitbake core-image-base          After compiling is done, u-boot & linux kernel source code is in the path below: u-boot: ~/imx-yocto-bsp/build-fb/tmp/work/imx7dsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/git linux: ~/imx-yocto-bsp/build-fb/tmp/work/imx7dsabresd-poky-linux-gnueabi/linux-imx/4.9.88-r0/git          We can create a new directory for uboot and linux kernel source code. Here I created a directory named disk2. # cd ~/ # mkdir disk2 # cd disk2 # mkdir u-boot-2017-03 # mkdir linux-imx-4.9.88 --Copy u-boot source code to a new directory # cd ~/imx-yocto-bsp/build-fb/tmp/work/imx7dsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/git # cp –r ./* ~/disk2/u-boot-2017-03 --Copy linux kernel source code to a new directory # cd ~/imx-yocto-bsp/build-fb/tmp/work/imx7dsabresd-poky-linux-gnueabi/linux-imx/4.9.88-r0/git # cp –r ./* ~/disk2/ linux-imx-4.9.88 2. Exporting 4.9.88 toolchain from Freescale Yocto BSP (1) Using MACHINE=imx7dsabresd to export the toolchain Step1: # cd ~/imx-yocto-bsp/ # DISTRO=fsl-imx-fb MACHINE=imx7dsabresd source fsl-setup-release.sh -b build-minimal … … Do you accept the EULA you just read? (y/n)  y EULA has been accepted. Welcome to Freescale Community BSP The Yocto Project has extensive documentation about OE including a reference manual which can be found at:     http://yoctoproject.org/documentation For more information about OpenEmbedded see their website:     http://www.openembedded.org/ You can now run 'bitbake <target>' Common targets are:     core-image-minimal     meta-toolchain     meta-toolchain-sdk     adt-installer     meta-ide-support Your build environment has been configured with:     MACHINE=imx7dsabresd     SDKMACHINE=i686     DISTRO=fsl-imx-fb     EULA= BSPDIR= BUILD_DIR=. meta-freescale directory found Here “build-minimal” is a directory for compiling source code, users can also set it other name. In ~/imx-yocto-bsp/build-minimal, Begin to export toolchain with the command. Step2: # DISTRO=fsl-imx-fb MACHINE=imx7dsabresd bitbake core-image-minimal -c populate_sdk [Comment-1] About DISTRO and MACHINE on above 2 commands MACHINE can be set the values below. imx6qpsabreauto imx6qpsabresd imx6ulevk imx6ull14x14evk imx6ull9x9evk imx6dlsabreauto imx6dlsabresd imx6qsabreauto imx6qsabresd imx6slevk imx6solosabreauto imx6solosabresd imx6sxsabresd imx6sxsabreauto imx6sllevk imx7dsabresd imx7ulpevk imx8mqevk   So MACHINE’s value is the name each Evaluation Borad. DISTRO can be set the values below: fsl-imx-x11 - X11 graphics are not supported on i.MX 8. fsl-imx-wayland - Wayland weston graphics. fsl-imx-xwayland - Wayland graphics and X11. X11 applications using EGL are not supported. fsl-imx-fb - Frame Buffer graphics - no X11 or Wayland. Frame Buffer is not supported on i.MX 8 bitbake rootfs type       core-image-minimal       core-image-base       core-image-sato       fsl-image-machine-test       fsl-image-validation-imx       fsl-image-qt5-validation-imx Below is the detailed description for above rootfs type: [Comment-2] Descriptions on difference of toolchain between i.MX6/7 and i.MX8MQ          i.MX6 and i.MX7 are both 32bit ARM processor, they use the same toolchain.          i.MX8MQ is 64bit ARM processor, so it’s toolchain is different from that of i.MX6/7. Setp 3:          After above compiling is done, enter into ~/imx-yocto-bsp/build-minimal/tmp/deploy/sdk # cd ~/imx-yocto-bsp/build-minimal/tmp/deploy/sdk # ls Run .sh file: Then continue operations according to guidance: Done: OK, Let us check /opt/fsl-imx-fb/ directory: # ls /opt/fsl-imx-fb/4.9.88-2.0.0/          Because we used MACHINE=imx7dsabresd, environment was named “cortex-A7”, compiler’s version is still 4.9.88. (2) Using MACHINE=imx6qsabresd to export the toolchain.          We can change “MACHINE=imx6qsabresd” and repeat above 3 steps, environment will be named “cortex-A9”.          Close the current terminal, and open a new one. # cd ~/ imx-yocto-bsp # DISTRO=fsl-imx-fb MACHINE=imx6qsabresd source fsl-setup-release.sh -b build-A9-min            Then automatically enter “~/imx-yocto-bsp/build-A9-min”, run command below. # DISTRO=fsl-imx-fb MACHINE=imx6qsabresd bitbake core-image-minimal -c populate_sdk # ~/imx-yocto-bsp/build-A9-min/tmp/deploy/sdk # ls # ./ fsl-imx-fb-glibc-x86_64-core-image-minimal-cortexa9hf-neon-toolchain-4.9.88-2.0.0.sh   Set it up in another directory: /opt/fsl-imx-fb/4.9.88 (3) Using MACHINE=imx8mqevk to export ARM64 toolchain          Export Toolchain for i.MX8MQ, create a new terminal, then run these 2 commands below. # ~/imx-yocto-bsp # DISTRO=fsl-imx-xwayland MACHINE=imx8mqevk source fsl-setup-release.sh -b build-xwayland # DISTRO=fsl-imx-fb MACHINE=imx8mqevk bitbake core-image-minimal -c populate_sdk Done.          Copy the toolchain to /opt/fsl-imx-fb directory # cd ~/imx-yocto-bsp/build-xwayland/tmp/deploy/sdk # ls #./fsl-imx-fb-glibc-x86_64-core-image-minimal-aarch64-toolchain-4.9.88-2.0.0.sh          I installed it to a new directory: /opt/fsl-imx-fb/4.9.88-arm64 #ls ls /opt/fsl-imx-fb/4.9.88-arm64/  OK, 64bit toolchain for i.MX8MQ has been exported to the directory. 3. Compling u-boot & linux kernel under Stanalone iMX7DSabreSD --Compiling  u-boot for imx7dsabresd # cd ~/disk2/u-boot-2017-03 # source /opt/fsl-imx-fb/4.9.88-2.0.0/environment-setup-cortexa7hf-neon-poky-linux-gnueabi # export ARCH=arm # make clean # make mx7dsabresd_defconfig # make u-boot.imx Done. --Compiling kernel and dtb for imx7dsabresd # cd ~/disk2/linux-imx-4.9.88/ [comment] If environment has been configured, that is, these 2 commands have been run on the current terminal, don’t need to run them again. “source /opt/fsl-imx-fb/4.9.88-2.0.0/environment-setup-cortexa7hf-neon-poky-linux-gnueabi” and “export ARCH=arm” # make clean # make imx_v7_defconfig # make            zImage is in “~/disk2/linux-imx-4.9.88/arch/arm/boot”          dtb is in “~/disk2/linux-imx-4.9.88/arch/arm/boot/dts”            Probably users want to run “make menuconfig”, and meet the errors like below. # sudo apt-get install libncurses*  (To solve the problem below) # make menuconfig [Comment-3]  Users can also use "environment-setup-cortexa9hf-neon-poky-linux-gnueabi" to compile u-boot and kernel. iMX8MQEVK --Compiling u-boot for imx8mqevk # cd ~/disk2/u-boot-2017-03 # source /opt/fsl-imx-fb/4.9.88-arm64/environment-setup-aarch64-poky-linux # export ARCH=arm64 # make clean # make imx8mq_evk_defconfig # make u-boot.imx Done. --Compiling kernel and dtb for imx8mqevk # cd ~/disk2/linux-imx-4.9.88/ [comment] If environment has been configured, that is, these 2 commands have been run on the current terminal, don’t need to run them again. “source /opt/fsl-imx-fb/4.9.88-arm64/environment-setup-aarch64-poky-linux” and “export ARCH=arm64” # make clean # make defconfig # make          Run the command to unset LDFLAGS: # unset LDFLAGS # make Done. 4. Compiling OS Firmware for i.MX7DSabreSD board --u-boot for mfg tools # make mx7dsabresd_config # make u-boot.imx          Then rename u-boot.imx to be “u-boot-mx7dsabresd-mfg.imx”. --kernel and dtb for mfg tools          Copy imx_v7_mfg_defconfig file to “arch/arm/configs”, then run commands below. # make imx_v7_mfg_defconfig # make          zImage will be generated at path arch/arm/boot.          dtb file will be generated at path arch/arm/boot/dts            Then rename zImage to be zImage-mx7dsabre-mfg,          Rename imx7d-sdb.dtb to be zImage-imx7d-sdb-mfg.dtb 5. Copy OS Firmware to the related path of MFG tools          Up to now, 3 files for OS Firmware has been generated, then copy these 3 files to mfgtools\Profiles\Linux\OS Firmware\firmware            When MFG Tools begins to run, these 3 files and ramdisk will be downloaded to SDRAM on board, then run them, and download images(u-boot\kernel\rootfs\)  which have been ready in  “mfgtools\Profiles\Linux\OS Firmware\files”.            Above steps and commands will be performed according to list in ucl2.xml. So customer will add a new list for her downloading or change an existing list according to image’s name. NXP TIC team Weidong Sun 04-25-2019

I have a few questions about the various reference designs for the i.mx6UL. Please see the attachment for specifics.

Step 1: Build r13.4.1         make         /* Store images file for MFGTool use */         make dist    /* Get ota_1.zip, and target_files_1.zip at out/dist, store them in a dedicated directory, for example .../release-1 */ Step 2: Modify any files in source code base; Step 3: make dist    /* Get ota_2.zip, and target_files_2.zip at out/dist, store them in a dedicated directory, for example .../release-2 */ Step 4: MFGTool flash release-1 images; Step 5: cp ota_2.zip to SD; Step 6: start board, then execute following commands under serial terminal;         cp /sdcard/ota_2.zip /cache/ota_2.zip         mkdir /cache/recovery         echo --update_package=/cache/ota_2.zip > /cache/recovery/command         sync         reboot recovery         Then you can see the upgrade successful. Step 7: MFGTool flash release-1 images; Step 8: ./build/tools/releasetools/ota_from_target_files -i .../release-1/target_files_1.zip .../release-2/target_files_2.zip ./diff_from_1_to_2.zip Step 9: cp diff_from_1_to_2.zip to SD; Step10: start board, then execute following commands under serial terminal;         cp /sdcard/diff_from_1_to_2.zip /cache/diff.zip         mkdir /cache/recovery         echo --update_package=/cache/diff.zip > /cache/recovery/command         sync         reboot recovery

Question: Is it true ture that MX6 VPU is capable of encoding dual H.264 streams that are 1024x600 at 60fps?  There are slides that claim three 720p30 streams or two 1080p30 streams simultaneously. There is little guidance as to what the VPU limits in resolution, frame rate and bit rate are for other resoluitons and frame rates. Is there any information that can be used to decide if  the VPU can encode an arbitrary video stream or multiple arbitrary video streams?  Since memory bandwidth will enter into this decision at some point has anyone quantified the memory bandwidth requirements verses video resolution and frame rate? Answer: Maximum supported trhoughput,  is 72,576,000 pixels /s @ VPU frecuency of 266 mhz 2 x  1024 x 600 x 60hz = 73,728,000 So this is not supported. If framerate is lower i.e.  30hz  then it will be supported.

imx53 DDR stress tester V0.042

Introduction EVIS (Enhanced Vision Instruction Set) is an API level program language, which is applicable on GC7000XSVX (i.MX8QM) and VIP8000NanoSi (i.MX8MP). The instructions take advantage of the enhanced vision capabilities in the vision-capble hardware, with low-latency. It provides additional functionality for vision image processing beyond the functions provided through the Khronos Group OpenVX API. In the i.MX8QM/i.MX8MP BSP, the OpenCL compiler also support the EVIS instructions. So, it is also an OpenCL VX Extension API. The source file can found in /usr/include/CL/cl_viv_vx_ext.h. Hardware Requirements i.MX8QM (GC7000XSVX) supports EVIS1. i.MX8MP (VIP8000NanoSi) supports EVIS2. Packed Data Types To fully utilize the computing power of the instructions, the extension API support packed data types. For example, in standard OpenCL, a vector char4 will occupy 4x 32-bit registers, while a packed char16 only occupies 128 bits. Thus use packed data types as possible.  The char, unsigned char, short, unsigned short, integer, unsigned integer, float packed data types are supported. They are defined with vxc_ prefix i.e. vxc_char, vxc_uchar, vxc_short, vxc_ushort, vxc_int, vxc_uint, vxc_float, followed by a literal value n that defines the number of elements in the packed data. Supported values of n are 2, 4, 8, and 16 for all the packed data types. Table 1 List of packed data type Type Description vxc_charn A vector of n packed signed character value vxc_ucharn A vector of n packed unsigned character value vxc_shortn A vector of n packed signed short value vxc_ushortn A vector of n packed unsigned short value vxc_intn A vector of n packed signed integer value vxc_uintn A vector of n packed unsigned integer value vxc_floatn A vector of n packed float value OP_CODE Instructions OP_CODE instructions operate on packed data. The enumeration can be found in /usr/include/CL/cl_viv_vx_ext.h. Only EVIS1 supports instructions: VXC_IAdd VXC_MagPhase VXC_BiLinear VXC_SelectAdd VXC_BitReplace VXC_Filter VXC_DP2x16/VXC_DP2x16_b Objects load and store Packed type image data read/write: supported types are packed 8-bit/16bit integer, 16bit float. Image read/write for image1d_t/image1d_array/image2d_t. Offset should be composed by using VXC_5BITOFFSET_XY(x, y). VXC_OP4(img_load, Dest, Image, Coord, Offset, Info) VXC_OP4_NoDest(img_store, Image, Coord, Color, Info) Parameters:         img_load/img_store    Read/write image data.          Dest                            The destination loading the data to.         Image                          The packed image data read from for img_load. The packed image data writing to for img_store.         Coord                          Coordinates to read/write the image data.         Color                           The image data being written to Image for img_store.         Info                              See more info in VXC_MODIFIER(StartBin, EndBin, SourceBin, RoundingMode, Clamp). VXC_MODIFIER(StartBin, EndBin, SourceBin, RoundingMode, Clamp) Parameters:         StartBin/EndBin           The first bin/the last bin for consecutive packed data.         SourceBin                    Not used.          RoundingMode            0: Toward Zero (truncated), 1: Toward Infinity (rounded up), 2: To Nearest Even, 3: not used.         Clamp                          0: no, result is truncated to fit result type (just the lower bits are copied), 1: yes, result is clamped to fit the result type. For example, int2 coord = (int2)(get_global_id(0), get_global_id(1)); vxc_uchar16 r1; VXC_OP4(img_load, r1, in_image, coord, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0)); VXC_Filter This interface applies a specified filter on a 3x3 pixel block. VXC_OP4(filter, Dest, Src0, Src1, Src2, Info) Parameters:         filter                           Filter modes.         Dest                          The filtered image.         Src0                          The first row pixels for 3x3 filter.         Src1                          The second row pixels for 3x3 filter.         Src2                          The third row pixles for 3x3 filter.         Info                            See more info in VXC_MODIFIER_FILTER(StartBin, EndBin, SourceBin, Filter, Clamp). VXC_MODIFIER_FILTER(StartBin, EndBin, SourceBin, Filter, Clamp) Parameters:         StartBin/EndBin        The first bin/the last bin for consecutive packed data.         SourceBin                 Not used.         Filter                          Filter modes are listed in table 2.         Clamp                        0: no, result is truncated to fit result type (just the lower bits are copied), 1: yes, result is clamped to fit the result type. Table 2. List of filter modes: Filter Mode Description VXC_FM_BOX Compute a 3x3 box filter: |1/9, 1/9, 1/9, 1/9, 1/9, 1/9, 1/9, 1/9, 1/9|. VXC_FM_Guassian Compute a 3x3 Gaussian filter: |1/16, 2/16, 1/16, 2/16, 4/16, 2/16, 1/16, 2/16, 1/16|. VXC_FM_SobelX Compute a 3x3 Sobel filter in the x-direction: |-1, 0, 1, -2, 0, 2, -1, 0, 1|. VXC_FM_SobelY Compute a 3x3 Sobel filter in the y-direction: |-1, -2, -1, 0, 0, 0, 1, 2, 1|. VXC_FM_ScharrX Compute a 3x3 Scharr filter in the x-direction: |3, 0, -3, 10, 0, -10, 3, 0, -3|. VXC_FM_ScharrY Compute a 3x3 Scharr filter in the y-direction: |3, 10, 3, 0, 0, 0, -3, -10, -3|. VXC_FM_Max Get the maximum from a 3x3 kernel. VXC_FM_Min Get the minimum from a 3x3 kernel. VXC_FM_Median Get the median from a 3x3 kernel. For example (details in Gaussian Filter examples), int2 coord_in1 = coord + (int2)(-1, -1);\n\ VXC_OP4(img_load, lineA, in_image, coord_in1, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int2 coord_in2 = coord + (int2)(-1, 0);\n\ VXC_OP4(img_load, lineB, in_image, coord_in2, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int2 coord_in3 = coord + (int2)(-1, 1);\n\ VXC_OP4(img_load, lineC, in_image, coord_in3, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int info = VXC_MODIFIER_FILTER(0, 13, 0, VXC_FM_Guassian, 0);\n\ VXC_OP4(filter, out, lineA, lineB, lineC, info); ;\n\ VXC_AbsDiff Calculates a result for the absolute difference between a and b. It works on packed data, so it can compute 16x 8-bit values or 8x 16-bit values. VXC_OP3(abs_diff, Dest, Src0, Src1, Info) Parameters:         abs_diff                 Specify the function of absolute difference.         Dest                      Destination to store the result.         Src0                      The first source to calculate the absolute difference.         Src1                      The second source to calculate the absolute differenece.         Info                       See more info in VXC_MODIFIER(StartBin, EndBin, SourceBin, RoundingMode, Clamp). There are also other interfaces will not be specified here, which can be found in the /usr/include/CL/cl_viv_vx_ext.h, i.e. VXC_IAdd, VXC_IAccSq, VXC_Lerp, VXC_MagPhase, VXC_MulShift, VXC_Clamp, VXC_BiLinear, VXC_SelectAdd, VXC_AtomicAdd, VXC_BitExtract and VXC_BitReplace.  Further Reading: OpenVX Vision Image Extension API Introduction - DP Dot Products

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

Question: What’s the best way to rotate a MX6 image 90 degrees, thought the IPU correct? IPU is limited to 1024x1024. Apparently we don’t support frame buffer rotation in the IPU, so we have to use some middleware. I know that Android’s surface flinger uses the GPU but do you know what we can use in Linux that uses H/W acceleration also? It looks look like X-server can rotate only when the Vivante driver is not  loaded, which means the hardware is not implementing rotations. Answer: it should be possible to split the picture into two halves and rotate them separately. Well, two halves if you can reduce the line count to 1024 … otherwise it would be 4 rotates. X11 Xrandr will be implemented on GPU sometime this year. It's in the R&D queue but as low priority. They could use GC320 low level API to rotate (if they use linux frame buffer). It implies a blit but it would be done by GC320 they will probably need to use virtualFB too. The API documentation is the BSP documentation (iMX6.2D.API.pdf) Attached a simple source using the 2D low level API. VirtualFB: https://community.freescale.com/message/289198

Starting from $52, the VAR-SOM-MX6 sets the bar for unparalleled design flexibility. The VAR-SOM-MX6 ensures scalable and simplified development, while also extending the product lifecycle. Thanks to four CPU core assembly options, customers can apply a single System on Module in a broad range of applications to achieve short time-to-market for their current innovations, while still accommodating potential R&D directions and marketing opportunities.     VAR-SOM-MX6 CPU: Freescale iMX6 Key features include: Freescale i.MX6 1.2GHz Quad / Dual / Single core Cortex-A9       2GB DDR3, 1GB SLC NAND Flash       Full HD 1080p video encoding/decoding capability       Vivante GPU providing 2D/3D acceleration       Simultaneous multiple display support       Gigabit Ethernet       TI WiLink™ 6.0 single-chip connectivity solution (Wi-Fi, Bluetooth®)       PCI-Express 2.0, S-ATA 3.0       Camera interface       USB 2.0: Host, OTG       Audio In/Out       Dual CAN Bus This versatile solution's -40 to 85°C temperature range and Dual CAN support is ideal for industrial applications, while 1080p video and graphics accelerations make it equally suitable for intensive multimedia applications. The impressive scalability of the VAR-SOM-MX6 satisfies the needs of the most demanding future application requirements whether faster processing power, enhanced algorithms or improved graphics and video performance to name just a few. The VAR-SOM-MX6 is an all-round solution with broad connectivity and sophisticated video and acceleration graphic capabilities, delivering a range of middle to high end assembly options all from the same product. For more details, please see VAR-SOM-MX6 CPU: Freescale iMX6