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

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

Here is an example for i.MX28 EVK board to support SPI NOR boot in uboot, kernel and MFGTool.   Attached files are the patches to support SPI NOR flash on i.MX28 EVK bord based on L2.6.35 ER11.09.01 BSP. It was verified on Spansion s25fl256s SPI NOR. "ER11.09.01_uboot_imx28_spi_nor.patch" is the Uboot patch. "ER11.09.01_kernel_imx28_spi_nor.patch" is the kernel patch. "ucl.xml" is the updated MFGTool config file, please update it to "Mfgtools-Rel\Profiles\MX28 Linux Update\OS Firmware\ucl.xml".   The uboot boot paramters for SPI: setenv bootargs_base 'setenv bootargs console=ttyAM0,115200' setenv loadaddr 0x42000000 setenv bootargs_spi 'setenv bootargs ${bootargs} root=/dev/mtdblock2 rootfstype=jffs2 rootwait rw ip=none' setenv bootcmd_spi 'run bootargs_base bootargs_spi;sf probe 2:0; sf read ${loadaddr} 0x100000 0x300000;bootm' setenv bootcmd 'run bootcmd_spi' saveenv   To boot the board from SPI NOR s25fl256s, the 4KB page region of the NOR should be put to top, the last 128KB of the NOR address space. The uboot.sb is about 220KB, it can't be put to 4KB and 64KB combined region. The IMX28 boot ROM can only handle simple page size for boot. All 4KB page region or all 64KB page region are both OK for boot, but combined region can't boot.   For default, the s25fl256s NOR's 128KB 4KB page size region is at the bottom of the NOR, we should update the OTP to set this region to TOP, in Uboot, we run the followed command to burn the OTP: MX28 U-Boot -> sf probe 2:0 MX28 U-Boot -> sf set_config_reg 0x04   To boot the i.MX28 EVK board from SPI2 NOR flash, the BM3~0 should be 0010.   In this example, we only used the JFFS2 file system. To support the UBIFS, there is a known issue, that the UBIFS will use vmalloc to alloc memory, and if SPI driver used the DMA, kernel will halt with error "kernel BUG at arch/arm/mm/dma-mapping.c:409!".   For 11.09.01 BSP, the default MFGTool rootfs "initramfs.cpio.gz" will be bigger than 4MB, but in i.MX28 bootlets code, the BSP only set ramdisk to 4MB, so we need modify this limitation for MFGTool.   Use command "./ltib -p imx-bootlets -m prep" to get the bootlets code, modify "ltib/rpm/BUILD/imx-bootlets-src-11.09.01/linux_prep/core/setup.c", function setup_initrd_tag(), change from "params->u.initrd.size =  0x00400000;" to "params->u.initrd.size =  0x00500000;". Modify "ltib/rpm/BUILD/imx-bootlets-src-11.09.01/updater.bd" and "updater_ivt.bd", change from "load 0.b    > 0x40800000..0x40c00000;" to "load 0.b    > 0x40800000..0x40d00000;".   Now the MFGTool rootfs size can be 5MB.   2013-05-09: Updated hardware rework: On iMX28 EVK board, rework J89 as followed and mount R320,R321,R322 and C178. MX28 U49 Pin1 /CS <-> NOR Pin7 CS# MX28 U49 Pin2  D0 <-> NOR Pin8 SI/IO1 MX28 U49 Pin5 DIO <-> NOR Pin15 SI/IO0 MX28 U49 Pin6 CLK<-> NOR pin 16 SCK. MX28 U49 Pin8 VCC <-> NOR Pin2 VCC                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 MX28 U49 Pin4 GND <-> NOR Pin10 VSS MX28 U49 Pin3 /WP <-> NOR Pin9 WP MX28 U49 Pin7 /Hold <-> NOR Pin pin1 hold   Software reset issue for 32MB SPI NOR: For 32MB SPI NOR, after booted into kernel, the kernel driver will set SPI NOR to 4 bytes address mode, but for iMX28 SPI boot, it can only boot with 3 bytes address mode, if reset the iMX28 board but SPI NOR was not reset, it will fail to reboot. Hardware solution: when iMX28 was reboot, reset the SPI NOR too, the SPI NOR will work in 3 bytes address mode as default. Software solution: In kernel SPI NOR driver, always switch SPI NOR to 3 bytes address mode after each SPI NOR access, and switch to 4 bytes address mode before each access. There is no such issue if the SPI NOR size is less than 32MB.    

Host : Ubuntu 11.10 Part 1. Installation of QNX 6.50 and QNX 6.50 SP1        1.1 Create an account and activate the created account that will be assigned an 30-days evaluation serial numberin then on www.qnx.com, and download qnxsdp-6.5.0-201007091524-linux.bin, qnxsdp-6.5.0SP1-201206271006-linux.bin;        1.2 Execute "sudo apt-get install ia32-libs"        1.3 Execute "sudo -E /your/path/qnxsdp-6.5.0-201007091524-linux.bin", follow the guides as prompted, enter the received evaluation serial number, then the installation of QNX 6.50 will be done;        1.4 Logout, and re-login, so far typing "qconfig" will return the following messages:         --------------------------------------------------------------------------------------------------------------------- alanz@alanz-VirtualBox:~$ qconfig QNX Installations   Installation Name: QNX Software Development Platform 6.5.0             Version: 6.5.0      Base Directory: /opt/qnx650            QNX_HOST: /opt/qnx650/host/linux/x86          QNX_TARGET: /opt/qnx650/target/qnx6         ---------------------------------------------------------------------------------------------------------------------        1.5 Execute "sudo chmod a+rw /etc/qnx/license/licenses"        1.6 Execute "sudo -E /your/path/qnxsdp-6.5.0SP1-201206271006-linux.bin"        1.7 Logout, and re-login, so far typing "qconfig" will return the following messages:         --------------------------------------------------------------------------------------------------------------------- alanz@alanz-VirtualBox:~$ qconfig QNX Installations   Installation Name: QNX Software Development Platform 6.5.0             Version: 6.5.0      Base Directory: /opt/qnx650            QNX_HOST: /opt/qnx650/host/linux/x86          QNX_TARGET: /opt/qnx650/target/qnx6 Additional Packages    Package Name: QNX Software Development Platform         Version: 6.5.0SP1            Base: QNX SDP 6.5.0    Installation Path: /opt/qnx650         ---------------------------------------------------------------------------------------------------------------------        1.8 Download bsp-nto650-freescale-mx6q-sabrelite-trunk-201301161142.zip, and unzip it; Part 2. Build i.MX6Q SabreLite QNX BSP        2.1 Edit a envsetup.sh as following:         --------------------------------------------------------------------------------------------------------------------- #!/bin/bash export QNX_HOST=/opt/qnx650/host/linux/x86 export QNX_JAVAHOME=/opt/qnx650/_jvm export QNX_TARGET=/opt/qnx650/target/qnx6 export QNX_CONFIGURATION=/etc/qnx export ARCH=arm export CPULIST=arm export VARIANTLIST=v7 export MAKEFLAGS=-I/opt/qnx650/target/qnx6/usr/include export PATH=$PATH:/opt/qnx650/host/linux/x86/usr/bin export QCONFIG=/opt/qnx650/target/qnx6/usr/include/qconfig.mk export BSP_ROOT_DIR=/home/alanz/Downloads/QNX_Software/i.MX6Q_SabreLite4QNX         ---------------------------------------------------------------------------------------------------------------------        Note: BSP_ROOT_DIR is the BSP unzip directory.        2.2 Execute "make clean", then "make". The generated file will be under images/ifs-mx6q-sabrelite.raw Part 3. Running i.MX6Q SabreLite QNX BSP        3.1 Copy images/ifs-mx6q-sabrelite.raw to SD;        3.2 Modify u-boot environment as following:         --------------------------------------------------------------------------------------------------------------------- setenv loadaddr '0x10800000' setenv bootcmd_sd 'mmc dev 0; fatload mmc 0:1 ${loadaddr} ifs-mx6q-sabrelite.raw; go ${loadaddr}' setenv bootcmd 'run bootcmd_sd' saveenv boot         ---------------------------------------------------------------------------------------------------------------------        3.3 Connect i.MX6Q SabreLite w/ serial and ethernet, turn on, type "qconn" and "ifconfig" in the serial shell. Part 4. Debug w/ QNX Momentics IDE        4.1 Type "qde" to activate Momentics IDE        4.2 On the top-right corner, there exist several icons named in "xxx perspective" to switch the main window according to current selected "perspective" context. Click "QNX System Information Perspective" to create a target to conect and debug as following depicted.        4.3 Switch to "C/C++ perspective" to create QNX C/C++ project as following depicted.        4.4 Switch to "Debug perspective" to perform "Debug Configuration" as following depicted.        Then it can debug program on target i.MX6Q SabreLite board.

Gamma correction Displays usually presents a nonlinear bright response. For example, a frame buffer value of 100 will almost never give half the brightness of a value of 200. Historically, this is due to the physics of CRT monitors, but newer display technologies emulate the behavior. This is not only for compatibility, but for solid reasons based in the science of human visual perception. A first-order approximation to the non-linearity of a CRT is: L = ν ^ γ where L is the radiance (light intensity) from the display, ν is the voltage applied to the CRT gun (normally proportional to the digital value in the frame buffer), and γ (Greek letter “gamma”) is a constant particular to the monitor; it's the unknown parameter that makes it all work. It usually ranges from about 2.0 to about 2.5. One useful fact is that the gamma curve is linear in log-log space (i.e. logL as a function of logν), and γ is just the slope of that line. Example of gamma correction The dotted line indicates a linear transfer function (γ=1), the framebuffer gamma; the solid line shows how a typical CRT behaves; the dashed line represents the inverse function, the corrected gamma. How to correct gamma on i.MX using DP (Display Processor)? Gamma correction can be performed by IC (Image Converter) or DP (Display Processor) sub-blocks inside IPU. Current Linux kernel (3.10) provided by Freescale has an IOCTL that changes the related gamma parameters registers DP_GAMMA_C_SYNC<i> and DP_GAMMA_S_SYNC<i> on Display Processor block. The steps below shows how to change the gamma using user space applications: 1 - Declare a variable as mxcfb_gamma: struct mxcfb_gamma fb_gamma; 2 - Enable the gama correction: fb_gamma.enable = 1; 3 - Set the constk and slopek values, where i = 0 to 15 and x and y are respectively the new constk and slopek constant values: fb_gamma.constk[i] = x; fb_gamma.slopek[i] = y; 4 - Open the framebuffer device and call MXCFB_SET_GAMMA: fd_fb = open("/dev/fb0", O_RDWR, 0) ioctl(fd_fb, MXCFB_SET_GAMMA, &fb_gamma) Running the code above will immediately change the gamma value.

Wayland:   Wayland is a display SERVER and COMPOSITION protocol. It is relatively new, as its first release was in 2012. The protocol enables applications to allocate their own off-screen buffers and render their window contents directly, using hardware accelerated libraries like OpenGL ES, or high quality software implementations like Cairo. Wayland is ONLY a display server protocol, not a display server itself. Weston is the reference Wayland protocol implementation.   YOCTO Setup . $ mkdir ~/bin $ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH $ git config --global user.name "Your Name" $ git config --global user.email "Your Email" $ git config –list $ mkdir fsl-release-bsp $ cd fsl-release-bsp $ repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-3.14.52-1.1.0_ga $ repo sync     you will be able to build Yocto and also have all the recipes to do so, we need to add WAYLAND, then execute the following steps: $ DISTRO=fsl-imx-wayland MACHINE=imx6qsabresd source fsl-setup-release.sh -b build-wayland $ bitbake fsl-image-gui After these steps, you will have a wayland based i.MX6Q image where you will be able to play with all the knowledge we provided here.   Once your image has been properly generated, you will find the Weston source codes in: <YOUR YOCTODIR>/build-wayland/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/weston/1.9.0-r0/weston-1.9.0     Wayland application for extended desktop: This functionality is only supported using the GAL2D blitter, in order to enable a multiple desktop approach, you need to pass the following parameters to your weston command: /etc/init.d/weston stop echo 0 > /sys/class/graphics/fb4/blank weston --tty=1 --use-gal2d=1 --use-gl=0 --device=/dev/fb0,/dev/fb4 &     Xwayland: Wayland is a complete window system in itself, but even so, if we're migrating away from X, it makes sense to have a good backwards compatibility story. With a few changes, the Xorg server can be modified to use wayland input devices for input and forward either the root window or individual top-level windows as wayland surfaces.   DISTRO=fsl-imx-xwayland MACHINE=imx6qsabresd source ./fsl-setup-release.sh -b build-xwayland bitbake fsl-image-gui Once you have the image your Wayland/Weston image will be able to run X11 applications   Excepting X11 applications that use EGL, we don’t support that, if you plan to use EGL apps, please use the Wayland provided functions to create the buffer.   Application for rotation: Weston allows rotating windows with super-key + middle mouse button. As this works for Wayland clients only, you can run Xwayland in weston, run your X application on Xwayland, and rotate the Xwayland display. For another option: Create a file ~/.config/weston.ini with this content: [core] modules=xwayland.so shell=desktop-shell.so idle-time=0 [shell] background-color=0xff002244 locking=false # panel-location=none    [launcher] icon=/usr/share/icons/gnome/24x24/apps/utilities-terminal.png path=/usr/bin/weston-terminal [launcher] icon=/usr/share/icons/hicolor/48x48/apps/firefox.png path=/usr/bin/firefox [output] name=X1 mode=640x800 transform=90 # wanna get mad? use: transform=flipped-270 scale=1 This weston.ini enables a rootless xwayland.so in weston. The [output] section with name=X1 defines weston's appearance as X client. transform=90 rotates the weston display.   the [launcher] sections can be used to create custom panel starters for your X applications. See  /usr/share/doc/weston/examples/weston.ini for more detailed information for further cases, I will attach in the future.

This is a generic script which flashes a Linux System (U-boot, uImage and root filesystem) into a SD card. Steps:     1. Download the script into a Linux system     2. Make the script executable (chmod +x mk_mx_sd)     3. Run it with '-H' to know its usage.     4. Run the script with real parameters, specifying the paths for U-boot, uImage and the root filesystem as seen above     5. Plug the SD into your target, boot the board and change the corresponding U-boot variables $ IMAGE=/data/BSP/L2.6.35_11.09.01_ER/L2.6.35_11.09.01_ER_images_MX5X $ ./mk_mx_sd  -d /dev/sdc \                       -u $IMAGE/u-boot-mx53-loco.bin \                       -k $IMAGE/uImage \                       -r $IMAGE/rootfs     6. In case you only want to flash a single binary (like U-boot), just specify the U-boot parameter (-u)

In i.MX8MQ and i.MX8M Mini, the codec used is WM8524, which only supports audio playback. Although 8M Mini does have PDM microphone interface (MICFIL), there is no support for audio record via I2S. This guide will show you how to add audio recording driver in i.MX8MQ/8MM step by step.   Hardware: i.MX8MQ/8MM Evk, I2S output digital microphone OS: Android/Linux Kernel version: 4.14.78 For detailed steps, please see attachment.

Overview This purpose of this document is to introduce how to support recovery mode for POR reboot event based on MX6 Android R13.4.1. Background If you boot Android R13.4.1 on MX6 SabreSD board, the reboot reason is Watchdog. But if the reboot reason is changed from Watchdog to POR, the recovery mode is failed to enter after factory reset. In R13.4.1, the bit 8 of SRC_GPR10 is used as the persistent bit of recovery mode. This bit is expected to be kept after reboot so that U-boot can use this bit to distinguish what mode should enter. However all SRC registers will be reset on POR sequence according to i.MX6DQRM Section 59.4.1.2.3 IPP_RESET_B (POR). So when the reboot reason is POR, the persistent bit of recovery mode is cleared even if the software set it before reboot. It causes the bootloader won't enter recovery mode after reboot. Software Changes According to i.MX6DQRM, the SNVS_LP General Purpose Register provides a 32 bit read write register, which can be used by any application for retaining 32 bit data during a power-down mode. So to support recovery mode for POR event, the SNVS_LP register can be used to store the persistent bit of recovery mode. The following changes are reqiured to apply (See patches.tar.gz) Apply for Uboot patch bootable/bootloader/uboot-imx/0001-ENGR00235817-mx6-use-SNVS-LPGPR-register-to-store-bo.patch. diff --git a/cpu/arm_cortexa8/mx6/generic.c b/cpu/arm_cortexa8/mx6/generic.c index 257c930..bd47130 100644 --- a/cpu/arm_cortexa8/mx6/generic.c +++ b/cpu/arm_cortexa8/mx6/generic.c @@ -1146,14 +1146,14 @@ int check_and_clean_recovery_flag(void) {   int flag_set = 0;   u32 reg; - reg = readl(SRC_BASE_ADDR + SRC_GPR10); + reg = readl(SNVS_BASE_ADDR + SNVS_LPGPR);   flag_set = !!(reg & ANDROID_RECOVERY_BOOT);   /* clean it in case looping infinite here.... */   if (flag_set) {    reg &= ~ANDROID_RECOVERY_BOOT; -  writel(reg, SRC_BASE_ADDR + SRC_GPR10); +  writel(reg, SNVS_BASE_ADDR + SNVS_LPGPR);   }   return flag_set; @@ -1168,14 +1168,15 @@ int fastboot_check_and_clean_flag(void) {   int flag_set = 0;   u32 reg; - reg = readl(SRC_BASE_ADDR + SRC_GPR10); + + reg = readl(SNVS_BASE_ADDR + SNVS_LPGPR);   flag_set = !!(reg & ANDROID_FASTBOOT_BOOT);   /* clean it in case looping infinite here.... */   if (flag_set) {    reg &= ~ANDROID_FASTBOOT_BOOT; -  writel(reg, SRC_BASE_ADDR + SRC_GPR10); +  writel(reg, SNVS_BASE_ADDR + SNVS_LPGPR);   }   return flag_set; diff --git a/include/asm-arm/arch-mx6/mx6.h b/include/asm-arm/arch-mx6/mx6.h index efb90c2..45381e2 100644 --- a/include/asm-arm/arch-mx6/mx6.h +++ b/include/asm-arm/arch-mx6/mx6.h @@ -732,6 +732,8 @@ #define SRC_GPR9  0x40 #define SRC_GPR10  0x44 +#define SNVS_LPGPR              0x68 + /* Get Board ID */ #define board_is_rev(system_rev, rev) (((system_rev & 0x0F00) == rev) ? 1 : 0) #define chip_is_type(system_rev, rev) \ Apply for kernel patch kernel_imx/0001-ENGR00235817-mx6-use-SNVS-LPGPR-register-to-store-bo.patch diff --git a/arch/arm/mach-mx6/system.c b/arch/arm/mach-mx6/system.c index 6d24f22..61649c5 100644 --- a/arch/arm/mach-mx6/system.c +++ b/arch/arm/mach-mx6/system.c @@ -563,7 +563,7 @@ void mxc_clear_mfgmode(void) #endif #ifdef CONFIG_MXC_REBOOT_ANDROID_CMD -/* This function will set a bit on SRC_GPR10[7-8] bits to enter +/* This function will set a bit on SNVS_LPGPR[7-8] bits to enter   * special boot mode.  These bits will not clear by watchdog reset, so   * it can be checked by bootloader to choose enter different mode.*/ @@ -574,18 +574,18 @@ void do_switch_recovery(void) {   u32 reg; - reg = __raw_readl(SRC_BASE_ADDR + SRC_GPR10); + reg = __raw_readl(MX6Q_SNVS_BASE_ADDR + SNVS_LPGPR);   reg |= ANDROID_RECOVERY_BOOT; - __raw_writel(reg, SRC_BASE_ADDR + SRC_GPR10); + __raw_writel(reg, MX6Q_SNVS_BASE_ADDR + SNVS_LPGPR); } void do_switch_fastboot(void) {   u32 reg; - reg = __raw_readl(SRC_BASE_ADDR + SRC_GPR10); + reg = __raw_readl(MX6Q_SNVS_BASE_ADDR + SNVS_LPGPR);   reg |= ANDROID_FASTBOOT_BOOT; - __raw_writel(reg, SRC_BASE_ADDR + SRC_GPR10); + __raw_writel(reg, MX6Q_SNVS_BASE_ADDR + SNVS_LPGPR); } #endif diff --git a/arch/arm/plat-mxc/include/mach/mx6.h b/arch/arm/plat-mxc/include/mach/mx6.h index 48b04b1..bb22de0 100644 --- a/arch/arm/plat-mxc/include/mach/mx6.h +++ b/arch/arm/plat-mxc/include/mach/mx6.h @@ -302,6 +302,8 @@ #define SRC_GPR9   0x40 #define SRC_GPR10   0x44 +#define SNVS_LPGPR   0x68 + /* GPC offsets */ #define MXC_GPC_CNTR_OFFSET  0x0

On i.MX8MP EVK, image is downloaded into eMMC/SD via OTG1, if customer wants to enable USB OTG2 on i.MX8MP for uuu tool. Pls find modification as attached.

HW: i.MX7 SabreSD SW: Android N7.1.1_1.0.0   There is KPP module on i.MX7, but NXP reference board didn't have it. We reworked a "keypad" and has the demo. Signal: For testing, launch an app in Android that can accept text input. KPP also supports multiple input, the "A" is showed by pressing "shift" + "a".   As a side note, 1. The input device driver is drivers/input/keyboard/imx_keypad.c 2. The input event driver is drivers/tty/vt/keyboard.c Original Attachment has been moved to: 0001-Enable-KPP-on-i.MX7.patch.zip

The Compatibility Test Suite Verifier is a supplement to the Compatibility Test Suite. The main difference lies in that the verifier is developed for tests that cannot run on their own so they require user input in order to be tested. These tests would include the audio quality, the touchscreen, accelerometer, camera, etc. There is no “best verifier option”, one CTS complements the other. In this document we will focus on how to perform the Verifier test. Requirements: A PC with the Android SDK installed. Your “Device Under Test” (your development board) Optional >> A second android device with compatible Wifi and Bluetooth Setup Steps: Install de Android SDK on your PC Download the appropriate CTS Verifier APK. The list of APK’s can be found here: https://source.android.com/compatibility/downloads.html Make sure that your Device Under Test has its system date and time set correctly. Install the CTS Verifier APK on the Device Under Test* For more information regarding ADB commands, follow this link: https://community.freescale.com/docs/DOC-102514 Initialization: After the setup is done, you should see the application installed: You will see the list of available tests for manual verification: Video Link : 4502 For each test, you will see detailed instructions to run it, and a “pass” and “fail” buttons. Video Link : 4530 Once you run each test, you will have the posibility to choose the outcome. (in some cases, pass/fail outcome will be determined automatically). The list of tests (for CTS Verifier 5.1_r2) is: Camera: FOV Calibration, Formats, ITS, Intents, Orientation, Video. Car: Car Dock Test Clock: Alarms and Timers Test Device Administration: Policy serialization test, screen lock test. Features: Hardware/Software feature summary Hardware: USB Accessory Test Job Scheduler: Charging constraints, connectivity constraints, idle mode constraints. Location: Battery saving mode test, location mode off test Managed provisioning: BYOD managed provisioning, device owner provisioning Networking: Bluetooth test, Wi-Fi direct test Notifications: CA Cert notification, CA Cert notificacion on boot, notification attention management, notification listener, notificacion package priority Other: Data backup, screen pinning, widget framework Projection: Projection cube, projection multitouch, projection offscreen, projection scrolling, projection video playback, projection widget Security: Keyguard password verification, SUID file scanner. Sensors: Accelerometer mearument, CTS Sensor batching, CTS Sensor integration, CTS sensor test, CTS single sensor test, magnetic field measurement, sensor batching. Streaming: Streaming video quality verifier. Exporting test results: Tap the “save disk” icon. A pop-up will show the path of the report that was created. Video Link : 4531 With the board connected to the PC through USB, pull the report using ADB: To download all reports run : adb pull /mnt/sdcard/ctsVerifierReports/ .

This document is aimed to introduce seamless switch on rear view camera function in android P9 auto, and this can also be referenced for sharing dpu(display process unit) between A core and m4 core on imx8qxp/qm platform. OS: Android p9 auto beta. (linux needs some modifies). SDK_2.5.1_MEK-MIMX8QX for m4 core. Hardware platform: imx8qxp/qm mek board IT6263 lvds to hdmi cable. max9286 deserializer board. ov16035 camera. Hardware block：     Imx8qxp dpu block, for imx8qm there are two dpus:     Android/Linux and M4 shared dpu path:     The switch function is done by framegen0 unit in dpu, framegen unit can select 7 modes: primary src only second src only primary on second second on primary .....etc. for more details, please refer to the kernel codes at include/video/dpu.h, fgdm_t type. Seamless switch booting flow: Patches contain three main parts: Linux kernel: remove init or configure codes of dpu units and lvds used by m4 core, add ui ready rpmsg pipe. M4 code: modify dpu pipes, add ui ready rpmsg handle. AOSP init.rc scripts: add sending ui ready message scripts.

Introduction This is a brief guide showing how to integrate the driver for the WF111 module to the i.MX6 BSP Release. In this case the WF111 driver is available on a repository and it’s in accordance with the Yocto Project, which allows to easily customize a linux distribution for your board. Requirements WF111 Documentation – Silicon Labs have made a great job of documenting the steps to add the WF111 driver to a Linux distribution and have created Application Note 996 (link below), which we will use as reference. http://www.silabs.com/documents/login/application-notes/AN996.pdf WF111 Driver - We will also be using the Yocto layer included on the following repository: https://github.com/engicam-stable/meta-engicam i.MX6 3.14.52 BSP Release – In out scenario the WF111 layer that will be imported includes a driver that it’s compatible with Linux Kernel 2.6.24 up to 4.1., which it’s important to keep in mind.   Installing the 3.14.52 BSP Release First, setup the 3.14.52 BSP as described on the i.MX Yocto Project User’s Guide.   Adding the WF111 Driver Layer Clone the WF111 Driver Layer to your sources folder inside the BSP Release directory. Since the 3.14.52 BSP Release is based on Fido we will clone the Fido branch of the driver repository. $ cd <BSP_RELEASE_DIR>/sources $ git clone https://github.com/engicam-stable/meta-engicam -b fido‍‍  Once the layer is cloned you would need to add the new later editing the bblayers.conf file located the following path: <BSP_RELEASE_DIR>/<BUILD_DIR>/conf/bblayers.conf By adding the following line to add the new layer.   BBLAYERS += " ${BSPDIR}/sources/meta-engicam "‍   This should make the wf111-driver available through bitbake since bitbake will now look into this layer for all available recipes. You can then add the driver to your image by adding the following line to the <BUILD_DIR>/conf/local.conf   IMAGE_INSTALL_append += "wf111-driver"‍ Or you may create a new image recipe that includes the wf111-driver package. However, there are certain kernel options that must be enabled for the driver to work.   Creating an append to configure the kernel options Before we can bake an image with the WF111 driver we would need to edit the kernel options as mentioned on Silabs AN996. The following kernel options must be enabled:   CONFIG_WIRELESS_EXT CONFIG_MODULES CONFIG_FW_LOADER We would need to add the CONFIG_WIRELESS_EXT as the other two options are enabled on the BSP by default.   This involves adding an addendum to the kernel recipe to change its configuration. You may either add this append to any layer. The best way to handle it would be using a new layer for all your customization. You can find how to create a new layer on the following document: https://community.nxp.com/docs/DOC-331917 We’ll use a new layer called meta-newlayer for this example. It’s important that this layer has a high priority so the changes from the bbappend are not overridden. The following alternative was suggested by Chris Hossack on the following thread: https://community.nxp.com/thread/376369 First, run the menuconfig tool on the bitbake environment: bitbake linux-imx -c menuconfig Enable the necessary options: Networking Support > Wireless > cfg80211 wireless extensions compatibility   Save the configuration and exit. Then run the following bitbake command, which will create a config fragment file that contains the changed made to the default kernel options. bitbake linux-imx -c diffconfig We’ll make an append file that adds the required options.  Content of the config fragment:   CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_SPY=y CONFIG_WEXT_PRIV=y CONFIG_CFG80211_WEXT=y CONFIG_LIB80211=y CONFIG_LIB80211_CRYPT_WEP=y CONFIG_LIB80211_CRYPT_CCMP=y CONFIG_LIB80211_CRYPT_TKIP=y # CONFIG_LIB80211_DEBUG is not set CONFIG_HOSTAP=y # CONFIG_HOSTAP_FIRMWARE is not set‍‍‍‍‍‍‍‍‍‍‍‍‍    Since we are appending the kernel layer we need to add the addendum on the same path as that of the original kernel recipe but within our layer and create the append file there. Also add the WF111.cfg file to the linux-imx directory:   We would need to copy (and you may rename it as well) to the folder where are will be creating the append recipe for the kernel. Copy:  <BSP_RELEASE>/<BUILD_DIR>/tmp/work/<MACHINE>-poky-Linux-gnueabi/linux-imx/<KERNEL_VERSION>/fragment.cfg To: <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx/WF111.cfg You can do so suing the following command: cp <BSP_RELEASE>/<BUILD_DIR>/tmp/work/<MACHINE>-poky-Linux-gnueabi/linux-imx/<KERNEL_VERSION>/fragment.cfg <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx/WF111.cfg‍ (Please note that the file was renamed for ease, but you may use any name for the config fragment)   We need to create the bbappend file on the following path (as it must be the same relative path as the original recipe it is appending) <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx_3.14.52.bbappend   The linux-imx_3.14.52.bbappend file would contain the following:   SRC_URI += "file://WF111.cfg"  do_configure_append() {          #this is run from         #./tmp/work/<MACHINE>-poky-linux-gnueabi/linux-imx/3.14.52-r0/git          cat ../*.cfg >> ${B}/.config  }‍‍‍‍‍‍    After creating this recipe you should be able to bake any image from the BSP and see the driver there. I tested with the core-minimal-image and found that the files were indeed added to /lib/firmware. $ bitbake core-image-minimal ‍‍‍

Introduction The NFC Reader Library is a feature complete software support library for NXP's NFC Frontend ICs. It is designed to give developers a faster and simpler way to deliver NFC-enabled products. This multi-layer library, written in C, makes it easy to create NFC based applications. The purpose of this document is to provide instructions on how to install the NFC Reader Library on imx7dsabresd and communicate with PN5180, a NFC frontend. It will describe all the steps required to connect the board to an OM25180TWR, the wire connections, the changes in the device tree, and the library configuration. Building the Linux image and the Bal kernel module This section describes how to build the Linux image using Yocto and how to compile the Bal kernel module. Informations specific for this library start from the next section. Requirements: a Linux host PC (ex. Ubuntu 14.04/16.04) and root permissions. To download the required host packages, use: $ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath socat libsdl1.2-dev Specific for Ubuntu: $ 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 To setup the repo utility (a tool written on top of git), run the commands: $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo Then add the following line to .bashrc to ensure the ~/bin is in the PATH variable. export PATH=~/bin:$PATH To download the Freescale Yocto Project Community BSP: $ mkdir fsl-release-bsp $ cd fsl-release-bsp $ repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-4.1-krogoth $ repo sync To build the image, in the fsl-release-bsp run the commands: $ mkdir buildDevSpi $ DISTRO=fsl-imx-xwayland MACHINE=imx7dsabresd source fsl-setup-release.sh -b buildDevSpi $ bitbake fsl-image-machine-test To build the toolchain, run: $ bitbake meta-toolchain $ cd buildDevSpi/tmp/deploy/sdk/ $ ./fsl-imx-xwayland-glibc-x86_64-meta-toolchain-cortexa7hf-neon-toolchain-4.1.15-2.1.0.sh Accept the default parameters. In order to deploy the image on an SD card use: $ sudo dd if=fsl-image-machine-test-imx7dsabresd.sdcard of=<sd card> bs=1M && sync The image is found in buildDevSpi/tmp/deploy/images/imx7dsabresd. For the kernel module compilation, setup the console environment: $ . /opt/fsl-imx-xwayland/4.1.14-2.1.0/environment-setup-cortexa7hf-neon-poky-linux-gnueabi Then, in the kernel module directory, replace the path with your linux build directory in the Makefile and run: $ make The bal.ko is the compiled module. To use the kernel menuconfig, run: $ bitbake -c menuconfig linux-imx Another useful command, for rebuilding the linux kernel image, is: $ bitbake -f -c compile linux-imx; bitbake -f -c deploy linux-imx; bitbake -f -c compile fsl-image-machine-test; bitbake -f fsl-image-machine-test Host interface The interface of the PN5180 to a host is based on a SPI interface, extended by the signal line BUSY. Only half-duplex data transfer is supported and no chaining is allowed, meaning that the whole instruction has to be sent, or the whole receiver buffer has to be read out. The module is connected to the i.MX7D board using the mikro bus expansion port in the following way: MK_BUS_CS, MK_BUS_SCK, MK_BUS_MOSI, MK_BUS_MISO are used for the SPI bus lines. MK_BUS_INT, MK_BUS_RX, MK_BUS_TX are used for the BUSY, RESET and IRQ lines. The pin configuration will be the following: GPIO6_IO22 will be the CS, GPIO6_IO14 will be BUSY, GPIO_IO12 will be RESET and GPIO_IO13 will be IRQ. The DWL pin, which can be used for firmware update, will be connected to GND. A common ground is also required. Connections table: Jumper Jumper Pins Description i.MX7D I/O Tower Edge J4 1 - 2 SPI Clk Selection ECSPI3_SCLK (SAI2_RX_DATA) B7 J20 1 - 2 PN5180 Reset GPIO6_IO12 (SAI1_RX_DATA) B8 J1 1 - 2 SPI SS0 GPIO6_IO22 (SAI2_TX_DATA) B9 J3 1 - 2 SPI MOSI ECSPI3_MOSI (SAI2_TX_BCLK) B10 J2 1 - 2 SPI MISO ECSPI3_MISO (SAI2_TX_SYNC) B11 J19 2 - 3 PN5180 BUSY GPIO6_IO14 (SAI1_TX_SYNC) B58 J5 1 - 2 PN5180 IRQ GPIO6_IO13 (SAI1_TX_BCLK) B62 X X PN5180 DWL GND B52 X X GND GND B2 Kernel Configuration In order to allow the library to manage the RESET, IRQ and BUSY pins, the options for Debug GPIO and Userspace I/O drivers must be enabled (in menuconfig, Device Drivers -> GPIO Support -> Debug GPIO and Device Drivers -> Userspace I/O -> Userspace I/O platform driver with generic IRQ). For controlling the SPI, there are two options: spidev or NXP bal. For spidev, it is necessary to select Device Drivers -> SPI support -> User mode SPI and apply the imx7d-sdb_spidev.patch (it also does the pinmuxing, it is attached to the document). When using NXP bal, it is necessary to compile the module, initialize it with insmod and apply the imx7d-sdb_bal.patch (it also does the pinmuxing, the patch and the module are attached to this document). Library Configuration For the library configuration, <lib-folder>/Platform/DAL/Board_Imx6ulevkPn5180.h must be replaced with Board_Imx7dsabresdPn5180_bal.h or Board_Imx7dsabresdPn5180_spidev.h (based on the selected spi interface). For compilation, the command is: $ ./build.sh yocto /opt/fsl-imx-xwayland/4.1.15-2.1.0/sysroots/ The last parameter is the location of the toolchain generated by yocto. A build folder is generated outside of the source code folder. The applications from the ComplianceApp can be deployed on the board in order to test the functionality provided. Other useful resources: – i.MX Yocto Project User's Guide: https://www.nxp.com/webapp/sps/download/preDownload.jsp?render=true – NFC Reader Library for Linux Installation: https://www.nxp.com/docs/en/application-note/AN11802.pdf – PN5180 component: https://www.nxp.com/docs/en/data-sheet/PN5180A0XX-C1-C2.pdf

Some of Chinese customer couldn’t normally download android source code from google site, here give a way to download android source from Mirror site of Tsinghua University. Preparations 1. Installing Ubuntu16.04.2 LTS Customer can download ubuntu-16.04.2-desktop-amd64.iso from https://www.ubuntu.com/download/desktop Then install it to VMware workstation player v12 or PC, after finishing installation, use “Software Update” to update system. In order to compile android9.0.0-2.0.0 BSP, necessary packages should also be installed on Ubuntu 16.04. $ sudo apt-get install gnupg $ sudo apt-get install flex $ sudo apt-get install bison $ sudo apt-get install gperf $ sudo apt-get install build-essential $ sudo apt-get install zip $ sudo apt-get install zlib1g-dev $ sudo apt-get install libc6-dev $ sudo apt-get install lib32ncurses5-dev $ sudo apt-get install x11proto-core-dev $ sudo apt-get install libx11-dev $ sudo apt-get install lib32z1-dev $ sudo apt-get install libgl1-mesa-dev $ sudo apt-get install tofrodos $ sudo apt-get install python-markdown $ sudo apt-get install libxml2-utils $ sudo apt-get install xsltproc $ sudo apt-get install uuid-dev:i386 liblzo2-dev:i386 $ sudo apt-get install gcc-multilib g++-multilib $ sudo apt-get install subversion $ sudo apt-get install openssh-server openssh-client $ sudo apt-get install uuid uuid-dev $ sudo apt-get install zlib1g-dev liblz-dev $ sudo apt-get install liblzo2-2 liblzo2-dev $ sudo apt-get install lzop $ sudo apt-get install git-core curl $ sudo apt-get install u-boot-tools $ sudo apt-get install mtd-utils $ sudo apt-get install android-tools-fsutils $ sudo apt-get install openjdk-8-jdk $ sudo apt-get install device-tree-compiler $ sudo apt-get install gdisk $ sudo apt-get install liblz4-tool $ sudo apt-get install m4 $ sudo apt-get install libz-dev More detail, see Android_User’s_Guide.pdf ( android 9.0.0-2.0.0 BSP documents) 2. Downloading and unpacking Android release package [ For android 9.0.0_2.2.0, see commemts, please!] https://www.nxp.com/support/developer-resources/evaluation-and-developmentboards/ sabre-development-system/android-os-for-i.mx-applicationsprocessors: IMXANDROID?tab=Design_Tools_Tab -- P9.0.0_2.0.0_GA_ANDROID_SOURCE File name is imx-p9.0.0_2.0.0-ga.tar.gz # cd ~ # tar xzvf imx-p9.0.0_2.0.0-ga.tar.gz Downloading Android 9.0.0-2.0.0 source code 1. Getting repo # cd ~ # mkdir bin # cd bin # curl https://mirrors.tuna.tsinghua.edu.cn/git/git-repo > ~/bin/repo # chmod a+x ~/bin/repo # export PATH=${PATH}:~/bin 2. Modifying repo File Open ~/bin/repo file with 'gedit' and Change google address From REPO_URL = 'https://gerrit.googlesource.com/git-repo' To REPO_URL = ' https://mirrors.tuna.tsinghua.edu.cn/git/git-repo/ ' 3、Setting email address # git config --global user.email "[email protected]" # git config --global user.name "xxxx" [ Email & Name should be yours] 4、Modifying android setup script and Running it Open ~/imx-p9.0.0_2.0.0-ga/imx_android_setup.sh and add a line like below: ... ... if [ "$rc" != 0 ]; then echo "---------------------------------------------------" echo "-----Repo Init failure" echo "---------------------------------------------------" return 1 fi find -name 'aosp-p9.0.0_2.0.0-ga.xml'| \ xargs perl -pi -e 's|https://android.googlesource.com/|https://aosp.tuna.tsinghua.edu.cn/|g' fi ... ... Then save it and exit. # cd ~/ # source ~/imx-p9.0.0_2.0.0-ga/imx_android_setup.sh Then android_build directory is created at ~/ If fetching errors occur, like below, run “repo sync” again. # repo sync # export MY_ANDROID=~/android_build [Note] imx_android_setup.sh will be in charge of downloading all android source code. 5.Begin to compile android 9.0.0-2.0.0 BSP $ export ARCH=arm64 $ export CROSS_COMPILE=${MY_ANDROID}/prebuilts/gcc/linuxx86/aarch64/aarch64-linuxandroid-4.9/bin/aarch64-linux-android- $ cd ~/android_build/vendor $ cp -r ~/imx-p9.0.0_2.0.0-ga/vendor/* ./ $ cd ~/android_build $ source build/envsetup.sh $ lunch evk_8mm-userdebug $ make –j4 NXP TIC team Weidong sun 2019-05-05

This article introduces how to connect a device via Bluetooth to the i.MX8M family of boards.

Question: Using Linux SDK 4.1.0, with CAAM drivers enabled, there is little noticeable difference in the performance of openssd compared to a kernel without the CAAM drivers. Tests were done using openssd. Test image AES-128 8192 byte block (M Bytes/sec) “openssl speed –evp aes-128-cbc” AES-128 8192 byte block (M Bytes/sec) With /dev/crypto “openssl speed –evp aes-128-cbc -engine cryptodev”  Ubuntu 11.04 Image 19.010 N/A Timesys 20.518 N/A SDK 4.1.0 LTIB 22.013 21.984 (errors reported) One can see that with SDK 4.1.0, performance is worse with crypto enabled.  This is probably due to the overhead of a faulty driver or incorrect implementation. The lowest number is for Ubuntu which could be attributed to the Unity GUI. Conclusion:  CAAM driver is not functional or I am using an improper testing procedure. Test Procedure: Board used is iMX6Q Sabre SDP Openssl was used for testing. Two command line commands were used, with and without the cryptodev engine. openssl speed –evp aes-128-cbc openssl speed –evp aes-128-cbc -engine cryptodev Openssl versions used in each build are slightly different: Ubuntu:              openssl 1.0.0e Timesys:              openssl  1.0.1e SDK 4.1.0:            openssl  1.0.1c Three versions of Linux were tested. Default kernel  4.0.0 with Ubuntu rootfs form image tarballs. Timesys kernel and root file system Kernel built with SDK 4.1.0 using LTIB with hardware crypto enabled Both 1 and 2 above did not have CRYPTODEV set in .config which contains the line “# CONFIG_CRYPTO_CRYPTODEV is not set” Option 3 had the line in .config as, “CONFIG_CRYPTO_CRYPTODEV=y” All three builds generate “/proc/crypto”  whose contents are attached.  A partial listing of /proc/crypto lists “caam” as a driver for all encryption methods supported.  Example printout for aes shown below: ame         : cbc(aes) driver       : cbc-aes-caam module       : kernel priority     : 3000 refcnt       : 1 selftest     : passed type         : ablkcipher async        : yes blocksize    : 16 min keysize  : 16 max keysize  : 32 ivsize       : 16 geniv        : eseqiv All three builds have “caam” and “enable_wait_mode=off” in the kernel command line in u-boot. Only option #3 contains both device file in “/dev/crypto” and an entry in “/proc/crypto” root@freescale ~$ cd / root@freescale /$ ls /proc/cr* /proc/crypto root@freescale /$ ls /dev/cr* /dev/crypto root@freescale /$ Test #1—Kernel build 4.1.0 openssl speed test without caam engine root@freescale ~$ openssl speed -evp aes-128-cbc                    Doing aes-128-cbc for 3s on 16 size blocks: 3471184 aes-128-cbc's in 2.94s Doing aes-128-cbc for 3s on 64 size blocks: 986286 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 249743 aes-128-cbc's in 2.93s Doing aes-128-cbc for 3s on 1024 size blocks: 64343 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 7954 aes-128-cbc's in 2.96s OpenSSL 1.0.1c 10 May 2012 built on: Sat Sep 7 18:47:34 PDT 2013 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall The 'numbers' are in 1000s of bytes per second processed. type 16 bytes     64 bytes    256 bytes 1024 bytes   8192 bytes aes-128-cbc 18890.80k    21040.77k    21820.55k 21962.41k    22013.23k root@freescale ~$ Test #2—Timesys kernel build of openssd without /dev/crypto # openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 3361305 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 924423 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 236623 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 59967 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 7514 aes-128-cbc's in 3.00s OpenSSL 1.0.1e 11 Feb 2013 built on: Thu Sep 5 21:54:37 EDT 2013 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: armv7l-timesys-linux-gnueabi-gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -I/here/workdir/factory/build_armv7l-times ys-linux-gnueabi/toolchain/usr/include -DL_ENDIAN -DTERMIO -DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -Os -pipe -Wa,--noexecstack -Wall The 'numbers' are in 1000s of bytes per second processed. type 16 bytes     64 bytes    256 bytes 1024 bytes   8192 bytes aes-128-cbc 17926.96k    19721.02k    20191.83k 20468.74k    20518.23k #  Test #3—Ubuntu rootfs and kernel image root@linaro-ubuntu-desktop:/# openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 3030128 aes-128-cbc's in 2.98s Doing aes-128-cbc for 3s on 64 size blocks: 852897 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 220572 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 55534 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 6846 aes-128-cbc's in 2.95s OpenSSL 1.0.0e 6 Sep 2011 built on: Wed Oct 5 01:45:02 UTC 2011 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -Wa,--noexecstack -g -Wall The 'numbers' are in 1000s of bytes per second processed. type             16 bytes     64 bytes 256 bytes   1024 bytes   8192 bytes aes-128-cbc 16269.14k    18195.14k    18822.14k 18955.61k    19010.99k root@linaro-ubuntu-desktop:/# Test #4—SDK 4.1.0 openssl speed test with “/dev/crypto” .  Note errors. root@freescale ~$ openssl speed -evp aes-128-cbc -engine cryptodev  invalid engine "cryptodev" 716715216:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(/usr/lib/engines/libcryptodev.so): /usr/lib/eng ines/libcryptodev.so: cannot open shared object file: No such file or directory 716715216:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244: 716715216:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450: 716715216:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:417:id=cryptodev 716715216:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(libcryptodev.so): libcryptodev.so: cannot open shared object file: No such file or directory 716715216:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244: 716715216:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450: Doing aes-128-cbc for 3s on 16 size blocks: 3572980 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 966002 aes-128-cbc's in 2.94s Doing aes-128-cbc for 3s on 256 size blocks: 255307 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 62967 aes-128-cbc's in 2.93s Doing aes-128-cbc for 3s on 8192 size blocks: 7890 aes-128-cbc's in 2.94s OpenSSL 1.0.1c 10 May 2012 built on: Sat Sep 7 18:47:34 PDT 2013 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall The 'numbers' are in 1000s of bytes per second processed. type 16 bytes     64 bytes    256 bytes 1024 bytes   8192 bytes aes-128-cbc 19055.89k    21028.61k    21786.20k 22006.21k    21984.65k root@freescale ~$ Answer: I do not know what is recent state of official Freescale BSP regarding CAAM, but to get OpenSSL working under CAAM support with reasonable acceleration  : https://community.freescale.com/message/318188#318188 The patches was used below : http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_3.0.35_4.0.0 Direct link to the patches: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.0.35_4.0.0&id=6068d7a77b2101c172fc2f003f90b1febbf99505 http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.0.35_4.0.0&id=b30237c79003223c6e8035d5be183cd4f0b469f9

         In recent months, some I.MX customers hope to compile u-boot-fw-utils in yocto and get fw_printenv & fw_setenv tools.          Although there are u-boot-fw-utils bblayers in Yocto recipes, by default, u-boot-fw-utils is not based on u-boot-imx, but downloaded from the u-boot source website, when using bitbake When u-boot-fw-utils compiles it, it will fail to compile.          For example: # cd  ~/imx-yocto-bsp-5.4.3_1.0.0 # DISTRO=fsl-imx-fb MACHINE=imx6sxsabresd source imx-setup-release.sh -b build_sabresd # bitbake u-boot-fw-utils -c compile          If changing .config to be mx6sxsabresd_optee_defconfig in the top directory of u-boot source code, new errors will occur, like descriptions in the link:          https://community.nxp.com/message/1318081?commentID=1318081#comment-1318081            The root cause is that the u-boot is not u-boot-imx.          If we did the test below, it is easy to validate it.      Compiling u-boot # bitbake u-boot-imx -c compile          After compilation is done, u-boot-imx source code will be released .      Changing u-boot source code of u-boot-fw-utils directory          Replace u-boot source code in u-boot-fw-utils directory with u-boot-imx source code. Then continue to compile u-boot-fw-utils # bitbake u-boot-fw-utils -c compile          We will find it can be compiled successfully. This shows that when u-boot-fw-utils is compiled, the downloaded u-boot source code must be u-boot-imx.          In order to achieve this, we need to add recipes to yocto's u-boot-imx, and we can successfully compile fw_printevn and fw_setenv through the bitbake command. Please follow these steps to add u-boot-fw-utils for i.mx to yocto! copy 2 files in attacments to ~/imx-yocto-bsp-5.4.3_1.0.0/sources/meta-imx/meta-bsp/recipes-bsp/u-boot cd ~/imx-yocto-bsp-5.4.3_1.0.0 run below comands # DISTRO=fsl-imx-fb MACHINE=imx6sxsabresd source imx-setup-release.sh -b build_sabresd # bitbake u-boot-imx-fw-utils -c compile # bitbake u-boot-imx-fw-utils -c install   Then you will get fw_printenv & fw_setenv [Comment]          If i.MX users are using other version of linux BSP, she only need to modify the following content of u-boot-imx-common_2019.04.inc to compile u-boot-fw-utils. …… LIC_FILES_CHKSUM = "file://Licenses/gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263"   UBOOT_SRC ?= "git://source.codeaurora.org/external/imx/uboot-imx.git;protocol=https" SRCBRANCH = "lf-5.4.y_v2019.04" SRC_URI = "${UBOOT_SRC};branch=${SRCBRANCH} \ " SRCREV = "228843cdf5435d4bd69f42a6015f78761ff4cc0d" ……          Then compile it following above steps.          Example for L4.14.98_2.0.0: 1.Copy u-boot-imx-common_2019.04.inc & u-boot-imx-fw-utils_2019.04.bb to ~/imx-release-bsp-4.14.98-2.0.0/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-bsp/u-boot/ 2.Rename files name according to u-boot version u-boot-imx-common_2018.03.inc     u-boot-imx-fw-utils_2018.03.bb 3.Modifying u-boot-imx-common_2018.03.inc In the directory, there is u-boot-imx_2018.03.bb file, open it, and find the link of u-boot and check sum, and use lines below to replace those lines in u-boot-imx-common_2018.03.inc In u-boot-imx_2018.03.bb file: …… LICENSE = "GPLv2+" LIC_FILES_CHKSUM = "file://Licenses/gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263"   UBOOT_SRC ?= "git://source.codeaurora.org/external/imx/uboot-imx.git;protocol=https" SRCBRANCH = "imx_v2018.03_4.14.98_2.0.0_ga" SRC_URI = "${UBOOT_SRC};branch=${SRCBRANCH}" SRCREV = "87a19df5e462f1f63e8a6d2973c7fb9e95284d04" …… Then in u-boot-imx-common_2018.03.inc, there is the same contents as above: Save it and exit. Go back to the top directory of yocto: ~/imx-release-bsp-4.14.98-2.0.0 # cd ~/imx-release-bsp-4.14.98-2.0.0 # DISTRO=fsl-imx-fb MACHINE=imx6sxsabresd source fsl-setup-release.sh -b build_sabresd # bitbake u-boot-imx-fw-utils -c compile # bitbake u-boot-imx-fw-utils -c install          The same method can be used for other Linux BSP versions.       NXP TIC Team Weidong Sun 05/28/2020

In order to run the QT5 demos on i.MX6 you should follow the instructions on this link: Building QT for i.MX6 Some of the demos on the release such as  /examples/opengl/hellogl_es2,  consist of a group of multiple widgets appearing on the screen. Normally these demos should work OK in a windowed environment such as Wayland or X11. In the case of Linux only environment, the plugin that draws to the screen is called EGLFS. This plugin has the restriction that it only supports one single widget at a time on the screen surface. Then demos such as hellogl_es2 are *not intended* to work along with this plugin, and it will never work. The errors found when using EGLFS consist on: These issues can be seen in the Qt OpenGL examples.  "hellogl_es2" and "2dpaint" seem to display one rendered frame and then break --   "hellogl_es2" shows the QT word and bubbles, and the GUI is hidden, while  "2dpaint" just shows the openGL version without label. It seems that when including  a QGLWidget on a form, the QGLWidget would work OK, but the rest of the form would not appear. I couldn't click any buttons or do anything.   Along with these problems I would also see one or more of these error messages in the output:   * This plugin does not support setParent!   * This plugin does not support propagateSizeHints()   * QOpenGLContext::swapBuffers() called with non-opengl surface However other demos such as hellowindow work well with EGLFS because they are single widget.  Also all demos created with qtquick will work OK since all visual QML items are rendered as a single widget using the scene graph, a low-level, high-performance rendering stack, closely tied to OpenGL. This is better explained here: Qt5 QPainter vs. QML &amp; Scene Graph.