Q: How to program i.MX6 eFUSE? A: what about using the mfg tool? In the end only the supplies, USB OTG and the boot mode pins need to be connected. The customers Idea was to have all devices (i.MX6 eFUSE, Flash, PFUZE, etc) pre- programmed before mounting on the board. I presented the flows we support (MFG Tool, Platform SDK) for eFUSE programming last Friday when I was at the customer. KITPF0100SKTEVBE Product Summary Page MfgTools is the most convenient way to burn eFuse. Or the customer can burn the fuse on their jig/socket board by the u-boot: How to Fuse in U-Boot U-Boot contains a tool, imxotp, which is used for fusing. U-Boot > imxotp imxotp - One-Time Programable sub-system Usage: imxotp imxotp read <index> - read fuse at 'index' imxotp blow [--force] <index> <value> - blow fuse at 'index' with hex value 'value' Tips: 'addr' to 'index': convert 'index' from 'address' index = (addr - otp_base) / 0x10 eg, addr is 0x021bc410, otp_base is 0x021bc400, the index = 1 '--force' must be present in order to blow the fuse. Command will abort if '--force' is missing. index = (addr - otp_base) / 0x10, where the addr is the address of the fuse you want to operate, the otp_base is the base address of the fuse block. 'value' should correspond to fuse settings according to the fuse map and desired fuse configuration. ---------------------------------- FIrst of all thanks for your reply. However both flow assumes the i.MX6 is already soldered on the board. Please note the specific request was if it is possible (and we can support a programming house) to pre program the efuses BEFORE they are soldered on the PCB thus on a standard programmer. Take an FLASH programmer as an example.

This tutorial has been done with an i.MX51 EVK. This example can be easily adapted to i.MX35 or i.MX53 that share the same GPU Core (Z160) and the same API (OpenVG 1.1). This tutorial show you how to do a simple image warp deformation with OpenVG 1.1.     Generation of Linux Image with 2D gpu support To support 2D/3D gpu, you need to select gpu driver in LTIB. In LTIB's "package list" select the following packages: [x] amd-gpu-bin-mx51 [x] libz160-bin Build your Linux Image and copy it to your SD card. Building OpenVG simple application Download the application (see attached archive) Untar/unbz2 the application source code. To build the simple OpenVG application, you need to adapt the Makerules file. First you have to indicate where your linux image has been generated withLTIB: ROOTFS = /home/fsl/LTIB_1_7/ltib/rootfs You also need to indicate the compiler path (usualy installed in /opt/freescale/usr/local/....): GNUTOOL_PATH=/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/ After that you have to copy gpu's driver headers files in the include folder of the project. You will find these header in /opt/freescale/pkgs/amd-gpu-bin-mx51-x.x.x.tar.gz archive: extract all the include folders/files in the include folder of the project. Now you can build the application:   fsl@fsl-laptop:~/SW/openVG_sample$ make /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc -mfloat-abi=softfp -mfpu=vfp -Wall -O3 -fsigned-char -D_LINUX -I/home/fsl/SW/openVG_sample/include -c warp.c -o warp.o In file included from warp.c:37: roselend_savoie_france_350x350.c:12391:66: warning: trigraph ??) ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:12964:71: warning: trigraph ??/ ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:14518:10: warning: trigraph ??- ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:15118:67: warning: trigraph ??) ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:15327:67: warning: trigraph ??' ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:15795:62: warning: trigraph ??! ignored, use -trigraphs to enable /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc -I/home/fsl/SW/openVG_sample/include -lOpenVG -legl13 -Wl,--library-path=/home/fsl/LTIB_1_7/ltib/rootfs/usr/lib,-rpath-link=/home/fsl/LTIB_1_7/ltib/rootfs/usr/lib -o warp warp.o fsl@fsl-laptop:~/SW/openVG_sample$ Copy the application on your SD card Put the SD card in the i.MX51 and run the gpu drivers $ login:root $ modprobe gpu Run the application $ ./warp Modifying the image A simple way to modify the image, is to use The Gimp. When you want to save your image, choose "C source code format": Then choose the prefix name (here "roselend"): Click on "Save". The "C" file of your image is generated: /* GIMP RGBA C-Source image dump (roselend_savoie_france.c) */ static const struct {   guint        width;   guint        height;   guint        bytes_per_pixel; /* 3:RGB, 4:RGBA */   guint8       pixel_data[350 * 350 * 4 + 1]; } roselend = {   350, 350, 4,   "\265\303\357\376\264\304\357\376\262\304\357\376\260\304\356\376\260\303"   "\356\376\257\303\356\376\257\302\355\376\257\301\355\376\257\302\355\376"   "\257\302\355\377\256\302\356\376\256\302\357\376\256\302\356\377\255\302" "\357\376\254\302\360\376\253\302\357\376\254\302\355\376\255\302\357\376" ...

The Linux L4.9.88_2.0.0 Rocko, i.MX7ULP Linux/SDK2.4 RFP(GA) release files are now available. Linux on IMX_SW web page, Overview -> BSP Updates and Releases ->Linux L4.9.88_2.0.0 SDK on https://mcuxpresso.nxp.com/ web page.   Files available: Linux:  # Name Description 1 imx-yocto-L4.9.88_2.0.0.tar.gz L4.9.88_2.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide. 2 L4.9.88_2.0.0_images_MX6QPDLSOLOX.tar.gz i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo, i.MX 6Solox Linux Binary Demo Files 3 L4.9.88_2.0.0_images_MX6SLEVK.tar.gz i.MX 6Sololite EVK Linux Binary Demo Files 4 L4.9.88_2.0.0_images_MX6UL7D.tar.gz i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 5 L4.9.88_2.0.0_images_MX6SLLEVK.tar.gz i.MX 6SLL EVK Linux Binary Demo Files 6 L4.9.88_2.0.0_images_MX8MQ.tar.gz i.MX 8MQuad EVK Linux Binary Demo files 7 L4.9.88_images_MX7ULPEVK.tar.gz i.MX 7ULP EVK Linux Binary Demo Files  8 L4.9.88_2.0.0-ga_mfg-tools.tar.gz Manufacturing Toolkit for Linux L4.9.88_2.0.0 iMX6,7 BSP 9 L4.9.88_2.0.0_mfg-tool_MX8MQ.tar.gz Manufacturing Toolkit for Linux L4.9.88_2.0.0 i.MX8MQ BSP 10 imx-aacpcodec-4.3.5.tar.gz Linux AAC Plus Codec for L4.9.88_2.0.0   SDK:   On https://mcuxpresso.nxp.com/, click the Select Development Board to customize the SDK based on your configuration then download the SDK package.    Target board: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6QuadPlus SABRE-AI Board 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 6SoloLite EVK Board i.MX 6SoloX SABRE-SD Board i.MX 6SoloX SABRE-AI Board i.MX 7Dual SABRE-SD Board i.MX 6UltraLite EVK Board i.MX 6ULL EVK Board i.MX 6SLL EVK Board i.MX 7ULP EVK Board i.MX 8MQ EVK Board   What’s New/Features: Please consult the Release Notes.   Known issues For known issues and more details please consult the Release Notes.   More information on changes of Yocto, see: README: https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-linux-rocko ChangeLog: https://source.codeaurora.org/external/imx/imx-manifest/tree/ChangeLog?h=imx-linux-rocko

Overview In latest i.MX6UL/i.MX6ULL EVK boards, Ethernet PHY chip is upgraded with new revsion ID (01) although the same part number KSZ8081RNBIA is used. The detailed change is as follows: Mark on old Ethernet PHY chip (Silicon Revision ID is 0, Mark is A2):             KSZ8081             RNBIA             1439A2T             M147J18M02 Mark on new Ethernet PHY chip (Silicon Revision ID is 1, Mark is A3)               KSZ8081               RNBIA               1602SA3T                M159S28M23                                   Software Patch Linux BSP requires to be updated to support this new Ethernet PHY because PHY setting is designed to be associated with silicon ID. See attached patch for the details (Please note: i.MX6ULL/i.MX6UL EVK shared the same board file.) The formal patch is also included into the releases starting from L4.1.15_2.0.1. See http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-bsp/recipes-kernel/linux/files?id=imx_4.1.15_2.0.1 If ethernet doesn't function on your i.MX6UL/i.MX6ULL EVK board in kernel, please check whether Silicon Revion Mark is A3 on the board and then apply for attached file for the test.

Following docs(English or Chinese version) are also can be referred as a hand on guide. Freescale i.MX6 DRAM Port Application Guide-DDR3 飞思卡尔i.MX6平台DRAM接口高阶应用指导-DDR3篇 Please find i.Mx6DQSDL LPDDR2 Script Aid through below link. i.Mx6DQSDL LPDDR2 Script Aid Please find i.Mx6DQSDL DDR3 Script Aid through below link. i.Mx6DQSDL DDR3 Script Aid Please find i.MX6SX DDR3 Script Aid through below link.. i.MX6SX DDR3 Script Aid Any questions are welcome! Change History: 0.02 - Add total 1Gbit density supporting.

For most of interlace output camera sensors, they only support up to 30fps sample rate. In this case, we may not get good display quality. In order to improve the permance under this case, we can use IPU VDI function to increase the output frequency to be 60fps and then we can get a better quality. The patch is an example to support YUV422(YUYV) 60fps VDI for Android camera preview. SW Platform: kk4.4.2_1.0.0-ga HW Platform: imx6q-sabresd Features: Support YUV422(YUYV) input format; Support IPU 60fps VDI; Supprot 60fps camera preview, but don't support camera capture. Patch: The linux kernel patch to support additonal IPU function can be found at: https://community.freescale.com/docs/DOC-173003 The Android Camera HAL can be found at here. Note: 1. The g_vdi_double is used to decide whether to support these features. When g_vdi_double is set to be 1, these features will be enabled; Or these features will be disabled and camera feature will be the same with default release. 2. The patch should be used at hardware\imx\mx6\libcamera2. 3. Accoeding to the real user case, the user can set IPU VDI motion mode to be 0 or 1 , but NEVER to be 2. 4. The fps can be up to 60fps, but it is not stable now.

Some customers often use LVDS LCD with low resolution on i.MX6 platform, such as 320x240, but by defualt , linux bsp doesn't support low frequency pixel clock for LVDS module input. Question:     When we port LVDS LCD with 320x240 resolution to android4.2.2, we found pixel clock is not correct, it always output 38.9MHz, it is no probem for big resolution , for example 1024x768, but the clock we need for 320x240 LCD is 6.4MHz.     According to the quesiton, Let us check IPU & LDB clock in i.MX6 datasheet at first : From above table, if ldb clock is from IPU, we will not get 6.4MHz pixel clock, so we will have to adjust its source clock: The following steps are procedure that ports LVDS LCD with 320x240 resolution to i.MX6Q. 1. Adding LVDS LCD timing structure to ldb.c static struct fb_videomode ldb_modedb[] = { {       "LDB-XGA", 60, 320, 240, 155914,       38, 20,       15, 4,       30, 3,       0,       FB_VMODE_NONINTERLACED,       FB_MODE_IS_DETAILED, }, {      "LDB-1080P60", 60, 1920, 1080, 7692,      100, 40,      30, 3,      10, 2,      0,      FB_VMODE_NONINTERLACED,      FB_MODE_IS_DETAILED,}, }; 2.Modifying clock source of ldb module Checking /arch/arm/mach-mx6/clock.c, we can find there are 3 ldb's clock source : &pll5_video_main_clk, &pll2_pfd_352M, &pll2_pfd_400M, static int _clk_ldb_di1_set_parent(struct clk *clk, struct clk *parent) {        u32 reg, mux;        int rev = mx6q_revision();        reg = __raw_readl(MXC_CCM_CS2CDR)               & ~MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_MASK;        mux = _get_mux6(parent, &pll5_video_main_clk,               &pll2_pfd_352M, &pll2_pfd_400M,               (rev == IMX_CHIP_REVISION_1_0) ?                &pll3_pfd_540M :       /* MX6Q TO1.0 */                &mmdc_ch1_axi_clk[0],     /* MX6Q TO1.1 and MX6DL */               &pll3_usb_otg_main_clk, NULL);        reg |= (mux << MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_OFFSET);        __raw_writel(reg, MXC_CCM_CS2CDR);        return 0; } By default, pll2_pfd_352M is configured as the clock source of ldb: clk_set_parent(&ldb_di0_clk, &pll2_pfd_352M);        clk_set_parent(&ldb_di1_clk, &pll2_pfd_352M); We should change the clock source to be pll5_video_main_clk clk_set_parent(&ldb_di0_clk, &pll5_video_main_clk,);        clk_set_parent(&ldb_di1_clk, &pll5_video_main_clk,); 3. Configuring initial clock in board-mx6q_sabresd.c static struct ipuv3_fb_platform_data sabresd_fb_data[] = {        { /*fb0*/        .disp_dev = "ldb",        .interface_pix_fmt = IPU_PIX_FMT_RGB666,        .mode_str = "LDB-XGA",        .default_bpp = 16,        .int_clk = false,        .late_init = false, } int_clk=false means LDB clock is from PLL2_PFD_352 or pll5_video_main_clk; int_clk=true mean LDB clock if from IPU. OK, after doing above steps, LVDS LCD with low resolution should normally work. Freescale TICS team Weidong.sun 2015-08-18

In an earlier topic (Linux fast boot on i.MX6 Sabresd board.) about Linux fast boot on i.MX6 SabreSD board, the demo showed an application startup procedure including u-boot boot, Linux kernel boot, rootfs mount, demo application load and run. Additionally, this demo shows a live video on a LVDS screen from board CSI camera. Its total boot up time is about 1.x seconds. Now, based on Linux fast boot, we integrate it with another demo application: surround view, this demo shows 4 different live videos on LVDS screen from 4 UDP data sockets. In this demo video is drawn by GPU to screen, that means the frame buffers decode by video decoder directly pass to GPU, which is not same as previous demo. The encode video format is also MJPEG in this demo. This demo creates 4 different threads every thread handle one UDP socket, receive buffer, push this buffer to video decoder, get frame buffer from video decoder, pass this buffer to GPU, start GPU render, command GPU draw the render buffer to the screen; this thread needs to occupy one ARM processor to show every video smoothly. So we need a i.MX 6DQ board in this demo. Hardware: i.MX 6DQ SabreSD board Software: 12.09 GA BSP Difference with previous fast boot demo: U-boot difference with previous fast boot demo. 1: Add logo show. (For remove CSI2, V4L2, Capture modules ) Kernel different with previous fast boot demo. 1: Add SMP support. 2: Add Network support. (IPV4, PHY, network driver(FEC)) 3: Remove CSI2, V4L2, Capture. (Remove this need in U-boot procedure Freescale logo show on the screen! ) 4: Add GPU support in kernel. Rootfs difference with previous fast boot demo: 1: Keep rc.s firstly run, while in previous fast boot demo, demo is the firstly running program on rootfs. 2: Get rid of almost all service in rc.conf just keep “mount /proc and /sys” service. Network performance on this demo Software : The default network receive buffer is about 128KB. This default size is too small for this demo; the demo application can't fetch receive buffer in time while kernel network stack will discard some UDP packets if we don't enlarge it. We enlarge this receive buffer through command in inittab before demo running. Hardware: i.MX6 DQ TOI less than 1.2 version has some Ethernet mac layer issue, this issue will also cause some UDP packets lost. So please ensure the SabreSD board i.MX6 DQ chip TOI version is equal 1.2 or more. Attached are some files for your reference. Below patches assume this SabreSD board boot from SD3 and default display port is LVDS1. 1: U-boot and kernel patches based on 12.09. 2: Demo application based on 12.09 vpu test program and vpu test program running configure file. 3: Rootfs startup scripts.

Before reading: only a personal works and sharing, not any form of "release". I didn't find any confidential information from the packages. So, I'm publishing it here. This is only for testing purpose. Do NOT use it for building a product. Use it at your own risk!! Yocto is flexible and powerful, and also, big and slow (when building). Sometimes we only need to build uboot or kernel or some piece of testing code. It's really a waste of time to build-up the whole Yocto environment which may cost over 50GB disk space and over 3 hours of building. I've made some scripts and sum them up to form a toolset for building uboot, kernel and some testing code out of Yocto environment. It's only a simple container and expect to use with uboot and kernel source code from formal Freescale release and a SDK built from Yocto project. GitHub source repo:       https://github.com/gopise/gopbuild What’s made off (a full package, not only the container): 1.    Some scripts and configurations files. 2.    SDK built from Yocto. 3.    Uboot/kernel from specific version. 4.    A hello-world to demonstrate how to build app in this environment. 5.    A slimmed rootfs binary from specific BSP pre-built as base. Will customize base on the source under “rootfs” folder. Only a placeholder in the container-only version. How to use it: Several common used board configurations have been included in the script: 6qsabresd/6qsabreai/6qpsabreai. You can add more into the “gopbuild” script easily. The “sabresd” has been set as default.      If you want to build all for sabresd (First of all, de-compress the package): cd <de-compressed-folder> source envsetup [It will prompt for selecting board configuration to be built. Choose one by input corresponding number or click <ENTER> for default board.] gmk ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍      If you want to build specific module for default board, such as uboot: gmk uboot ‍‍‍‍‍‍‍‍‍      Build kernel for sabreai board instead of default device: gmk kernel sabreai ‍‍‍‍‍‍‍‍‍      Clean everything? gmk all clean ‍‍‍‍‍‍‍‍‍ After a successfully full build, you will get everything under “output” folder, including a log folder contains full build log:      “u-boot.imx/zImage/rootfs.tar.bz2/*.dtb”, can be used with MFG or uuu.      “fsl-image.sdcard”, can be burn into SD card directly. "Ready-for-building" Package: The "gopbuild" itself is a "container-only" package which doesn't contain any source or SDK. I've also made some packages based on latest BSP release for i.MX6/i.MX7/i.MX8. These packages are "ready-for-build" package which you can de-compress and build it directly. -------------------------------------------------------------------------------------------------- URL：https://pan.baidu.com/s/1Xlh1OBGsTRXez_NQw-Rjxg Password: gdc9 -------------------------------------------------------------------------------------------------- Note: 1. To build for i.MX8 (8QM/8MQ/8QXP), you need L4.14.* or above. 2. To build for i.MX8, please download the SCFW from i.MX software page       i.MX Software and Development Tools | NXP      After download, decompress corresponding package for specific chip and put it under "/platform/scfw/". Take i.MX8QXP for example:             /platform/scfw/scfw_export_mx8qx/ All material (uboot/kernel/test code and SDK) are from official Yocto release. Thanks!

Getting started with Linux on the i.MX53QSB

Overview i.MX6Dual/Quad supports using internal LDO or bypass internal LDO. LDO bypass is helpful to save power consumption and reduce thermal under high loading use cases because the power consumption on internal LDO can be saved. The purpose of this document is to introduce how to enable LDO bypass based on i.MX6 R13.4.1 release on i.MX6Dual/Quad SabreSD board. Constraint LDO Bypass solution currently can only be applied to i.MX6Dual/Quad 1GHz. LDO bypass function will force disabled on i.MX6Dual/Quad 1.2GHz, but customer can estimate this function through limit the max ARM frequency to 1GHz by command line 'arm_freq=1000' on i.MX6Dual/Quad 1.2GHz . Hardware Voltage Settings The following table lists the voltage settings in each working CPU frequency and VPU frequency with LDO bypass solution: VPU Frequency ARM Frequency VDDARM_IN (V) VDDSOC_IN (V) 0 to 352MHz 996MHz 1.25 1.25 264-> 352MHz 702MHz 1.15 1.25 0 to 264MHz 792MHz 1.15 1.175 264->352MHz 396MHz 0.95 1.25 <264MHz 396MHz 0.95 1.175 VDDARM_IN and VDDSOC_IN voltage setting should be within the voltage range, considering the ripple: VDDARM_IN - ripple>VDDARM_INmin VDDARM_IN + ripple<VDDARM_Inmax For the Min/Max value, refer to the i.MX6Dual/Quad data sheet. The above list is based on SabreSD PFuse-100. Software Changes Please apply the patches into Android-13.4.1-LDO_BYPASS-pathes.tar.gz.gz based on R13.4.1. The change lists: uboot-imx: move LDO bypass code and one PFUZE1.0 workaround code to kernel. Remove CONFIG_MX6_INTER_LDO_BYPASS in u-boot. kernel: A set of patches are used to support LDO bypass enable/disable by command option. How to Enable/Disable LDO Bypass After applying for above patches, you can add command option into boot command line to enable or disable LDO: Command option “ldo_active=off”: Enable LDO bypass mode Command option “ldo_active=on”: Enable LDO active

FAE Title Date i.MX Device BSP Description Leo Demo uImage for iMX257 does not support EXT3 filesystem 2/May2013 257 L2.6.31_09.12.00_SDK_images_MX25 For some reason the demo uImage does not support EXT3 filesystems (ext2 is not good for SD cards). kernel has to be recompile with this feature. Xisco start-weston command doesn't work when running from SD card. Only from NFS 3/may/2013 6 RC3.0.35.4.0.0 When compiling rootfs with LTIB, there is a problem that /tmp is tmpfs but keeps the size as 512k, far from common program running requirement, and it's full when system boots up.   When executing start-weston script it needs to write to /tmp and it fails. Only happens with LTIB built BSP.   $ mount -t tmpfs /tmp /tmp        Should be run before executing start-weston Xisco Porting OpenGL ES2 cpp apps for i.MX6 7/may/2013 6 RC3.0.35.4.0.0 When porting OpenGL ES2 cpp apps that were written for i.MX53, you will find an error saying that the function :   fbGetDisplay()   needs more arguments.   All that is needed to fix this error is to change the function to:   fbGetDisplayByIndex(0)   And you will be able to compile your app. Leo Stand-alone MFG and Android MFG are not the same Wed May 15 12:15:17 CDT 2013 6 JB4.2.2_1.1.0 In case you want to flash Android, use the MFG inside the source code tarball and not the stand-alone (the one found directly on the SW & Tools tab). Seems that it takes some time for both to be sync (the same) Leo gst-ffmpeg plugins is broken Thu May 16 13:31:44 CDT 2013 6 RC3.0.35.4.0.0 Attached patch should be applied to gst-ffmpeg code Original Attachment has been moved to: 0001-gstffmpegdemux.c-Remove-deprecated-flow-macros.patch.zip

as we known, mx6sx doesn’t have IPU, if we need to resize, rotation or blending…., we can use pxp module, this part, we talk about rotation for example. We also can use GPU for rotation, but in imx6sx, the number after 6sx in the part number stands for the chip including gpu or not, the number 4 and 3 mean mx6sx has gpu, like MCIMX6X3EVN10AB. and 1,2 and 3 mean mx6sx doesn’t have gpu, like MCIMX6X2EVN10AB for gpu, we know we can use xrander to rotate ,in this part, we focus on pxp rotation the stesp: enable pxp in the kernel:               $ bitbake -c menuconfig linux-imx, then choose Device Drivers ---> DMA Engine support ---> [*] MXC PxP support [*] MXC PxP Client Device 2) download the built image from tmp/deploy/images/imx6sxsabresd 3) boot up the board, then you can find the pxp_v4l2_test.out in the unit test 4) use the command as below to test the rotation: ./pxp_v4l2_test.out -sx 480 -sy 272 -res 352:240 -a 100  -r 90 fb-352x240.yuv BLANK   Sx and sy is resolution for display, -res is resolution for image or video. -r is for rotaion, you can set 0,90,180 and 270 for it. I attach the fb-352x240.yuv for testing

This is sample code for CSC settings for /dev/fb1. It can calculating the CSC matrix and updates in real time from given parameters(Brightness,Contrast,Saturation,Hue, and gamma).

  IMX6 UL boot process is described in Chapter 8 (System Boot) of the Reference Manual. Also you may look at the following Community regarding i.MX6 boot ROM activity. How to build bootable SD image (for i.MX6 SL as example)  U-boot is used as Linux bootloader and U-boot image should be located in SD area, used by i.MX6 boot ROM. The simplest way to get bootable SD card is just to copy system image in so called .sdcard format. Such image is prepared in Yocto by default and can be transfered to SD card with Linux dd command or Windows win32diskimager utility. Guide to the .sdcard format  Win32 Disk Imager download | SourceForge.net   The full SD image (.sdcard) should contain all parts, needed for Linux boot (U-boot, kernel, dtb, file system), maybe except U-boot environment. Carry out the following command to copy the SD card image to the SD/MMC card. Change sdx below to match the one used by the SD card. $ sudo dd if=<image name>.sdcard of=/dev/sdx bs=1M && sync   Note, U-boot environment (described below) should be set (and saved) in U-boot after the first start.   In any case it makes sense to understand general structure and implementation details of bootable SD card. Instructions are provided in section 4.3 (Preparing an SD/MMC card to boot) of i.MX Linux® User's Guide in Linux doc package (L4.1.15_2) http://www.nxp.com/webapp/Download?colCode=L4.1.15_2.1.0_LINUX_DOCS&Parent_nodeId=1337699481071706174845&Parent_pageType…  Summary page : i.MX 6 / i.MX 7 Series Software and Development Tool|NXP    For a Linux image to be able to run, four separate pieces are needed: • Linux OS kernel image (zImage) • Device tree file (*.dtb) • U-Boot bootloader image • Root file system (*.ext3 or *.ext4)   The mentioned files may be found in demo images on NXP Web or generated with Yocto. After a build is complete, the created image resides in <build directory>/tmp/deploy/images The device tree file (.dtb) contains board and configuration-specific changes to the kernel. Change the device tree file to change the kernel for a different i.MX board or configuration.    By default, the kernel image and DTB are located on FAT partition without a fixed raw address on the SD card. Generally fix addresses / blocks of SD card may be applied for kernel and DTB location. The users have to change the U-Boot boot environment if the fixed raw address is required. In example below the following image layout on SD card is assumed : Start address (sectors) = 0x400 bytes (2) for U-boot (i.MX6 boot ROM reads first 4K bytes of SD card). Start address (sectors) = 0xa00000 bytes (20480) for FAT partition, size=500MB, intended for Kernel zImage and DTBs. Start address (sectors) = 0x25800000 bytes (1228800) for rootfs.    Preparing the card   An SD/MMC card reader, such as a USB card reader, is required. Any Linux distribution can be used. Further follow instructions in sections 4.3.1 (Preparing the card), 4.3.3 (Partitioning the SD/MMC card), 4.3.4 (Copying a bootloader image), 4.3.5 (Copying the kernel image and DTB file), 4.3.6 Copying the root file system (rootfs) of attached "i.MX_Graphics_User's_Guide.pdf". The next step - try to insert the SD card to slot in i.MX6UL board, select proper boot options for SD boot and power the system. U-boot prompt should appear. Finally it is needed to configure environment for further Linux boot from SD. U-Boot > setenv mmcdev 1 U-Boot > setenv mmcpart 1 U-Boot > setenv mmcroot '/dev/mmcblk1p2 rootwait rw' U-Boot > setenv loadaddr 0x80800000 U-Boot > setenv fdt_addr=0x83000000 U-Boot > setenv fdt_file imx6ul-9x9-evk.dtb U-Boot > setenv mmcpart 1 U-Boot > setenv loadfdt 'fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}' U-Boot > setenv loadkernel 'fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage' U-Boot > setenv bootcmd 'mmc dev ${mmcdev}; run loadkernel; run mmcargs; run loadfdt; bootz $ {loadaddr} - ${fdt_addr};' U-boot > saveenv fdt_file should be set for your case ( on example “imx6ul-9x9-evk.dtb”) Try reboot with new environment.

The i.MX6Q-SDP is used to stream OV5642 parallel camera video encoded as JPEG using the hardware CODEC engine to a Linux client which decodes and displays on the screen.

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

This is the procedure and patch to set up Ubuntu 12.04 64bit Linux Host PC and building i.MX6x L3.0.35_4.1.0.  It has been tested to build GNOME profile and with FSL Standard MM Codec for i.MX6Q SDB board. A) Basic Requirement: Set up the Linux Host PC using ubuntu-12.04.3-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC $ sudo apt-get update $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install ia32-libs libc6-dev-i386 lib32z1 $ sudo apt-get install uboot-mkimage $ sudo apt-get install scrollkeeper $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L3.0.35_4.1.0_130816_source.tar.gz $ ./L3.0.35_4.1.0_130816_source/install After that, you will find ~/ltib directory created D) Apply the patch to make L3.0.35_4.1.0 could be installed and compiled on Ubuntu 12.04 64bit OS $ cd ~/ltib $ git apply 0001_make_L3.0.35_4.1.0_compile_on_Ubuntu_12.04_64bit_OS.patch The patch modifies the following files: dist/lfs-5.1/base_libs/base_libs.spec dist/lfs-5.1/ncurses/ncurses.spec E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib Reference: L3.0.35_4.1.0_130816_docs/doc/mx6/Setting_Up_LTIB_host.pdf https://community.freescale.com/message/332385#332385 https://community.freescale.com/thread/271675 https://community.freescale.com/message/360556#360556 scrollkeeper is for the gnome-desktop compilation NOTE: When compiling gstreamer, this warning was pop up.  Just ignore it seems okay.

The attached patch applies to iMX6_Platform_SDK for i.MX6 Dual and Quad and brings 2 additional SDMA memory to memory scripts: fixed destination address, increasing source address fixed source address, increasing destination address. With this patch, the new scripts are also integrated in the SDMA Test menu of the Platform SDK. I created these scripts starting from the ROM script ap_to_ap. In order to dump the content of the SDMA ROM, I used mxc_printSDMAcontext function which is also included in the attached patch and can be invoked when needed.