The imx_bootlets package in LTIB contains the code that will be the first code loaded and executed by ROM when booting a build of the Linux BSP. It is responsible for initializing some of the low level peripherals such as the integrated power supply and the DRAM controller as well as a few other initialization tasks. The default configuration of the bootlet code for the latest i.MX233 and i.MX28x release (SDK 10.05 and SDK 10.12 respectively) support a hardware configuration that has both a LiIon battery configuration (as shown in the reference schematics for these platforms as shown on freescale.com). For other configurations though such as a VDD5V connection only or a DCDC_BATT/Battery connection only, some additional changes are recommended.

This page describes how to determine the NAND timing parameters for use in the NAND driver. This is independent of any OS that may be used. Analyzing NAND Datasheets  We use a spreadsheet to capture and analyze NAND features. That spreadsheet is [attached to this wiki page|Adding support for a new NAND with i.MX28– Nand Analysis^nand_analysis_template.xls]. We analyze a NAND as described below. We must have the NAND datasheet to do the analysis. Copy the *analysis spreadsheet* to a new filename with the exact part number(s) of the NAND(s) being analyzed. Fill in sheet 1 ("Cover Page") of the analysis spreadsheet. Work on sheet 3 next: Fundamental Features. Other tables. If the NAND is one of a family listed together in a data sheet, then analyze the whole family with one spreadsheet. You can use the "Similar to" rows for the additional members of the family. Add more rows if needed. Most NANDs have an asyncrhronous interface, so there is not a simple clock frequency involved. Instead, there are various setup times, hold times, and output delays that imply limits on the I/O rate to/from the NAND. The spreadsheet compares the NAND's timing specifications to see if sums of the setup, hold, and output times are shorter than the minimim read-cycle or write-cycle times. The spreadsheet is specifically intended for use with the Nand controller in STMP378x/i.MX233/i.mx28 chips, so the spreadsheet performs the timing calculations with the goal of deriving the timing parameters *TSU*, *TDS*, and *TDH* for those CPUs. If the TDS and/or TDH quantities {color:#ff0000}turn red{color} after all the timings have been computed, then the computed TDS and/or TDH are too short for the specified cycle-time of the NAND. In that case:           You will have to increase one or both of them in the software. Write a note somewhere in the analysis spreadsheet about the values that you choose, but don't mess up the automatic computations. Record how the flash denotes factory-marked bad-blocks. (Some use the first page of a block, some use the last page,, etc.) Compare it to this [current superset of bad-block marking methods [http://wiki.freescale.net/display/PSGSW/Storage+Media%2C+Flash+Bad+Block+Marks] used to detect any flash factory bad block. Example Analysis Examples of NAND datasheets and analyses can be found on the [Hynix NAND Page | http://wiki.freescale.net/display/PSGSW/Hynix+NAND+Flash+Documents].

i.MX27 and i.MX31 Issues When Interfacing Micron's 78nm mDDRs Micron is discontinuing some "-75" mDDR parts (133MHz) popular on i.MX27 and i.MX31 designs, newer "-6" are being used to replace the EOL devices. However, loss of data issues may be experienced when i.MX mDDR controller is used to interface with newer Micron's mDDR. On some cases, the bootloader works, memory tests on RedBoot pass. However, Linux hangs when booting. Here are the DDR Controller configuration changes that may be used to avoid the issue: (This configuration is not proven to work on every design, but has been validated on at least 3 different boards.) ESDRAMC Configuration Registers Set ESDCFG0/1 to 0x0079D72F 0xD800_1004 = 0x79D72F Drive Strength Control Registers Use "Normal". i.MX27 Default. Enhanced MDDR Delay Line Configuration Debug Register Set the ESDCDLYx to 0x002C0000 0xD800_1020 = 0x2C0000 0xD800_1024 = 0x2C0000 0xD800_1028 = 0x2C0000 0xD800_102C = 0x2C0000

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

ERR005723           PCIe: PCIe does not support L2 Power Down   Description: When PCIe works as Root Complex, it can exit L2 mode only through reset. Since PCIe doesn't have a dedicated reset control bit, it cannot exit L2 mode.   Projected Impact: PCIe does not support L2 Power Down   Workarounds: The PCIe can be put in PDDQ mode to save on PCIe PHY power and wakeup only by the OOB (Out of Band) wakeup signal (since wakeup by a beacon from link partner is not supported) driven from the link partner (End Point). This signal could be used as a GPIO interrupt to exit this mode. The limitation of this workaround is that the link partner cannot be put into L2.   Proposed Solution:                 No fix scheduled   Linux BSP Status:                 No software workaround available   SW workaround used to fix ERR005723 in Linux BSP Why the original workarounds can’t be implemented in Linux BSP * PCIe controller doesn’t have the reset mechanism that can be used when re-insmod the PCIe driver without power down/up PCIe module. * During the PCie driver rmmod/insmod operations, the PCIe CLKs would be turned off/on. IC can’t guarantee that the PCIe PHY can work well and re-establish the PCIe link properly. One SIMPLE SW workaround for this errata imx: pcie: toggle bit18 of grp1 fix pcie can't exit L2 issue.   Set bit18 of gpr1 before enter into supend, and clean it after resume, can fix the following errata. Errata ERR005723_PCIe PCIe does not support L2 Power Down. About the details, please refer to the attached patch. "0001-imx-pcie-toggle-bit18-of-grp1-fix-pcie-can-t-exit-L2.patch"   The conception of the other SW workaround (System warm-reset) The procedures of the original suspend/resume. Suspend User suspend command echo mem > /sys/power/state All driver call suspend function SRPG,  ARM save all state to memory Enter Stop mode and Power down ARM Resume: GPC receive IRQ Wake up system Power on ARM domain. ROM code running Jump to SRPG point Recovery ARM status from memory Call all devices resume function. Because PCIe only reset by system reset, we need change above follow. Resume: GPC receive IRQ Wake up system Power on ARM domain. ROM code running Jump to SRPG point Warm Reset system, memory context will be kept. But all peripheral status lost. ROM code running Jump to SRPG point again. Recovery ARM status from memory Call all devices resume function. Resume function call init to initialize it.  And recover to the status saved before. Impact: Can’t support usb remote wake up, which required 4ms responsive Longer latency, warm reset need some ms.  The recovery of the device status needs some more ms. Risk: Current BSP have not tested above follow Device driver have not supported this follow yet. Need additional work to enable \debug\test it. Modules enabled in this workaround now: * UART* ENET* PCIe Tests procedure. HW: one i.MX6Q SD boards, and one INTEL pciex1 1000M CT network card. SW(The images used by me are attached): * Apply the attached patches(kernel and uboot) to the kernel/uboot source codes, re-build, get the images. Kernel is based on imx_3.0.35_4.0 release, uboot , is based on imx_v2009.08 # build out SD/MMC and USB driver to make DRAM hibernate work # build pcie in. *procedure of the suspend/resume tests;     # unload ep's driver --> suspend/resume --> reload ep's driver. NOTE: Please make sure that the command line contains “no_console_suspend”The command used to enable the console input wake up after login the consol:echo enabled > /sys/devices/platform/imx-uart.0/tty/ttymxc0/power/wakeup Log when the INTEL CT 1G network card is used: -------------------------------log--------------------------------------------PM: Syncing filesystems ... done.                                             start suspendFreezing user space processes ... (elapsed 0.01 seconds) done.Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.add wake up source irq 101add wake up source irq 99add wake up source irq 103add wake up source irq 51add wake up source irq 58PM: suspend of devices complete after 15.482 msecsPM: late suspend of devices complete after 0.823 msecsDisabling non-boot CPUs ...CPU1: shutdownCPU2: shutdownCPU3: shutdownIMX PCIe imx_pcie_pltfm_suspend entering.IMX PCIe imx_pcie_pltfm_suspend exit.          suspendedU-Boot 2009.08-00679-g6ec6783 (May 20 2013 - 14:50:20)     resumeCPU: Freescale i.MX6 family TO1.2 at 792 MHzsrc 0x92eac8resume 0x92eac8jump to resumeIMX PCIe imx_pcie_pltfm_resume entering.IMX PCIe imx_pcie_pltfm_resume pcie start re-link.IMX PCIe port imx_pcie_pltfm_resume: re-link up.Enabling non-boot CPUs ...CPU1: Booted secondary processorCalibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU1 is upCPU2: Booted secondary processorCalibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU2 is upCPU3: Booted secondary processorCalibrating delay loop (skipped) already calibrated this CPU i.MXC CPU frequency driver CPU3 is up PM: early resume of devices complete after 0.974 msecs remove wake up source irq 58 imx-ipuv3 imx-ipuv3.0: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7) imx-ipuv3 imx-ipuv3.1: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7) remove wake up source irq 51 remove wake up source irq 103 remove wake up source irq 101 remove wake up source irq 99 PM: resume of devices complete after 54.174 msecs Restarting tasks ... done. PHY: 1:01 - Link is Up - 100/Full                            resume is ok, reload ep’s driver num is 61 e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2 e1000e: Copyright(c) 1999 - 2011 Intel Corporation. e1000e 0000:01:00.0: Disabling ASPM L0s e1000e 0000:01:00.0: (unregistered net_device): Failed to initialize MSI-X interrupts.  Falling back to MSI interrupts. e1000e 0000:01:00.0: (unregistered net_device): Failed to initialize MSI interrupts.  Falling back to legacy interrupts. e1000e 0000:01:00.0: eth1: (PCI Express:2.5GT/s:Width x1) 00:1b:21:3a:18:8b e1000e 0000:01:00.0: eth1: Intel(R) PRO/1000 Network Connection e1000e 0000:01:00.0: eth1: MAC: 3, PHY: 8, PBA No: E42641-005 e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: seq=0 ttl=64 time=3.126 ms 64 bytes from 192.168.0.1: seq=1 ttl=64 time=0.244 ms 64 bytes from 192.168.0.1: seq=2 ttl=64 time=0.232 ms 64 bytes from 192.168.0.1: seq=3 ttl=64 time=0.206 ms 64 bytes from 192.168.0.1: seq=4 ttl=64 time=0.222 ms 64 bytes from 192.168.0.1: seq=5 ttl=64 time=0.207 ms 64 bytes from 192.168.0.1: seq=6 ttl=64 time=0.250 ms 64 bytes from 192.168.0.1: seq=7 ttl=64 time=0.209 ms 64 bytes from 192.168.0.1: seq=8 ttl=64 time=0.154 ms 64 bytes from 192.168.0.1: seq=9 ttl=64 time=0.211 ms   --- 192.168.0.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 0.154/0.506/3.126 ms PM: Syncing filesystems ... done.                                   ep’s functions are ok, re-do the suspend/resume tests Freezing user space processes ... (elapsed 0.01 seconds) done. -------------------------------end-------------------------------------------- Original Attachment has been moved to: uboot_patch_image.zip Original Attachment has been moved to: 0001-imx-pcie-toggle-bit18-of-grp1-fix-pcie-can-t-exit-L2.patch.zip Original Attachment has been moved to: kernel_patch_image.zip

This documents describes how to add the NFC support to i.MX8M mini evk running Android Pie. Hardware setup: The i.MX8M mini evk (see i.MX 8M Mini Evaluation Kit | NXP) featuring Raspberry Pi compliant connector, the OM5578/RPI PN7150 demo kit can be used to perform this porting (see NFC Development Kits for Arduino and more|NXP). However a small modification must be done because some of the signals required by PN7150 are not mapped to i.MX8M mini expansion connector pins. OM5578 IRQ signal must be mapped to Raspberry Pi connector pin #19 and OM5578 VEN signal must be mapped to Raspberry Pi connector pin #21. See below a picture of the modification: Then, the two boards can fit together as shown in the picture below: Quick start using demo image: The demo image including support for PN7150, is based on Android P9.0.0 Pie (P9.0.0_1.0.0, 4.14 kernel) i.MX software release (see i.MX Software | NXP). Related documentation can be downloaded from here: https://www.nxp.com/docs/en/supporting-information/android_p9.0.0_1.0.0-ga_docs.zip. Just flash the demo image (downloaded from here:https://www.nxp.com/lgfiles/updates/NFC/ANDROID_P9-0-0_PN7150_IMAGE_8MMEVK.zip) following guidelines from i.MX_Android_Quick_Start document (part of Android P9.0.0_1.0.0 Documentation package mentioned above). The NFC support is then included in the device settings, as shown in below screenshot of the device: Approaching the NFC tag, provided as reference in the OM5578 demo kit, to the NFC Antenna will trigger a sound notification: Unfortunately the Android demo image doesn't embed a web browser, so it won't be automatically open when the NFC tag content (an URL to the demo kit web page) is read. Otherwise (if a web browser is installed) you could see such page opening on the device: Adding PN7150 support to imx-android-pie release: If you wish to add PN7150 support to your imx-android-pie environment, just apply the patches (imx-p9.0.0_1.0.0-ga_pn7150_patches.tar.gz file attached) from the ${MY_ANDROID} source code root folder (refer to i.MX_Android_User_Guide document part of Android P9.0.0_1.0.0 Documentation package mentioned above).  $ patch -p1 -d device/fsl/ <device_fsl.patch  $ patch -p1 -d packages/apps/Nfc <packages_apps_Nfc.patch  $ patch -p1 -d hardware/nxp/nfc <hardware_nxp_nfc.patch  $ patch -p1 -d vendor/nxp <vendor_nxp.patch  $ patch -p1 -d vendor/nxp-opensource/kernel_imx/ <vendor_nxp-opensource_kernel_imx.patch When building, the PN7150 support will then be included to the android image, as shown in the demo image described above. Reference: This porting have been done (demo image and patches creation) following guidelines provided in AN11690_NXP-NCI_Android_Porting_Guidelines document.

Hypoxemia is a common clinical condition associated to several diseases that affect the respiratory system, including not only the lungs diseases, but also cardiac, neurological, neuromuscular and chest wall diseases. Its occurrence bring serious risks being essential its detection for appropriate treatment, and even to prevent the death of the patient. Hypoxemia is defined as the low saturation of oxygen carried by the blood. The most efficient way to determine the oxygen saturation is the gasometry, an invasive method (through the collection of blood) which is able to determine the gases present in the blood as well as its relative amount, as well as other data related to the blood. The Oximetry is a less effective method, but not least important, because of its practicality for not being an invasive method. Depending on the quality of the equipment, it can ensure very small variations with respect to the gasometry. In some cases, the constant monitoring of oxygen saturation is required. The portable oximeters are useful in such cases due to their ease of use. For monitoring oxygen saturation in the blood and also the heart rate, the machine suitable for this purpose is the Pulse Oximeter. Such equipment can be easily purchased at a low cost, but requires an assisted operation for each measurement, by the user or another person. This project proposed the development of a device capable of measuring blood oxygen saturation and heart rate. The data collected will be transmitted to a Smartphone, featuring an Android Application that displays the received data to the user and sends an automatic message to a health care center with the user's location in case of emergency. The project will also have sensors (accelerometers) to detect when the user has lost concience and fallen to the ground. This device will help to people with a history of health problems such as hypertension, hypoxia, risk of heart attack, among other diseases, giving them more autonomy, since in case of any health problems, somebody will be informed. The mobile monitoring of vital signals will detect when these signals vary significantly out of a safe range, and upon such occurrance a message is sent to pre-registered telephone numbers informing the user's location, and that he needs help help. The device will monitor the blood oxygen level and heart rate by measuring the change in the transparency of the blood through the presence of oxygen saturated hemoglobin is made. The measurement is taken by the emission of light at two wavelengths (red and infrared), where a sensor detects the intensity of light that is absorbed by hemoglobin, which depends on the degree of oxygen saturation. From the comparison between the received signals for each wavelength, it is possible to determine the degree of oxygen saturation in the blood. The meter is controlled by a microcontroller to be selected for this project. There will be a Bluetooth module connected to the microcontroller in order to establish the communication between the device and a paired Smartphone. An Android App will be developed to control the communicatin, display the user information sent by the device as well as send automatic voice messages to pre-registered telephones. The App will also reproduce additional messages played through the headphones to help the user in using the devices features, and also in case of emergency.

Most engineers should incorporate the following fundamental methodology when designing and bringing up a new board design: 1. Review the schematics and layout to ensure proper connectivity of all devices 2. Once the board returns from the manufacturer, measure and document all of the voltage rails of each IC on the board (especially the SoC and DRAM) 3. Ensure JTAG debugger connectivity (due to the complexity of systems today, every new board design should have some “hooks” to allow JTAG connectivity, even if these are simply test points) 4. Bring up and ensure proper DRAM functionality; it is imperative the first three steps are precisely accomplished – often times, DRAM instability or non functionality is due to improper connection (including not being connected to the voltage net) or poor layout. Once these four steps are completed, the board can then proceed to a more broad based checkout of other peripherals using some type of compiled test code executed from DRAM. More often than not, the end user’s board will differ from Freescale reference design boards either in how the DRAMs are connected or simply by using a different DRAM vendor.  As such, tools were created to aid in the development of DRAM initialization scripts.  The resulting script, though targeted for the RealView development system (aka include files), can be easily ported to another debugger’s command syntax or to assembly code for use in boot loaders.  These tools are Excel spread sheet based and include a “How To Use” tab, making the tool usage relatively self-explanatory.  Each tool is unique to a specific i.MX processor and to the DRAM technology used with each processor.  This attached files are tools available for the following i.MX SoCs:

Hello Android users Sagar has posted on the Element14 community three clear tutorials (accessible following the link below) to create an Android application on the RiOTboard. RIoTboard: Part 1: Build an Android app on RIoT... | element14 RIoTboard: Part 2: Build an Android App on RIoT... | element14 RIoTboard: Part 3: Build an Android App on the ... | element14 I recommend you to start following those steps to ensure a proper setup of the Android tools. Happy Programming Greg

Wi-Fi Android IMX53 QSB enable WIFI android How to Support New WiFi Card in Android How to enable PCIe WiFi into i.MX6 Android Release? WiFi.zip

- In LTIB generate a rootfs.jffs2 with a erase block size of 16KB: ./ltib -c ---Target Image Generation   Options ---> ---Choose your root file system image type     Target image: (jffs2) --->   (16) jffs2 erase block size in KB - Copy the generated rootfs.jffs2 to /tftpboot : cp rootfs.jffs2 /tftpboot - Program 200732 Redboot binary. The 200732 Redboot is available in the 20071008 BSP iso. After mounting the iso go to the bootloaders directory, extract the redboot_200732.tar.gz file and use the pre-built mx31ads_redboot.bin inside the bin directory. - Boot from NAND and setup the network parameters fis init load -r -b 0x100000 /tftpboot/zImage fis create -l 0x200000 kernel load -r -b 0x100000 /tftpboot/rootfs.jffs2 fis create -l 0x1d000000 root - Pass the following kernel command line: fis load kernel exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock6 rootfstype=jffs2 init=linuxrc ip=none mtdparts=mx" You need to replace mtdblock6 with your rootfs partition, see below: mx31# cat /proc/mtd dev:    size  erasesize  name mtd0: 00040000 00020000 "RedBoot" mtd1: 001a0000 00020000 "kernel" mtd2: 0001f000 00008000 "FIS directory" mtd3: 00001000 00008000 "RedBoot config" mtd4: 00040000 00004000 "RedBoot" mtd5: 00200000 00004000 "kernel" mtd6: 01d00000 00004000 "root" mtd7: 00003000 00004000 "FIS directory" mtd8: 00001000 00004000 "RedBoot config" mx31#

Yes. The Yocto Project site hosts some of the MX machines here. NOTES: If the machine's folder is present but it is empty, a building error may have occurred. Check the build's status for the machine on the archives or send an email to the list. Due to limited resources, not all (Freescale) machines are (nightly) built, in case you need one of these, you need to bake it yourself. You can start building following these instructions.

  The mfgtool is the tool download the images to i.MX series of applications processors. It’s convenient and easy use to download the images to your board. About its introductions, work flow and use guide you can see details in the Document file of mfgtool. If customers use our reference boards, they can directly use the default mfgtools we supply for every version BSP and board. But when customers design board and do porting with our i.MX series processors. As they do many changes from our reference board, they need to rebuild the images for their board and for the download tool mfgtool. In the old version BSP, take the L3.0.35_4.1.0_130816 version as an example. When finishing porting the BSP for design board. Run the following command line to generate the manufacturing firmware. ./ltib --profile config/platform/imx/updater.profile --preconfig config/platform/imx/imx6q_updater.cf --continue –batch For android BSP Android4.2.2, one can use the follow command: make distclean make mx6dl_sabresd_mfg_config make In the newest BSP, for linux BSP in yocto use the command: $ bitbake fsl-image-mfgtool-initramfs For the newest android BSP, the command” make mx6dl_sabresd_mfg_config” can not use anymore. So how to get the \Profiles\Linux\OS Firmware\firmware\u-boot-imx6dlsabresd_sd.imx? The easiest way that you can use the u-boot you build for your board, and in the newest BSP, mfgtool can use the same u-boot with the normal u-boot for your board. You do not need to build the u-boot for mfgtool separately. They can use the same one. Hope this can do some help for you.

The i.MX 6 D/Q/DL/S/SL  Linux L3.10.17_1.0.2 Patch release is now available on www.freescale.com ·          Target HW boards o   i.MX6DL  SABRE SD board o   i.MX6Q  SABRE SD board o   i.MX6DQ SABRE AI board o   i.MX6DL SABRE AI board o   i.MX6SL EVK board This patch release is based on the i.MX 6 Linux L3.10.17_1.0.2 BSP release. ·         Release Description o    Kernel branch: imx_v2013.04_3.10.17_1.0.0_ga o    U-Boot branch: imx_3.10.17_1.0.0_ga o    Graphics: gpu-viv-bin-mx6q, 3.10.17_1.0.2 o    Graphics: gpu-viv-g2d, 3.10.17_1.0.2 o    Graphics: Xorg-driver, 3.10.17_1.0.2 ·         Patch Description Please consult the release notes.

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

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

This doc show: on i.MX8QXP MEK board, configure ov5640 sensor(parallel interface) output 5MP(2592x1944) RAW(Bayer) data at 15fps, and Parallel Capture Subsystem and Image Sensor Interface capture RAW RGB data, and i.MX8QXP GPU debayer RAW data then display image. HW: i.MX8QXP MEK board, MEK base board (to place the parallel camera), 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 kernel patch imx8-ov5640-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/imx8/ov5640_v3.c. This register setting is come from ov5640 software application note and data sheet. Configure at i.MX8QXP side The Parallel Capture Subsystem consists of the Parallel Capture Interface (BT 656) and associated peripherals. It interfaces to the Parallel CSI sensor. This allows for up to 24 RGB data bits in parallel or for RGB components on consecutive clocks (up to 10-bit color depth). The formats supported are RGB, RAW and YUV 422. Below is Parallel Capture Subsystem diagram: For RAW format data, CSI_CTRL_REG of Parallel Capture Subsystem need configured as my patch, otherwise found cannot get correct data.   The multiple input sources (MIPI CSI, Parallel Capture) captures the pixel data and feeds it to the ISI. The ISI is responsible for capturing and pre-processing the pixel data from multiple input sources and storing them into the memory. Below is ISI diagram: For RAW format data, it should be bypass any processing pipeline of ISI, just use ISI to save it to memory.   Capture test code To capture the RAW data and save it to file, check my patch imx8_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: ./imx8_cap.out -of -cam 1 -fr 15 -fmt BA81 -ow 2592 -oh 1944 -num 100   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.MX8QXP 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 g2d lib, it is dma-buffer also get logic/physical address of buffer, then queue it as DMABUF to 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 imx8_debayer-gpusdk-5.3.0.diff which apply on i.MX GPU SDK 5.3.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=IMX8DQXPRM b>https://www.nxp.com/webapp/Download?colCode=L4.14.98_2.0.0_MX8QXP&appType=license c>https://github.com/NXPmicro/gtec-demo-framework d>ov5640 data sheet e>ov5640 software application note f>Efficient, High-Quality Bayer Demosaic Filtering on GPUs https://www.semanticscholar.org/paper/Efficient%2C-High-Quality-Bayer-Demosaic-Filtering-on-McGuire/088a2f47b7ab99c78d41623bdfaf4acdb02358fb

Overview The document describes the procedure to measure the memory to memory copy performance by using SDMA on i.MX6Q. Materials i.MX6Q Sabre SD board L3.0.35_4.1.0_130816 BSP Procedure Install BSP and build kernel Extract imx unit test source: ./ltib -p imx-test -m prep Apply attached patch to sdma memcopy code cd ltib/rpm/BUILD/imx-test-3.0.35-4.1.0 patch -p1 -i LTIB_4.1.0_sdma_m2m_test.patch Build imx unit test ./ltib -p imx-test -f Copy kernel and rootfs to SD Card. Boot kernel and login Insert the kernel module for SDMA memory copy test: insmod /lib/modules/XXX/test/mxc_sdma_memcopy_test.ko Start SDMA memory copy test /unit_tests/mxc_sdma_test.out Result root@freescale ~$ insmod /lib/modules/3.0.35-2666-gbdde708-g1c42f8b/test/mxc_sdma_memcopy_test.ko SDMA test major number = 248 SDMA test Driver Module loaded root@freescale ~$ /unit_tests/mxc_sdma_test.out in dma_m2m_callback 65532byte / 0.003382sec buffer 1 copy passed! root@freescale ~$ /unit_tests/mxc_sdma_test.out in dma_m2m_callback 65532byte / 0.003367sec buffer 1 copy passed! root@freescale ~$ /unit_tests/mxc_sdma_test.out in dma_m2m_callback 65532byte / 0.003364sec buffer 1 copy passed! In summary, > 19Mbyte/sec

This document is a user guide for the GStreamer version 1.0 based accelerated solution included in all the i.MX 8 family SoCs supported by NXP BSP L5.4.24_1.1.0. Some instructions assume a host machine running a Linux distribution, such as Ubuntu, connected to i.MX 8 device. These commands were tested using Ubuntu 18.04 LTD, and while Ubuntu is not required on the host machine, other distributions have not been tested. These instructions are targeted for use with the following hardware: • i.MX 8MQ EVK • i.MX 8MN EVK • i.MX 8MN EVK • i.MX 8QXP MEK B0 • i.MX 8QM MEK B0   Release History v1.0 - Mar 2020 - Initial release. v2.0 - Sep 2020: Added the following content: - Mux/Demux Examples - Audio Examples - Image Examples - Transcode Examples - Streaming Examples - Multi-Display Examples - Scaling and Rotation Examples - Zero-copy Examples - Debug Examples Maintainers: . Marco Franchi . Pedro Jardim

Note that this document only applies for REV2 of the SCM QWKS board Refer to the attached presentation to check how the OV5640 camera can be connected to the QWKS rev2 with a retrofit of the OV5640 camera set as in the image below Enjoy!!!