When using Gigabit Ethernet on boards i.MX running Windows 10 IoT Core users may experience network unstability and low latency using build W1809_1_1_0_imx-iotcore. This was fixed by increasing the size of Rx/Tx buffer in ethernet driver. Fix will be part of the next release of BSP, to apply fix to current version a patch was created. To apply patch, copy content of zip archive to appropriate location in folder structure and rebuild BSP.

Hello! Here's some CODE!!! #include <iostream> #include <stdio.h> #include <assert.h> #include <string.h> #include <fcntl.h> #include <malloc.h> #include <math.h> #include <stdlib.h> //#define EGL_USE_GLES2 #include <GLES2/gl2.h> #include <EGL/egl.h> #include <GLES2/gl2ext.h> #include <EGL/eglext.h> #include <termios.h> #include <unistd.h> #include <fcntl.h> #ifdef EGL_USE_X11 #include <X11/X.h> #include <X11/Xlib.h> #endif EGLDisplay egldisplay; EGLConfig eglconfig; EGLSurface eglsurface; EGLContext eglcontext; EGLNativeWindowType eglNativeWindow; EGLNativeDisplayType eglNativeDisplayType; EGLNativeDisplayType fsl_getNativeDisplay() {   EGLNativeDisplayType eglNativeDisplayType = NULL; #if (defined EGL_USE_X11)   eglNativeDisplayType = XOpenDisplay(NULL);   assert(eglNativeDisplayType != NULL); #elif (defined EGL_API_FB)   eglNativeDisplayType = fbGetDisplayByIndex(0); //Pass the argument as required to show the framebuffer #else   display = EGL_DEFAULT_DISPLAY; #endif   return eglNativeDisplayType; } EGLNativeWindowType fsl_createwindow(EGLDisplay egldisplay, EGLNativeDisplayType eglNativeDisplayType) {   EGLNativeWindowType native_window = (EGLNativeWindowType)0; #if (defined EGL_USE_X11)   Window window, rootwindow;   int screen = DefaultScreen(eglNativeDisplayType);   rootwindow = RootWindow(eglNativeDisplayType,screen);   window = XCreateSimpleWindow(eglNativeDisplayType, rootwindow, 0, 0, 400, 533, 0, 0, WhitePixel (eglNativeDisplayType, screen));   XMapWindow(eglNativeDisplayType, window);   native_window = window; #else   const char *vendor = eglQueryString(egldisplay, EGL_VENDOR);   if (strstr(vendor, "Imagination Technologies"))   native_window = (EGLNativeWindowType)0;   else if (strstr(vendor, "AMD"))   native_window = (EGLNativeWindowType)  open("/dev/fb0", O_RDWR);   else if (strstr(vendor, "Vivante")) //NEEDS FIX - functs don't exist on other platforms   { #if (defined EGL_API_FB)   native_window = fbCreateWindow(eglNativeDisplayType, 0, 0, 0, 0); #endif   }   else   {   printf("Unknown vendor [%s]\n", vendor);   return 0;   } #endif   return native_window; } void fsl_destroywindow(EGLNativeWindowType eglNativeWindowType, EGLNativeDisplayType eglNativeDisplayType) {   (void) eglNativeWindowType; #if (defined EGL_USE_X11)   //close x display   XCloseDisplay(eglNativeDisplayType); #endif } void GLInit (void) {   static const EGLint s_configAttribs[] =   {   EGL_RED_SIZE, 5,   EGL_GREEN_SIZE, 6,   EGL_BLUE_SIZE, 5,   EGL_ALPHA_SIZE, 0,   EGL_SAMPLES, 0,   EGL_NONE   };   EGLint numconfigs;   printf("1");   eglNativeDisplayType = fsl_getNativeDisplay();   printf("2");   egldisplay = eglGetDisplay(eglNativeDisplayType);   printf("3");   eglInitialize(egldisplay, NULL, NULL);   printf("4");   assert(eglGetError() == EGL_SUCCESS);   printf("5");   eglBindAPI(EGL_OPENGL_ES_API);   printf("6");   eglChooseConfig(egldisplay, s_configAttribs, &eglconfig, 1, &numconfigs);   assert(eglGetError() == EGL_SUCCESS);   assert(numconfigs == 1);   printf("7");   eglNativeWindow = fsl_createwindow(egldisplay, eglNativeDisplayType);   assert(eglNativeWindow);   printf("8");   eglsurface = eglCreateWindowSurface(egldisplay, eglconfig, eglNativeWindow, NULL);   assert(eglGetError() == EGL_SUCCESS);   printf("9");   EGLint ContextAttribList[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE };   eglcontext = eglCreateContext( egldisplay, eglconfig, EGL_NO_CONTEXT, ContextAttribList );   assert(eglGetError() == EGL_SUCCESS);   printf("10");   eglMakeCurrent(egldisplay, eglsurface, eglsurface, eglcontext);   assert(eglGetError() == EGL_SUCCESS); } void GLEnd (void) {   printf("Cleaning up...\n");   eglMakeCurrent(egldisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);   assert(eglGetError() == EGL_SUCCESS);   eglDestroyContext(egldisplay, eglcontext);   eglDestroySurface(egldisplay, eglsurface);   fsl_destroywindow(eglNativeWindow, eglNativeDisplayType);   eglTerminate(egldisplay);   assert(eglGetError() == EGL_SUCCESS);   eglReleaseThread(); } int main (int argc, char **argv) {   GLInit();   for( int i = 0; i < 100000; ++i)   {   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);     // Clear The Screen And The Depth Buffer   glClearColor (.0f, .0f, 1.0f, 1.0f);   eglSwapBuffers (egldisplay, eglsurface);   }   GLEnd(); } Above code is stitched together from samples from GPU SDK. I've built an image using Yocto (dylan branch) and build the meta-toolchain-qt (and qte). Successfully managed to build above code ONLY FOR X11. Issues i am facing: 1) if build for X11 and run app on the board, window shows, but it stays white, when it should be BLUE...doesn't update no matter what color i glClear to. 2) when compiling with FB, fbCreateWindow and etc don't get recognized, i.e. undefined reference to `fbCreateWindow' .... WHAT header contains these functions???? 3) if even the basic samples don't work, how the hell is anybody supposed to build a GL application on this board?? --- more rhetorical than a real question, just frustrated here... what did i do wrong? 4) please show me a working tutorial or some code on how to get this EGL context initialized...i'm running at wit's end here...

Tool: VMware Workstation Player Linux Distribution : Ubuntu 16.04 1. Create the VM in VMware Workstation. 2. Select the .iso file to install the Ubuntu 16.04 in the VM. 3. In "Specify Disk Capacity", I recommend the disk size is 200GB. 4. Then click "Finish" to create the VM. 5. If you have local mirror sources, change the source in /etc/apt/source.list. This will speed up a lot when you download the Linux packages and software. 6. Type these two commands to update the Ubuntu system. - sudo apt-get update - sudo apt-get upgrade 7. Install Yocto Project host packages $ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath socat libsdl1.2-dev $ sudo apt-get install libsdl1.2-dev xterm sed cvs subversion coreutils texi2html docbook-utils python-pysqlite2 help2man make gcc g++ desktop-file-utils libgl1-mesa-dev libglu1-mesa-dev mercurial autoconf automake groff curl lzop asciidoc u-boot-tools 8.Install the repo a. Create a bin folder in the home directory. $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo b. Add the following line to the .bashrc file to ensure that the ~/bin folder is in your PATH variable. export PATH=~/bin:$PATH If you cannot download the repo from google, please try this one: Git Repo | 镜像站使用帮助 | 清华大学开源软件镜像站 | Tsinghua Open Source Mirror  9. Yocto project setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-sumo -m imx-4.14.98-2.0.0_ga.xml $ repo sync 10. Building an image The syntax for the fsl-setup-release.sh script is shown below. $ DISTRO=<distro name> MACHINE=<machine name> source fsl-setup-release.sh -b <build dir> $ DISTRO=fsl-imx-xwayland MACHINE=imx8qxpmek source fsl-setup-release.sh -b build-xwayland $ bitbake fsl-image-qt5-validation-imx or $ bitbake core-image-full-cmdline (smaller size of rootfs) (for more examples, please refer to the i.MX_Yocto_Project_User's_Guide.pdf) 11. U-boot and Kernel Source code in Yocto u-boot : imx-yocto-bsp/build-xwayland/tmp/work/<board_name>/u-boot-imx kernel : imx-yocto-bsp/build-xwayland/tmp/work/<board_name>/linux-imx 12. Deploy folder of the images imx-yocto-bsp/build-xwayland/tmp/deploy/images/<board_name> Some useful commands for your information: 1. Kernel Menuconfig $ bitbake linux-imx -c menuconfig 2. Rebuild the u-boot and kernel source code $ bitbake u-boot-imx -c compile -f $ bitbake linux-imx -c compile -f 3. Rebuild the whole project to generate the images to deploy folder again for example, if you build the fsl-image-qt5-validation-imx before , then type this: $ bitbake fsl-image-qt5-validation-imx -f Reference: (1) Download the BSP and the Documentation   :  i.MX Software | NXP 

In the old Android release R10.3.x for i.MX5x, I had followed the user guide instructions to install the USB driver and am able to setup the ADB connection successfully. Unfortunately, for the same PC, the ADB fails to detect my i.MX6SL EVK which is using R13.5. Updating the Android SDK tools cannot help. The reason is the new Android device is using a different USB VID from the old release. So, to solve this problem, we need to update the ADB configuration to scan for the new vendor ID. Below are the steps to update the ADB configuration for Windows PC. These steps (and the steps for Linux PC as well) can also be found in the R10,3.x user guide. 1. Run the SDK's tools to generate an ADB configure file: C:\Program Files\Android\android-sdk\tools> android.bat update adb 2. Modify the adb usb configure file to add the new vendor id 0x18d1. File: X:\Profile\<your account>\.android\adb_usb.ini # ANDROID 3RD PARTY USB VENDOR ID LIST -- DO NOT EDIT. # USE 'android update adb' TO GENERATE. # 1 USB VENDOR ID PER LINE. 0x15a2 0x18d1 3. Unpack the Freescale Android USB win driver "android_usb_fsl.zip" in your Android BSP release package. If you can't find this file in your current package, please get the R10.3.x release for i.MX5x and unpack it. 4. File "tetherxp.inf" in the unpacked "android_usb_fsl" may not be the updated one if the "android_usb_fsl.zip" is extracted from an old release. So, please overwrite the file "tetherxp.inf" in unpacked "android_usb_fsl.zip" by the new "tetherxp.inf" in your current Android BSP release. 5. Enable the "USB debugging" option on the i.MX6 device System settings -> Developer options -> USB debugging 6. Connect the Android Device into PC, uninstall your old driver named "Android Phone" in the device manager, then re-install driver by scanning and locating .inf file under the directory you unpack the android_usb_fsl.zip manually. 7. Restart the ADB server C:\Program Files\Android\android-sdk\platform-tools> adb kill-server C:\Program Files\Android\android-sdk\platform-tools> adb start-server 8. Finally, test your ADB connection C:\Program Files\Android\android-sdk\platform-tools> adb devices List of devices attached 0123456789ABCDEF     device Congratulations! Your ADB is now working. If you have additional information about this topic, please feel free to comment. This document was generated from the following discussion: i.MX6: Android connect to ADB

On the build folder, type bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq where <image> is the image name (e.g. core-image-minimal). In case you want to know if a certain <package> is included on an image, just grep the output bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq | grep <package>

Some processor’s GPIO settings on the i.MX Pins Tool version 7 may not show allow to select direction and just show an option “Input/Output” as shown. This will be fixed, but the settings can be changed on the local processor data as a workaround. For more information and documentation for the Pins Tool for i.MX please visit its home page on the link below: https://www.nxp.com/design/designs/pins-tool-for-i-mx-application-processors:PINS-TOOL-IMX   First, find where the Pins Tool data package is stored. To do this open the Pins Tool and click Help > About. On the About screen click the Details button. Take also note of the name of the package that needs to be fixed.   Go to the location where the data package is stored and find the processor data. The file that would need to be updated is signal_configuration.xml    Find the GPIO pin data and change the directions from the string ““inOut”to the string “in out”. Then save this file.    Close and reopen the Pins Tool. The direction on the updated package should now show the options Input and Output.  

Check new updated version for with Morty here Step 1 : Get iMX Yocto AVS setup environment Review the steps under Chapter 3 of the i.MX_Yocto_Project_User'sGuide.pdf on the L4.X LINUX_DOCS to prepare your host machine. Including at least the following essential Yocto packages $ sudo apt-get install gawk wget git-core diffstat unzip texinfo \   gcc-multilib build-essential chrpath socat libsdl1.2-dev u-boot-tools Install the i.MX NXP AVS repo Create/Move to a directory where you want to install the AVS yocto build enviroment. Let's call this as <yocto_dir> $ cd <yocto_dir> $ repo init -u https://source.codeaurora.org/external/imxsupport/meta-avs-demos -b master -m imx7d-pico-avs-sdk_4.1.15-1.0.0.xml Download the AVS BSP build environment: $ repo sync Step 2: Setup yocto for Alexa_SDK image with AVS-SETUP-DEMO script: Run the avs-setup-demo script as follows to setup your environment for the imx7d-pico board: $ MACHINE=imx7d-pico DISTRO=fsl-imx-x11 source avs-setup-demo.sh -b <build_sdk> Where <build_sdk> is the name you will give to your build folder. After acepting the EULA the script will prompt if you want to enable: Sound Card selection The following Sound Cards are supported on the build: SGTL (In-board Audio Codec for PicoPi) 2-Mic Conexant The script will prompt if you are going to use the Conexant Card. If not then SGTL will be assumed as your selection Are you going to use Conexant Sound Card [Y/N]? Install Alexa SDK Next option is to select if you want to pre-install the AVS SDK software on the image. Do you want to build/include the AVS_SDK package on this image(Y/N)? If you select YES, then your image will contain the AVS SDK ready to use (after authentication). Note this AVS_SDK will not have WakeWord detection support, but it can be added on runtime. If your selection was NO, then you can always manually fetch and build the AVS_SDK on runtime. All the packages dependencies will be already there, so only fetching the AVS_SDK source code and building it is required. Finish avs-image configuration At the end you will see a text according with the configuration you select for your image build. Next is an example for a Preinstalled AVS_SDK with Conxant Sound Card support and WiFi/BT not enabled. ==========================================================   AVS configuration is now ready at conf/local.conf             - Sound Card = Conexant                                     - AVS_SDK pre-installed                                       You are ready to bitbake your AVS demo image now:               bitbake avs-image                                        ========================================================== Step 3: Build the AVS image Go to your <build_sdk> directory and start the build of the avs-image There are 2 options Regular Build: $ cd <yocto_dir>/<build_sdk> $ bitbake avs-image With QT5 support included: $ cd <yocto_dir>/<build_sdk> $ bitbake avs-image-qt5 The image with QT5 is useful if you want to add some GUI for example to render DisplayCards. Step 4 : Deploying the built images to SD/MMC card to boot on target board. After a build has succesfully completed, the created image resides at <build_sdk>/tmp/deploy/images/imx7d-pico/ In this directory, you will find the imx7d-pico-avs.sdcard image or imx7d-pico-avs-qt5.sdcard, depending on the build you chose on Step3. To Flash the .sdcard image into the eMMC device of your PicoPi board follow the next steps: Download the bootbomb flasher Follow the instruction on Section 4. Board Reflashing of the Quick Start Guide for AVS kit to setup your board on flashing mode. Copy the built SDCARD file $ sudo dd if=imx7d-pico-avs.sdcard of=/dev/sd bs=1M && sync $ sync Properly eject the pico-imx7d board: $ sudo eject /dev/sd NXP Documentation Refer to the Quick Start Quide for AVS SDK to fully setup your PicoPi board with Synaptics 2Mic and PicoPi i.mx7D For a more comprehensive understanding of Yocto, its features and setup; more image build and deployment options and customization, please take a look at the i.MX_Yocto_Project_User's_Guide.pdf document from the Linux documents bundle mentioned at the beginning of this document. For a more detailed description of the Linux BSP, u-boot use and configuration, please take a look at the i.MX_Linux_User's_Guide.pdf document from the Linux documents bundle mentioned at the beginning of this document.

The Linux L4.9.11_1.0.0 RFP(GA) for i.MX6 release files are now available on www.nxp.com    Files available: # Name Description 1 L4.9.11_1.0.0-ga_images_MX6QPDLSOLOX.tar.gz i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo, i.MX 6Solox Linux Binary Demo Files 2 L4.9.11_1.0.0-ga_images_MX6SLEVK.tar.gz i.MX 6Sololite EVK Linux Binary Demo Files 3 L4.9.11_1.0.0-ga_images_MX6UL7D.tar.gz i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 4 L4.9.11_1.0.0-ga_images_MX6SLLEVK.tar.gz i.MX 6SLL EVK Linux Binary Demo Files 5 L4.9.11_1.0.0-ga_images_MX7ULPEVK.tar.gz i.MX 7ULP EVK Linux Binary Demo Files  6 L4.9.11_1.0.0-ga_mfg-tools.tar.gz i.MX Manufacturing Toolkit for Linux L4.9.11_1.0.0 BSP 7 L4.9.11_1.0.0-ga_gpu-tools.tar.gz L4.9.11_1.0.0 i.MX VivanteVTK file 8 bcmdhd-1.141.100.6.tar.gz The Broadcom firmware package for i.MX Linux L4.9.11_1.0.0 BSP. 9 imx-aacpcodec-4.2.1.tar.gz Linux AAC Plus Codec for L4.9.11_1.0.0 10 fsl-yocto-L4.9.11_1.0.0.tar.gz L4.9.11_1.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide.   Target boards: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6QuadPlus SABRE-AI Board i.MX 6Quad SABRE-SD Board and Platform i.MX 6DualLite SABRE-SD Board i.MX 6Quad SABRE-AI Board i.MX 6DualLite SABRE-AI Board i.MX 6SoloLite EVK Board i.MX 6SoloX SABRE-SD Board i.MX 6SoloX SABRE-AI Board i.MX 7Dual SABRE-SD Board i.MX 6UltraLite EVK Board i.MX 6ULL EVK Board i.MX 6SLL EVK Board i.MX 7ULP EVK Board (Beta Quality)   What’s New/Features: Please consult the Release Notes.   Known issues For known issues and more details please consult the Release Notes.   More information on changes, see: README: https://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp/tree/README?h=imx-morty ChangeLog: https://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp/tree/ChangeLog?h=imx-morty

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.

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

The HSM Coding-Signing is new. When we follow the instructions in Code-Signing Tool User’s Guide , still has something to overcome, most of them are related to the OS. Actually, Code-Signing Tool User’s Guide  can not give detail every “obvious” step. The purpose of this document is to share the experiences on my system. Hope those experience can give you some clues on your system.     25JUL2024 - add pkcs11 proxy                         HSM Code-Signing Journey_25JUL2024.pdf                          HSM Code-Signing Journey_25JUL2024.txt  

  Some customers want to expose their i3c device on the /dev, In order to develop their i3c APP or operation the i3c device like I2C. But in our default BSP code, we do not support this feature for I3C device, This article will introduce how to make the i3c device expose to the user space. Board : i.MX 93 EVK BSP Version : lf-6.1.55-2.2.0 I3C device : LSM6DSOXTR Step 1 : Rework the i.MX93 EVK Board, Install the R1010.      Step 2 : Apply the add_i3c_device_to_dev.patch file to the linux kernel code              Command : git apply add_i3c_device_to_dev.patch Step 3 : Re-compile the kernel Image file.              Command : make imx_v8_defconfig                                  make Step 4 : Boot your board with "imx93-11x11-evk-i3c.dtb" file and see if you can see the I3C device on the /dev directory. Result : We can see the i3c device is appeared in /dev directory, The i2c-8 is an i2c device mounted to the i3c bus. The i3c is backward compatible with i2c device. It will simulate the I2C signal loading i2c device.                 PS : You can also use the i2ctool detect i2c-8 device. As shown in the following picture:   Note : If you need the patch file, Please contact me any time for free.

This article is rather short that only mentions the script that is needed to make an iMX93EVK act as a USB mass storage device so that whenever you connect your iMX device to a windows/linux system via USB, it should get enumerated something like a usb drive.  The storage that is used in this example is mmc so the expectation is that you have inserted a mmc card in the slot. Below is the script:- #!/bin/sh   # This composite gadget include function: # - MASS STORAGE     # # Exit status is 0 for PASS, nonzero for FAIL # STATUS=0   # Check if there is udc available, if not, return fail UDC_DIR=/sys/class/udc if test "$(ls -A "$UDC_DIR")"; then echo "The available udc:" for entry in "$UDC_DIR"/* do echo "$entry" done else STATUS=1 echo "No udc available!" exit $STATUS; fi   id=1; udc_name=ci_hdrc.0 #back_file=/dev/mmcblk1 back_file=/tmp/lun0.img   mkdir /sys/kernel/config/usb_gadget/g$id cd /sys/kernel/config/usb_gadget/g$id   # Use NXP VID, i.MX8QXP PID echo 0x1fc9 > idVendor echo 0x12cf > idProduct   mkdir strings/0x409 echo 123456ABCDEF > strings/0x409/serialnumber echo NXP > strings/0x409/manufacturer echo "NXP iMX USB Composite Gadget" > strings/0x409/product   mkdir configs/c.1 mkdir configs/c.1/strings/0x409   echo 5 > configs/c.1/MaxPower echo 0xc0 > configs/c.1/bmAttributes   mkdir functions/mass_storage.1 echo $back_file > functions/mass_storage.1/lun.0/file ln -s functions/mass_storage.1 configs/c.1/   echo $udc_name > UDC First execute the script. After that insert the g_mass_storage module in the kernel by executing :- modprobe g_mass_storage file=/dev/mmcblk1 removable=1 In the dmesg output, you will see something like below:-   After that you can connect a C type USB cable to the USB1 port of imx93evk and the other end to any USB ports of a laptop. The moment it is connected, you would be able to see a USB drive similar to what you get when we connect a pen-drive. 

Information about the transition from the NXP Demo Experience to GoPoint for i.MX Application Processors.

i.MX93 DDR stress test tool is different with previous i.MX tool. This Chinese article describe how to debug i.MX93 DDR and introduce DDR config tool usage.

  Introduction   Prior to 6.1.22_2.0.0 BSP release, Bluetooth interface are based on the tty line discipline framework, so we need to use hciattach tool to enable it in the user space. From 6.1.22_2.0.0 BSP, the nxp bluetooth driver no longer needs the help of the userspace hciattach tool, and the tty port bound by bluetooth also won't be exported to the user space, so you cannot find the corresponding tty device anymore. So, you won't see the (/dev/ttymxcX), for the Bluetooth interface. All jobs has been done in the new NXP Bluetooth driver. New Method   The new NXP Bluetooth UART Driver is based on a server driver for the NXP BT serial protocol, which can enable the built-in Bluetooth device inside an NXP BT chip. This driver has a Power Save feature that will put the chip into a sleep state whenever there is no activity for 2000ms and will be woken up when any activity is to be initiated over UART.  Device Tree support The new BT framework requires adding a "bluetooth" sub node with a device compatibility string to the attached UART node in the dts file &uart1 { bluetooth { compatibility = "nxp,88w8987-bt"; fw-init-baudrate = <3000000>; #Optional. Default is considered 115200 if this parameter not defined. }; };   Note: The parameter ‘compatibility = “nxp,88w8987-bt”’ will use for 88W8987, IW416, 88Q9098, IW612 chipsets and need to change for 88W8997 with parameter ‘compatibility = “nxp,88w8997-bt”’.   Note: ’fw-init-baudrate’ parameter depends on the module vendor. The Murata and Azuere wifi modules support in BSP release uses the default value -- 115200. We strongly recommend looking at the module vendor-specific baud rate parameter. Note: For the old 88Q9098 Murata 1XL module that uses the 3Mbps by default, please add the fw-init-baudrate = <3000000> property in dts files to make it work. Enable Guide   Use wifi interface to load combo (wifi & bt) firmware and enable BT Need to load wifi driver first, then load the BT driver, otherwise, BT driver suspend/resume test will fail. This is a HW limitation, since NXP wifi and BT module use the same power control pin(W_DISABLE1#), if we don't load the wifi driver, SDIO bus will power down the wifi chip during suspend resume, which may cause the BT chip also been powered down and cannot work after resume back. So we need to load the wifi driver to make sure SDIO bus won't power down the BT chip to make sure BT functions can work during suspend resume. modprobe moal mod_para=nxp/wifi_mod_para.conf modprobe btnxpuart or insmod mlan.ko insmod moal.ko mod_para=nxp/wifi_mod_para.conf insmod btnxpuart   Unload UART Driver modprobe moal Make sure run hciconfig hci0 up or hciconfig hci0 reset or bluetootctl power on before unload btnxpuart driver. If we don't open hci0 interface, the driver cannot send change to 115200 baud rate command to BT chip, which causes the host and BT chip baud rate mismatch, the host still uses 115200bps talk to the BT chip which now use 3Mbps, it cannot work anymore. So we need to make sure open the hci0 interface before unload btnxpuart driver.   mod_para=nxp/wifi_mod_para.conf modprobe btnxpuart sleep 3 hciconfig hci0 up #Note: Need to up hci interface before unload the BT module hcitool -i hci0 cmd 3F 23 02 00 00 modprobe -r btnxpuart modprobe -r moal sleep 3​ For better reference: Please find the I.MX 8MQ Linux getting started user guide, UM11483, Chapter "7.1 Bring-up using NXP Bluetooth UART driver"  Bluetooth Deep Sleep Feature App Note AN13920, Chapter 6 Load NXP UART driver module NOTE: Please do not run the power save feature for Murata IW612 2EL Module Regards, Mario

Environment BSP: L6.1.22_2.0.0​ Platform: i.MX93 Links:  https://github.com/NXP/swupdate-scripts https://github.com/nxp-imx-support/meta-swupdate-imx   The AN13872 provides us the swupdate yocto layer, swupdate-scripts and test steps, but there is still much to add. The purpose of this knowledge base is to provide customized advice. 1.How to port meta-swupdate-imx to any yocto version you want? As meta-swupdate-imx only provide kirkstone version, we can upgrade or degrade it based on this version. We will take L6.1.22_2.0.0​ porting steps as an example. 1.1 Download Yocto layer  cd imx-yocto-bsp/sources git clone https://github.com/sbabic/meta-swupdate.git -b mickledore git clone https://github.com/nxp-imx-support/meta-swupdate-imx.git 1.2 Modify  Yocto layer  imx-yocto-bsp/sources/meta-swupdate-imx/conf/layer.conf   You can find swupdate version in imx-yocto-bsp/sources/meta-swupdate/recipes-support/swupdate/ 1.3 Handle patches in meta-swupdate-imx/recipes-bsp/u-boot/files/ About patchs in sources/meta-swupdate-imx/recipes-bsp/u-boot/files/ and imx-yocto-bsp/sources/meta-swupdate-imx/recipes-support/swupdate/files/, you need use devtool to unpack uboot and swupdate into workspace and add changes manunally for development. CONFIG_ENV_OFFSET_REDUND=CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE   sources/meta-swupdate-imx/recipes-bsp/u-boot/u-boot-imx_%.bbappend 2.How to flash base image? Use uuu or dd command, just like common imx-image-xxx 3.swupdate-scripts porting suggestions 3.1 Partition table You can modify partition table refer the size of images. For different soc, the first offset is different. If you are porting i.MX8MP based on iMX8MM, the offset should be 32K.   3.2 Some errors 3.2.1 This error indicates that you need enlarge size of rootfs. e2fsck 1.45.5 (07-Jan-2020) The filesystem size (according to the superblock) is 887599 blocks The physical size of the device is 768000 blocks Either the superblock or the partition table is likely to be corrupt! Abort<y>?    3.2.2 You need upgrade e2fsck verison. e2fsck 1.46.5 (30-Dec-2021) /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/slota/core-image-base-imx93-11x11-lpddr4x- evk.ext4 has unsupported feature(s): FEATURE_C12 e2fsck: Get a newer version of e2fsck! /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/slota/core-image-base-imx93-11x11-lpddr4x- evk.ext4: ********** WARNING: Filesystem still has errors ********** resize2fs 1.46.5 (30-Dec-2021) resize2fs: Filesystem has unsupported feature(s) (/home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_ass  solution: wget https://mirrors.edge.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/v1.47.0/e2fsprogs-1.47.0.tar.xz tar -xf e2fsprogs-1.47.0.tar.xz cd e2fsprogs-1.47.0/ ./configure make -j16 sudo make install   3.2.3 mtools /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 58: mdir: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 66: mcopy: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 66: mcopy: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 68: mdir: command not found solution: sudo apt-get install mtools

i.MX8 VPU hardware decoder support below video codec: H.265 HEVC Main Profile 4Kp60 Level 5.1 H.264 AVC Constrained Baseline, Main and High profile H.264 MVC WMV9 / VC-1 Simple, Main and Advanced Profile MPEG 1 and 2 Main Profile at High Level AVS Jizhun Profile (JP) MJPEG4.2 ASP, H.263, Sorenson Spark Divx 3.11, with Global Motion Compensation (GMC) ON2/Google VP6/VP8 RealVideo 8/9/10 JPEG and MJPEG A/B Baseline   i.MX8 VPU Linux driver is implemented based on V4L2 standard. Chromium beside software video decoding, it also support hardware video decoder(VideoDecodeAccelerator),  there are some kind of VideoDecodeAccelerator, one of them is V4L2VDA. Please note V4L2VDA is using V4l2 api, so it is possible that change V4L2VDA to enable Chromium hardware video playback on i.MX8.   This doc share patch to add chromium video decode accelerate by using i.MX8QM/i.MX8QXP VPU. It will support chromium H.264, H.265, VP8 hardware video decode. H.264 and H.265 need use mp4 container. VP8 use webm container.   HW: i.MX8QM/i.MX8QXP MEK board, 1080P HDMI display, mouse, keyboard SW: i.MX8 5.10.72_2.2.2 yocto bsp release(which included chromium 91.0), and patch in this doc   Patch description: imx8-5.10.72-vpudrv-update.diff, update i.MX8  5.10.72_2.2.2 kernel vpu driver to https://source.codeaurora.org/external/imx/linux-imx/commit/drivers/mxc/vpu_malone?h=lf-5.15.y&id=fa7c67e2c9ed4fb8392fa258f931d6996339a17a chromium-ozone-wayland_91.0.4472.114.bb.diff, change meta-browser/meta-chromium/recipes-browser/chromium/chromium-ozone-wayland_91.0.4472.114.bb for adding some compile flags, etc. 5.10.72-merge.patch, this patch change chromium source code to add video decode accelerate by using i.MX8 VPU.   Build steps: 1>Download i.MX8 5.10.72_2.2.2 yocto release from nxp.com 2>apply chromium-ozone-wayland_91.0.4472.114.bb.diff to change meta-browser/meta-chromium/recipes-browser/chromium/chromium-ozone-wayland_91.0.4472.114.bb 3>put 5.10.72-merge.patch to folder path_of_yocto-5.10.72-2.2.2/sources/meta-browser/meta-chromium/recipes-browser/chromium/files/ 3>apply imx8-5.10.72-vpudrv-update.diff to i.MX8 5.10.72_2.2.2 kernel 4>under the yocto image build folder, add "CORE_IMAGE_EXTRA_INSTALL += "chromium-ozone-wayland" to file path_of_yocto-5.10.72-2.2.2/folder-of-bld/conf/local.conf 5>run bitbake to build rootfs image   Test steps: After system boot up, put some video clip under /home/root/video then run below cmd (do not run chromium without any parameter, as that will start chromium with some other setting, you can check /usr/lib/chromium/chromium-wrapper) "/usr/lib/chromium/chromium-bin   --no-sandbox --ozone-platform=wayland --enable-features=VaapiVideoDecoder  --enable-accelerated-video-decode   --enable-clear-hevc-for-testing --ignore-gpu-blacklist --window-size=1920,1180  /home/root/video" then use mouse to click video clip and will start playback.   Reference: https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors:IMX8-SERIES https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX https://www.chromium.org/audio-video/#:~:text=codec%20and%20container%20support https://github.com/igel-oss/meta-browser-hwdecode/blob/master/recipes-chromium/chromium/files/0001-Add-support-for-V4L2VDA-on-Linux.patch      

This is a detailed programming aid for the registers associated with i.MX 8MNano (m815S) DDR initialization.  For more details, refer to the main mScale DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/1104467 Please note that this page is only intended to store the RPA spreadsheets. For questions, please create a new community thread.

Host TFTP and NFS Configuration Now configure the Trivial File Transfer Protocol (TFTP) server and Networked File System (NFS) server. U-Boot will download the Linux kernel and dtb file using tftp and then the kernel will mount (via NFS) its root file system on the computer hard drive. 1. TFTP Setup   1.1.1 Prepare the TFTP Service   Get the required software if not already set up. On host for TFTP: Install TFTP on Host $ sudo apt-get install tftpd-hpa   (Note: There are a number of examples in various forums, etc, of how to automatically start the TFTP service - but not all are successful on all Linux distro's it seems! The following may work for you.)   Start the tftpd-hpa service automatically by adding a command to /etc/rc.local. $ vi /etc/rc.local   Now, just before the exit 0 line edit below command then Save and Exit. $ service tftpd-hpa start  Now, To control the TFTP service from the command line use: $ service tftpd-hpa restart    To check the status of the TFTP service from the command line use: $ service tftpd-hpa status   1.1.1 Setup the TFTP Directories Now, we have to create the directory which will contain the kernel image and the device tree blob file. $ mkdir -p /imx-boot/imx6q-sabre/tftp Then, copy the kernel image and the device tree blob file in this directory. $ cp {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/zImage /imx-boot/imx6q-sabre/tftp $ cp {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/<dtb file> /imx-boot/imx6q-sabre/tftp   OR we can use the default directory created by yocto {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/ The tftpd-hpa service looks for requested files under /imx-boot/imx6q-sabre/tftp The default tftpd-hpa directory may vary with distribution/release, but it is specified in the configuration file: /etc/default/tfptd-hpa. We have to change this default directory with our directory   Edit default tftp directory $ vi /etc/default/tftpd-hpa   Now, change the directory defined as TFTP_DIRECTORY with your host system directory which contains kernel and device tree blob file. Using created directory TFTP_DIRECTORY=”/imx-boot/imx6q-sabre/tftp” OR Using Yocto directory path TFTP_DIRECTORY=”{YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}” Restart the TFTP service if required $ service tftpd-hpa restart   1.2 NFS Setup 1.2.1 Prepare the NFS Service Get the required software if not already set up. On host for NFS: Install NFS on Host $ sudo apt-get install nfs-kernel-server The NFS service starts automatically. To control NFS services : $ service nfs-kernel-server restart To check the status of the NFS service from the command line : $ service nfs-kernel-server status 1.2.2 Setup the NFS Directories Now, we have to create the directory which will contain the root file system. $ mkdir -p /imx-boot/imx6q-sabre/nfs   Then, copy the rootfs in this directory. $ cp -R {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs/* /imx-boot/imx6q-sabre/nfs   OR we can use the default directory created by yocto. $ {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs 1.2.3 Update NFS Export File The NFS server requires /etc/exports to be configured correctly to access NFS filesystem directory to specific hosts. $ vi /etc/exports Then, edit below line into the opened file. <”YOUR NFS DIRECTORY”> <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Ex. If you created custom directory for NFS then, /imx-boot/imx6q-sabre/nfs <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Ex: /imx-boot/imx6q-sabre/nfs 192.168.*.*(rw,sync,no_root_squash,no_subtree_check) OR /{YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check)   Now, we need to restart the NFS service. $ service nfs-kernel-server restart   2 Target Setup   We need to set up the network IP address of our target. Power On the board and hit a key to stop the U-Boot from continuing. Set the below parameters, setenv serverip 192.168.0.206       //This must be your Host IP address The path where the rootfs is placed in our host has to be indicated in the U-Boot, Ex. // if you choose default folder created by YOCTO setenv nfsroot /{YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs   OR // if you create custom directory for NFS setenv nfsroot /imx-boot/imx6q-sabre/nfs Now, we have to set kernel image name and device tree blob file name in the u-boot, setenv image < zImage name > setenv fdt_file <dtb file name on host> Now, set the bootargs for the kernel boot, setenv netargs 'setenv bootargs console=${console},${baudrate} ${smp} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp' Use printenv command and check loadaddr and fdt_addr environment variables variables for I.MX6Q SABRE, loadaddr=0x12000000 fdt_addr=0x18000000   Also, check netboot environment variable. It should be like below, netboot=echo Booting from net ...; run netargs; if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; ${get_cmd} ${image}; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if ${get_cmd} ${fdt_addr} ${fdt_file}; then bootz ${loadaddr} - ${fdt_addr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi; Now, set environment variable bootcmd to boot every time from the network, setenv bootcmd run netboot Now finally save those variable in u-boot: saveenv Reset your board; it should now boot from the network: U-Boot 2016.03-imx_v2016.03_4.1.15_2.0.0_ga+ga57b13b (Apr 17 2018 - 17:13:43 +0530)  (..) Net:   FEC [PRIME] Normal Boot Hit any key to stop autoboot:  0   Booting from net ... Using FEC device TFTP from server 192.168.0.206; our IP address is 192.168.3.101 Filename 'zImage'. Load address: 0x12000000 Loading: #################################################################         #################################################################         #################################################################         #################################################################         #################################################################         #################################################################         ###########################################################         2.1 MiB/s done Bytes transferred = 6578216 (646028 hex) Using FEC device TFTP from server 192.168.0.206; our IP address is 192.168.3.101 Filename 'imx6q-sabresd.dtb'. Load address: 0x18000000 Loading: ####         1.8 MiB/s done Bytes transferred = 45893 (b345 hex) Kernel image @ 0x12000000 [ 0x000000 - 0x646028 ] ## Flattened Device Tree blob at 18000000   Booting using the fdt blob at 0x18000000   Using Device Tree in place at 18000000, end 1800e344 switch to ldo_bypass mode!   Starting kernel ...