SABRE-AI Development Platform bulletin on Touch Interrupt

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

Installing OpenOCD and GDB i.MX27 This tutorial was tested on i.MX27ADS REV. 2.6 and may not work on other board revision. Step 0: Installing the FTDI library The libFTDI is necessary when using JTAG based on FT2232 or others FTDI chips. LibFTDI need libusb, then install it first: $ sudo apt-get install libusb-dev Download libftdi from http://www.intra2net.com/en/developer/libftdi: $ wget http://www.intra2net.com/en/developer/libftdi/download/libftdi-0.18.tar.gz Now decompress and install it: $ tar zxvf libftdi-0.18.tar.gz $ ./configure $ make $ sudo make install Step 1: Compiling OpenOCD To compile OpenOCD you need to have GCC, Autoconf and automake installed. Get the OpenOCD source code (we are using rev. 1083): svn checkout http://svn.berlios.de/svnroot/repos/openocd/trunk openocd --revision 1399 Create the configure file and Makefile.in: $ ./bootstrap Run configure: $ ./configure --enable-ft2232_libftdi Compile: $ make Install it: $ sudo make install Step 2: Initializing OpenOCD Connect your JTAG interface on computer and i.MX27ADS board. Run OpenOCD passing as parameter the processor config and JTAG interface config: $ sudo openocd -f interface/myinterface.cfg -f board/imx27ads.cfg Replace myinterface.cfg by jtag interface you are using. In our case we are using Signalyzer Jtag Interface: $ sudo openocd -f interface/signalyzer.cfg -f board/imx27ads.cfg Note: We need to add "jtag_speed 5" on signalyzer.cfg in order to it works on i.MX27ADS. You will see this init message: # openocd -f interface/signalyzer.cfg -f board/imx27ads.cfg Open On-Chip Debugger 1.0 (2009-03-06-08:47) svn:1399 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ jtag_speed: 5 dcc downloads are enabled Info : JTAG tap: imx27.bs tap/device found: 0x1b900f0f (Manufacturer: 0x787, Part: 0xb900, Version: 0x1) Info : JTAG Tap/device matched Info : JTAG tap: imx27.cpu tap/device found: 0x07926121 (Manufacturer: 0x090, Part: 0x7926, Version: 0x0) Info : JTAG Tap/device matched Warn : no telnet port specified, using default port 4444 Warn : no gdb port specified, using default port 3333 Warn : no tcl port specified, using default port 6666 Step 3: Creating an ARM GDB tool If you already have an arm-elf-gdb then skip this step, otherwise go on. To create an arm GDB enter on LTIB -> Package List and select this: [*] gdb [ ]   gdb to run natively on the target [*]   cross gdb (runs on build machine) It will create the ARM GDB file at ~/ltib-dir/bin/gdb $ cd /home/alan/ltib-imx27ads-20071219/bin Copy this gdb binary to /usr/bin renaming it to arm-elf-gdb: $ sudo cp gdb /usr/bin/arm-elf-gdb Step 4: Debugging an application You can test the ledtest application to i.MX27ADS supplied by OpenOCD: Enter in ledtest directory: $ cd openocd/testing/examples/ledtest-imx27ads Run arm-elf-gdb passing as argument the gdbinit_imx27ads file: $ arm-elf-gdb --command=gdbinit-imx27ads You will see this gdb message: $ arm-elf-gdb --command=gdbinit_imx27ads GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB.  Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-linux". Setting up for the Freescale iMX27 ADS Board. The target endianness is set automatically (currently little endian) The target may not be able to correctly handle a memory-write-packet-size of 1024 bytes. Change the packet size? (y or n) [answered Y; input not from terminal] 0xc0000260 in ?? () JTAG device found: 0x1b900f0f (Manufacturer: 0x787, Part: 0xb900, Version: 0x1) JTAG device found: 0x07926121 (Manufacturer: 0x090, Part: 0x7926, Version: 0x0) target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x200000d3 pc: 0xc0000264 MMU: disabled, D-Cache: disabled, I-Cache: disabled Loading section .text, size 0x13c lma 0xa0000000 Start address 0xa0000000, load size 316 Transfer rate: 45963 bits/sec, 316 bytes/write. Warning: the current language does not match this frame. Breakpoint 1 at 0xa000008c: file test.c, line 12.  Breakpoint 1, main () at test.c:12 12                    volatile unsigned char *ledoff = ((volatile unsigned char *)0xD4000008); (arm-gdb) Now issue continue (or just c) command and you will see D30 LED blinking! (arm-gdb) c Continuing. You can repeat this test and issue next (or just n) to debugging line by line then you can see the LED turning on and off. Using step (or just s) is not a good option because it will spend much time on for loop.

The i.MX 6 D/Q L3.035_1.1.3 patch release is now available on the www.freescale.com ·         Files available # Name Description 1 L3.0.35_1.1.3_TEMP_PATCH This patch release is based on the i.MX 6Dual/6Quad Linux   L3.0.35_1.1.0 release. The purpose of this patch release is fix the   miscalibration issue for the thermal sensor.

[中文翻译版] 见附件   原文链接： i.MX Create Android SDCard Mirror 

OpenGL OpenGL is the premier environment for developing portable, interactive 2D and 3D graphics applications. Since its introduction in 1992, OpenGL has become the industry's most widely used and supported 2D and 3D graphics application programming interface (API), bringing thousands of applications to a wide variety of computer platforms. OpenGL fosters innovation and speeds application development by incorporating a broad set of rendering, texture mapping, special effects, and other powerful visualization functions. Developers can leverage the power of OpenGL across all popular desktop and workstation platforms, ensuring wide application deployment. Source: http://www.opengl.org/about/overview/ On i.MX processors, OpenGL takes the advantage of GPU (Graphics Processing Unit) block to improve 3D performance. Installing and running Demos Get more information on how to install and run demos using OpenGL on i.MX31 on this application note: AN3723 - Using OpenGL Applications on the i.MX31 ADS Board - http://www.freescale.com/files/dsp/doc/app_note/AN3723.pdf?fsrch=1 Develop a simple OpenGL ES 2.0 application under Linux This tutorial shows how to develop a simple OpenGL ES 2.0 application with LTIB and an i.MX51 EVK board. This tutorial can be adapted to i.MX53 that share the same 3D GPU core (Z430) and API (OpenGL ES 2.0).

USB Certification report of i.Mx6

There is no Freescale GStreamer element which does the JPEG decoding, so we must rely on a standard one, like 'jpegdec'. In case your Linux system was built using LTIB, in order to have the jpegdec element included on the gst-plugin-good, follow these steps: On the LTIB menuconfig, make sure the following packages are selected: gstreamer-plugins-good libjpeg libpng Remove the configure parameters '--disbale-libpng' and '--disable-jpeg' on the file './dist/lfs-5.1/gst-plugins-good/gst-plugins-good.spec' Rebuild and flash your board (or SD card) again. Image display VSALPHA=1 gst-launch filesrc location=sample.jpeg ! jpegdec ! imagefreeze ! mfw_isink Important: non 8 pixel aligned width and height is treated as not supported format in isink plugin.

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

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-345307 

The new i.MX OTP Tools release is now available on http://www.freescale.com/, under this link. Change details: Fixes an issue with the rom-plugin device firmware that is used by BitBurner and otp_burner tools to program fuses. These tools are part of IMX_OTP_TOOLS package.    The plugin was failing to check the status whether the data packets have been received or not.    As such, at times before receiving data from host the firmware was processing the usb buffer    with previously sent or received data resulting in incorrect values being programmed. To fix    this issue we modified the firmware to make sure we receive the data before processing the usb buffer.                 Here is the sequence of usb transfers (protocol):                 1.            Cmd-phase: Host send cmd to write to otp register with cmd type, register index and number of registers to write                 2.            Data-phase: Host send data for values to write to otp register.                 3.            Status-phase: Device sends status to host                 4.            Cmd-phase: Host send cmd to read otp register to verify data written was correct                 5.            Data-phase: Device send data from otp registers                 6.            Status-phase: Device sends status to host   The problem was at #2 wherein device would process usb buffer before confirming whether data has received or not.

ATK (Advanced Toolkit) ATK (Advanced Toolkit) is a Windows software for programming the flash memory of i.MX boards. Using ATK This section will describe the procedure to erase the flash memory and program the bootloader. 1 - Connect a serial cable between PC and i.MX board. 2 - Some hardware configurations (switches) must be done to flash the board.   Set SW2 switch as below: Switch SW2 -> 11111 3 - Run ATK going to Start -> Programs -> AdvancedToolKit -> AdvancedToolKit   Set the options:   Device memory -> DDR; Custom Initial File -> (keep it unmarked)   Communication Channel -> Serial Port (Usually COM1) 4 - Click on Flash Tools to erase, program or dump the the flash memory and click GO h4> Flash Programming The next step is to program the bootloader image into the board's Flash following the steps below. 1 - Select the parameters as shown in the figure below and press Program. The bootloader binary image file can be found into your Board Support Package Set Program, NOR Spansion 2 - Add it on Image File field and press Program. 3 - Close ATK, turn off the board and set switch back as shown in the picture below. Set SW2 switch as below: Switch SW2 -> 11010 Installing ATK on Linux Download ATK: Download. Extract ATK: # unzip ATK_1_41_STD_installer.zip Execute the default install process: # wine SETUP.EXE Get mfc42.dll and msvcp60.dll from a Windows Machine (C:\Windows\System32) and copy to wine system32 (/root/.wine/drive_c/windows/system32) Run ATK: # wine ADSToolkit_std.exe

i.MX25 for Industrial and General Embedded The i.MX25 family of multimedia applications processors extends the Freescale ARM9™ portfolio and makes the industrial and general embedded market a key focus of i.MX with the integration of many new features. Speed up to 400 MHz, low power consumption and multiple connectivity options support the growing needs of industrial and general embedded products, while allowing customers to reduce their overall system bill of materials cost. The i.MX258 processor provides additional security features making it the ideal solution for payment terminal (POS), or any other type of product needing secure system boot and tamper detection. i.MX25 for Automotive Today's drivers expect more connectivity in more places from more things—phones, media players and, increasingly, cars. Bluetooth™ connectivity is becoming the norm as more people keep their hands on the wheel instead of on the phone. Connectivity and compatibility with media players is becoming a requirement as consumers' media investment goes digital. The challenge: how can designers support high-end features such as connectivity and media playback without charging high-end prices? The i.MX25 family of processors offers integration that tailors itself to the connectivity requirements of today's automobile but eliminates expensive parts not needed for a cost-conscious infotainment system. The i.MX25 applications processor is a Freescale Energy-Efficient Solutions product. Product Information on Freescale.com i.MX257: Multimedia Applications Processor i.MX251: Multimedia Applications Processor i.MX253: Multimedia Applications Processor i.MX255: Multimedia Applications Processor i.MX258: Multimedia Applications Processor Additional Resources i.MX25 PDK Board I.MX25 PDK Board Get Started i.MX25 PDK Board Flashing NAND i.MX25 PDK Board Flashing SPI NOR i.MX25 PDK Board Flashing SD Card i.MX25 PDK Board Running Linux I.MX25 PDK U-boot SplashScreen I.MX25 PDK U-boot SDCard I.MX25 PDK Using FEC i.MX25: When using 120MHz UPLL as clock source, GPT counter returns unexpected results Limitations of the i.MX SIM Controller to Pass the EMV Certification

Question: What is minimum requirement for VDDSNVS_IN voltage to keep RTC timing info in SNVS block? In the datasheet, there is requirement for VDDSNVS_IN input and it is 2.9V to 3.3V. Is it recommended requirement for RTC operation? Other security function is not used in SNVS and just interested in basic RTC fuction after power off. Answer: The finall answer is tha to folow our datasheet saying for no matter if you are only RTC keeping application. "The SNVS regulator takes the SNVS_IN supply and generates the SNVS_CAP supply which powers the real time clock and SNVS blocks. If  VDDHIGH_IN is present, then the SNVS_IN supply is internally shorted to the VDDHIGH_IN supply to allow coin cell recharging if necessary. The output voltage is roughly one third(1/3) of SNVS_IN. -- in the SNVS_CAP powered on-chip logics, need min 0.9v for normal operation, we can only guarantee the operation in this condition, whih means min SNVS_IN = 3*SNVS_CAP = around 2.7. with some margin, so min 2.8v is the requireent. Again, we can only guarantee the operation in this condition(VDD_SNVS_CAP >0.9v). The datasheet is correct : VDDSNVS_IN must not be less than 2.8 V (Table 6. Operating Ranges, of IMX6DQCEC,  Rev. 2.2, 07/2013 )  I guess you talked about operating condition in ON mode. In case of OFF mode, VSNVS output of PFUZE depends on LICELL input power and usually coincell can supply under 2.5V output. According to PFUZE spec, VSNVS output in OFF mode is under 1.8V. And as I know, LP (low power) part of SNVS is only operation al in OFF mode so I don't think VDDSNVS_IN requires over 3V in that condition. In my assumption, SNVS can maintain itis data and RTC if VDDSNVS_IN is over 1.1 ~ 1.3V in OFF mode but I just want to know what is our spec for it. If we consider low power modes of the i.MX6, then - according to Table 10 (Stop Mode Current and Power Consumption) of IMX6DQCEC, Rev. 2.3, 07/2013 (for example) - in "SNVS Only" mode VDD_SNVS_IN of 2.8V is considered. Here 2.8 V is taken as minimal value. At least, as we can see, there are no other specifications.

ATK (Advanced Toolkit) ATK is a Windows tool for programming the flash memory of i.MX boards. It can be downloaded here. Using ATK This section will describe the procedure to erase the flash memory and program the bootloader. 1. Assemble the PDK using the CPU board, the Personality board, and the Debug board. 2. Connect a USB cable between the PC and the i.MX25 PDK Personality board. 3. Some hardware configurations (switches) must be set for booting from UART/USB:   On the debug board:   Switch SW5 -> Off   Switch SW6 -> Off   Switch SW7 -> Off   Switch SW8 -> Off   Switch SW9 -> On   Switch SW10 -> On   On the personality board:   Switch SW21 -> 11000000   Switch SW22 -> 00000000 {{Note|On SW5 thourgh SW10, "1" means the keys selected towards the edge of the board.} 4. Run ATK (1.6 or above) going to Start -> Programs -> AdvancedToolKit -> AdvancedToolKit   Set the options:   i.MX CPU -> i.MX25_TO1.1   Device memory -> DDR2;   Custom Initial File -> (keep it unmarked)   Communication Channel -> USB 5. Power up the i.MX25 PDK 6. Click on "Next" 7. Click on Flash Tools to erase, program or dump the the flash memory and click GO. NAND Flash Erasing 1. Configure the Dip Switch of Personality Board:                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      Switch 1 2 3 4 5 6 7 8 SW1 OFF OFF OFF OFF N/A N/A N/A N/A SW2 ON OFF OFF ON ON OFF OFF OFF 2. Choose NAND model K9LAG08U8M 3. Continue the steps Remember to select the checkbutton BBT (Back Block Table) Commands to flash kernel and rootfs fis init -f load -r -b 0x100000 zImage -h <host IP address> fis create -f 0x300000 kernel load -r -b 0x100000 rootfs.jffs2 -h <host IP address> fis create -f 0x800000 root fis load kernel exec -c "noinitrd console=ttymxc0 115200 root=/dev/mtdblock2 rw ip=dhcp rootfstype=jffs2" Command to create rootfs.jffs2 mkfs.jffs2 -r rootfs -e 0x80000 -s 0x1000 -n -o rootfs.jffs2

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-344462 

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

Qtopia Qt Extended, formerly known as Qtopia until September 30, 2008, is an application platform for Embedded Linux-based mobile computing devices such as personal digital assistants, mobile phones, and web pads. It is being developed by Qt Software, a subsidiary of Nokia. [Source: http://en.wikipedia.org] Qt Software discontinues Qt Extended March 3, 2009 — Oslo, Norway — Qt Software today announced that the product, Qt Extended, will be discontinued as a stand-alone product. Instead, selected features will be migrated into the Qt framework which will result in Qt becoming an even richer, cross-platform application framework. The final release of Qt Extended will be version 4.4.3, which will is planned for release on March 5, 2009. Qt Extended will be maintained for one year from that date. Qt Software will honor all existing support agreements, and for customers who need continued access to support beyond the term of their current agreement, Qt Software is offering the possibility of purchasing supplemental support. [Source: http://www.qtsoftware.com/about/news/qt-software-discontinues-qt-extended] Compiling Qtopia Crosscompiling Qtopia for i.MX processors requires some packages to be installed on host (PC). For more details click on your host PC Linux distribution below: All Boards Qtopia All Boards Qtopia on Ubuntu It's possible to compile Qtopia (version 2 or 4) by selecting Qtopia on package list or simply selecting Qtopia profile on Ltib configuration. Starting Qtopia Touchscreen setup When the system starts up, TSLIB_TSDEVICE environment variable must be set and ts_calibration application must be called to calibrate the touchscreen. $export TSLIB_TSDEVICE=/dev/input/event1 /dev/input/event1 is the usual touchscreen device. Some systems can address the touchscreen device to other names. It's possible to check what's the touchscreen device by typing: $cat /dev/input/<supposed device> After the command above, when touchscreen is pressed, some characters will be showed indicating that the <supposed device> device is the touchscreen device and it's working properly. $ts_calibrate Calibrate screen will appear. After touchscreen calibration, Qtopia can be executed by calling the following script: $/etc/rc.d/init.d/qtopia start Qtopia will be started.

This doc show: on i.MX6Q SabreSD board, configure ov5640 sensor(parallel or MIPI) output 5MP(2592x1944) RAW(Bayer) data at 15fps,and i.MX6Q IPU capture RAW RGB data, and i.MX6Q GPU debayer RAW data then display image. HW: i.MX6Q-SabreSD board, ov5640 sensor. SW: Linux 4.14.98_2.0.0 BSP, and patches in this doc. Configure at camera sensor side A Bayer filter is a color filter array (CFA) for arranging RGB color filters on a square grid of photosensors. The filter pattern is 50% green, 25% red and 25% blue, hence is also called BGGR, RGBG ,GRGB, or RGGB. The ov5640 has an image array capable of operating at up to 15 fps in 5 megapixel (2592x1944) resolution. OV5640 support output formats: RAW(Bayer), RGB565/555/444,CCIR656, YUV422/420, YCbCr422, and compression. To make ov5640 output 5MP RAW data at 15fps, check my patch imx6_ov5640_dvp_mipi_raw_capture_driver-4.14.98_2.0.0.diff which apply on i.MX Linux 4.14.98_2.0.0 BSP kernel code: Parallel interface ov5640, use ov5640_raw_setting[] array of drivers/media/platform/mxc/capture/ov5640.c. This register setting is come from ov5640 software application note and data sheet. MIPI interface ov5640, use ov5640_mipi_raw_setting[] array of drivers/media/platform/mxc/capture/ov5640_mipi.c. This register setting is combine setting of original code (remove ISP register setting), plus PLL register setting for MIPI interface, plus some data format register setting. Configure at i.MX6Q side The i.MX6Q IPU camera port(CSI-2 module) support data format include Raw(Bayer), RGB, YUV 4:4:4, YUV 4:2:2 and grayscale, up to 16 bits per value. Below is camera data routing for i.MX6Q:    Below is i.MX6Q IPU block daigram: The CSI-2 of IPU which is responsible for synchronizing and packing the video (or generic data) and sending it to other blocks. The video data received by CSI-2, could be sent to three other blocks: SMFC, VDI, IC. For RAW (Bayer) data capture, should go through path like this: CSI-2-->SMFC-->IDMAC-->DDR memory It means RAW data is received as generic data, see IPU_PIX_FMT_GENERIC in my patch, and IPU cannot process this kind data, it is just received to DDR memory. For MIPI interface camera, need note is i.MX6 side MIPI D-PHY clock must be calibrated to the actual clock range of the camera sensor’s D-PHY clock and the calibrated value must be equal to or greater than the camera sensor clock, detail see  AN5305. Take MIPI ov5640 as example: Pixel clock = 2592x1944x15fpsx(1/2 cycle/pixel)x1.35 blank interval = 51MHZ MIPI data rate = 51MHZ x 16 bit = 816Mb/s so 816/2/2*2 is 408MHZ is i.MX6 side D-PHY clock. Here due to one bayer pixel is 8bit, and i.MX6 MIPI data bus is 16 bit, so above use 1/2 cycle/pixel. And check ov5640_mipi_raw_setting[], you will got the sensor side D-PHY clock is about 672/2 = 336MHZ. And check AN5305, register MIPI_CSI2_PHY_TST_CTRL1 of i.MX6 need set as 0xC, but here i still keep it as default BSP value 0x14.   3.Capture test code I changed unit test mxc_v4l2_capture.c to capture the RAW data and save it to file. Check my patch imx6_ov5640_raw_captupre_test_4.14.98_2.0.0_ga.diff which apply on i.MX  Linux 4.14.98_2.0.0 BSP unit test code. Note the usage is: ./cap.out -c 1 -i 1 -fr 15 -m 6 -iw 2592 -ih 1944 -ow 2592 -oh 1944 -f BA81 -d /dev/video1 savefile.dmp parameter -i 1 means use CSI to MEM mode /dev/video1 is MIPI ov5640, /dev/video0 is parallel ov5640   4.Display RAW data The RAW data cannot be displayed directly, debayer process is needed to get complete red, green, blue color for each pixel. The debayer process if run on CPU, will cost much CPU time. To save CPU time, debayer could done by GPU. The method is, captured RAW data upload to GPU as texture , then GPU will do the debayer, then full color of each pixel will be got, then display it. To upload RAW camera data to GPU with zero memory copy, i will use i.MX6Q GPU extension GL_VIV_direct_texture. It create a texture with direct access support. API glTexDirectVIVMap,  which support mapping a user space memory or a physical address into the texture surface. The API glTexDirectVIVMap need logic and physical address of data buffer, so i will allocate data buffer from /dev/mxc_ipu, it is dma-buffer also get logic/physical address of buffer, then queue it as USERPTR to ipu v4l2 capture driver, after dequeue got RAW camera data, pass it to GPU for debayer. GPU side, I will use OpenGL shader code from "Efficient, High-Quality Bayer Demosaic Filtering on GPUs". Check my patch imx6-5640-debayer-testcode-gpusdk-5.2.0.diff which apply on i.MX GPU SDK 5.2.0 code. Note, here i only do is debayer, no extra process.   Known issue One thing is ov5640 output 5MP at 15fps, compare with output 5MP at 5fps, there are more noise of camera data at 15fps case. My debug found is , this noise seems come from ov5640 itself.   Reference: a>https://www.nxp.com/webapp/Download?colCode=IMX6DQRM b>https://www.nxp.com/webapp/Download?colCode=L4.14.98_2.0.0_MX6QDLSOLOX&appType=license c>https://github.com/NXPmicro/gtec-demo-framework d>https://www.nxp.com/docs/en/application-note/AN5305.pdf e>ov5640 data sheet f>ov5640 software application note g>Efficient, High-Quality Bayer Demosaic Filtering on GPUs https://www.semanticscholar.org/paper/Efficient%2C-High-Quality-Bayer-Demosaic-Filtering-on-McGuire/088a2f47b7ab99c78d41623bdfaf4acdb02358fb