BSP: L5.4.47-2.2.0-rc2 Board: imx8QM B0 HW:  LVDS2HDMI , MIPIDSI2HDMI. It is the porting of i.MX8QM dpu loopback to isi. to the 5.4.y, with the addition of the MIPI-DSI loopback and the HDMI loopback.  Overview of the DC capture configuration: For enabling the capture: only DC 0 Stream 0  and DC 1 Stream 1 can be captured The pixel link Master address should be set to 3 because the Receiver Address at ISI is 3 and can't be changed. To continue displaying the stream, the Receiver Address at LVDS and DSI or HDMI should be changed to 3. It is possible to change the RA by using GPIO of the modules.   Patches: Create V4L2 device enabling the capture of by the ISI of DC loop-backs. Enable ISI capture from DSI 0 / LVDS 1 in 1920x1080 (at the same time.) Enable ISI capture from HDMI in 2840x2160 (half with even pixel) in 1920x2160. While capturing with the ISI, the captured screen continue to be displayed. Remark: Ov5640 cameras are also enabled in the same dtb. So 4 stream in 1920x1080 can be captured at the same time. Installation and gstreamer command: See readme

The i.MX8QuadMax SMARC System On Module integrates Dual Cortex A72 + Quad Cortex A53 Cores, Dual GPU systems, 4K H.265 capable VPU dual failover-ready display controller based i.MX8 QuadMax SoC with on SOM Dual 10/100/1000 Mbps Ethernet PHY, USB 3.0 hub and IEEE 802.11a/b/g/n/ac Wi-Fi & Bluetooth 5.0 module.

Two IPUs are supported in i.MX6Q SoC, each IPU supports 1920x1080 resolution, and 4 kinds of interfaces on i.MX6Q PADs can be used to connect display devices: HDMI, Digital RGB24, LVDS1+LVDS2, MIPI DSI. In the documents, we will discuss how to expand VGA port with digital RGB and realize dual-display via HDMI & VGA, The solution has been validated on Android4.2.2 and Android4.4.2 BSP released by NXP. 1.  Expanding VGA port based on digital RGB24 interface with ADV7125 Schematic is in attachments. 2. Configurations of envionment variables in u-boot The following settings are for booting via NFS, users can adjust them to boot via Flash on board. setenv ipaddr 192.168.1.103 setenv serverip 192.168.1.102 setenv gateway 192.168.1.1 setenv ethaddr 00:04:9f:00:ea:d3 setenv bootargs_base 'setenv bootargs console=ttymxc0,115200' setenv bootargs_android 'setenv bootargs ${bootargs} init=/init androidboot.console=ttymxc0 androidboot.hardware=freescale' setenv bootargs_nfs 'setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gateway}:${netmask}::eth0 off root=/dev/nfs nfsroot=${serverip}:${nfsroot}' setenv bootargs_disp 'setenv bootargs ${bootargs} video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 video=mxcfb1:dev=lcd,1920x1080M@60,if=RGB24,bpp=32 video=mxcfb2:off fbmem=32M vmalloc=400M' setenv bootcmd_net 'run bootargs_base bootargs_android bootargs_nfs bootargs_disp;tftpboot ${loadaddr} uImage;bootm' 3. Configurations in BSP file (1)IOMUX of DISP0 port (in header file)     MX6Q_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK,     MX6Q_PAD_DI0_PIN15__IPU1_DI0_PIN15,        /* DE */     MX6Q_PAD_DI0_PIN2__IPU1_DI0_PIN2,        /* HSync */     MX6Q_PAD_DI0_PIN3__IPU1_DI0_PIN3,        /* VSync */     MX6Q_PAD_DISP0_DAT0__IPU1_DISP0_DAT_0,     MX6Q_PAD_DISP0_DAT1__IPU1_DISP0_DAT_1,     MX6Q_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2,     MX6Q_PAD_DISP0_DAT3__IPU1_DISP0_DAT_3,     MX6Q_PAD_DISP0_DAT4__IPU1_DISP0_DAT_4,     MX6Q_PAD_DISP0_DAT5__IPU1_DISP0_DAT_5,     MX6Q_PAD_DISP0_DAT6__IPU1_DISP0_DAT_6,     MX6Q_PAD_DISP0_DAT7__IPU1_DISP0_DAT_7,     MX6Q_PAD_DISP0_DAT8__IPU1_DISP0_DAT_8,     MX6Q_PAD_DISP0_DAT9__IPU1_DISP0_DAT_9,     MX6Q_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10,     MX6Q_PAD_DISP0_DAT11__IPU1_DISP0_DAT_11,     MX6Q_PAD_DISP0_DAT12__IPU1_DISP0_DAT_12,     MX6Q_PAD_DISP0_DAT13__IPU1_DISP0_DAT_13,     MX6Q_PAD_DISP0_DAT14__IPU1_DISP0_DAT_14,     MX6Q_PAD_DISP0_DAT15__IPU1_DISP0_DAT_15,     MX6Q_PAD_DISP0_DAT16__IPU1_DISP0_DAT_16,     MX6Q_PAD_DISP0_DAT17__IPU1_DISP0_DAT_17,     MX6Q_PAD_DISP0_DAT18__IPU1_DISP0_DAT_18,     MX6Q_PAD_DISP0_DAT19__IPU1_DISP0_DAT_19,     MX6Q_PAD_DISP0_DAT20__IPU1_DISP0_DAT_20,     MX6Q_PAD_DISP0_DAT21__IPU1_DISP0_DAT_21,     MX6Q_PAD_DISP0_DAT22__IPU1_DISP0_DAT_22,     MX6Q_PAD_DISP0_DAT23__IPU1_DISP0_DAT_23,     MX6Q_PAD_NANDF_D4__GPIO_2_4,        /* ADV7125 Power on / off (2) Frame buffer static struct ipuv3_fb_platform_data qcorein_fb_data[] = { /*    {     .disp_dev = "ldb",     .interface_pix_fmt = IPU_PIX_FMT_RGB666,     .mode_str = "LDB-WXGA",     .default_bpp = 16,     .int_clk = false,     .late_init = false,     }, */     {     .disp_dev = "hdmi",     .interface_pix_fmt = IPU_PIX_FMT_RGB24,     .mode_str = "1920x1080M@60",     .default_bpp = 32,     .int_clk = false,     .late_init = false,     },     {     .disp_dev = "lcd",     .interface_pix_fmt = IPU_PIX_FMT_RGB24,     .mode_str = "1920x1080",     .default_bpp = 32,     .int_clk = false,     }, }; (3) Settings about IPUs /* HDMI -- IPU1_DI0 */ static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {     .ipu_id = 1,     .disp_id = 1, }; /* RGB24 DISP0 LCD(Here is RGB24-->VGA via ADV7125 -- IPU0_DI0 */ static struct fsl_mxc_lcd_platform_data lcdif_data = {     .ipu_id = 0,     .disp_id = 0,     .default_ifmt = IPU_PIX_FMT_RGB24, }; (4) Adding LCD data in board_init() funtion static void __init mx6_qcorein_board_init(void) { .... imx6q_add_lcdif(&lcdif_data); ... } (5) Adding mxc_lcd.c driver to linux kernel When using make menuconfig to configure kernel, don't forget to add LCD driver to kernel.  Note: If users are using other version of android BSP, she can do porting according to above thinking. Weidong Sun NXP TIC team

GStreamer has a simple feature to enable tracing, allowing the developer to do basic debugging. These can be done in two ways: Adding the parameter --gst-debug=LIST to the pipeline (a pipeline is a executed gst-launch command) Prepending the environment variable GST_DEBUG=LIST' LIST is a a comma-separated argument, indicating the GStreamer elements to trace. For example, if one needs to trace the sink element      $ GST_DEBUG=*sink*:5 gst-launch playbin2 uri=file:///sample.avi or      $ gst-launch playbin2 uri=file:///sample.avi --gst-debug=*sink*:5 Both commands produces the same log. In case want to trace for than one element, so can simple add the <element>:5, for example      $ GST_DEBUG=mfw_v4lsink:5,vpudec:5 gst-launch playbin2 uri=file:///sample.avi The number 5 indicates the log category, where 5 is the highest (the most verbose log you can get) and 0 produces no output (5=LOG, 4=DEBUG, 3=INFO, 2=WARN, 1=ERROR). Log can be huge in each pipeline run. One way to filter it is using the grep command. Before grepping, one needs to redirect the standard error to the standard output (GStreamer log goes always to stderr), so      $ GST_DEBUG=mfw_v4lsink:5,vpudec:5 gst-launch playbin2 uri=file:///sample.avi 2>&1 | grep <filter string> In case the log needs to be shared, it is important to remove the 'color' of the log, again, one just needs to add the parameter --gst-debug-no-color or prepend the env variable GST_DEBUG_NO_COLOR=1 ----- More shell variables that GStreamer react, can be found here https://developer.gnome.org/gstreamer/0.10/gst-running.html

gst-inspect is a tool to to get documentation about GStreamer elements. Pipeline Check installed GST elements gst-inspect | tail -1 Check installed FSL GST elements gst-inspect | grep imx Element documentation gst-inspect <gst element>

This document describes the i.MX 8MQ EVK HDMI output and mini-SAS connectors features on Linux and Android use cases, covering the supported daughter-board, the process to change Device Tree (DTS) files or Boot Images, and enable these different display options on the board.

Qt framework Qt is a cross-platform complete development framework with tools designed to streamline the creation of stunning native applications and amazing user interfaces for desktop, embedded and mobile platforms. Qt's cross-platform full framework and tools enables developers to target various desktop, embedded, mobile and real-time operating systems with one code base. Qt brings freedom to the developer saving development time, adding efficiency and ultimately shortening time to market. Building Qt Compile Qt for i.MX28 Building QT5 for i.MX53 Building QT for i.MX6 Qt on iMX6 Installing tools Installing and Configuring QT Creator (Ubuntu) Qt5 with Qt3D over Wayland rootfs Demos Qt5 Cinematic Experience Demo on i.MX6 Video - IMx 53 Qt5 qt3d demo Qt5 with Qt3D over Wayland rootfs Information Qt5 on i.MX6  DO's and DONT's Best Practices for QML

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

By default Linux BSP will work with LVDS screen on i.MX 6SoloX SABRE board. To enable MCIMX28LCD on the board, following need to be modified in u-boot: setenv panel 'MCIMX28LCD' setenv fdt_file 'imx6sx-sdb-lcdif1.dtb' #add video=mxc_lcdif:SEIKO-WVGA,bpp=16 to kernel command line you’re using #For example, when booting from MMC it will be: #  setenv mmcargs 'setenv bootargs console=${console},${baudrate} root=${mmcroot} video=mxc_lcdif:SEIKO-WVGA,bpp=16' saveenv

Use the EPDC Unit Test to exercise your EPD panel 1.  Introduction The i.MX 6Solo/6DualLite and i.MX 6SoloLite processors contain an Electrophoretic Display Controller (EPDC) designed to drive E-INK(TM) EPD panels supporting a wide variety of TFT backplanes. Detailed information about the EPDC is available in the i.MX 6Solo/6DualLite and i.MX 6SoloLite Reference Manuals. Information about programming the EPDC and integrating support for a particular panel into the Linux BSP is provided in the Linux BSP Reference Manual. Now that you have your panel hardware and software integrated, how can you tell if it is all working? Or perhaps you're using a standard panel that doesn't seem to be working - how can you test it at the lowest level? The answer is the EDPC Unit Test. 2. Running the EPDC Unit Test Most i.MX processor hardware modules have an associated unit test in the unit_tests directory of the root file system image. The basics of running the EPDC unit test are simple. After logging in as root on the debug console, change to the unit tests directory and execute the test as follows: $ cd /unit_tests $ ./mxc_epdc_fb_test.out Without any arguments, the unit test runs thirteen individual tests and takes about 8 minutes to complete. You will get a lot of output on the panel and it may not be obvious that the images are displaying correctly. Running the unit test with no arguments is a nice automated way to make sure your panel is at least displaying something, and is not causing a crash or hang. But to really verify correctness each test should be run individually and the output carefully reviewed. This can be accomplished by passing a test number option as follows: $ ./mxc_epdc_fb_test.out -n 1 To show a list of all the available options, as well as a list of the individual test numbers, use the "-h" argument. The helpful output is shown below. $ ./mxc_epdc_fb_test.out -h EPDC framebuffer driver test program. Usage: mxc_epdc_fb_test [-h] [-a] [-p delay] [-u s/q/m] [-n ]         -h        Print this message         -a        Enabled animation waveforms for fast updates (tests 8-9)         -p        Provide a power down delay (in ms) for the EPDC driver                   0 - Immediate (default)                   -1 - Never                    ms - After ms milliseconds         -u        Select an update scheme                   s - Snapshot update scheme                   q - Queue update scheme                   m - Queue and merge update scheme (default)         -n        Execute the tests specified in expression                   Expression is a set of comma-separated numeric ranges                   If not specified, tests 1-13 are run Example: ./mxc_epdc_fb_test.out -n 1-3,5,7 EPDC tests: 1 - Basic Updates 2 - Rotation Updates 3 - Grayscale Framebuffer Updates 4 - Auto-waveform Selection Updates 5 - Panning Updates 6 - Overlay Updates 7 - Auto-Updates 8 - Animation Mode Updates 9 - Fast Updates 10 - Partial to Full Update Transitions 11 - Test Pixel Shifting Effect 12 - Colormap Updates 13 - Collision Test Mode 14 - Stress Test In addition to "-n" to run individual tests, the "-a" and "-u" options are provided to set animation mode and waveform used, respectively. These options make sense only for some of the individual tests, as noted in the next section. The "-u s" (snapshot) mode purposely does not allow pending updates, so some of the tests will cause the driver to issue the following warning in snapshot mode: imx_epdc_fb: No free intermediate buffers available. The "-p" (power down delay) option allows you to specify how soon the device driver automatically powers down the controller after all pending updates have completed. The default is 0 (zero), meaning power down immediately. Use "-1" to disable power down (i.e. never power down). Sidebar: You can use another unit test, "dump-clocks.sh", to view the state of the EPDC clocks (i.e. the power state of the module). In the example below, a "1" in the third column indicates that the clock is running; a "0" indicates the clock is gated: $ ./dump-clocks.sh | grep epdc epdc_pix_clk             pll5_video_main_clk       1   26666667 epdc_axi_clk             pll2_pfd2_400M             1  198000000 3.  Individual Test Details Important! The notes below assume you are running the version of the unit test binary in the tar file attached to this How-to. Please extract the file mxc_epdc_fb_tests.out from the tar file into your rootfs unit_tests directory before running the test. Most tests begin with a screen blank operation (all white pixels). Each test works with all three update schemes (snapshot, queue, queue and merge) unless otherwise noted. 3.1 Test 1: Basic Updates Draws the following patterns: Crosshatch Squares Text Ginger image Colorbar 3.2 Test 2: Rotation Updates Draws text, squares, crosshatch, and square outlines in all rotation modes: No rotation Clockwise (90 degrees) Upside down (180 degrees) Counterclockwise (270 degrees) The square outlines are drawn first in RGB format and then in Y8 format. 3.3 Test 3: Grayscale Framebuffer Updates Draws a top half black screen and then a colorbar, rotated clockwise. First draws in normal Y8 format and then in inverted Y8 format. 3.4 Test 4: Auto-waveform Selection Updates Draws several small squares using auto-waveform selection. Note: unlike the i.MX508 EPDC driver, the i.MX 6 driver does not report the final waveform selection to user-level applications. This test also verifies that squares at non-8-bit aligned pixels can be drawn. 3.5 Test 5: Panning Updates Draws a colorbar to an off-screen region. Draws the Ginger image to the frame buffer. Sets the focus (pan) to the colorbar, then updates portions of the screen. You should see the colorbar poke through. Slowly pans from Ginger to the entire colorbar. Use pan to flip between black and white buttons. Flashes buttons using pixel inversion. Flashes buttons using panning. 3.6 Test 6: Overlay Updates Switches between the frame buffer (FB) and the alternate (overlay) frame buffer as follows: Draws Ginger to the FB. Draws the colorbar to the alternate frame buffer. Shows the FB (Ginger). Shows the alternate FB (colorbar). Shows FB again (Ginger). Shows half FB, half alternate FB. Shows cutout region of alternate FB. Shows cutout in upper corner. Shows black screen. Shows clockwise-rotated text overlay in center. 3.7 Test 7: Auto-Updates Important! The auto-update mechanism must be enabled in the kernel configuration for this test to work. Enable it using the LTIB Kernel configuration menu item "Device Drivers->Graphics support->E-Ink Auto-update Mode Support." Also, please check the Linux BSP Release Notes for any issues with this feature. 3.8 Test 8: Animation Mode Updates Shows how normal (gray level) and monochrome (black and white) updates compare in appearance and performance. Quickly flashes back and forth between black and white screens. Draws normal squares. Draws black and white squares. Draws Ginger in gray scale and monochrome. Draws colorbar in gray scale and monochrome. Draws normal Y8 colorbar and monochrome colorbar. Draws inverted normal Y8 colorbar and inverted monochrome colorbar. You can run this test in animation mode using the "-a" command line option. Animation mode only updates monochrome pixels, so you will notice a drawing speed improvement. Also, you will see the implementation of one of the "rules" of using this mode: The screen must be blanked (all white or all black) when switching in and out of animation mode. 3.9 Test 9: Fast Updates Animates a square across the screen and down one side. This test can also be run in animation mode using "-a". See the animation mode notes in the Test 8 description above. 3.10 Test 10: Partial to Full Update Transitions Draws small gray squares using separate updates in partial update mode (only pixels that change are updated). Then re-draws the entire screen in one update using full update mode. In full update mode, you will notice the entire screen transition from black to the final grey value. 3.11 Test 11: Test Pixel Shifting Effect Draws a short, two pixel line and then sends two updates one pixel apart in distance and 5 seconds apart in time. Nothing much to see here; just verifies that a one pixel update shift works. 3.12 Test 12: Colormap Updates Creates a colormap and uses it to draw full screen blanks and to draw a color bar. In this test, you should follow along with the text printed in the debug console and verify each state: Screen should be black. Screen should be white now. Screen should still be white. Should be inverted color bar (white to black, left to right). Colorbar again, with no CMAP (black to white, left to right). Posterized colorbar. In the above output, "CMAP" means colormap and "Posterized colorbar" is a colorbar drawn from only black and white components. 3.13 Test 13: Collision Test Mode Draws two overlapping rectangles. Tests for collision on the first rectangle, which should result in the message: Collision test result = 0 Then draws the same overlapping rectangles, this time testing for collision on the second rectangle. The result should be: Collision test result = 1 Note: This test cannot be run using the snapshot scheme. If you try to use "-u s" it will print a message and return. 3.14 Test 14: Stress Test Draws thousands of random rectangles on the screen in different rotations. Runs for about 8 minutes. This test must be explicitly specified on the command line; it does not run by default. For example: $ ./mxc_epdc_fb_test.out -n 14 Note: This test cannot be run using the snapshot scheme. If you try to use "-u s" it will print a message and return. 4. Customizing A great way to know what's really going on in each test is to look at the source code. You may want to customize the source as well - say to add a new test that exercises some cool feature of your panel. Fortunately, the source is included in the BSP distribution so you can extract, customize, and rebuild it as needed. The magic of LTIB is beyond the scope of this article, but here are some hints: # Extract the unit test source from the imx-test package: $ ./ltib -m prep -p imx-test # Source is now in rpm/BUILD/imx-test-12.08.00/test/mxc_fb_test/mxc_epdc_fb_test.c (your package version number my be different). # Build from source: $ ./ltib -m scbuild -p imx-test # Deploy all unit test binaries to ltib rootfs directory: $ ./ltib -m scdeploy -p imx-test # Alternatively you can copy just the epdc unit test binary as follows: $ sudo cp rpm/BUILD/imx-test-12.08.00/platform/IMX6S/mxc_epdc_fb_test.out rootfs/unit_tests/ As noted in the Individual Test Details section, you should replace the file mxc_epdc_fb_test.c referenced above with the one found in the tar file attached to this How-to. 5. Something is wrong! Of course there are many things that can go wrong that are beyond the scope of this article, but assuming your hardware is working and the panel options are correctly configured in the BSP (again, beyond our scope), here are some things to check: Is the kernel configured correctly for EPDC support? Check that the following item is enabled in the LTIB Kernel configuration menu: "Device Drivers->Graphics support->E-Ink Panel Framebuffer." Are the U-boot kernel command line arguments set correctly for EPDC? For example, "video=mxcepdcfb:E060SCM consoleblank=0". The "consoleblank=0" command is useful to prevent entering low power suspend mode while you are testing. Does the "Tux" image display correctly on your panel after system boot? If so, the EPDC driver was a least able to perform the initial framebuffer update to your panel. Note: for Tux to display at boot, you need to disable LCDIF support at "Device Drivers->Graphics support->Support MXC ELCDIF framebuffer." Are there any EPDC-related error messages in the kernel log after boot? You can check with "dmesg | grep epdc".

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

If someone wants to use the OpenGL ES 2.0 extension "GL_OES_vertex_array_object", the macro "GL_GLEXT_PROTOTYPES" must be defined in his program first. Then he can get the extension program location by calling the API eglGetProcAddress.  Here is an example to use this extension. #define GL_GLEXT_PROTOTYPES PFNGLGENVERTEXARRAYSOESPROC glGenVertexArraysOESv; PFNGLBINDVERTEXARRAYOESPROC glBindVertexArrayOESv; PFNGLDELETEVERTEXARRAYSOESPROC glDeleteVertexArraysOESv; glGenVertexArraysOESv = (PFNGLGENVERTEXARRAYSOESPROC)eglGetProcAddress ( "glGenVertexArraysOES" ); glBindVertexArrayOESv = (PFNGLBINDVERTEXARRAYOESPROC)eglGetProcAddress ( "glBindVertexArrayOES" ); glDeleteVertexArraysOESv = (PFNGLDELETEVERTEXARRAYSOESPROC)eglGetProcAddress ( "glDeleteVertexArraysOES" ); After these steps, the new alias glGenVertexArraysOESv, glBindVertexArrayOESv, glDeleteVertexArraysOESv can be use to call the VAO operation function in OpenGL ES 2.0 extensions.

MIPI can support video streaming over 1, 2, 3 and 4 lanes. On i.MX6 Sabre boards, the OV5640 camera supports 1 or 2 lanes and the NXP Linux Kernel uses 2 lanes as default. In order to use only one lane, follow the steps below: 1 - Change the board Device Tree on Linux Kernel. On file <linux kernel folder>/arch/arm/boot/dts/imx6qdl-sabresd.dtsi, find the entry "&mipi_csi" and change lanes from 2 to 1. 2 - Configure OV5640 to use only one lane instead of two. On file <linux kernel folder>/drivers/media/platform/mxc/capture/ov5640_mipi.c, change the register 0x300e value from 0x45 to 0x05. This register setup is located at struct ov5640_init_setting_30fps_VGA. 3 - Build the kernel and device tree files. 4 - Test the camera. Unit test can be used to test the video capture: /unit_tests/mxc_v4l2_overlay.out -di /dev/video1 -ow 1024 -oh 768 -m 1 5 - Checking if it's really using one lane. MIPI_CSI_PHY_STATE resgister (address 0x021D_C014) provides the status of all data and clock lanes. During video streaming using 2 lanes, the register value constantly changes its value between 0x0000_0300 and 0x0000_0330. When using only one lane, this register value constantly changes its value between 0x0000_0300 and 0x0000_0310. To read the register value during the stream, run the video test with &: /unit_tests/mxc_v4l2_overlay.out -di /dev/video1 -ow 1024 -oh 768 -m 1 & Now, run the memtool: /unit_tests/memtool -32 0x021dc014 1 i.MX6DL running mxc_v4l2_overlay.out with only one lane:

When configuring i.MX6 IPU IDMAC CPMEM parameters or debugging it, it's hard to find the value of a parameter inside the 160 bits word. This web tool separates the 160 bits words into parameters making it easier to check their values. Link: i.MX Tools 

This is a How-To documentation for OpenCL on i.MX6 using LTIB, there are all necessary steps and sample code to create,  build and run a HelloWorld application.

This doc show how to use i.MX8QXP Display Controller GammaCor unit to tune gamma. HW: i.MX8QXP MEK board, HDMI monitor SW: i.MX Linux 4.14.98_2.2.0 BSP release, patch in this doc 1.Introduce gamma The gamma, gamma correction, gamma encoding, gamma compression , these words all related one kind operation , see wiki page of it: The device used for image capture/print/display follow this power-law. For example the camera captured image , to view this image on display device as good as original captured image : gamma encoding when camera saved sensor data to image file,  and  gamma decoding when that image file display on your PC LCD monitor. That is : 2. i.MX8QXP Display Controller Gamma Correction Unit The Gamma Correction unit position is located between Frame Gen unit and TCon unit.   More detail see below contents from i.MX8QXP RM: So GammaCor unit could be used as adjust display gamma , or brightness or contrast. To used it, need follow the steps at RM 15.9.2.4.4.8.3.   Something need to note: You need program 33 sample point value into the register, these sample point value range is from 0 to 1023. Note, first write is start sample point value , then the other is delta value: current sample point minus previous sample point value. You can use GammaCor unit on any channel of R/G/B. If you use normalized function f(x), the following formula should be used to clut[i = 0..32] = round( f(i * 32 / 1023) * 1023) 3. i.MX8QXP Linux device driver patch and test code Apply attached  patch 8qxp_dpu_gammacor_4.14.98_2.2.0.diff on Linux kernel. In the kernel patch, function dpu_gammacor_update, I choose not calculate delta value between each sample pint , let user space application calculate delta value and passed to kernel. Apply 8qxp-dpu-gammacor-modetst.diff on libdrm-imx, to get test application which is based on modetest.  Test app will read one greyscale image file 720P.rgb, put it under same folder of test application , calculate sample point value by pow function  , and calling drmModeCrtcSetGamma to pass related value to kernel,  next loop will change sample point value, and will see that greyscale image will changed on HDMI monitor. After system boot up, run below cmd to check result of test application systemctl stop weston ./gamma_show_rgba.out -P 29@32:1280x720@AB24 Reference: a>https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM b>https://www.nxp.com/webapp/Download?colCode=L4.14.98_2.2.0_MX8QXP&appType=license c> https://source.codeaurora.org/external/imx/libdrm-imx/ d> https://en.wikipedia.org/wiki/Gamma_correction

SW: Linux 4.14.98_2.2.0 bsp release , gpu sdk 5.3.0 and patch in this doc HW: i.MX8QXP MEK board Inspired by the GIMP adjust color curve tool,  I write similar gui test code for i.MX8QXP gamma curve tuning. That is on display will show one linear curve first, use mouse to change any part of this curve, after that calculate value of point on changed curve , then pass related value to i.MX8QXP DPU gammcor unit , at last the display effect will be changed by DPU. When test code start up , will draw Y=X curve on display, that will from (0,0) to (500, 500) to (1023,1023). After you use mouse drag some part of the curve, will generated a new point (x_new, y_new) which is not on original Y=X curve. Then need draw a new curve that pass  through the (0,0) , (500, 500) , (x_new, y_new), (1023,1023).  That new curve , i choose to use Catmull-Rom Splines to get it. Use Catmull-Rom Splines for approximate a curve that pass through n point, then need n+2 control point. Extra 2 point could be selected as you want ,and they will affect the shape of the curve. Catmull-Rom Splines could pass through all control point, it is C1 continuity, no convex hull property. For example, there is four control point p0, p1 , p2 , p3,  to draw the curve pass through all of them, it could divide to segment p0 to p1 , segment p1 to p2 , segment p2 to p3. For segment p1 to p2 , select four control point as p0,p1, p2, p3, use Catmull-Rom Splines as below: For segment p0 to p1 , need use four control point as p0, p0, p1, p2: For segment p2 to p3, need use four control point as p1, p2, p3, p3: In this test code,  i will use gpu vertex shader to calculate each segment of curve, then use transform feedback to read back point value of each segment to cpu side, cpu side will pass related value to DPU gammcor unit for gamma tuning.   Test steps: Apply 8qxp_dpu_gammacor_4.14.98_2.2.0.diff on linux-imx for i.MX8QXP DPU device driver. Apply dpu_gamma_curve_gpusdk5.3.0.diff on imx-gpu-sdk for build this gui test code. Update the new kernel image, and copy test code to rootfs. Run any other application first to draw some thing on screen, for example  /usr/share/cinematicexperience-1.0/Qt5_CinematicExperience. Then run gui test code in this code, S01_SimpleTriangle_Wayland. Then there will show one linear curve on display , use mouse to change the curve as you like by put mouse cursor close to the curve, press the mouse button , drag it and release the mouse button, you will see the new curve on display , and also the display effect also be changed. Reference: 1>https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8x-family-arm-cortex-a35-3d-graphics-4k-video-dsp-error-correcting-code-on-ddr:i.MX8X  2>https://www.nxp.com/design/software/embedded-software/linux-software-and-development-tools/embedded-linux-for-i-mx-applications-processors:IMXLINUX?tab=Design_Tools_Tab  3>https://github.com/NXPmicro/gtec-demo-framework  4>https://en.wikipedia.org/wiki/Cubic_Hermite_spline  5>http://www.mvps.org/directx/articles/catmull

The attached is the document and sample code for iMX5 system 80 interface LCD driver based on IPUV3. It is based on iMX51 2.6.31_09.12 BSP (SDK 1.7), tested on iMX53 3-Stack board. 1. Description This is Smartlcd driver for Freescale MX51 SDK1.7 release. (Kernel: 2.6.31_09.12.00/01)  2. File List -- Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch: SmartLCD panel support patch, and unit test code. -- Sample.config: the config file for reference. -- readme.txt: this file, please refer to it before use the package. -- SmartLCD Structure.pptx: the basic structure for smartlcd on IPUv3. 3. Requirement - MX51_3DS Green board(TO2.0) - No hardware rework needed, only need plug the giantplus GMA722A0 to J10. - MX51 SDK1.7 release package - L2.6.31_09.12.00_SDK_source.tar.gz                                - redboot_200952.zip 4. How to use 4.1 How to use demo -- Program default redboot.bin to board via ATKtools -- Copy attached zImage to tftp folder (assume /tftpboot) -- extract default rootfs to NFS folder (assume /nfsroot) -- COPY attached imx51_fb_test to ~/unit_test folder. -- Power on the board -- After redboot is boot up, use following command to boot up linux kernel    load -r -b 0x100000 zImage    exec -c "noinitrd console=ttymxc0 root=/dev/nfsroot rootfstype=nfsroot nfsroot=10.192.225.221:/nfsroot/rootfs rw ip=dhcp" -- Once the linux kernel launched, run following commands to test smartlcd panel.    cd /unit_tests    ./imx51_fb_test 4.2 How to use source code -- Current release code is based on L2.6.31_09.12.00_SDK_source.tar.gz. Extract the file to your working folder. -- Entering the working folder and type "./install", select a folder to install ltib. (such as .../ltib) -- Entering ltib folder and type "./ltib" to build Linux platform.  If you are not familiar with this setp, please refer to doc "i.MX_3Stack_SDK_UserGuide.pdf" for detail. -- Entering folder ".../ltib/rpm/BUILD/linux", copy "Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch" from release package to current folder    Run command "patch -p1 < Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch" -- When complete, run command "make ARCH=arm menuconfig", and you can refer to attached sample.config for detail.    * enable    Device Drivers ----> Graphics support ----> [*]   Asynchronous Panels                                            ----> [*] GiantPlus 240x320 Panel                                             * disable    Device Drivers ----> Graphics support ----> [ ]   Synchronous Panel Framebuffer                                         ----> Multimedia support    ----> [ ]   Video For Linux                                             -- Run command "make ARCH=arm" to build kernel.  4.3 How to do SMARTLCD driver test -- After Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch applied, there will be an folder "IMX51_TEST" under linux. -- Go to that folder, and run "make ARCH=arm", imx51_fb_test will be created. -- Copy imx51_fb_test to rootfs/unit_test. and run. 5. History N/A 6. Known Issue -- V4L2 not working yet.

This document describes the i.MX 8MM EVK mini-SAS connectors features on Linux and Android use cases, covering the supported daughter cards, the process to change Device Tree (DTS) files or Boot images, and enable these different display options on the board.

File related to the following question: MX53 u-boot Splash Screen support