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

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!!!

How to connect i.MX51 and Ubuntu using USB cable: i.MX51 Side Plug in USB cable. getprop debug.adb.usb - Shows that debug.adb.usb are not set by default setprop persist.service.adb.enable 0 -> disable adb setprop debug.adb.usb 1 - adb will be through USB (for Ethernet, use setprop debug.adb.usb 0) setprop persist.service.adb.enable 1 -> enable adb Example: # getprop debug.adb.usb  # # # setprop persist.service.adb.enable 0 disabling adb # adb_release android_usb gadget: high speed config #1: android setprop debug.adb.usb 1 # # setprop persist.service.adb.enable 1 enabling adb # adb_open adb_release adb_open android_usb gadget: high speed config #1: android # Ubuntu Side On Ubuntu side, the most important tip is regarding permission. ADB server MUST be started with root right. Example of right mistake: $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb devices List of devices attached ????????????    no permissions  $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb shell error: insufficient permissions for device How to proceed to get permission: $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb kill-server $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb start-server * daemon not running. starting it now * * daemon started successfully * $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb devices List of devices attached 0123456789ABCDEF    device  $ sudo <AND_SDK_DIR>/android-sdk-linux_86/tools/adb shell ADB over Ethernet/Wi-Fi To make ADB work in i.MX51 using TCP: In your host machine: - Install Android SDK - export ADBHOST=BOARD_IP (setenv ADBHOST=xxx.xxx.xxx.xxx) - adb kill-server In your board: - make sure that ro.secure property is *not* set when the adbd daemon is launched, so edit the file default.prop - make sure that /dev/android_adb or /dev/android do *not* exist - stop adbd - start adbd Now you will be able to list the device: hamilton@saygon:/opt/work/androidsdk/android-sdk-linux_86/tools$ ./adb kill-server hamilton@saygon:/opt/work/androidsdk/android-sdk-linux_86/tools$ ./adb devices * daemon not running. starting it now * * daemon started successfully * List of devices attached emulator-5554   device

The Linux L4.1.15_2.0.3 Patch for i.MX 6ULL@900MHz Release is now available on www.nxp.com. BSP Updates and Releases -> Linux -> Linux 4.1.15_2.0.3 Patch.   Files available: # Name Description 1 L4.1.15_2.0.3_6ULL_patch_images.tar.gz i.MX 6ULL-EVK@900MHz Linux Binary Demo Files   Information of release, see: README: http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-4.1-krogoth ChangeLog: http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/ChangeLog?h=imx-4.1-krogoth

i.MX 35 PDK board has 256 MB of RAM, due to a bug in Redboot bootloader compiled for the board effectively there is only 128 MB available. This procedure fixes this bug to be able to use 256 MB of RAM. Redboot supporting 256 MB of RAM 1. Download the attached Redboot256.bin file. 2. Flash the new redboot image instead of the old one using one of the methods: All Boards Updating RedBoot Through RedBoot